[Solved] Making Dialog Windows and choises multiplayer usable

[SMOrc]

Hi ho,
it's me. Today i want to ask you about the topic of dialog windows, button creation and using "neutralized" triggers in multiplayer.
I already made myself known to the dialog system with tutorials and posts here but i did not find any good explanation on how to make triggers
with dialog really usable - without making the triggers specific for each and every player.

My current problem with a test map is, that i have a trigger running on a chat command giving simple choices and rewards based on the button pressed,
but when i call the GUI function "Dialog - Clear dialogtext" after the event "Dialog - A dialog button is clicked for dialogtext", the editor does not quite what i want it to.
Either all dialog text gets deleted, even if another player still has the window open or when repeating the trigger, the choices get shown multiple times each.

Here the starter triggers:

• Playertypes
  • Events
    • Player - Player 1 (Red) types a chat message containing dialog as An exact match
    • Player - Player 2 (Blue) types a chat message containing dialog as An exact match
  • Conditions
  • Actions
    • Dialog - Change the title of dialogtext to Is this a text dial...
    • Dialog - Create a dialog button for dialogtext labelled Yes
    • Set VariableSet dialogbuttons[1] = (Last created dialog Button)
    • Dialog - Create a dialog button for dialogtext labelled No
    • Set VariableSet dialogbuttons[2] = (Last created dialog Button)
    • Dialog - Show dialogtext for (Triggering player)

• button 1
  • Events
    • Dialog - A dialog button is clicked for dialogtext
  • Conditions
    • (Clicked dialog button) Equal to dialogbuttons[1]
  • Actions
    • Player - Add 1000 to (Triggering player).Current gold
    • Dialog - Clear dialogtext

Same for dialogbuttons[2], just with wood instead.

My wild guess is i have to make it MUI or save something for each player.
Would i go wrong with making Dialog triggers for each player specifically instead to avoid this?

Best Regards
SMOrc

 

[PurgeandFire]

Instead of creating the dialog buttons when "dialog" is entered, I recommend creating them when the map starts (or technically, after 0.00 seconds have elapsed because if you do it on map initialization, they won't work).

• Dialog Setup
  • Events
    • Time - Elapsed game time is 0.00 seconds
  • Conditions
  • Actions
    • Dialog - Change the title of dialogtext to Is this a text dial...
    • Dialog - Create a dialog button for dialogtext labelled Yes
    • Set VariableSet dialogbuttons[1] = (Last created dialog Button)
    • Dialog - Create a dialog button for dialogtext labelled No
    • Set VariableSet dialogbuttons[2] = (Last created dialog Button)

Then when someone types a message, simply show the dialog for the player:

• Playertypes
  • Events
    • Player - Player 1 (Red) types a chat message containing dialog as An exact match
    • Player - Player 2 (Blue) types a chat message containing dialog as An exact match
  • Conditions
  • Actions
    • Dialog - Show dialogtext for (Triggering player)

Finally, when a dialog button is clicked, feel free to reward the gold/lumber--but don't clear the dialog.

• button 1
  • Events
    • Dialog - A dialog button is clicked for dialogtext
  • Conditions
    • (Clicked dialog button) Equal to dialogbuttons[1]
  • Actions
    • Player - Add 1000 to (Triggering player).Current gold

• button 2
  • Events
    • Dialog - A dialog button is clicked for dialogtext
  • Conditions
    • (Clicked dialog button) Equal to dialogbuttons[1]
  • Actions
    • Player - Add 1000 to (Triggering player).Current lumber

The issue you're running into is because you're adding new buttons to the dialog whenever the chat message is entered--and that applies globally. (e.g. so if Player 1 types "dialog", they'll see "Yes" and "No". But if Player 2 then types "dialog" while Player 1 is still viewing the dialog, it'll add two new buttons, showing: "Yes", "No", "Yes", "No"). This is a good illustration of how complex things can get in multiplayer when multiple players can trigger the same code independently. In our heads, we think of each person "owning" their own dialog, but ultimately, adding buttons and clearing the dialog apply to everyone globally.

While it is possible to technically manipulate the dialogs for specific players (using GetLocalPlayer()), it is something you have to be a bit careful using because any "agents" that get created locally can cause a disconnect for the other players (so usually you mostly just show/hide things for specific players). And in most cases, showing/hiding dialogs should be sufficient. As a general rule of thumb for dialogs, I recommend following these rules:

1. Setup Dialogs Once - If your dialogs are static (e.g. fixed options, like "Yes"/"No", and you don't play on changing it dynamically), I recommend adding those buttons once after the game starts. Then just leave the dialog alone from then on, and use "Dialog - Show Dialog for Player". Don't clear it.
2. Use Separate Dialog Variables For Each Distinct Menu - Rather than re-using a single dialog for everything in your map, I strongly recommend creating separate dialogs for each menu, even if they have the same options. For example, if you have one menu that rewards gold, I recommend making one dialog variable for that (e.g. DialogGold). Then if you have another menu that gives you an item, I recommend using a separate variable for that (e.g. DialogItem). This type of organization will make your code a LOT easier to manage without running into strange bugs from trying to manipulate one dialog used by everyone. Trust me.
3. Use Separate Dialog Variables Per Player For Dynamic Menus - Let's say you really need dynamic menus that change per player, e.g. maybe you want to show buttons for each item the player's character owns. Instead of manipulating one dialog for everyone, create a dialog array and use a separate dialog variable for each player. Then when it comes time to show it, just show the specific one for that player (you can use the Player's Index as the array index to make this easier). This will also make the code a lot easier to manage and less prone to bugs--for the same reason listed in #2.