Closed Andre601 closed 3 years ago
I cannot reproduce this when testing it in MineDown and there even is a test for a similar case. (A color character after the end of the hex code) Which build of ServerListPlus are you running?
It was the latest dev build from the Jenkins (from 14th of november) which is 35
Also, perhaps try a test with the full hexadecimal code and not just the short one?
Also, also, this may even be an issue with SLP in the first place. Perhaps it applies chat colors before any minedown rendering is done? This issue should perhaps be transfered to the SLP fork's repo.
Also, perhaps try a test with the full hexadecimal code and not just the short one?
That is the next test after that and I also tested your exact config value which produced the correct coloring. The only thing I can think of is that this is either an issue in SLP directly like you mentioned or that the build includes some older MineDown version as I remember that there were some issues regarding the compile.
This is most likely the cause as when the Lib works as intended, then it has to be the plugin at the very least.
Yeah, I checked it and you are completely right, it replaces the color codes before MineDown even gets a chance to convert it itself. Gonna move this to the SLP repo (or not I guess, you can only transfer issues to repos by the same user/org :S) and see if I can find a fix for it.
Used Version
Using MineDown through ServerListPlus fork 3.5.0-SNAPSHOT
Config
Environment description
Ubuntu 20.04 PaperMC 277 (MC 1.16.4
Full Log
What other programs/plugins are you running?
What is happening?
When using the
&<code>&
syntax for defining colors such as HEX colors does it seem to first parse legacy colors followed by the codes, which may have been broken due to this fact.As an example, the line
&7[&#F39C12&1.16.4&7] &#F39C12&PowerPlugins.net
appears like this:My guess is, that MineDown, if responsible at all, parses legacy colors, such as &1 first, which turns the ampersand into a section symbol (§) which therefore breaks any
&<code>&
color code.What did you expect to happen?
MineDown should first parse its own custom color formats to prevent any unwanted overrides happening.
Additional context