How exactly does OnCreation() trigger work?

[Lu_]

If I use it in the first block in an area script and have Continue() there, do I have to have OnCreation() in all the blocks that will run simultaneously with the first?

[CamDawg]

Short answer: no.

 

OnCreation() is an instant trigger, meaning it only returns true in the very first script round when an area or creature is loaded. There are a handful of triggers like this--Die(), for example, only returns true the round that a creature dies as opposed to Dead(), which would return true any time after a creature died. In general, I try to avoid instant triggers like Die() or OnCreation() because those time windows are easily interrupted and can often cause the triggers to fail when they should fire. We've swapped a few Die() for Dead() triggers in the Fixpack, for example, to address some of this inherent flakiness.

[Lu_]

How can you replace Die() with Dead()? Creature's scripts stop running when the creature dies, don't they? If that's true then Dead() won't work in their script, only a Die() block will. Or am I wrong?

As for the OnCreation(), I've recently heard that it makes an area script start running earliest, before you see the area you are entering. If this is true it can be very useful sometimes

Anyway, I want to know for certain if it's safe to have an area script kinda

IF
OnCreation()
Global("A","MYAREA",0)
THEN
RESPONSE #100
SetGlobal("A","MYAREA",1)
Continue()
END

IF
Global("B","MYAREA",0)
THEN
RESPONSE #100
SetGlobal("B","MYAREA",1)
END

The blocks will run together when I enter the area the first time, won't they? I don't have to add OnCreation() to the second block, or do I?

[CamDawg]

How can you replace Die() with Dead()? Creature's scripts stop running when the creature dies, don't they?

There's usually a bit of wiggle room to get in a last action or two.

 

The blocks will run together when I enter the area the first time, won't they? I don't have to add OnCreation() to the second block, or do I?

As it is, it's possible (though unlikely) that there are conditions where the second block would execute but not the first, so I would add OnCreation() to the second block for consistency. You should also add a Continue() to the second block. Without that, any existing blocks below it that use OnCreation() won't execute.

[Lu_]

"As it is, it's possible (though unlikely) that there are conditions where the second block would execute but not the first, so I would add OnCreation() to the second block for consistency [...] "

I mean in my example the first blocks in an area script, -- I will add OnCreation() to the second block, then, as you suggest

For the Die() trigger, here's a problem that I'd love to discuss. Say, you want to make sure that some of your party members cannot be resurrected (namely, Imoen, -- since she, as the authors insist, is a child of Bhaal) The easiest solution is to have in her script kinda

 

IF

Die()

InPartyAllowDead(Myself)

THEN

RESPONSE #100

LeaveParty()

END

 

(the second trigger is redundant, though)

The obvious alternative to this, of course, is to have a respective block in BALDUR.bcs, with Dead("IMOEN2") trigger. I have always thought that adding to BALDUR.bcs is kinda last resource, when you have no other solution, but other than that... they put a lot of insignificant stuff in the original script anyway

 

For the Die(), I too have always had a feeling that it is VERY unreliable. Though I don't know if this is its nature, or maybe it just doesn't fare well with certain triggers or actions

 

 

[CamDawg]

The problem with Die() in particular is that it's often in a creature's AI script. The creature is typically executing other actions (or has multiple actions already queued up) and the Die() window passes before the engine can process it.

 

I think you should be able to use what you're proposing in Imoen's script directly, but swap out Die() with either StateCheck(Myself,STATE_REALLY_DEAD) or Dead("IMOEN2"). The latter is probably easier since you won't have to worry about defining STATE_REALLY_DEAD. Keep InPartyAllowDead as a trigger since it will prevent the block from infinitely looping.

[Lu_]

Do you mean that creatures' scripts continue running when they are dead? Or is it only true for party members?

[Erg]

Using Dead() or StateCheck(Myself,STATE_REALLY_DEAD), etc. on a dying creature is not reliable. See this: http://forum.baldursgate.com/discussion/14033/known-1454-the-twins-and-the-boogeyman/p1

[Lu_]

@ Erg

We're talking the original game. EE engine is different, so while what you say of Dead() and StateCheck(Myself,STATE_REALLY_DEAD) may well be true, I am not sure if your experience with EE matters here

[CamDawg]

Erg's broader point is true though--it's lower risk to use baldur.bcs, as the creature may cease running scripts before it can execute its death block.

 

edit: Or more accurately, putting the dead check in a script not being run by the dying creature. For Imoen, best bet would be baldur.bcs. For others, it may be an area script.

[Miloch]

I've never seen a problem with Die() as long as (and this is important) it's the first block in the first-executed script on the creature. It seems the engine will always try this first block even after creature death. The other caveat is that you can't have two Die() blocks that return true (however, if the first one returns false, the 2nd one should execute if it returns true IIRC). The whole implementation of P5Tweaks was based around this, which worked fine after the kinks were ironed out (e.g. one of its Die() blocks interfered with the vampire's Die() gaseous form trigger) and before ToBEx deprecated it.

[Lu_]

So having two identical first blocks with Die() in the 'override' script would reduce the chance of failure greatly, correct? That sounds very inspiring

[Miloch]

There'd be no point in having two identical Die() blocks. Either the block will fire or it won't. What I was saying is that you could, in theory, have something like this:

 

IF
  Die()
  Race(Myself,VAMPIRE)
THEN
  RESPONSE #100
    (some vamp stuff)
END

IF
  Die()
THEN
  RESPONSE #100
    (some non-vamp stuff)
END

And the first block would fire if the creature is a vampire, the second block would fire if the creature isn't a vampire, but only one or the other block would fire. However, if you Continue() the first, I think the 2nd block will also run (which is also what the IESDP says). My main point is just to make sure any Die() blocks are first in your CRE's first script; otherwise every single previous block will need a Continue(), which should be used with caution.

[Lu_]

Here is what I also wanted to suggest back then when the topic was hot, but then forgot somehow

Party member's death can be checked via

! InParty ()

InPartyAllowDead ()

Is it not better than using either Dead () or StateCheck () trigger?

[Miloch]

From what I understand, those InParty triggers only check whether the object is in the party, not whether the NPC is dead, and the latter only allows for a dead party member (doesn't check whether the NPC is actually dead). So if you wanted to check for actual party member death, you'd need to use that in conjunction with another trigger that checks that, as CamDawg suggested above.