Spice
Assigned
Reported
Comments
This issue has existed for such a long time and has been making hardcore impossible to play for longer periods of time. It hints at a particularly faulty programming of the bedrock server side, and of client-server communication. It has to be fixed.
Also, the issue report only has 1 vote? So many people have complained about server-client desync, yet no one actually votes for the fixes to be implemented. Please vote for this, and all its related reports:
Servers are integral to the minecraft experience, yet the code that makes them is built with major faults. Bring this issue up to the forefront, before the code is expanded and these bugs become harder to fix.
This issue can easily be fixed by adding the ability to turn vsync on or off. Currently, it’s enabled by default, and cannot be changed. Vsync lowers framerate and increases input lag, it’s basically useless. No reason why it should be on by default, and it should be toggleable in the settings.
Tested on bedrock on pc, vsync off removes all input lag. Should work similarly on consoles.
Please close this issue. It has nothing to do with any of this.
The server this picture is from is not modified. It is vanilla 21w44a.
I don't think that the fabric mod loader team would be happy to fix a vanilla bug.
My client is modified, yes but not gamechanging, only HUD overlays and a resource pack which i don't think could in any way modify vanilla mechanic. No datapack was used in this scenario.
This issue affects basically everything. The way packets are handled should be optimized.
The following problems are caused by desync bugs:
random teleportation
random damage out of nowhere (fall damage, normal damage)
blocks placing out of order (example: while briding, server movement calculation is prioritized (or received first) and since server thinks ‘no block below feet’ the player starts to fall)
server-dependent actions (like throwing throwables, hitting players) not happening
How can desync issues be ‘fixed’ (as well as is possible) ? It’s difficult to say, because for some reason the bedrock edition source code isn’t public. But without seeing the source code, I have some potential considerations to suggest:
Packets should have id or date attributes and be executed in the correct order, with timeouts, of course.
If packets are verified and corrected on the server side, then the verification of the packets should obviously take the packet ids/dates into account. Placing 20 blocks in 1 second - for example - is only potentially unfeasible, if latency isn’t regarded, but if there were 4s of latency, then all packets should be accepted (not as black and white as this example, of course).
The server should verify packets from the client, but not - ever - override them if they are within a threshold of “credibility”.
If latency exceeds a certain threshold, all packets sent should simply be canceled. While this rewind ultimately impacts the gameplay fluidity greatly, that happens with large lag spikes regardless. It is better to rewind to a ‘safe’ state (which is what happens by canceling the packets) than to execute them later at the wrong speed, in the wrong order, or just at the wrong time.
Biggest and most important suggestion: Server authoritative movement should not be on by default on singleplayer worlds. It makes no sense to introduce lag and latency to the singleplayer experience in the name of an anticheat. If people want to cheat in their singleplayer world, it’s ultimately their choice. The experience of the majority shouldn’t be worsened drastically due to the few.
I would hope these suggestions could be helpful. I doubt this message will be seen.