proghealer
Assigned
Reported
Comments
This issue is about CJK Input Method Editor (IME) not functioning; your problem is about console output, and probably is not limited to CJK texts (since yours is an encoding problem.) Please do not confuse two different problem that happens to both affect CJK texts.
Apparently you did find the appropriate bug to your problem (MC-157942 and MC-197483), and also this issue is closed, so I'll just leave this message to inform you about this.
This is not about the specific translation within some language (which crowdin provides), but about the sorting order of the list of languages in the game (and not the launcher).
The problem is, Mojang people probably have no idea where's the problem and how to fix it.
MC-2781 got resolved only because I looked into a (possibly) hack done by another Taiwan player and rephrased it here, and the Mojang person "fixed" it probably just did what I said. (I inspected the bytecode after the fix; they are not exactly the same logic but good enough to make it work.)
Quote the description:
I think the community users and Mojang should work together to completely resolve this issue.
Too bad I don't have any experience using LWJGL to develop games so I can't give much help other than spread the word.
This is duplicate of MC-176029. Don't know if it's WAI or not though; the sentence quoted above only says about one compass.
The description of the advancement is changed to "Sleep in a bed to change your respawn point"; it explicitly says "sleep in a bed", ie. the intended condition is the action of sleeping in a bed, not resetting respawn point. Besides, 20w12a adds yet another way to reset spawn point (in the nether) so the clarification is needed anyway.
MCL-10094 found out the critical number is 10. If you have at least 11 profiles, it will not sort; if you have 10 or less then it's fine.
The count 10 includes "Lastest Snapshot" if you enable snapshots.
Affects version 2.1.1462 on Windows.
Affects "sort by last played" as well: the order is not either ascending or descending with respect to both "created" and "lastUsed" field in launcher_profiles.json. I have an old profile with both field "1970-01-01T00:00:00.002Z" (this AFAIK comes from old launcher profiles) sorted first in "sort by last played" order, before "Latest Release" and "Latest Snapshot".
ย
16w03a: Now they both says container.minecart. In en_US.lang there's new entry for container.minecart.hopper and container.minecart.chest so this might be some kind of string index error.
Um...fixed? I still see "Minecart" in 16w02a. Or is something should say there instead?
On a may-not-be related note: renamed minecart with hopper and minecart with chest shows their name properly in both 1.8.9 and 16w02a.
Traditional Chinese IME on Windows is confirmed fixed as well.
As Joongi Kim pointed out, Mac issue is in another way; in fact, since the patches in the link I provided above also not working on Mac, those patches may aimed at Windows users only.
Anyway, many thanks to Grum on fixing this bug! ๐
Washing leather armor and washing banner both uses water in cauldron, but have different behavior. IMO we should choose one of the two behavior and change the other one to it; I'd prefer the leather armor way, but this is up to the developer.
And even if this behavior is intended, that washing a banner when survival inventory is full do not give the washed banner is surely a bug. At least it should throw out the washed banner to the world.
As an update, in 15w42a the reported behavior does not change.
Tried on both 15w31b and 15w31c.
15w31b has this problem the other way around (as described in MC-83883): It dupes banner in survival but not creative.
15w31c goes back to what we had here: It dupes banner in creative but not survival.
So this is still an issue in 15w31c.
There is a post on ๅทดๅๅง็น (One of the biggest gaming forum in Taiwan) a few months before this bug created:
http://forum.gamer.com.tw/C.php?page=1&bsn=18673&snA=35796 (Traditional Chinese)
The op provided class file replacement (for release versions) which when patched (using the old-school replace-file-in-jar method), this problem is fixed. This post is continuously updated with new releases, currently providing fixes for 1.7.2 through 1.8.2-pre4 before the post was locked by board mod when other users replying to this three-year-old post. He posts later updates on his user page of that site:
http://home.gamer.com.tw/homeindex.php?owner=a0918430588 (Also Traditional Chinese)
Recently I finally got some time to work out what he did to the class to fix the problem. Here is what I found.
Take the 1.8.3 patchfile he provided for example: The method he changed in axv.class is l(). This method is roughly like this:
public void l()
{
if(org.lwjgl.input.Keyboard.getEventKeyState())
{
this.a(org.lwjgl.input.Keyboard.getEventCharacter(), org.lwjgl.input.Keyboard.getEventKey());
}
this.j.Z();
}(I javap'ed the class file and recreated the method from bytecode by myself; fortunately this method is very small โ only ten bytecode instructions. For the same reason, the class name / method name is the obfuscated name except the calls to LWJGL.)
He changed this method to become:
public void l()
{
char ch = org.lwjgl.input.Keyboard.getEventCharacter();
if(ch >= 32 || org.lwjgl.input.Keyboard.getEventKeyState())
{
this.a(ch, org.lwjgl.input.Keyboard.getEventKey());
}
this.j.Z();
}(Again, this is recreated from javap result by myself. ch is using a local register to store, so I reckon he had a local variable for it; the name ch is arbitrarily chosen.)
This fixed the problem.
I havn't used LWJGL before, so I don't really know why this fixed the problem; my guess is that since we need multiple keystrokes to enter one character, the event getting the character is different from the keystroke event. (I have a wild guess here: in this case, LWJGL only get the final character event; the intermediate keystroke events are eaten by IME. I don't know if this is true or not.) Since the character event is not associated with any key, its getEventKeyState() return value is meaningless and probably LWJGL just return false in these case, which then causes l() to discard this event.
Hope this information can help Mojang developers to fix this problem once and for all.
This is still a problem in 1.8-pre1.
Also, when the survival inventory is full, you didn't get the washed banner.
In any case, the water in cauldron is not used; on the other hand, the water is used when washing a leather armor.
For those who haven't heard of it, Mojang says in 1.21 pre-release 1:
If I'm not mistaken, this feature starts from this bug report. Since this feature is currently temporarily removed, it is reasonable to reopen this bug report to continue keeping track.