interruptability

[fuzzie]

How does interruption work? I consider only Baldur's Gate 2 here, for now.

 

There seem to be two interruption flags associated with each object; the SetInterrupt one and a per-action one. Both seem fairly simple:

 

The SetInterrupt one appears to be reset when a new script is executed, and defaults to FALSE (cannot interrupt) for most objects but TRUE (can interrupt) for actors. It's stored in some bit of flags for actors (I think there's another thread that documents this) and somewhere else for normal objects.

 

The per-action one seems to be set every time an action runs, and an action can block in such a way that it can be interrupted or so it can't be interrupted.

 

Both flags seem to happily stop new script blocks from executing, the game from being saved, etc.

 

The unanswered questions I have (other than the standard request for confirmation of the above):

 

* does ActionOverride set that per-action non-interruptable flag? or another one? Disasters seem to happen in various game scripts if the overridden actions are allowed to be immediately interrupted - but there are many other possible explanations here, such as disallowing new script executions if there are actions on the queue but no blocking action copied into the object.

 

* why would anything bother doing SetInterrupt at the end of their script if it's simply reset by the engine the next time anything runs? did I miss something in my testing?

 

* ActionOverride seems to work by adding actions to the queue of the target and force-stopping any current blocking action executing on the target (maybe useful information here: it doesn't wipe the queue), does that force-stop still happen if the target is uninterruptable?

 

* Is there anything else related anyone knows? (other engine version differences, how it interacts with dialogs/cutscenes - I already saw somewhere (from Taimon?) that the cutscene code adds SetInterrupt actions - and other such things)

 

I'll try and work these out myself, but I'd appreciate any input in the meantime.

[devSin]

SetInterrupt() should have an even more limited lifespan than you suggest (it shouldn't persist beyond the current queue IIRC).

 

ActionOverride() shouldn't alter the interrupt state for the target object. But there's a small window where chunks of ActionOverride()s can be passed along (to prevent just continually overriding the previous override). With any sort of delay between invocation, however, it will just happily chomp the previous ActionOverride() results (and whatever action was sent to the target is performed with the normal interrupt state).

 

ActionOverride() really should destroy the whole queue, though... ? I don't remember anything with targeting creatures with a locked-down queue (but the only places they would do this would send a SetInterrupt(FALSE) as the first call).

[Avenger]

Lets consider this:

 

ActionOverride(Player1,displaystring(myself,1))

SmallWait(1)

ActionOverride(Player1,displaystring(myself,2))

 

You say, this snippet will make player1 only display strref #2?

[devSin]

DisplayString() is probably instant and SmallWait() is so brief that they probably both run.

 

But in general, you can chain a gargantuan number of ActionOverride()s without worry. If you sprinkle other stuff in between, you're probably going to end up "overwriting" a lot of the queue. (It's not an exact science, though. You can usually sprinkle in SetGlobal() and other stuff and have your ActionOverride()s cumulate. (It might be related somehow to INSTANTs, or not, but I haven't actually played BG2 or looked at scripting this year at all, so this is all just ancient memory.)

 

(Except, if that script is being run by Player1, you probably will only ever see the first string since ActionOverride() will reset your AI.)

 

Also keep in mind that it pretty much works differently in every single variant of the engine. I hate it all.

[fuzzie]

Try this in BG2 (ok, I guess no-one will bother, but alas): ActionOverride some other object with a long Wait followed by a DisplayString #1, then do a SmallWait yourself, and then ActionOverride the target with another DisplayString (#2).

 

According to what I was trying to say with "force-stopping any current action", you'll end up with the SmallWait, then instantly the first string displayed followed by the second. I've found that you can fiddle with this by adding blocking actions to the mix, and see that it's not just instants stuff, too.

 

And devSin is right, SetInterrupt doesn't persist across a queue wipe at all!