ServerListPlus fork won't support more than 3 hex color codes per motd line

[MithrandirCraft]

Hey, this is in regards to your ServerListPlus fork supporting hexadecimal color codes through your MineDown library, on mc 1.16.3, waterfall (bungee).

I'm asuming the library is shaded into your SLP fork, and all I need in addition to your fork is ProtocolLib updated.

In ServerListPlus.yml, configuring an motd like this:

Personalized:
  Description:
  - |-
    &aM&#55FF55&i&#55FF55&t&#55FF55&h&#55FF55&randircraft
                  &#2CFF00&¡Hola de nuevo &l%player%!

will make the 4th hexcode on the first line show as text instead of formatting the following text.
Only setting 3 formatting hexcodes will work fine. It seems like there's a per-line limit. It also doesn't matter if the hexes are diferent, I set them all to the same because I was trying to figure out what's wrong.
The second line works fine, and it's not because it's a diferent hex, but rather that it's a new line.

Also, I had to set the first letter's (M) color with a regular standard minecraft color code, because it wouldn't work otherwise for whatever reason (that's another issue).

I wanted to make some gradient-like effects, but I can't like this. Am I doing it wrong or is there an issue / limitation here?

In essence, how do you make gradients using your fork? Is it even possible?

[Phoenix616]

Gradients and colors at the beginning definitely work, they are not a limitation with the library itself. (I use that myself for my server) However I am using the Bungee version and never tested the Bukkit one so there might be an issue there. I'll have to investigate that and maybe it's a ProtocolLib issue but that's hard to say without me testing it (if so I'll transfer it to the other repo, no reason to make a new one myself)

[MithrandirCraft]

I'm using this on Waterfall, and the ProtocolLib version was the latest dev build.

[Phoenix616]

Oh for some reason I thought you were using this on the Minecraft server, my bad. In that case ProtocolLib has no influence whatsoever on this.

[Phoenix616]

I cannot reproduce the issue in the latest MineDown. I've updated the version used in my ServerListPlus fork, please check if that already solves your issue. If not then this might be a MOTD-specific issue :S

[MithrandirCraft]

Using the last version of your fork + protocollib on waterfall, but the 4th hex onward, I mentioned from SLP's motd configuration won't work, could I be missing something?

[Phoenix616]

Using the last version of your fork + protocollib on waterfall, but the 4th hex onward, I mentioned from SLP's motd configuration won't work, could I be missing something?

As already said: ProtocolLib has nothing to do with the issue, it doesn't even run on Waterfall.

You can always try using the events syntax and see if that works better.

[MithrandirCraft]

The proposed alternate method seems to work fine.

[Phoenix616]

There actually might be some oddities with the rgb legacy-like format then and not the MOTD :/

[Andre601]

While we are at the topic of the SLP fork here (I don't want to create a separate, unrelated issue here as the fork doesn't have issues open)

Wouldn't it be beneficial to have direct support for MiniMessage at this point?
It becomes fairly popular and has features such as Gradients, which is something I personally would like to utilize.

From all the things is the Gradient really the one feature I currently miss here...

[Phoenix616]

While we are at the topic of the SLP fork here (I don't want to create a separate, unrelated issue here as the fork doesn't have issues open)

Wouldn't it be beneficial to have direct support for MiniMessage at this point?
It becomes fairly popular and has features such as Gradients, which is something I personally would like to utilize.

From all the things is the Gradient really the one feature I currently miss here...

Please either open an issue on the SLP fork if your request is related to that (although I will never add MiniMessage support, I simply don't like its syntax and prefer my own MineDown one. Of course I can't stop anyone from forking) or open an issue on MineDown to request gradient support officially. (Which is already on my to do list though and will be implemented once I find the time and a good solution for it.

[Andre601]

Please either open an issue on the SLP fork if your request is related to that (although I will never add MiniMessage support, I simply don't like its syntax and prefer my own MineDown one. Of course I can't stop anyone from forking) or open an issue on MineDown to request gradient support officially.

This proofs to me that you didn't even bother to read my message as a whole, otherwhise you would've spotted the "(I don't want to create a separate, unrelated issue here as the fork doesn't have issues open)" in my message.
I would've created an issue there if you allowed that in the first place.

And that you don't like MiniMessage's syntax is imo not a valid reason for others to not have support for it. You don't have to use it for your purposes, but since this is pretty much the only fork I know of, which supports HEX colors, do people have to use this one, if they want to keep SLP... So what if another person comes and askes for this? And then another one? And then again?
MiniMessage is by far one of the more popular and well used libs for colors, so I highly doubt people would prefer your syntax (that doesn't even work right when the code ends on a valid legacy color/formatting code. See #9) over the one of MM.

But this was just my response to this. Do with it what you want.

[Phoenix616]

This proofs to me that you didn't even bother to read my message as a whole, otherwhise you would've spotted the "(I don't want to create a separate, unrelated issue here as the fork doesn't have issues open)" in my message.
I would've created an issue there if you allowed that in the first place.

I read your message and enabled the issues on that repo when I posted my original reply. Sorry for not making that clear in my reply.

And that you don't like MiniMessage's syntax is imo not a valid reason for others to not have support for it. You don't have to use it for your purposes, but since this is pretty much the only fork I know of, which supports HEX colors, do people have to use this one, if they want to keep SLP... So what if another person comes and askes for this? And then another one? And then again?
MiniMessage is by far one of the more popular and well used libs for colors, so I highly doubt people would prefer your syntax (that doesn't even work right when the code ends on a valid legacy color/formatting code. See #9) over the one of MM.

But this was just my response to this. Do with it what you want.

Well I will continue using my syntax for the plugins I use. If someone else wants to use a different syntax in their plugins then they are obviously free to do so but I will not waste tons of my free time trying to integrate third party libraries that I didn't design or have any experience in (and which's syntax I really don't like) into plugins that are already working for my own use case. (Which all my free plugins are designed for: What I need on my own Minecraft server)

Your options here are pretty clear:

• Create your own fork of SLP and implement MiniMessage
• Open an issue on some SLP repo requesting MiniMessage support and hope that someone will get around doing it for free
• Pay someone to do so

And if you have issues with MineDown itself then feel free to open a ticket describing it in detail and I will get around to it once I find the time and frame of mind working on that.