I am unable to reproduce this issue in 24w03a.
Can confirm. When first opening a container, you cannot hold an item and shift-double-click to move all stacks from one container to the other. Only after an initial shift-single-click can you then shift-double-click to move all the stacks.
Further, once you can shift-double-click, you can only move the item type that you moved with shift-single-click regardless of what items you shift-double-click on.
I disagree with this being considered "reasonable". Place 1 flower, pick up 3-4 flowers. Hundreds of duplicated items in minutes.
The same cycle can be exploited between a Cartographer an Librarian, buying Glass blocks and selling Glass Panes.
With the 1.14.4 release, the issue has returned. Raw Input "Off" does solve the problem" for me.
As of 1.14.3, this issue seems to have been resolved. I can no longer reproduce this issue.
Your world appears to be corrupted, and may require a restart to fix. If you can't restart that world, you may find it quite buggy, and suffer from unexpected crashes. Best of luck.
Actually, this isn't a local system problem at all. The file hosted on the UK cloud server has an invalid checksum, and needs to be updated.
As a reminder, there are two possible outcomes caused by non-ANSI characters in the Windows userpath:
Under default conditions, the user will receive the following: Error: Could not find or load main class net.minecraft.client.main.Main
When using the --workDir argument avoid the Windows userpath, the user will receive the following: java.lang.UnsatisfiedLinkError: Failed to locate library: lwjgl.dll
@unknown, the bug report includes two conditions and two outcomes. One condition is a vanilla state, whereas the other is using --workDir (which should be a workaround for the initial crash, but instead produces a different unexpected error).
Note in the last paragraph, the specific logs are matched to the tests. Your confusion results from mismatching tests and log results. If you'd like more or specific logs, I can happily produce them. Edit: To help clarify things, I've attached both Launcher_log files (with and without the --workDir argument).
My goal here is to focus on the underlying issue: common characters from certain languages prevent the game from running. This results in two distinct outcomes, depending on how the game is run. This bug report illustrates both.
Invalidating and moving my post is certainly fine, as long as we don't lose track of the broader issue and both errors that result (not just the single error listed in the target bug report).
Thank you for the reply, Neko. These are not the solutions. I am testing with both the bundled Java and a clean install of jre1.8.0_181. Both produce the same error. I do not have D3Dgear installed. I have tested with several versions of Nvidia drivers, including 398.82 and 416.34 (latest version, clean install) for my 660Ti, all with the same result.
Again, 1.13.1 runs without any error. Only 1.13.2 and 18w43b produce the error.
I'm having exactly this same issue.
1.13.1 and older run just fine. 1.13.2 and 18w43b both crash shortly after pressing play roughly 90% of the time (when it does run, play is normal until I exit). No game log (latest.log) or crash report are created. The launcher game output states:
monitor | Process Monitor | Process crashed with exit code -1073741819 |
The launcher log does contain the error and stops here:
[1025/131816:INFO:GameCallbacks.cpp(199)] game/cft (Client thread) info LWJGL Version: 3.1.6 build 14
[1025/131819:INFO:GameCallbacks.cpp(199)] launcher/launcher (main) info
[1025/131819:INFO:GameCallbacks.cpp(199)] launcher/monitor (Process Monitor) fatal Process crashed with exit code -1073741819
Minecraft IRC support was unable to identify any issues with the computer and is suggesting that I reload Windows. However, Since 1.13.1 and older run without error, I am having difficulty accepting the the issue is with the system when the failure is specific to the last two versions.
EDIT: I've attached the Windows event log, which points to lwjgl.dll
@@unknown , I've tested your modified GLFW and it does indeed fix the issue with both RDP and KaVoom. Your efforts are stunningly impressive. I appreciate that this will take some time to filter it's way into the official release.
This issue occurs on 1.12 PreRelease-7. Screenshots at standard 4:3 @ 1280x960:
http://i.imgur.com/jO34iZa.png
http://i.imgur.com/frxyDLe.png
I think the issue is Minecraft calculating the Auto GUI scale by the size of the normal inventory, thus (mostly) setting the GUI scale to Large which leads to the recipe book overlapping the inventory on 4:3 screens.
In fact, this is exactly it. at the 1280x960 resolution I was testing, "Large" works fine but "Auto" sets the GUI scale to a size larger than "large" and the inventory subsequently fails. This isn't the only failure, as a number of option menus are also cropped on the sides.
Having said that, I suspect "Auto" being the real problem makes this report a duplicate of MC-37839.
Maria Lemon, This issue occurs when you select any 4:3 aspect ratio. Here is a screenshot of 1.12-Pre6 at 1280x960: http://i.imgur.com/KUjPzjF.png
If this were happening at some wacky resolution that no one uses, this might be a non issue. The trouble is, this happens at the default 4:3 monitor resolution and impacts a meaningful number of people.
confirmed for 17w18b
http://i.imgur.com/K0velE2.png
Testing with 17w14a. This issue still happens.
Game set to 1024x768. Open crafting table. This is the resulting GUI: http://i.imgur.com/RrN1lkk.png
I can still duplicate the issue in 24w10a
Edit: Still happening in 24w11a