Originally Posted By: SniperHF
I just used your script with exactly those calls and it worked fine.

How do you have the trigger registered? Are you using registerforcharacter or registerforplayers? I used registerforplayers.

Also which doc are you reading this particular line from?



I'd probably tackle this problem differently anyway, the time between the character burning and being petrified is tiny.


I'd do this:
IF
CharacterEnteredTrigger(_Player, TRIGGER_GR_SampleTrigger)
THEN
CharacterApplyStatus(_Player, "PETRIFIED", 15.0, 10);
TriggerUnregisterForCharacter(TRIGGER_GR_SampleTrigger,_Player);
BurnThePlayer(_Player);

PROC
BurnThePlayer((CHARACTER)_Player)
THEN
CharacterApplyStatus(_Player, "BURNING", 3.0, 1);

The time between applying the statuses does not matter, if you want one, you have to use a timer.
With the way Osiris works, it is even hard to create 'racing conditions' (although possible ;-)

What is important to know is that what Larian calls an 'event' is not what you would probably expect from events (or if you know interrupts for processors or whatever).
They do not 'fire' immediately, they are queued and executed at some later point when 'their time has come', i.e. when they are next in the execution stack.
So the first chance for an 'event handler' to be executed is AFTER your current statement has completely finished, which includes all procedure calls and all other handlers, in the case above, all CharacterEnteredTrigger() handlers throughout the code, because Osiris needs to check at least if the 'a character entered a trigger' condition of all other rules need to be considered in this situation.
(Your handler might be the last one executed, depending on the file name.)

It also does not matter, where in your code you put a handler, Larian often puts them between two procedures of the same name (especially the TimerFinished() event), putting it between two PROCs does not mean it will be executed immediately though. It will be executed at the earliest AFTER all PROCs of that name have finished executing. Some other 'events' might have been queued earlier though and will be executed before. Calls and rules from setting values are executed immediately (With the 'rules' I mean stuff like IF DB_Companion( _Companion ) ...). 'Events' are not.

That means for example, that you cannot set a variable in a PROC, add items to the inventory, clean that variable at the end of your procedures and use that variable in the ItemTemplateAddedToCharacter() event because it will no longer exist there since you cleaned it before the event actually executes.
It took me forever and tons of testing (and a lot of tears ;-) to find out why some pieces of my code did not work although I expected them to work, always thinking of 'traditional events'.

In the original example it could be that no 'event' is actually executed because by the time the event 'fires', there is no longer a trigger. (But I'm not sure about that, did not do anything with triggers yet except for simple point triggers for teleporting. I'm also not sure if unregistering a trigger should even 'fire' the LeftTrigger() event at all.)