Running Dialogs within a Script (Solved)

[Ethan D]

*Sigh* I had hoped I wouldn't have to post in this forum again, oh well.

In the AGS help it says that Dialog.Start() will run the dialog not where it is called but after the currently running script finishes.  I am using dialogs to add decisions into the game so the dialog has to run where it is called.  

I can think of one way to solve this which would be to have a variable within the dialog that when it is changed calls the next part of the script that it is interrupting.  While this would work, I do want to know if there is a way to get a dialog to run in the middle of script without having to add variables left and right.

-Thanks!

[Wonkyth]

I'm not really sure, but in theory....
If it says that it runs at the end of the current script, you might be able to make it the only thing IN the currently running script....

[Ethan D]

I tried putting brackets around it to make it part of a subscript but it still ran at the end of everything

Edit:  I'm not sure how else I could accomplish that

[Wonkyth]

It could mean the actual script, rather than the current code-block.
In that case, you'd have to put it in another script and import it in the header.

[monkey0506]

Dialog.Start gets called at the end of the game loop. This means all the other function calls, etc. for that loop get performed first, then the dialog is started.

The easiest way of working around this is just to put lines of code that should be executed after the dialog is started into the dialog script (with at least one whitespace character at the beginning of the line so the engine knows you're using "normal" scripting).

[RickJ]

Another approach to your problem is to create a finite state machine that is executed from the repeatedly execute function of the room or global script.   The state machine executes the script commands contained in a specific state each game cycle.  The repeatedly execute script finishes each game cycle so the problem you describe is non-existent in this case.

Here is an untested example of how to do this.  You will need one state machine for each set of dialog/scripts.

Code: ags

*** Script Header ***
#define FSMRUN -1

*** Room Script ***
// Define a finite machine that does "Stuff"
int   StuffState=-1;
function StuffStateMachine(int request) {
   // Do the control stuff
   if ((request>=0)&&(StuffState==-1)) StuffState = control;
   else {
      // Do the state stuff
      if (StuffState==0) {         // Implement script for state 0
         SomesSriptCode();       // Script code
         dMerchant.Start()         // Start a dialog
         StuffState=1;                // Tell FSM to go to next state
      }
      else if (StuffState==1) {  // Implement script for state 1
         // Do nothing                // Wait for Dialog to finish
                                              // dMerchant dialog sets  StuffState=2;  to finish
      }
      else if (StuffState==2) {  // Implement script for state 2
         SomesMoreSriptCode();// Script code
         StuffState=-1;                // Tell FSM to go to next state
      }
   }
   return StuffState;
}

function AnyOtherFunction() {
   // Startup the Stuff state m,achine
   StuffStateMachine(0);
}

function roomRepExec() {
   // Execute the Stuff state machine
   StuffStateMachine(FSMRUN); 
}

Monkey's suggestion seems easiest in this case though.

[monkey0506]

I actually considered suggesting that route as an alternative but it's so much overhead!

On an unrelated note I actually have a full FSM script module that supports named machines and states, complete with demo, lacking only documentation. The funny thing is how long I've just let it sit there rotting on my hard drive. :

[RickJ]

I hadn't thought of dong in the dialog itself.  However this technique can also be useful  for other things such as moving NPC's around in the background etc.

[Khris]

I've suggested a possible easy solution at least once in the past but I don't know what happened to it.

Back when AGS had the Interaction Editor, all one had to do was use two RunScript actions and call the dialog in the first.
And the current editor already makes it possible to enter e.g. "cGuy_Talk; cGuy_Talk2" into an event field.
The only thing missing is the engine parsing that and calling both functions in order. Since it supports the queuing of functions, this shouldn't require rewriting huge amounts of code, it seems like a relatively simply thing to add.

On the other hand, calling that second function from within the dialog before every stop command isn't that much more work either.

[Ethan D]

well, the simplest thing I could think of was to just add a variable within the dialogue that gets called regardless of which choice is made and then have that variable checked in repeatedly execute to run the next chunk of the script and so on.  It works fine now.

Thanks for all the suggestions.