helpchat / deluxemenus Goto Github PK

Add a way for actions to be executed without having colors parsed.

Some other stuff that might be disabled for raw actions: placeholder parsing, action parsing.

I don't even know how this would work. Would this just be a new action? [player:raw]/[player:no-colors]? Or would this be a tag similar to <delay=1>?

Me and
Glare think this is just going to add way more complexity than benefits. A user has requested this feature for a specific case (see attached image)

Right now with the chance, we know that it's only possible to execute a single action when an action is successful. But what if we could create multiple ones just by adding something like <+++> that could support a 2nd, 3rd... action too. So:
[message] &7Hello y won <+++> [console] eco give %player_name% 5000<chance=10>
so basically when the chance is included, the plugin will also search for a <+++> and it will know that there is more that 1 actions that needs to be executed. Also i think the <+++> is very very rare to be used normally, and that's why it can be used as an identifier for multiple actions in chance.

Improve the default menus that come with DeluxeMenus to better showcase new features or even the more underrated features.

Right now, model_data supports only positive values, but there are few plugins that generate negative values as their model_data. It would be cool for negative value support to be added to model_data

When you have multiple open commands

open_commands:
- command1
- command2

and you update the menu file then execute /dm reload (or /dm reload <menu> ), and then open the menu using /command1, the menu is updated, but if you open it with /command2, you see the old menu.

Seems to happen both when you register and when you don't register the commands (using register_commands: true)

When I transferred my purpur serever from 1.19.3 to 1.20.2 rgb of tipped_arrow (even with + potion_effects) stops working at the delux menus. Dm ver 1.14.0
Core Pur Pur 1.20.2

Item:

  'item1':
    material: tipped_arrow
    slot: 10
    amount: 1
    rgb: 100, 100, 100
    display_name: '&6name'

it is a pain to have 20+ menus all in one folder. I have tried to put them in a different folder in the config but they don't register

What if we tweak how the <delay> tag works? I'm thinking of having Deluxemenus store delayed actions locally in the plugin, linked to users' UUIDs. This way, when a player leaves the server and comes back online, those actions can be executed. Currently, when a player leaves the server, delayed actions are lost. This sometimes leads to minor issues and requires more complex workarounds, making the delay command a bit challenging for those with limited experience in Deluxemenus. Imagine the scenario:

click_commands:
- [broadcast] &7%player_name% +2000$ in 10seconds
- [message] &7Hello Blitz<delay=100>
- [console] eco give %player_name% 2000<delay=200>

After the [broadcast] command, if the player leaves the server and doesn't return within the next 5 or 10 seconds, there's a risk of losing one or both of the delayed actions. This is where Deluxemenus could step in to store these delayed actions, perhaps in something like:

(player_uuid): 
  - [message] &7Hello Blitz  #When 5 seconds pass aka - 100 ticks
  - [console] eco give %player_name% 2000 # When 10 seconds pass aka - 200 ticks

In the usual scenario, when these actions attempt to execute but the player isn't online, they would instead be stored and executed once the player is back online.

While the Spigot API does not support Adventure, we can still try to add support for it.

One way to support this would be to do a double translation: MiniMessage String -> Adventure Component -> Legacy String.
The downsides of this would be that components/tags such as translatable, keybind, etc. would not be supported.

I was told that this can also be achieved using reflection and that https://github.com/TriumphTeam/triumph-gui/ does exactly this.

One thing I want to make clear is that only one option will be supported at a time. Menu creators won't be able to combine Legacy Strings with MiniMessage Strings. They will be able to toggle the option they want to use per plugin and not per menus inside "config.yml". By default Legacy Strings will be used to offer backwards support.

Create an API that can be used by other plugins to integrate with DeluxeMenus.

One of the first things I personally want to see added is custom materials. This would allow other plugins to add new materials without us having to track and also update each integration which can be very time consuming.

Other features are to be discussed. An initial POC could be created and released in alpha.

