Problems mixing SignalEvent and object scripts?

Neverwinter Nights 1 Toolset, Scripting, NWNX
1

NWN1 Platinum/Diamond, plus CEP, in single-player mode.

I have some placeables that interact, and I’ve been trying to use user-defined events to have them communicate. Two examples:

  1. Secret doors (placeables): when one is opened, the matching one is opened as well. (Or closed.)
  2. A door and a lever. When the lever is toggled, the door should open and close accordingly. And contrariwise; when the door opens or closes, the lever should be moved to match.
  3. A secret door that can be opened, used, or closed – rather than just opened (once) or used.

So I have a single script for OnUserDefined that knows how to do these things, run the appropriate animations, and set the appropriate variables.

When I had unique scripts for each of the items and hard-coded the related tags, it worked fine. My first foray into trying to do it with signals works thus:

  1. A test secret door placeable (with no matching other end) has a unique OnUsed script. If the door is closed, the script calls SignalEvent(OBJECT_SELF) to open the door. The UDE handler plays the appropriate animation. If the door is already open, ActionStartConversation() is called so the player has a choice between using the door and closing it.

All of the changes made to the door are done through its action queue, with Action* and AssignCommand() calls.

What happens, however, is that when the door is opened through the UDE handler, either from the OnUsed script (by clicking on the door) or signaled from a lever, the visual is of the door opening and then quivering. Nor does clicking on the door do anything once it’s open (which is when the OnUsed script calls ActionStartConversation() – and it does get called, I’ve checked), although the open/close signals sent by toggling the lever work, and the door can be re-closed that way.

{Ramble, ramble; it’s late, I’m sorry}

The first thing that came to mind was some sort of threading conflict, such as immediate versus queued actions. E.g., the UDE handler script was still blocking other actions. I think I’ve ruled that out by putting everything into the placeable’s action queue. Also, if the placeable had been set uncommandable somehow, the lever wouldn’t be able to cause it to change state by sending it an event.

Is there some sort of interaction I’m missing? Some list of things that shouldn’t be done in OnUserDefined scripts in conjunction with others? I’ve instrumented the crap out of the scripts to log client messages, and I can’t figure it out. Everything looks like it’s working – but once the door-open animation is played, the door’s OnUsed script can’t be invoked.

Thanks for any ideas!

2

Some remarks on the issue.

  1. Playing animation doesn’t fire relevant event script. Ie. playing open animation on a regular door will not cause the door to execute OnOpen event script. Something to consider.
  2. There is no need to use SignalEvent, you can just open/close connected doors from the OnUse script directly.
  3. I saw the quiver issue to happen on placeable doors. Don’t recall if they were usable or not afterwards, but this is some model or engine issue you can’t influence with scripts.
  4. Why reinventing the wheel? NWN has a script for handling secret doors already and it works (albeit I use version from community patch which is slightly changed).
  5. Placeable doors tends to animate with huge delay in larger modules. EE was supposed to fix this, but iirc there was still small delay even under EE. Might be fixed now though, this experience is from 2 year old patch.
2 Likes
3

I agree that there is no need to use SignalEvent. If you do it that way you need more scripts than necessary.

4

If the tag of the lever is in a variable on the door and vice-versa, you can have the same script on both objects, that toggles the lever or the door as appropriate.

Then you can use that same script for every pair of objects in the module.

2 Likes
5

Meh, I found a solution. Just adding another branch to the conversation, one that should never be reached, made everything work correctly.

@Shadooow:

  1. I realise the animation is distinct from the other mechanics of making something happen. It is, after all, just the visual.
  2. I simplified my various use cases. Interactions involved are often more complex than described.
  3. The quiver seems to have gone away when the conversation got foxed.
  4. NWN1’s secret door mechanism doesn’t provide for closing secret doors once they’ve been opened. Being able to close them is crucial in this case. Plus, I’ll probably be using the HoTU mechanism.
  5. This module isn’t going to be particularly large, but I’ll keep an eye out for that. Thanks!

@Zwerkules: So far my experience is that abstracting out the animations+actions into UDEs is no more complex than scripting it otherwise, but I’ll keep an eye out for comparisons.

@Proleric: The objects aren’t always in pairs. Sometimes there are multiple objects involved. :neutral_face:

Thanks for the replies and suggestions!