rundialog and delayed activation

[Dave Gilbert]

From the manual:

NOTE: The conversation will not start immediately; instead, it will be run when the current script function finishes executing.

Is there any way around this issue?  My current script has a lot of "runDialogs", and splitting the script up into a dozen dialog_request functions is making it real messy.  Any advice appreciated!

Thanks,

-Dave

[Ishmael]

In the interactions editor you can split your code into two Run Scripts, and have the RunDialog end the first one...

[Pumaman]

If you've got a lot of script interspersed with RunDialogs, might it be easier simply to translate the dialog into DisplaySpeech commands so it's all in the script? Obviously this would kinda defeat the point of the dialog editor if the conversations were complicated though.

[Dave Gilbert]

Well, I decided to break up long dialogs sequences by giving the player dialog OPTIONS at various points.  So there are already a bunch of DisplaySpeech commands (or should I use "Say" commands now?), but at various points I want the player to make a dialog choice, which I have to use the dialog editor and RunDialog for.  So now I have to go and move chunks of the code into the global script and divide it up into various Dialog_Request functions.  I'd really prefer to keep everything in the local room script.  I don't know if there's a neat and clever way to do that, but I'll do it the messy way if there are no other options.

[Pumaman]

Ah I see, I don't think there's an easy way of doing that.

Would some sort of  ShowDIalogOptions(int topic)  blocking command be useful, so that you could prompt the user to choose a dialog option directly from the room script?

[Dave Gilbert]

Would that return to the room script once the it is complete?  If so, then it would be very very useful for me.

[Stacy Davidson]

I know this is really old one, but I thought it might be worth asking the question over again, since it's been a few years and I notice this is still in v3:

NOTE: The conversation will not start immediately; instead, it will be run when the current script function finishes executing.

I was just wondering today why it works this way, and then I ran across this older post.  Is there a reason a function can't pause to run a dialog, then return to the same spot in the script?  As opposed to continuing through the script and then running the dialog afterward?

As it stands, I have just been using indenting to write truck loads of code within each dialog.

Is that the best way to do it, or has this issue been addressed in some way since this message?

Thanks,
-s

[Gilbert]

As far as I know this had not been changed and (as you knew already) the recent addition of the script-in-a-dialogue feature (as opposed to the old run-script method) serves sort of as a work-around.

I'm not sure, but it's probably due to design choice that, dialogues were somewhat implemented differently from other scripts, so it's difficult to make dialogues run in-between a function (probably requires a re-write of a huge amount of codes).

I personally would find this useful also, but am always wondering what should happen, if say, there's a room-change within the dialogue and the current room script got unloaded.

[Pumaman]

The reason for this is that the script engine is not currently re-entrant -- meaning that if you call into the AGS Engine with a command like Dialog.Start(), AGS cannot then call back into the script to run your dialog scripts since it is already running.

This is something that I'd like to address at some point, but for now this still applies.