Closed kristophergeou closed 8 months ago
On first glance, this looks like a system akin to the LuckPerms meta storage. I personally use the LP meta system to store quite a bit of player metadata, which can easily work with DeluxeMenus via placeholders.
This seems a bit out of scope for DeluxeMenus, and wouldn't support cross-server setups (which are quite common; and which LP already supports).
yeah I a aware of the meta system of luckperms. I personally use the variables system from the executable plugin series mostly. https://docs.ssomar.com/executableitems/configurations/item-configuration/item-features But overall the meta system of deluxemenus could use some improvements, that's why i suggested this.
I personally agree with @Starmism here. While it is clear that DeluxeMenu's metadata system isn't the most feature rich, it was never intended to be. All it was ever meant to do was store simple information about menu users such as number of clicks on an item
LuckPerms already offers what you're asking for (and more). Plus as mentioned before, it even works cross-server.
Maybe we can consider the part of moving it towards our own files but this will break backwards compatibility, something we might be more interested in. Also, I personally don't like the idea of adding more points of failures directly into DeluxeMenus. It already has so many.
I personally think that if all the features you are asking for are to be created, they should be done in completely separate plugin.
And then there's also the fact that storing huge amount of information in yaml files is not the best
Closing this for now.
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:
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 tono
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: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;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 hascube
in their name, it will returnHello
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)