Forge breaking color.properties

[MastaNub]

Forge breaks color.properties for text.xpbar.
Optifine:
https://imgur.com/a/6boJ7K8
Forge with OF:
https://imgur.com/a/KYrnqaO

[sp614x]

Forge uses a custom experience bar rendering that OptiFine can't directly change.

[MastaNub]

@sp614x is it fixable?

[sp614x]

There is a workaround to fix it, but it may have negative impact on the performance. It needs some testing to check if the FPS impact is noticeable/acceptable.

[MastaNub]

Any progress? 😋

[Invades]

This still appears to happen and is really frustrating, any progress? It's been more than 2 years ever since this bug report.. It would at least be nice to know what the workaround is. (I'm using latest OF preview and forge versions on 1.8.9)

EDIT: I also tried using a couple of OF versions before that and the recommended forge version instead but that didn't seem to change anything. (didn't think it would but I tried anyways just in case)

[Invades]

@sp614x

[Moulberry]

This is trivial to fix.

Mixin example (for L5):
`@Mixin(GuiIngameForge.class)
public class MixinGuiIngameForge {

@Redirect(method="renderExperience",
        at=@At(
                value = "INVOKE",
                target = "Lnet/minecraft/client/gui/FontRenderer;drawString(Ljava/lang/String;III)I"
        )
)
public int renderExperience_drawString(FontRenderer fr, String str, int x, int y, int color) {
    if(color == 8453920) {
        color = CustomColors.getExpBarTextColor(color);
    }
    return fr.drawString(str, x, y, color);
}

}`

The example fix for L6 is more complicated because of default package shenanigans which requires reflection.
I have forwarded the information to the guys over at Sk1er who might be able to implement it in under 2 years.

[ghost]

here's above's fix implemented in asm, which is likely the best way to approach this if you end up fixing it yourself
search for 8453920, add an instruction right after that calling CustomColors.getExpBarTextColor(int), which ends up being CustomColors.getExpBarTextColor(8453920); as you're passing 8453920 right before the method is called

[ghost]

any possibility on this being fixed by the time M5 releases?