I know bliz or gaby said no when i suggested it, but i will put it out there in case anybody wants to develop it, cause why not? So basically external configs! A folder named configs that in there you will be able to make other unlimited secondary config files as a category. Something like:
(main `config.yml)

test_menus: 
file: config/test_menus.yml

instantly when the plugin checks the config as a folder it will go and check if in that folder there is a file named test_menus.yml which will be considered as an external config, that will work as if it was the default one, and load menus from there too

Got a report in discord mentioning that [commandevent] action might not work anymore. The user has mentioned that they have updated both their server and DeluxeMenus. Will try to get hold of old and new versions for both.

Need to investigate this.

Conversation can be followed here.

It was suggested in the HelpChat Discord server that we add a new requirement type that would allow menus to check if specific NBT tags are set, what value they have, etc.

We would have to first decide if this is a good idea or not and then what are all the features this will add and how they will look like.

Source:
https://discord.com/channels/164280494874165248/164280494874165248/929161941346312212

Currently all of the messages are hard coded to the plugin itself, which makes it impossible for the user to edit them, and could potentially make unnecessary spam on the console. I am talking mostly about the [refresh] combined with the delay for the `user doesn't have a menu open! Nothing to refresh. So in general it would he nice if we could set to empty strings things like that.

EDIT (Blitz): See here: #20 (comment)

Hello,

In order to improve the plugins, I would like to know if it was possible to integrate your plugin into Maven, in order to be able to use them internally?

thx

No issue

Right now, there's 2 ways to close a menu:

• Press escape (or any other key or action that usually lets you close an inventory in Minecraft)
• Press an item inside the menu that will execute the [close] action.

These 2 ways of closing a menu work very differently at the moment:

• If you close the menu using the escape button, it can't be cancelled. Also, close_commands don't get executed.
• If you close the menu using the [close] action, menu designers can chose when the menus can be closed, and also they can execute extra actions when the menu is closed.

I am proposing a few things:

• We add close requirements. These would let menu designer more easily decide when menus can be closed. These would only work with the [close] action just like the close requirements.
• We add a new per menu option that would let menu designer chose if players should be able to close menus using only the [close] action or if they should also be able to use escape.

Design and implement a complete chance system inside DeluxeMenus. I have no idea how this would look like. Open to suggestions.

Someone suggested we simply add a new <stop-actions> tag, and when an action with this tag is fired, all remaining actions stop from executing. This in combination with the <chance> tag might be a decent enough combination. Even if this isn't the rout we might end up going, the tag might still be useful for something else so that could be a different feature.

Some inventories (tested with LOOM and ANVIL), Don't display the items they're supposed to.
They do execute the actions and check requirements.

I found a post about this from 1.15.2: https://www.spigotmc.org/threads/set-item-inside-a-loom.445807/
According to it, some inventories that don't store items like furnaces, chests, etc., can't have items inside using just the spigot API. Tho from their testing this also happens with crafting table (Crafting tables work for DeluxeMenus).

I don't really know what we should do. We have a couple options:

• We remove support for those inventory types completely.
• We leave them as they are with invisible items but actions still working
• We use packets and maybe get them to work somehow?

This was my test menu: https://paste.helpch.at/avocumofuh.bash

After consideration - I think this should be called "Saved Action Variables". This is too differentiate it a bit from regular "actions". Having "saved" before the title of the feature would immediately differentiate it from the "actions" section.

I think there needs to be a "Saved Click Command/Action Variables" feature that works across the plugin.

These variables should have the option to be "per-menu" (Within the menu file) or global for any menu (a separate file).

Specifically for things like click commands. Where you could have a list like this:

- CDVAR1: '[message] &8(&cCOOLDOWN&8) &7You can not send another public stat message for &e%mcd_left_formatted_StatBroadcastCD%&7.'

And then any click commands section could use it, and then if you needed to change something like the formatting - you would only need to update one variable. EX:

deny_commands:
          - '[sound] ENTITY_GOAT_RAM_IMPACT 1 0.5'
          - '[sound] ENTITY_ITEM_FRAME_BREAK 1 0.5'
          - '[sound] ENTITY_VILLAGER_NO 1 1'
          - '[variable] CDVAR1'

^ The last line would execute the action defined earlier.

This would make it a lot simpler to put together menus where many items have similar messages (like cooldowns). Saves you from cluttering your menu config and also having to copy and paste all your messages. Plus, if you need to reformat a message, you don't need to do a search and replace, or manually go through everything - just update the variable.

You could also expand this system to let variables contain multiple actions. EX:

SOUNDVAR1:
    - '[sound] ENTITY_GOAT_RAM_IMPACT 1 0.5'
    - '[sound] ENTITY_ITEM_FRAME_BREAK 1 0.5'
    - '[sound] ENTITY_VILLAGER_NO 1 1'

Then if it's used in a click command section, it activates ALL the actions associated with it:

deny_commands:
          - '[variable] SOUNDVAR1'
          - '[variable] CDVAR1'

This would save tons of time and effort when putting together larger menus (Or any sized menu with global variables). I know there have been some placeholderAPI expansions suggested, and some luckperms meta options - but all of those can get confusing to keep track of. This system would keep it all within the plugin. Making it nice and tidy. Just a suggestion - it would save me an absurd amount of hours.

Server: Arclight-1.20.1-1.0.1
System: Windows 11 23H2 (22631.3007)
Plugins List:

Advanced-Portals-0.9.3.jar
BKCommonLib-1.20.1-v3-1613.jar
CMILib1.4.4.2.jar
DeluxeMenus-1.14.0-Release.jar
EssentialsX-2.20.1.jar
LuckPerms-Bukkit-5.4.116.jar
MCKotlinPaper-1.3.0-k1.8.21.jar
MyWorlds-1.20.1-v3-SNAPSHOT-245.jar
ODailyQuests-2.2.3.jar
packetevents-spigot-2.2.0.jar
PlaceholderAPI-2.11.5.jar
ProtocolLib.jar
QuickShop-5.1.2.5.jar
Residence5.1.4.1.jar
Shopkeepers-2.19.0.jar
SkinsRestorer.jar
TabList-bukkit-v5.7.5.jar
Vault-1.7.3.jar
VoidGen-2.2.1.jar
XConomy-Bukkit-2.25.8.jar

Mods List:

Blue-Archive-Halos-forge-1.20.1-1.0.20.0.jar
cfm-forge-1.20.1-7.0.0-pre36-pr_799.jar
geckolib-forge-1.20.1-4.4.jar
minecraftbluearchivebanner-1.20.1-0.1.1.jar
moonlight-1.20-2.8.82-forge.jar
supplementaries-1.20-2.7.22.jar
touhoulittlemaid-1.20.1-release-1.1.6.jar

It is recommended to send a message with a command or enter a specific word, such as clicking on the menu to send a message whether to buy this item [OK] [Decline] Entering a specific word is to enter the world you want to teleport into.

Deluxemenus doesn't currently support the display of the light levels. So the

material: light
nbt_ints:
  - "BlockStateTag.level:8"

won't return the correct light level to the material. Would be cool to get added too

Add an option to add trim upgrades to armor, thanks.

Add internal placeholders that would work inside menus. One placeholder people seem to want a lot is a "slot" placeholder that would return the slot of the current item. Something to note is that not all placeholders would work everywhere. There would be menu placeholders and item placeholders.

Hey there @BlitzOffline i think a few of the changes you did in the last dev build #178 regarding the parsing broke the parseother and utils expansion when you are trying to parse placeholders for another person. cause this is how the placeholders appear now with the latest build:

I also tried to use the previous build #177 and this issue doesnt seem to happen

Basically hide_inventory: true/false if you want to hide a user's inventory (items) when they open a menu, so everything looks more nice and clear

DeluxeMenus supports more than just commands execution and so I believe "actions" would be a better suited term.

I think a fair transition would be as follows:

• we add new options: click_actions, open_actions and close_actions
• after the change was uploaded to spigot we update the wiki to only show "actions" instead of "commands
• we support "commands" for a few updates
• we remove "commands" support in favor of "actions"
• one optional step would be a simple app that replaces all instances of strings such as "close_commands" to "close_actions"

The only issue to be discussed is how having both "commands" and actions for an item would work.
My initial idea would be to completely ignore "commands" if "actions" are specified as this suggests the user is aware of what "actions" are and why they were added. Also, giving a warning in console together with the previously stated solution sounds fair to me.

see title :)

