HelpChat / DeluxeMenus

DeluxeMenus but open source!?
https://wiki.helpch.at/clips-plugins/deluxemenus
MIT License
77 stars 36 forks source link

Better Meta System #21

Closed kristophergeou closed 8 months ago

kristophergeou commented 8 months ago

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 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)

Starmism commented 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).

kristophergeou commented 8 months ago

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.

BlitzOffline commented 8 months ago

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.