Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MiniMessage format support #743

Open
Andre601 opened this issue Jul 31, 2022 · 4 comments
Open

MiniMessage format support #743

Andre601 opened this issue Jul 31, 2022 · 4 comments
Labels
area/i18n Translation and customization of plugin messages. blocked/rework Awaiting a larger rework effort. rework/i18n Relevant to the localization rework effort. type/enhancement New or improved feature.

Comments

@Andre601
Copy link

Feature request

Short description

It would be a nice addition to have support for the MiniMessage text format in MobArena. That way could people also define more complicated things such as hover text for specific text areas or maybe even click actions.

I could f.e. imagine MobArena sending an announcement that an arena may start soon and thanks to that format could the text contain a click action to join the arena itself.

Implementation details

Personally, I would go with using MiniMessage while dropping the legacy colour code one. This one, especially for stuff like HEX colours is horrible and not a good option to utilize.
Not to mention do Spigot forks such as PaperMC natively support the Adventure library and MiniMessage through their sendMessage methods.

This of course would have conflicts with normal spigot servers which could be fixed by having separate versions of MobArena (A multi-module project) for Spigot and PaperMC respectively... Tho this too would come with work and some complications in other areas...

The easiest solution could probably be to shade in the libraries and use them accordingly. Perhaps make dedicated classes for sending stuff on Spigot and PaperMC.

Additional info

MiniMessage is getting more and more popular amongst people (And not just devs), especially since it allows more special things like the aforementioned hover text and click action with a simple Syntaxt that doesn't require the dev to have a complicated parsing mechanic implemented.
It would certainly help people to make nice looking text with stuff such as Gradients.

@garbagemule garbagemule added type/enhancement New or improved feature. area/i18n Translation and customization of plugin messages. rework/i18n Relevant to the localization rework effort. blocked/rework Awaiting a larger rework effort. labels Feb 18, 2023
@garbagemule
Copy link
Owner

There was a bit of discussion on Discord about this particular issue a while back, and I just want to make a quick note here for the sake of completeness.

As per the maintainability goals of the project, we can't add support for something that isn't natively supported in the Bukkit API. The only feasible solution at this point in time is a rework of the message system that allows for extension plugins to bridge the gap similar to how MobArenaStats, MobArenaPlaceholders, and Sait's extension have done for their areas of responsibility. This is a fairly simple task, really, but it will take a significant amount of time. The arguably best solution would be to swap to the Paper API for native support, but this would cut off 35 % of the servers running MobArena. As long as the Paper API remains a true superset of the Spigot API and such a large portion of servers aren't running Paper, Spigot's Bukkit API is the most accommodating. I don't see flexible text formatting as a strong enough reason to significantly reduce maintainability, especially considering much more pressing matters pertaining to the actual "mob" and "arena" aspects of the plugin.

@Andre601
Copy link
Author

Andre601 commented Feb 18, 2023

Perhaps the future hard-fork of Paper or the upcoming paper-plugin feature would be a solution? Later one would essentially allow you to define a separate main class where you could then use paper-exclusive stuff when the plugin runs on said paper server, with spigot being present as a fallback.

Also, how is MobArena working in terms of versions? Like what versions is the latest release used on? Do you have stats on that?
Because if it is at least 1.13 could you utilize the Library loader feature of Spigot to load in MiniMessage and use it without having to shade in stuff, so that you could use a central setup and then use something like an interface to create a Spigot and Paper-native system that is used depending on what server it would be running on.

I feel like those would be some of the more elegant solutions here to have.

@Andre601
Copy link
Author

Also, for the sake of clarification, regarding the aforementioned paper plugin stuff I mean this here: PaperMC/Paper#8108

Latest comment says it's planned to be published this weekend (Unless something happens I guess), so it could be an idea to look into this stuff honestly...
It would really help you keeping Spigot support while still using Paper features where possible by simply having a separate main class for paper to load (And some other classes to load for Paper stuff).

And as mentioned would it fall back to be treated as Spigot plugin, so the existing code would still work for older versions without issues.

@garbagemule
Copy link
Owner

If a Paper hard fork results in the community as a whole shifting to Paper as the "mother project", chances are plugin developers will follow suit and slowly drop support for Spigot's Bukkit API. In that case, it would be natural for MobArena to tag along. In the worst case, we'll need a multi-module project to keep supporting both platforms. That would suck.

Thanks for the paper-plugin hint, I didn't know this was a thing. It sounds like an interesting idea! I'm not entirely sure how well it would work in practice, but a bit of experimentation could probably illuminate some potential issues or possibilities. I had a stab at making a multi-module project out of MobArena for 1.8 and 1.12 support a while back, and it was a mess to deal with the discrepancies. Something as simple as making a player "unmount" a horse had to be tugged away behind an interface and three separate implementations. It made me miss dependency injection frameworks... It's always a tradeoff between making abstract types for hyper-specific things or making very general abstractions that have to absorb a lot of responsibility, which often results in code duplication.

But yeah, interesting stuff. Exciting to see what comes out of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/i18n Translation and customization of plugin messages. blocked/rework Awaiting a larger rework effort. rework/i18n Relevant to the localization rework effort. type/enhancement New or improved feature.
Projects
None yet
Development

No branches or pull requests

2 participants