mezz

I misinterpreted the purpose of this return value. There is no bug, please close this issue.

This was fixed in 1.12 during the move to data driven recipes.

This has been recently fixed in Forge for 1.12. The code might be useful for analysis of this bug.
https://github.com/MinecraftForge/MinecraftForge/commit/32e811bd7a72efc59dd05c89775e62de908070ce

After discussing this with others, we think the best solution is to break up these lists so they are indexed by chunk.
That way, an unloaded chunk can just drop its ticking list and there is no slow remove on a giant list.
It could also make finding nearby entities more efficient.

Confirmed in snapshot 16w50a

In snapshot 16w50a the behavior is different but still incorrect:

Every number format is Locale.US style and ignores both the system (JVM) language and the Minecraft language.

When the Minecraft language is set to French it should display numbers like "1 000 000" and "1,00" but instead it uses the US style "1,000,000" and "1.00".

I have confirmed this issue in 1.11.

There are two bugs:

1. decimal places are formatted using the system (JVM) locale instead of the language set in Minecraft

2. grouping separators (thousands place) is always formatted with a NumberFormat.getIntegerInstance(Locale.US), hard coded.

To replicate this bug you can override the system (JVM) locale to French with these arguments on the command line:

-Duser.country=FR -Duser.language=fr

In all cases, the system (JVM) language should be ignored and the Minecraft language should be used for formatting.

With English language in Minecraft, and French system language, numbers should be formatted like this: "1,000,000" and "1.00" but they show up with the format "1,000,000" and "1,00" instead.

With French language in Minecraft, and English system language, the numbers should be formatted like this: "1 000 000" and "1,00" but they show up with the format "1,000,000" and "1,00" instead.

When this issue is fixed, the French non-breaking-spaces will be used properly and it will expose this bug as well: https://bugs.mojang.com/browse/MC-2595

Can this please be reconsidered as a minor bug?
Forcing Anistropic Filtering generally does not cause artifacts in other games.
I was able to force Anistropic Filtering some time ago without any visual artifacts (I think 1.6.4) and it really improved the look of distant textures in Minecraft.

Confirmed in 16w44a

Confirmed in 16w44a

ahl.class

public class ahl
{
    private final Object[][] a;
    
    public ahl() {
        this.a = new Object[][] { { als.R, new afh(afj.n, 9) }, { als.S, new afh(afj.m, 9) }, { als.ah, new afh(afj.l, 9) }, { als.bT, new afh(afj.bZ, 9) }, { als.y, new afh(afj.be, 9, aek.l.b()) }, { als.cn, new afh(afj.aF, 9) }, { als.cA, new afh(afj.k, 9, 0) }, { als.cx, new afh(afj.R, 9) }, { als.cE, new afh(afj.aU, 9) } };
    }
    
    public void a(final ahn \u2603) {
        for (final Object[] array : this.a) {
            final alr \u26032 = (alr)array[0];
            final afh \u26033 = (afh)array[1];
            \u2603.a(new afh(\u26032), "###", "###", "###", '#', \u26033);
            \u2603.a(\u26033, "#", '#', \u26032);
        }
        \u2603.a(new afh(afj.n), "###", "###", "###", '#', afj.bF);
        \u2603.a(new afh(afj.bF, 9), "#", '#', afj.n);
    }
}

Sorry for the edits, I initially confirmed with 16w42a instead of 16w43a.

Here is the obfuscated code from the 16w43a jar, confirming the bug without Forge.

ahj.java

public class ahj
{
    private final Object[][] a;
    
    public ahj() {
        this.a = new Object[][] { { alq.R, new aff(afh.n, 9) }, { alq.S, new aff(afh.m, 9) }, { alq.ah, new aff(afh.l, 9) }, { alq.bT, new aff(afh.bZ, 9) }, { alq.y, new aff(afh.be, 9, aei.l.b()) }, { alq.cn, new aff(afh.aF, 9) }, { alq.cA, new aff(afh.k, 9, 0) }, { alq.cx, new aff(afh.R, 9) }, { alq.cE, new aff(afh.aU, 9) } };
    }
    
    public void a(final ahl \u2603) {
        for (final Object[] array : this.a) {
            final alp \u26032 = (alp)array[0];
            final aff \u26033 = (aff)array[1];
            \u2603.a(new aff(\u26032), "###", "###", "###", '#', \u26033);
            \u2603.a(\u26033, "#", '#', \u26032);
        }
        \u2603.a(new aff(afh.n), "###", "###", "###", '#', afh.bF);
        \u2603.a(new aff(afh.bF, 9), "#", '#', afh.n);
    }
}

I contribute code to Forge. It does not edit this class, this is a vanilla issue.

I am only using Forge to look at the code in a convenient way, this issue exists in vanilla.

I confirmed this is still an issue in 1.10.2, but I cannot check snapshots because Forge is only available for release versions. Is that ok?

Oh never mind, I see you reopened it. I was only searching open issues.

Thank you.
I think I wasn't able to find that issue because it says "mimap" in the title which is misspelled, it should be "mipmap".

I selected it, which was a mistake.
I'm not sure why other people are arguing about it.
Thanks FVbico.