Jump to content



Recommended Posts

You might want to add a note into the IESDP under EscapeArea() to the effect that any action in a script that comes after EscapeArea() will not be run e.g.

   DO ~EscapeArea()

results in the NPC leaving the area but the experience is not given and the global variable is not set. However, this does work as expected:

   DO ~AddexperienceParty(3000)



Link to comment

Sorry - my search-foo is not working well this morning - do we actually have a list of uninterruptable actions? Stuff where we know for certain that needs to be at the end of a set of actions called at the end of a dialog, for instance?

Link to comment

Are you guys sure that what is stated in the original post is true?

Here's a similar piece of code that I have tried, -- the last block in a D-file looked kinda



SAY ~Blah~

IF ~~ THEN DO ~MoveToPoint([100.100])


ActionOverride("Creature2",Dialogue(Player1))~ EXIT



All went pretty smoothly, the first creature would DestroySelf, the 2nd -- talk to my character

Link to comment

ActionOverride() is magic. (DestroySelf() also doesn't lock down the character like EscapeArea(), and I think there's an instance in BG where they run local actions after it.)


In general, it hardly matters. If it doesn't seem to work, just fiddle with the order a bit.


There are ways to shoot yourself in the foot, but since you're free to shuffle actions around, it shouldn't be a big deal.

Link to comment

Well, there is indeed a little bit of difference and it is the blocking feature of EscapeArea().

After (when) EscapeArea() is executed, it stops the execution of other actions, and continues the execution of EscapeArea(). Moves the actor towards the nearest exit, and eventually marks it for destruction. But, it won't execute actions in the same cycle as the blocking action.


Since DestroySelf() is an instant, it can continue with other instant actions after executing it.

This is because DestroySelf() just sets a flag in the actor to remove it in the next AI cycle.

It is a silly idea to use it in that order anyway.


What DevSin said about ActionOverride is also true, it is specially handled, so things may behave differently.

Link to comment


This topic is now archived and is closed to further replies.

  • Create New...