Server &3&lLegacy Chat Formatting&r &7- &e&oSome Ideas

[ayunami2000]

I like the ease of use that legacy color codes provide. I propose:

• /taglegacy - Set a tag using legacy formatting codes.
• /togglemm - Toggles MiniMessage versus legacy chat formatting for a player's own chat messages. saved to Plex database for next time.

They do not harm or change default behaviors. They simply allow users who prefer legacy chat formatting codes to use them.

It is my opinion that MiniMessage takes up too much space in the small, single-lined chat box that Minecraft offers. For the character limit as well as the limit on-screen, it is much harder to keep track of your text with MiniMessage than it is with legacy formatting codes.

 

[Telesphoreo]

Object, I don't think we should support legacy. Component / MiniMessage is the future and it's just better to get used to it

 

[mattlawn]

vouch for signs and items

 

[Telesphoreo]

vouch for signs and items

Signs aren't controlled by Plex I believe. We do have ItemizerX but that uses MiniMessage. I'm pretty sure you can use other mods or clients to modify items with legacy that aren't in game though

 

[Allink]

Vouch, while I personally prefer MiniMessage over legacy formatting, I think that this functionality would be useful for people who can't stand/use the verbose nature of MiniMessage. I don't particularly care enough about this topic to argue at length about which one is the superior formatting, and I believe it to be merely a matter of preference.

However, legacy colour formatting is a much more prevalent and well-known system - they've existed for a much longer time than MiniMessage, and as such more people will be familiar with it in comparison to MiniMessage. I don't think you'll meet someone who knows how to use MiniMessage and yet doesn't know how to use/remember common colour codes. The inverse of that is absolutely the case with lots of people - you're going to meet people who don't know what MiniMessage is and yet know the ins and outs of legacy colour formatting. The core audience of MiniMessage at the moment is, as I see it, plugin developers and Paper server administrators. There is next to no usage of MiniMessage outside of Paper and Kyori-relevant platforms.

I don't think there's any reason to not make it available at the very least as an alternative to the current MiniMessage-based system.

 

[ayunami2000]

Just tested, signs use MiniMessage.

 

[videogamesm12]

How about we add a system to Plex that allows modules to optionally add their own "processor" of sorts to the plugin to optionally apply the relevant formatting to a component through an old fashioned for-loop? Processors would obviously need to have some form of detection to avoid wrongfully handling something. If a server owner wants to optionally support legacy components or even markdown, they could simply install the module for it. This also would work for chat formatting as well.

 

[Allink]

How about we add a system to Plex that allows modules to optionally add their own "processor" of sorts to the plugin to optionally apply the relevant formatting to a component through an old fashioned for-loop? Processors would obviously need to have some form of detection to avoid wrongfully handling something. If a server owner wants to optionally support legacy components or even markdown, they could simply install the module for it. This also would work for chat formatting as well.

I think all of the "processors" we want are already expressed in Adventure itself with the component serializer implementations provided by Paper, so ideally there isn't much of a need to abstract it into yet another group of modules - it should be, ideally, something we add to Plex itself and allow configuration of at the user's discretion.

 

[Kaddicus]

Vouch, yes MiniMessage has its benefits, but there's no reason to not support Legacy. "MiniMessage is the future" isn't reason enough imo.

 

[Alco_Rs11]

I Vouch. Legacy is what 99% of players are accustomed to and I doubt people will be willing to learn minimessage just so they can set a nickname or tag. Minimessage is cool, especially for plugin configurations and other applications like that but honestly, it's incredibly impractical for usage in commands such as /tag.

 

[Taah]

So we can do the hacky way of what I did in the TFMExtras module and convert each legacy code to its minimessage equivalent so then we can treat it as a proper component thereafter by deserializing with minimessage, removing checks, etc.
Would look like this:

        String text = PlexUtils.cleanString(PlexUtils.getTextFromComponent(event.message()));
        text = text.replace("&a", "<green>")
                .replace("&b", "<aqua>")
                .replace("&c", "<red>")
                .replace("&d", "<light_purple>")
                .replace("&e", "<yellow>")
                .replace("&f", "<white>")
                .replace("&1", "<dark_blue>")
                .replace("&2", "<dark_green>")
                .replace("&3", "<dark_aqua>")
                .replace("&4", "<dark_red>")
                .replace("&5", "<dark_purple>")
                .replace("&6", "<gold>")
                .replace("&7", "<gray>")
                .replace("&8", "<dark_gray>")
                .replace("&9", "<blue>")
                .replace("&0", "<black>")
                .replace("&r", "<reset>")
                .replace("&l", "<bold>")
                .replace("&o", "<italic>")
                .replace("&n", "<underline>")
                .replace("&m", "<strikethrough>")
                .replace("&k", "<obf>");
        //Process the text String by converting it back to a Mini component

 

[ayunami2000]

So we can do the hacky way of what I did in the TFMExtras module and convert each legacy code to its minimessage equivalent so then we can treat it as a proper component thereafter by deserializing with minimessage, removing checks, etc.
Would look like this:

        String text = PlexUtils.cleanString(PlexUtils.getTextFromComponent(event.message()));
        text = text.replace("&a", "<green>")
                .replace("&b", "<aqua>")
                .replace("&c", "<red>")
                .replace("&d", "<light_purple>")
                .replace("&e", "<yellow>")
                .replace("&f", "<white>")
                .replace("&1", "<dark_blue>")
                .replace("&2", "<dark_green>")
                .replace("&3", "<dark_aqua>")
                .replace("&4", "<dark_red>")
                .replace("&5", "<dark_purple>")
                .replace("&6", "<gold>")
                .replace("&7", "<gray>")
                .replace("&8", "<dark_gray>")
                .replace("&9", "<blue>")
                .replace("&0", "<black>")
                .replace("&r", "<reset>")
                .replace("&l", "<bold>")
                .replace("&o", "<italic>")
                .replace("&n", "<underline>")
                .replace("&m", "<strikethrough>")
                .replace("&k", "<obf>");
        //Process the text String by converting it back to a Mini component

don't forget hex (&#123456)

 

[Taah]

don't forget hex (&#123456)

Hex will be done using minimessage, it makes more sense imo lol and it's not very different (<#abcdef>, <#123456>)
As for colors, https://github.com/plexusorg/Plex/c...4cd9b534f0d192de88cf138728179a4c594efd141f32b adds this in for the 1.4 future update of Plex so tags will support both mini and legacy

 

[xen]

Vouch. People should should be able to use either one.

 

[videogamesm12]

Quite a bit has changed since this suggestion was created. Tags and chat messages now support legacy color codes alongside MiniMessage.

Is this suggestion still necessary?