Minecraftforge: [1.13] Color codes render invalidly in Eclipse console.

[Darkhax]

Messages printed to the console in Eclipse have some invalid characters appended to the start. Running the game using ./gradlew runClient does not show these errors. It looks like these characters are part of the line color codes.

[00:01:17.863] [Client thread/INFO] [minecraft/TextureMap]: Max texture size: 16384
[00:01:19.387] [Client thread/INFO] [minecraft/TextureMap]: Created: 512x512 textures-atlas
[00:01:21.711] [Client thread/WARN] [minecraft/GameSettings]: Skipping bad option: lastServer:
[00:01:21.942] [Client thread/INFO] [mojang/NarratorWindows]: Narrator library for x64 successfully loaded

Forge: 24.0.147
MC: 1.13

[tterrag1098]

They are ANSI console color codes, and they don't work in a lot of terminals. This feels like something that should be specific to intellij setup.

[autaut03]

Was removing highlighting necessary? It was so much easier to read the console with actual colors :/

[LexManos]

Feel free to PR a better solution, Something that works on all consoles and doesn't leave invalid characters in eclipse, powershell, and cmd.

[cpw]

I 100% agree. This change is stupid.

[LexManos]

Then feel free to fix it properly, i personally hate colorful consoles. And detest the convaluted nature that is log4j. You know that. I feel something functional is more important then something pretty. But be sure to test it on something other then linux.

[autaut03]

I don't know of a proper way to fix it, that's left to other contributors, however I'd still like to leave few words about this issue.

The change only affects Forge itself, meaning that the only two places where we can see these characters are when running the client and running the server. These two are usually ran from an IDE and rarely from a console.

There's IDEA, which supports color codes. There's Eclipse, which supports them with a plugin. Maybe <1% of VS Code users, which most likely also supports the codes. PowerShell supports them as well. Windows' CMD, even though it shouldn't be used at this point, also does.

Besides a little fixable problem with Eclipse, everything on my Win10 machine supports color codes. But even if something doesn't support them, is it really that much of a problem? A couple of wierd chars at the beginning of each line doesn't really change much, especially considering that not supporting these characters is mainly a problem of console implementations, not logger's.

I feel like the change should be simply reverted, and instead a note should be left somewhere saying "Install plugin X or switch to other IDE"

[LexManos]

"Install Plugin X" is not a solution. The ONLY officially targeted IDE is bog standard Eclipse. No plugins or extensions. IntelliJ support is a secondary thing added by others in the community.
As for not using cmd, sorry but the main developer of this project uses it as the main interface outside of Eclipse. So no matter your opinion it still matters.
And for your note about 'rarely from a console' You do realize this effects end users right... They ALL run them from a console of some kind. Clients not so much. But servers most definitely.

cpw will be addressing this, he has been instructed to make sure it works properly in ALL environments. If it doesn't, it shouldn't be pushed. As I've stated. I care ZERO about fancy colors and I fixed a issue that was reported. I just want something that works, without spamming gibberish into the console. If that means we strip out all highlighting then so be it.

[autaut03]

Okay, Eclipse is outside of this issue's scope. Still, "gibberish symbols" are more than fine from my point of view. That's the price for using outdated tools (and I can call it that if even CMD supports colors). But again, it is out of my control, that's why I said that I can't do anything about it.

And ALL consoles support colors, besides Eclipse. So how does it affect end users?

Sure, it should work properly in all environments. But if the only way to do that is by removing useful features, just to support that one old thing that doesn't care, then there might be something wrong with this kind of a "solution".

[jaredlll08]

"it's more than fine from my point of view" says the person who doesn't have to deal with the weird symbols.

At the end of the day, I, as an IDEA user don't really want IDEA specific features, it should work exactly the same on all IDEs, people shouldn't have a worse experience just because the IDE they are comfortable using doesn't support a cosmetic feature.

[mezz]

We had it working before with these PRs: https://github.com/MinecraftForge/MinecraftForge/pull/4802 https://github.com/MinecraftForge/MinecraftForge/pull/4821
That stuff was thrown out with the 1.13 update, but the code can probably be scavenged from there easily enough.
The basic idea is to detect if the terminal supports colors and only use them if it does, but there is a decent amount of logic required to do it well.

[autaut03]

who doesn't have to deal with the weird symbols.

Well, I can still imagine what it's like.

don't really want IDEA specific features

