Hi hive mind. I have an issue that is stumping me. Basically, I have an inventory bar that appears when you move your mouse to the top of the screen. When the mouse cursor enters the "trigger area", the inventory bar drops down. When you move the mouse away, the bar disappears. This is a pretty standard system. 90% of my games have used it.
(http://www.wadjeteyegames.com/temp/dropdown2.png)
Typically, when there is a dialog option menu up on the screen (where you choose from a list of things to say), you can NOT activate the inventory bar. This, again, is standard behavior.
(http://www.wadjeteyegames.com/temp/dropdown3.png)
However, I am noticing that the inventory bar occasionally DOES appear when there is a dialog option menu up under very specific circumstances.
If GAMEPLAY is interupted - e.g., you are walking across a room and a character calls out to you and begins a conversation - the inventory bar appears underneath the dialog options:
(http://www.wadjeteyegames.com/temp/dropdown1.png)
If the conversation is initiated by the player - e.g., you click on a character to begin a conversation - the inventory bar does NOT appear. This is the desired behavior.
I've coded dropdown inventory bars in almost all of my games and this has never happened before. Any light shedding is appreciated!
Maybe you have "run game loops when dialog options is displayed" turned on, and so this inventory bar is checked in the repeatedly_execute? Or maybe repeatedly_execute_always (don't remember which one is active when options are on screen).
Hmm, also, since you mentioned that it does not happen when player interacts with character, maybe there is some flag set when you start dialog by generic interaction, but when NPC starts it this flag is not set?
Quote from: Crimson Wizard on Wed 14/06/2017 23:23:04
Maybe you have "run game loops when dialog options is displayed" turned on, and so this inventory bar is checked in the repeatedly_execute? Or maybe repeatedly_execute_always (don't remember which one is active when options are on screen).
I DO have that turned on, yes! But the inventory bar is activated under repeatedly_execute, not _always. So that still shouldn't happen?
QuoteHmm, also, since you mentioned that it does not happen when player interacts with character, maybe there is some flag set when you start dialog by generic interaction, but when NPC starts it this flag is not set?
Yeah I'm wondering the same thing. Why one circumstance and not the other? I haven't found anything yet, but will keep digging!
I solved a similar issue in the 9verbs template like this.
In the CustomDialogGui script, you need to add a global var like
bool in_speech;
In the _prepare function, you can add
in_speech = true;
// you can also hide you inventory gui here
if (gDavesInventory.Visible == true) {
gDavesInventory.Visible = false;
}
And finally in the repeatedly_execute area of the module, add this
if (in_speech == true) {
in_speech = false;
if (gDavesInventory.Visible == false) {
gDavesInventory.Visible = true;
}
}
Of course you can also export/import in_speech and prevent the gui showing up in your inventory module.
Hmm. I put your code in, but it doesn't solve the problem. :(
From what I can see of the last bit of code:
if (in_speech == true) {
in_speech = false;
if (gDavesInventory.Visible == false) {
gDavesInventory.Visible = true;
}
}
If this code is put in repeatedly_execute like you instructed, then if "in_speech" equals true, it immediately sets itself to FALSE and then turns the inventory bar back to visible. It doesn't seem to be checking to see if the dialog menu is still on the screen? I am not sure how to do that myself. Unless I am missing something.
The key question seems to be whether
repeatedly_execute() runs during dialogs when you have the game set to "run game loops when dialog options is displayed", or only
repeatedly_execute_always(). If
repeatedly_execute() does run (or
can run, at least), then this...
Quote from: Dave Gilbert on Wed 14/06/2017 23:46:32
I DO have that turned on, yes! But the inventory bar is activated under repeatedly_execute, not _always. So that still shouldn't happen?
... would be the source of your problem, because, well, you are actively turning it on. (Presumably under different circumstances of triggering the dialog, you're sometimes calling it in a blocking way, preventing the inventory from popping up and explaining the inconsistency.)
If, on the other hand,
repeatedly_execute() does
not run during dialogs, then abstauber's code snippet won't run, and it
ought to solve the problem, barring any other issues.
Since I'm on a Mac, I'm too lazy to actually check how it works.
I set up some break toggles to check if Abstauber's code was being triggered, and it was. So repeatedly_execute definitely does run during dialogs, but ONLY in the cases where the dialog is triggered by the game (i.e., interrupting gameplay) instead of a player interaction.
Why that happens is... a mystery.
Maybe you could use the late_rep_exe_always to check if the dialog is open, and if it is to close the inventory gui?
Abstauber's second part of the code won't work like that, it will disable its own purpose, as you could already notice. Maybe it is not complete relevant code he is using.
You need to remove "in_speech = false;" from there, and put it where dialog ends. I do not remember how that's possible to detect though.
EDIT: Unless checking for the dialog GUI's visibility does not work, another variant is this. If you are scripting custom dialogs, then in "dialog_options_repexec" you can set flag "dialog options on screen", and check it in the repeatable_execute, then reset (after the check). It will be reset every time and updated next game frame.
But this won't work for the moments when dialog options are not on screen and character speech is displayed (or any other animations or actions during dialog).
Yeah, there doesn't seem to be an flag anywhere to check if the dialog window is on the screen or not.
What I can do is turn the inventory bar invisible at the START of the exchange and then make it visible at the end. It's a hack, and it works, but it's kind of hacky and I'd prefer a blanket solution to the problem. Plus some conversations have several exit points and if I miss one of them the inventory bar will never show up again.
Abstauber, is there any way to detect IF the dialog window is on screen or not using your module?
edit: CW I just saw your edit. I didn't even THINK about the dialog_options_repexec function. Worked like a charm. Thank you!
Quote from: Crimson Wizard on Thu 15/06/2017 17:13:42
But this won't work for the moments when dialog options are not on screen and character speech is displayed (or any other animations or actions during dialog).
But those will be blocking, right? So
repeatedly_execute() shouldn't be running during those parts anyway.
Yep. Snarky is right. This was never an issue when character speech is displayed. Only dialog menus. At first blush, this appears to be solved now!
Glad that this could be solved, even with my added confusion.
But I'm almost certain, that repeatedly_execute does not fire during dialogs, only repeatedly_execute_always does. And even repeatedly_execute_always should not fire unless you set "Run game loops during dialogs" in the general settings.
Or did this change recently?
Another thing to solve this would be this one, since all GUIs are usually disabled during dialogs
IsInterfaceEnabled()
In 95% of the cases, you are right Abstauber. For some reason, repeatedly_execute IS getting activated in cases where the dialog tree interrupts gameplay. For example, you set up a region so if you walk over it, an NPC talks to you and a dialog menu window appears. While the menu is up, the inventory bar would drop down (although I couldn't click on it). I could reproduce this 100% of the time.
Wow, you never stop learning about quirks of AGS :)
Thanks for the clarification.