Selicre
- hyperpony
- hyperpony
- Europe/Moscow
- Yes
- No
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
WEB-411![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
MC-162908
Elytra on an armor stand will render with additive blending; elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Elytra on an armor stand will render with additive blending, so will every entity rendered subsequently; elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Entity rendered with additive blending.
Several armorstands with plain elytra will have their frame render with additive blending, too. Wearing enchanted elytra and enchanted armor will render the entire elytra as transparent, then apply enchantment glint to the entire thing.
Elytra on an armor stand will render with additive blending, so will
everyentity rendered subsequently; elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Elytra on an armor stand will render with additive blending, so will one entity rendered subsequently; elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Elytra on an armor stand will render with additive blending, so will one entity rendered subsequently, if there's no items in the world; elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Elytra on an armor stand will render with additive blending, so will one entity rendered subsequently, if there's no items in the world
; elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.E
nchanted elytra with enchanted armor on players is transparent and has the enchantment glintapplied to the entire texture.Elytra on an armor stand will render with additive blending, so will one entity rendered subsequently, if there's no items in the world.
Elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Elytra on an armor standwill render with additive blending, so will one entity rendered subsequently, if there's no items in the world.Elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
If an armorstand is first to render, elytra will render on it with additive blending, so will one entity rendered subsequently, if there's no items in the world.
Elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
If an armorstand is first to render, elytra will render on it with additive blending, so will every armorstand and one entity rendered subsequently, if there's no items in the world.
Elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
If an armorstand is first to render, elytra will render on it with additive blending, so will every armorstand and one entity rendered subsequently, if there's no items in the world.
Elytra on players will render with broken textures if they're holding an item and with their skin data if they're not.
Enchanted elytra with enchanted armor on players is transparent and has the enchantment glint applied to the entire texture.
Note: this is a complex issue and I'm not sure about whether all the details are correct.
When pressing two or more keys on the same frame/tick, one of them will only be considered pressed after a delay specified by xset r rate. Pressing another key while this delay happens entirely drops the key to be pressed.
This breaks sprinting, walking diagonally, and jumping forward.
Workaround: set the XMODIFIERS environment variable to "@im=null", or "@im=xim".
When pressing two or more keys on the same frame/tick, one of them will only be considered pressed after a delay specified by xset r rate. Pressing another key while this delay happens entirely drops the key to be pressed.
This breaks sprinting, walking diagonally, and jumping forward.
Workaround: set the XMODIFIERS environment variable to "@im=null", or "@im=xim".
Another workaround: apply the patch from
When pressing two or more keys on the same frame/tick, one of them will only be considered pressed after a delay specified by xset r rate. Pressing another key while this delay happens entirely drops the key to be pressed.
This breaks sprinting, walking diagonally, and jumping forward.
Workaround: set the XMODIFIERS environment variable to "@im=null", or "@im=xim".
Another workaround: apply the patch from
When pressing two or more keys on the same frame/tick, one of them will only be considered pressed after a delay specified by xset r rate. Pressing another key while this delay happens entirely drops the key to be pressed.
This breaks sprinting, walking diagonally, and jumping forward.
Workaround: set the XMODIFIERS environment variable to "@im=null", or "@im=xim".
Fix:
1) apply the patch from here to the 3.2.2 source tree, and compile it
2) add -Dorg.lwjgl.librarypath="/path/to/library/" to the launcher options (write the folder it's in, not the .so file itself)If you do not want to bother with recompiling glfw, I have a precompiled binary for arch linux at https://i.selic.re/libglfw.so
(If a mod can confirm there's no malicious edits, that would be nice!)
When pressing two or more keys on the same frame/tick, one of them will only be considered pressed after a delay specified by xset r rate. Pressing another key while this delay happens entirely drops the key to be pressed.
This breaks sprinting, walking diagonally, and jumping forward.
Workaround: set the XMODIFIERS environment variable to "@im=null", or "@im=xim".
Fix:
1) apply the patch from here to the 3.2.2 source tree, and compile it (thanks,
2) add -Dorg.lwjgl.librarypath="/path/to/library/" to the launcher options (write the folder it's in, not the .so file itself)If you do not want to bother with recompiling glfw, I have a precompiled binary for arch linux at https://i.selic.re/libglfw.so
(If a mod can confirm there's no malicious edits, that would be nice!)
When pressing two or more keys on the same frame/tick, one of them will only be considered pressed after a delay specified by xset r rate. Pressing another key while this delay happens entirely drops the key to be pressed.
This breaks sprinting, walking diagonally, and jumping forward.
Workaround: set the XMODIFIERS environment variable to "@im=null", or "@im=xim".
Fix:
1) apply the patch from here to the 3.2.2 source tree, and compile it (thanks, comment-608172)
2) add -Dorg.lwjgl.librarypath="/path/to/library/" to the launcher options (write the folder it's in, not the .so file itself)If you do not want to bother with recompiling glfw, I have a precompiled binary for arch linux at https://i.selic.re/libglfw.so
(If a mod can confirm there's no malicious edits, that would be nice!)
To reproduce the bug, simply create a repeating command block containing {{/tp @p ~ ~ ~ }} and activate it.
The server-side client will freeze in place as expected, but the client is free to move around. Breaking blocks is impossible past the intended 6m radius, but placing blocks and interacting with them is impossible entirely.
The reason is that the server still uses the relative teleport flags for the ~ syntax, and the client confirms it too late; here's a pastebin of the relevant packets: https://pastebin.com/pgFsQcz8. From this I can deduce that the server thinks that there's no need to update the client's position, since from its point of view it's already been teleported to the correct location (even though the position of the player changed since the packet was sent, making its new position invalid).
The fix would be to use absolute coordinate flags instead of relative. Maybe there's a check that hasn't been updated for the 1.13+ syntax of teleport?
To reproduce the bug, simply create a repeating command block containing /tp @p ~ ~ ~ and activate it.
The server-side client will freeze in place as expected, but the client is free to move around. Breaking blocks is impossible past the intended 6m radius, but placing blocks and interacting with them is impossible entirely.
The reason is that the server still uses the relative teleport flags for the ~ syntax, and the client confirms it too late; here's a pastebin of the relevant packets: https://pastebin.com/pgFsQcz8. From this I can deduce that the server thinks that there's no need to update the client's position, since from its point of view it's already been teleported to the correct location (even though the position of the player changed since the packet was sent, making its new position invalid).
The fix would be to use absolute coordinate flags instead of relative. Maybe there's a check that hasn't been updated for the 1.13+ syntax of teleport?
Also applies to books.
Can't seem to be able to reproduce this on windows 10 either, so I am assuming this is a linux-only bug. It is fixable by setting the key repeat settings to repeat all keys after 1ms, but that kinda breaks everything else on the system.
For anyone still looking for a workaround, using
$ export XMODIFIERS="@im=null"fixed it for me. Note that this may end up with you having even more input issues, but it does seem to work.
@Roescoe Wild: This is an environment variable; some display environments may support starting an application with it set (you certainly don't wanna do this for every application), but the most portable way is to simply open a terminal, paste that line there, and run minecraft from the location you have it installed in. You can make that a shell script, which is a file with e.g.
Protip: if you see a $ at the beginning of the line, it indicates that you should be running this in a terminal. Same for #, but as a superuser.
@Roescoe Wild: you can select text with shift+home while at the end of the line, and iirc copy/paste with ctrl+/shift+insert.
I have recently switched to a keyboard with a much better polling interval, so it's harder to trigger, but I can't seem to be able to trigger it at all while I still could on 1.18.1. Given the glfw version was bumped, I think it's safe to say that the bug has been fixed.