[Suggestion] MiniMessage support
Opened this issue · 3 comments
This issue contains a suggestion, that was brought up in #1 and that I now want to mention here so that it is clearer.
While I first was against MiniMessage, am I now in favour of adopting the MiniMessage format into ATO and BTLP.
There are a few downsides:
- You rely on another library. If there are breaking changes in a new MC version, you have to wait for them to update.
- Depending on how ATO interacts with Spigot and/or if ProtocolLib changes things up is the usage of something like the Bukkit-platform of Adventure required for Spigot, to allow Adventure support with it. This adds more complexity as PaperMC on the other hand adds native Adventure components support to pretty much everything that supports it, so you either have to use the Bukkit-platform for both, or find a workaround in some way.
The benefits on the other hand can't be denied either:
- Relatively easy to read formatting. No weird
&#RRGGBBor[color=#RRGGBB]formatting required. A uniform format would be available for every platform. - Better and easier ways for adding static gradients to text components. Instead of creating a separate
!color_animationplaceholder can players simply define a gradient using the provided format inside the component itself. - More people adopt this format, meaning more players get to know it and get used to it.
It would certainly be a useful change to have. But there is obviously one question remaining: What about support for legacy colors?
While I'm a person that would say "make it a breaking change" can I also see the negative impact of that, which is why I would suggest to add a basic parser in ATO/BTLP that turns & colors into their respective MiniMessage part.
For example would &4 become <red>. You could then pass this on to the MiniMessage parser to get the components to use.
If not too difficult could ATO/BTLP perhaps even "convert" tab lists (and the config's custom placeholders) using the above, but I can see possible damage done here unless automatic backups would be created.
It wouldn't be the most reliable solution, but would give people a bit of time to update their configurations, before you would completely switch over to MiniMessage and drop legacy color codes.
It would certainly be a useful change to have. But there is obviously one question remaining: What about support for legacy colors?
While I'm a person that would say "make it a breaking change" can I also see the negative impact of that, which is why I would suggest to add a basic parser in ATO/BTLP that turns&colors into their respective MiniMessage part.
For example would&4become<red>. You could then pass this on to the MiniMessage parser to get the components to use.
That is a good idea.
If not too difficult could ATO/BTLP perhaps even "convert" tab lists (and the config's custom placeholders) using the above, but I can see possible damage done here unless automatic backups would be created.
I don't think automatic conversions are a good idea. If a feature will be dropped in the future, we could inform the user about that, so they can make the change themselves.
It wouldn't be the most reliable solution, but would give people a bit of time to update their configurations, before you would completely switch over to MiniMessage and drop legacy color codes.
Personally, I think it would be best to keep the compatibility forever. It is not just about using those format codes in the config itself, but also about compatibility with other plugins. Especially the&4format is very common. Such color codes may be part of placeholders.
I don't like the bukkit/bungee aproach of "deprecate and keep forever".
Keeping old stuff forever should not be a justified thing here.
If they want to keep old stuff, let them, but don't cater towards them. Otherwise will you cater to a community that is or will be as toxic as the 1.8 one.
Any update on this? I try to create gradient user name with vault prefix and suffix but it looks like BTLP does not support MiniMessage nor any related format else.