Dialog options halt repeatedly_execute_always?

Started by GarageGothic, Tue 01/03/2005 11:37:52

Previous topic - Next topic

GarageGothic

Is there any workaround for repeatedly_execute_always being halted while dialog options are shown? I CAN keep it running despite all other text windows and popup modal GUIs, but the built-in dialog options kills it?

monkey0506

Well, I'm not sure why that would be happening (as rep_ex_always is supposed to execute ALWAYS), but I'm sure that my dialog scrolling workaround allows rep_ex_always to execute.  I hope this helps fix your problem:

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=18466.0

The workaround was designed for scrolling dialogs, but it's GUI based dialog control allows you to do other things as well such as custom-defining the highlight color and
animating objects/characters/backgrounds/etc. while choosing a dialog option.  Note that this doesn't use the built-in dialog system (all dialogs are handled in the global script), but unless there's a better solution (perhaps you posting your code so the real problem can be identified), this should work for you.  Michael Rittenhouse

strazer

Are you sure it's not because of a
  if (IsGamePaused() == 0) {
in there?

Pumaman

There are three situations in AGS where the game is completely paused (ie. no game loops are running in the background). rep_exec_always is guaranteed to run every game loop, but it won't run if there are no game loops running (if you see what I mean).

The 3 situations are:
* Display() message box displayed
* Dialog options displayed
* Built-in save/load/quit dialog displayed

strazer

Ah, right, I was thinking of popup modal GUIs.

As for not pausing the game while dialog options are displayed, there's a tracker entry: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=496

monkey0506

OH MY GOSH!  I'm the official (a.k.a. only linked) custom dialog options GUI.  Wow.  I feel so AMAZING.  But, there is a point to my post:

@CJ (rather, CJ's post (I don't care who answers...))

You said that there are no loops running during a Display command.  Does this exclude DisplaySpeech?  Because in my game I have been trying to allow certain keypresses during speech and I'm using Display for the player character instead of DisplaySpeech, and I've been having a lot of problems with it.  Does rep_ex_always run during DisplaySpeech commands but not Display commands?  Thanks for any help on this.  You would not believe the happiness that I can feel flowing through my veins just knowing that I did something useful (perhaps temporary, but useful) *looks at tracker entry again*.

GarageGothic

Thanks for clearing that up CJ, it explains a lot of things. I hope it'll be changed eventually, so we can keep background and idle animations etc. going even while choosing topics.

monkey0506

Quote from: GarageGothic on Wed 02/03/2005 16:22:13
so we can keep background and idle animations etc. going even while choosing topics.

*Have you looked at the links provided?  There is a workaround...*

GarageGothic

#8
Yes, thank you, there is a workaround. But it is pretty massive. Is it really worth rescripting your whole dialog system and making conversation scripting much more complicated, just for a little animation? I don't think so. There doesn't seem to be any real reason for the game not just pausing the game normally, like popup GUIs, in the first place.

Besides, I've been trying to test the scrolling dialog template for the last few weeks, downloading the files several times even, always getting an error when running the game (on the latest beta).

monkey0506

Umm...Have you reported it so that it can be fixed?  It could possibly be a compression problem, because my version of PicoZip became corrupt very soon after compressing the files.  Also, have you made sure that you used the latest scripts?  And, yes, the dialog workaround is massive, but considering that in order to allow the animations and scrolling, the entire dialog system had to be re-written (since I don't have access to AGS's source) I DO think that it is worth rescripting my whole dialog system.  I wrote the dialog system for my own personal uses (scrolling) but based on the size (in terms of code) and the frequency which some of these things are inquired about, I posted the code for others to use.  If you wanted, you could easily make the scripting system less complicated:

I.  Put your dialog topics in global messages and call the corresponding message with DisplayMessage() instead of RunCustomDialog().
II.  Use the built-in dialog system for the dialog speech (not the topics) by putting only one topic (so that it will be run automatically) in each dialog and using RunDialog() instead of RunCustomDialog().
III.  Use the built-in dialog system entirely.

You can use I, II, III, or even I & II.  All of these would make your global script shorter, and may (in your opinion) simplify conversation scripting.  In essence, I did not make "conversation scripting much more complicated", I just handle it differently.  The syntax for the built-in dialog system is:

// dialog editor
@S
return
@topic_num
char1: "something."
char2: "something else."
return
@topic_num2
char2: "something."
char1: "something else."
return
stop

The syntax for my dialog system is much the same, just in the global script:

// global script
//// RunCustomDialog(int dialog, int option)
if (dialog == 1) { // Dialog 1
  if (option == 1) { // Option 1 - Dialog 1
    DisplaySpeech(CHAR1, "something.");
    DisplaySpeech(CHAR2, "something else.");
    }
  else if (option == 2) { // Option 2 - Dialog 1
    DisplaySpeech(CHAR2, "something.");
    DisplaySpeech(CHAR1, "something else.");
    }
  }
}

You have to manually test the dialog number, but other than that it's not much different.  After testing the dialog number, you test the option number:

@1 // built-in
if (option == 1) // mine

Then, under this, you define what is to be said:

char1: "something."  // built-in
DisplaySpeech(CHAR1, "something"); // mine

With my workaround you do have to manually display the option text (DisplaySpeech(CHAR1, dlgnum[dialog].text0) OR  DisplaySpeech(CHAR1, "%s", GetOptionText(option)) and you have to make use of a function for the text-display, but it's not really that much different in context.

Then, when you're done displaying messages, you end the dialog:

stop // built-in
} // mine

I understand that it is a lot of code "just for a little animation", but then, think about how much code actually went into making the built-in dialog system that you can't edit.  I don't know how much it is comparatively, but I would venture to say that it's not a small amount of scripting.  Please go by the official thread and report the bug so that it can be fixed.

Pumaman

Quote from: monkey0506 on Wed 02/03/2005 03:36:19
You said that there are no loops running during a Display command. Does this exclude DisplaySpeech?

It does not apply to DisplaySpeech. While speech is being displayed, animations are running and the game is basically still running in the background, hence rep_exec_always runs too.

But with Display(), the game is not running in the background so neither does rep_exec_always.

monkey0506

One more question:

Since the game doesn't run during Display() but it does during DisplaySpeech(), if I click the "always display text as speech" checkbox, will my Display() commands be parsed as DisplaySpeech()?

SSH

12

GarageGothic

monkey, I've now reported the bug in the scrolling dialog thread.

As for my statement that it wasn't worth recoding the dialog system for a bit of animation, I just meant in my own case. I wasn't trying to diminish your script, which I think is absolutely great.
The thing is that I'm using so many workarounds for my dialog system to do what it does now (a perfect replica of GK1 text display style), that I'd rather not do it all over again just for a little animation, which nobody will pay attention to anyway. Actually your scripting might be a lot easier to use than what I'm doing now (using a lot of dialog_request calls in the dialog script).

SMF spam blocked by CleanTalk