Dropdown inventory bar appearing during certain dialogs - SOLVED!

Started by Dave Gilbert, Wed 14/06/2017 23:17:30

Previous topic - Next topic

Dave Gilbert

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.



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.



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:



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!

Crimson Wizard

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?

Dave Gilbert

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!

abstauber

I solved a similar issue in the 9verbs template like this.

In the CustomDialogGui script, you need to add a global var like
Code: ags

bool in_speech;


In the _prepare function, you can add
Code: ags

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
Code: ags

  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.

Dave Gilbert

Hmm. I put your code in, but it doesn't solve the problem. :(

From what I can see of the last bit of code:
Code: ags

  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.

Snarky

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.

Dave Gilbert

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.

Cassiebsg

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?
There are those who believe that life here began out there...

Crimson Wizard

#8
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).

Dave Gilbert

#9
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!

Snarky

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.

Dave Gilbert

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!

abstauber

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
Code: ags
IsInterfaceEnabled()




Dave Gilbert

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.


abstauber

Wow, you never stop learning about quirks of AGS :)
Thanks for the clarification.

SMF spam blocked by CleanTalk