Add of new minecraft colours

[roimee6]

Introduction

Minecraft has just added the colours that are linked to the materials

Tests

[dktapps]

Related to #2988 - due to this change we'll no longer be able to use underline or strikethrough codes on the terminal

[dktapps]

Labelling this as blocked, since it causes breakages to other features. The discussion what to do about that hasn't been resolved yet.

[Yexeed]

Is it possible to reopen this now since #2988 is closed now? Or it wasn't the reason why this got blocked?

[dktapps]

No, the issue of being unable to use certain formatting codes on the server still exists, as well as changes in behaviour for any existing code

[Yexeed]

Well, then, why don't just add new codes and do not remove deprecated ones? They are counted as deprecated in MC ecosystem for a very long time already, so as for my opinion, adding new codes will:

• support textformat methods such as colorize(), tokenize() and clean()
• console will also have new codes since rgb sources are now available on wiki.

Cons:

• well, yes, the deprecated striketrough and underline still exists in textformat, but - are supported by the console.

So there is no 100% need to remove/deprecate them, and they will exist for unknown period of time, just as they are now, but the devs will get the ability to use new codes in api.

That's how I see the issue. I accept the fact that I may have missed something, that's alright, you may point me directly to the problems that I'm not aware of

[dktapps]

We can't have them conflicting with strikethrough and underline because the console won't be able to use them. That's the whole problem.

[dktapps]

For completeness, a collection of proposed solutions for this problem:

1) Don't add the new constants

Doesn't seem like a good option - these new things aren't going to go away, and we still have problems without them, as people already use the new codes just by using their § codes directly

2) Add the constants, but allow them to conflict

Users of the underline & strikethrough constants will get unexpected formatting on clients, & console wouldn't know whether to use formatting or new colours

3) Custom formatting codes to support underline & strikethrough on the console

Presents the possibility for any custom codes to conflict with new Minecraft codes in the future
Raises migration questions if these were used in code for the terminal if Minecraft later decided to support them
Needing strings to be preprocessed to strip out custom codes before sending to clients (not a big deal)

4) Drop underline & strikethrough support via TextFormat & set the constants to ""

Losing support for strikethrough & underline on terminal via TextFormat, although technically they'd still be available by using Terminal properties directly - however this would be a bit crap if we wanted to use them internally

This would minimize the impact to users of the constants as some formatting would just disappear on the terminal, but this impact is probably minimal.

We could also add TextFormat::javaToBedrock() for cleaning up hardcoded formatting codes - right now this would just strip out underline & strikethrough codes (to prevent incorrect formatting), but if Bedrock gained support for the missing codes later on, it could replace them to the Bedrock ones as appropriate.

I'm currently leaning towards option number 4 as it seems like the least likely to cause problems, but it does mean that we lose some functionality.

[ipad54]

This is probably was done by accident

[dktapps]

Yeah, but the PhpStorm formatter does this and there doesn't seem to be a way to stop it. I've stopped trying to fight with it at this point.

I guess this is the price we pay for maintaining a non-standard code style...