Add the support of args in the open gui menu action, really usefull for open menu for a player with arg you can control dans player can't use it.

Like for a shop confirmation have the price and the id in args and open with another menu.

%deluxemenus_opened_menu% - Returns the ID of the menu that the player currently has open.

%deluxemenus_has_open_menu% - Returns yes/no if a user has a menu opened.

%deluxemenus_previously_opened% - Returns the previous id of the menu that the player had opened.

Overall:
Consider a more streamlined approach for Deluxemenus by introducing a direct variable/meta system within the plugin. This would eliminate the reliance on the current meta storage in the playerdata folder, which can pose challenges in managing meta IDs and values. My suggestion involves creating a dedicated meta folder within Deluxemenus, where data names associated with non null meta values, and will be stored for at least one player that had value on that meta, which makes the new system more efficiencyt and reducing vulnerability to world file changes.

Example:
• You run the [meta] action to set a meta for the player.
• When the command runs, it checks that this meta doesn't exist on the folder so it will create a yml file for it.
• [meta] set %player_name% FynnyCube STRING FUNNYCUBE IS THE BEST ADMIN
• File created: FunnyCube.yml

• The file could be something like that:

TYPE: STRING
DEFAULT: null  
PLAYER: YES/NO
VALUES: 
  - %player_uuid% : FUNNY CUBE IS THE BEST ADMIN