Neither do I. I want the code to be as simple as possible while maintaining it's goals, but we shouldn't sacrifice useful everyday features because a 3rd party service fails to implement them. It's not something "IDEA specific" - no, it has nothing to do with IDEA or JetBrains at all. They are ANSI codes, supported by other IDEs, by built-in windows consoles (cmd, powershell), every popular terminal on linux and macOS. This is a standard, chosen by Apache wisely; not created out of thin air. It is literally supported by everything, and other projects (even not Java ones, and even much bigger than Forge) use them everywhere. What I mean is that it's not Forge's, log4j's or IDEA's problem; it's Eclipse's.

LexManos stated above that it's officially supported, and IDEA is not. I can neither decline it nor agree with it, because I only recently started modding; however, I will have to say that projects aren't usually IDE-bound. Neither is Forge. It mustn't rely on it, or try to compensate for missing features, because it's left to decide for the end user. That's exactly why in Forge docs there's a section about IDEs, saying, quote: "Depending on your favourite IDE, there is a different set of recommended steps" and two IDEs are listed below.

Once again, I'm sorry if I'm wrong, but I don't see anything regarding "official" IDE. They both have a step-by-step guide on how to start a project with them, and I can't think of any reason of prioritizing a specific tool that's not even relevant to the project itself.

This went out of this issue's scope; however, that doesn't mean it shouldn't be taken into consideration.

[mezz]

Forge has configured log4j to send color characters to terminals that do not support them.
That is the issue, let's not discuss IDE support.

[jaredlll08]

"I want the code to be as possible"
The simplest code that Lex saw was removing it, rather than spending hours installing a bunch of IDEs making sure that each of them work correctly, for a cosmetic feature that he doesn't even like.

Also after looking at it more, it appears that I mislead myself, I've had coloured logs in IntelliJ for a while now, never thought it was Forge doing it until I saw this issue, but apparently (looking at the code, please correct me if I'm wrong), this is only a thing in 1.13+, not 1.12, which is what I have been primarily using, so I guess it's the Minecraft Modding plugin for IDEA that's adding it.

Since you have no problem forcing eclipse users to install a plugin, you should be happy to install one yourself that adds this yea?

In all seriousness, a possible fix would be making this an opt in system similar to how Mezz's last commit to the file on the 1.12 branch works, use environment variables to tell log4j to use highlighting, it may not be the simplest thing, but it solves the potential issue of having to figure out if someone has a plugin installed that adds colours support.

Lastly, you really should learn to read logs without the use of colours, pastebin/gist/notepad++/(whatever program you end up viewing crash logs in) most likely won't support ansi colours like this, so when people start sending you game logs, you won't have colours to help you navigate it.

[mezz]

cpw has added a lot of good logger commits to the 1.13-pre branch today, please check it out instead of debating the merits of various logging related things. I know it's well-intentioned, but y'all are adding a lot of noise to an otherwise pretty straightforward issue.

[autaut03]

Thank cpw for reopenning and fixing the issue. I hope it would get resolved and closed soon.

Meanwhile, I'll leave my short response here, as github doesn't have another way of communicating, sadly. It's still relevant to the issue.

The simplest code he doesn't even like

The simplest was to just leave as is. It wasn't critical at all, and, as I way saying, is Eclipse's problem.

that's adding it

I'm not sure about 1.12. For 1.13 though, colors wouldn't show even with the plugin installed. Yes, if IDEA had this problem I would insist on forcing its users, even if it included myself, on installing a plugin, because that's one of the reasons they exist.

people start sending you game logs

File logs shouldn't have the colors for this reason. I won't have colors in production logs, but at least I will during the development.

[mezz]

Stop

[liach]

The log4j config is something you can specify with a system property, just like -Xmx4G. You should do it on your own; it is not really forge's business to fix it. Log4j is file/console aware as well; you can learn that from the example mojang log4j config.

[autaut03]

For those wondering, with recent changes from cpw, you can enable color codes in your project this way:

build.gradle -> minecraft -> runs, set property forge.logging.noansi to a string false, like this:
properties 'forge.logging.noansi': 'false'

Do that for every run configuration you want. There are probably other ways that I'm unaware of, maybe some that are more environment-dependent or/and more correct, but this should be fine, as ForgeGradle follows this way of setting properties for logging.

[tterrag1098]

Thank you for that explanation. As this is resolved, closing.