mojira.dev

Thinkofdeath

Assigned

No issues.

Reported

MC-67961 Using the Set Compression packet causes the client to disconnect Invalid MC-31927 Maps in item frames have Z fighting issues when next to rotated maps Fixed

Comments

The fix for this seems to be resending attributes on world change (done for Spigot and tested)

Edit: Should fix MC-29386 too

Compression is two way, changing the threshold causes both the client and the server to start using it. The issue comes in when this case happens:

Set compression (sent by server) -> 150 ms delay due to lag. The client can send a lot of packets (movement, interacts etc) during that window and they'll be sent with the old compression threshold until the client gets the packet. The server has no way of knowing when the client has started to use the new threshold.

@unknown The packet will never work in its current state due to the fact you can't tell when the client gets your packet and starts using the new threshold therefore you'll be out of sync causing that issue (in some cases).

Should do, don't have it applied to test. The patch itself was applied against Spigot (Minecraft server mod) on the partially de-obfuscated source. Wouldn't recommend trying to apply it yourself unless you understand how to work with the mod, I just included it to show roughly to mojang were I fixed it.

--- src/main/java/net/minecraft/server/EntityMinecartFurnace.java	2015-04-06 18:50:46.198347410 +0100
+++ src/main/java/net/minecraft/server/EntityMinecartFurnace.java	2015-04-06 18:50:46.214347410 +0100
@@ -58,17 +58,9 @@
 
         if (d0 > 1.0E-4D && this.motX * this.motX + this.motZ * this.motZ > 0.001D) {
             d0 = (double) MathHelper.sqrt(d0);
-            this.a /= d0;
-            this.b /= d0;
-            if (this.a * this.motX + this.b * this.motZ < 0.0D) {
-                this.a = 0.0D;
-                this.b = 0.0D;
-            } else {
-                double d1 = d0 / this.m();
-
-                this.a *= d1;
-                this.b *= d1;
-            }
+            double d1 = (double) MathHelper.sqrt(this.motX * this.motX + this.motZ * this.motZ);
+            this.a = (motX / d1) * d0;
+            this.b = (motZ / d1) * d0;
         }
 
     }

Full source here: https://gist.github.com/thinkofname/1435c96a8d7efcd2698e

From my testing this seems to completely fix the issue although it might need some more testing

From my understanding is that in 1.8 portals have two states (90:1 and 90:2) which control the portal's facing direction, any other value gets replaced with air. In 1.7 and older portals created on the other side to the one you built were created as 90:0 (uncomputed) the server/client would work out the facing when it needed.

Another issue with the packet from IRC:

<Drainedsoul> I don't understand how the play version is useful
<Drainedsoul> given that there's – as far as I know – no acknowledgement, how can you prevent race conditions?
<Drainedsoul> adjusting the compression on the fly could make in flight, valid compressed/decompressed packets suddenly erroneous when received

Seems to be fixed in 13w48b