• Notes:
  The DEFAULT value of that meta for every user when they do %deluxemenus_meta_FunnyCube_STRING% so there is no need anymore to specify it at the end. Additionally that value can also be changed via the config. The default value for the string can be null and for integer 0.

The PLAYER also introduce a new method of meta that i will explain a bit later. But what it means is that this is a meta for each user individually. When player is set to no then it means that kind of meta specifically is a global one, and it will be treated as global for all the users. And the value could be instead:

VALUES: 
  - global: Hello

And this value like i said will be the same for all the users on the server.

Another cool addition could be meta_requirement: which can be used in the meta files alone and would be similar to the way the normal requirements work so;

TYPE: STRING
DEFAULT: null
PLAYER: no
meta_requirement: 
  requirements: 
    cube:
      type: 'string contains' 
      input: '%player_name%'
      output: 'cube'
VALUES: 
  - global: Hello 

This wil still be a global meta but it will make it only accessible to certain people who have cube in their name. So when the players has cube in their name, it will return Hello for them, the ones that don't, will return null. This Overall i think it's a very nice addition for teams, guilds, island teams, parties, gangs, and everywhere were people can be a group.

Additional stuff:
/dm edit <meta> <player:yes/no> - Possible to change the value from player to global
/dm meta list- Shows every meta ID
/dm meta <user> list - Shows all the meta and their value that the user has in a huge string like the one u do on /dm list (FunnyCube:STRING:Hello)

I currently have a placeholder that also outputs a placeholder, for example:
%luckperms_prefix% will output "&cMVP%color_plugin%+" and and it won't parse the "%color_plugin%" placeholder for some reason

basics_menu.yml.json
The 'stone' must connect the player to the 'survival' server, that is on the same Velocity proxy as the lobby.
I tried both [connect] and [server], but they don't work
Maybe I forgot to import some placeholders from PlaceholderAPI ecloud, or what's the problem?

