In-between dialog sequence. (Solved)

[Davostros]

Me again    with a not-so stupid question (i hope so).
Ok here is my script :
function room_AfterFadeIn()
{
 gHotspotgui.Visible = true;
 oOpeneddoor.Visible = true;
 oCloseddoor.Visible = false;
 PlayMusic(1);
 SetMusicMasterVolume(1);
 cGuard.Walk(350, 314, eNoBlock, eAnywhere);
 Wait(250);
 cGuard.Say("Test");
 cGuard.Walk(26, 314, eNoBlock, eAnywhere);
 Wait(250);
 oOpeneddoor.Visible = false;
 oCloseddoor.Visible = true;
}      

All I wanted first is the non-player character to say "test" after coming from the opened door then go back from where he came and close the door. And it works just fine.
What i would like second is to introduce a dialog when he reaches the x,y spot where he says "test".
But I have no idea how to tell AGS that he needs to stay there until the dialog ends, THEN go back like he does in the first script. So when i run this script:
function room_AfterFadeIn()
{
 gHotspotgui.Visible = true;
 oOpeneddoor.Visible = true;
 oCloseddoor.Visible = false;
 PlayMusic(1);
 SetMusicMasterVolume(1);
 cGuard.Walk(350, 314, eNoBlock, eAnywhere);
 Wait(250);
 cGuard.Say("Test");
 dDialog0.Start();
 cGuard.Walk(26, 314, eNoBlock, eAnywhere);
 Wait(250);
 oOpeneddoor.Visible = false;
 oCloseddoor.Visible = true;
}

Everything about the dialog works fine but the non-player character goes back from where he came, closes the door THEN launches the dialog. Please help!

[Khris]

It's right in the manual, Dialogs don't get started until after the function finishes.
The easy way is to put this:

Code: ags

 cGuard.Walk(26, 314, eNoBlock, eAnywhere);
 Wait(250);
 oOpeneddoor.Visible = false;
 oCloseddoor.Visible = true;

in the dialog script, right before the "stop" command.
Don't forget that you need at least one space at the beginning of standard script command lines for them to work in dialog scripts.

[monkey0506]

Dialogs are always queued and run delayed after every other script function in that particular game loop has finished. It's somewhat of a horrible annoyance really.

I put a fair amount of work into trying to circumnavigate it, but ultimately I found that the only way to do it from the scripting side without having to track whether the dialog has run yourself involved editing the engine, in which case it could probably just be set to not run as a queued function in the first place.

So, what you can do is just run the "after dialog" events any time the dialog would be stopped (a stop command in the dialog). This is kind of a messy route, but at the moment it's the only functional one. You can either call the individual commands directly, call dialog_request, or just call a custom (global) function (meaning the function is in any script ASC file and there's an import of the function in the associated ASH header file).

Khris beat me, but yes.

[Davostros]

Thanks both of you for responses.
If i put the "after-dialog" scripts in the dialog it works, non-player character stops and moves back after the dialog is done, wich is what i wanted. The only problem i still have is that it won't work for the doors, as the error message says "Undefined token "oOpeneddoor"". Same for "oCloseddoor" of course."
so i still need a way for that to work after the non-player character leaves the room.

[Khris]

Right, I completely forgot about that.
Just look up the ID number of the objects in the list in the room editor, then replace the name with object[ID]:

Code: ags

 ...
  object[1].Visible = false;
  object[2].Visible = true;

The reason is you can't use room specific names (those of hotspots and objects) in a global context, even if the dialog is only ever called in that room. Therefore you have to use the hotspot[] and object[] array which always point to those of the currently loaded room.

[Davostros]

Right, I completely forgot about that.
Just look up the ID number of the objects in the list in the room editor, then replace the name with object[ID]:

Code: ags

 ...
  object[1].Visible = false;
  object[2].Visible = true;

The reason is you can't use room specific names (those of hotspots and objects) in a global context, even if the dialog is only ever called in that room. Therefore you have to use the hotspot[] and object[] array which always point to those of the currently loaded room.

Thanks a lot LeKhris, problem solved.