Closed BlitzOffline closed 6 months ago
There are still 3 things to figure out before this PR can be merged:
/A PLAYER1 2
is used to open first menu[openguimenu] B 18
is used to open the second menu
In this specific case, argument player_name
would be given the value PLAYER1
from the previous menu. This would raise another question however. Consider the following case:/A PLAYER1 2
is used to open first menu[openguimenu] B 18 2 175
is used to open the second menu
How do we decide which argument is used? This is easy for only 4 arguments but can get very complicated with more arguments.I find that it complicates the logic unnecessarily and that it is not very practical or even understandable. The person only needs to put {arg} to retrieve them and can put them in the action, which is much more visual.
Like that: "[openmenu] punish-confirm {target} mute {reason}"
Which part is complicated exactly? Can you be a bit more specific?
To recover part of the arguments if they have the same name, On the configuration side it's not very clear how it works like that.
To recover part of the arguments if they have the same name, On the configuration side it's not very clear how it works like that.
I'm sorry but I am a bit lost. Can you tell me about which bullet point from my comment are you talking about specifically? Or are you talking about the entire PR?
Keeping part of the arguments, not replacing them if they have the same name, ...
I find that it's not very clear and for example if I want to replace the player_name, how do I do it? I would have simply overwritten the arguments with the new ones, I find it more understandable
Keeping part of the arguments, not replacing them if they have the same name, ...
I find that it's not very clear and for example if I want to replace the player_name, how do I do it? I would have simply overwritten the arguments with the new ones, I find it more understandable
But this is how my PR currently works. I think I have to give another example because it is pretty hard to explain.
There are 2 menus:
name | command | arguments |
---|---|---|
A | /menuA | player_name, age |
B | /menuB | player_name, amount |
You open menu A using /menuA PLAYER1 18
When you open menu B from inside the menu A, you can currently do this in 2 ways:
[openmenu] B
[openmenu] B PLAYER2 2
If you do it the first way, you will have the following arguments in menu B: {player_name} = PLAYER1
and {age} = 18
If you do it the second way, you will have arguments: {player_name} = PLAYER2
, {age} = 18
and {amount} = 2
in menu B.
We need to keep the first option because this is how DeluxeMenus has worked for a long time and changing it would break old menus.
Also, you can always do [openmenu] B {player_name} 2
to open the menu and then you'll have the following arguments in menu B: {player_name} = PLAYER1
, {age} = 18
and {amount} = 2
.
Yes no worries about that, what I found unclear is what happens when you do [openmenu] B 2
.
And it's currently don't register argument inside the menu if you don't have command to open it.
For bullet point 3 and your response, I feel the best way would be to just require all arguments and avoid confusion. As itsme-to said, I would just have the player use {arg}
to pass it forward.
If there are no arguments supplied, then carry over.
This PR adds support for arguments to the
[openmenu]
and[openguimenu]
actions.How it works:
- '[openmenu] menu1 arg1 arg2'
Closes #30
EDIT: Should be merged after #46