Would love to see a $slot$ placeholder that can be used in item name/lore/actions/etc.

Example:

filler:
  material: stone
  display_name: 'Slot: $slot$'
  slots:
  - 0-54

These following material options return STONE instead of AIR as a display for the item, when the slot is empty.
armor_helmet, armor_chestplate, armor_leggings, armor_boots

Example Menu:

menu_title: '&8Stone'
size: 9
items:
  'armor_helmet':
    material: armor_helmet
    slot: 0
  'armor_chestplate':
    material: armor_chestplate
    slot: 1
  'armor_leggings':
    material: armor_leggings
    slot: 2
  'armor_boots':
    material: armor_boots
    slot: 3

Allow people to specify an MMOItems id/name as material and display the ItemStack provided by MMOItems .

https://gitlab.com/phoenix-dvpmt/mmoitems#using-mmoitems-as-dependency

iGabyTM

It works like a namespace key from what I see. https://gitlab.com/phoenix-dvpmt/mmoitems/-/wikis/Main%20API%20Features#generating-an-item

I saw another suggestion (#11) So pretty much something similar for these two plugins too.
material: ei-<item_id>
material: eb-<block_id>
This one will get the material that the ID of that item/block is, and it's name and lore

ExecutableItems: https://docs.ssomar.com/executableitems/developer-api
ExecutableBlocks: https://docs.ssomar.com/executableblocks/developer-api

In 1.20, the smithing table inventory gained 1 extra slot. DeluxeMenus forces the size to 3 items.

After the first parse of the placeholder material, it is replaced with the parsed material which results in the placeholder material not being updated until a server restart

I do not know if it will be possible, but it would be nice to add the new menu configuration system that have plugins like superiorskyblock, trmenu among others that goes by pattern or layouts, I have seen plugins that allow you to use together the slot system with the one I just mentioned, the difference is that instead of knowing the slot number you put a letter or name to the item and then place it in the layout forming a 6x9 example of a trmenu menu.
example menu

Since we already shade Adventure and Adventure-Bukkit-Platform, I don't see why we can't just add a new [adventure-sound] action to DeluxeMenus. This would be nice since it would let users play any sound they want, including ones added by resource packs.

This has not yet been added because Adventure sounds have a lot of optional arguments which makes it hard to serialize the sound into a single string/action.

Add a new argument ${anvil_input} that would allow menu designers use the text entered by players inside the anvil text box.

The $ would be used just to not break old menus in the small chance that they have arguments called anvil_input. This might not be that big of a deal. To be discussed.

Add PlaceholderAPI placeholders and DeluxeMenus arguments support to other options:

• Slots
• to be determined

Remove ability to create menus inside config.yml. With version 1.14.0 of DeluxeMenus we've deprecated that option so we need to start thinking about removing it entirely.

I think the best way to do this is completely ignore menus declared inside config.yml that do not have a file: specified and throw a big red warning in console.

Some people that do not read the console logs will come complaining but I think it is better than just stopping DeluxeMenus if it finds a menu inside the config.

DeluxeMenus only supports Minecraft 1.13.2 now, which means data can no longer be used as data but just as damage.
Instead of continuing to use the Deprecated API feature to set the damage, we can use the new API (Damageable)

I recommend the following steps:

• Add a new config option called damage while keeping the old data
• If data is present in the config, send a warning in the console letting people know it is being renamed to damage
• If both options are present in the config, ignore data
• Use the Damageable API to set the damage now
• No longer use the deprecated way of setting data

After these changes are completed and merged, update the wiki to reflect them.
At a later stage, completely remove the data option.

Remember to open a new issue regarding the complete removal of the data option after this issue is closed!

After upgrading from 1.13.7 to 1.14.0, Placeholder material will only be updated after reloading, which causes some issues such as (placeholder-%player_item_in_hand%) not being able to feed back in real time.

Could you please add the option to use a Villager Trading GUI? This would be extremely helpful for me and other players.