Can't use rockets

[jcarter3]

Testing using v1.27.2 using gophertunnel as a proxy (based on the example in main.go) - when connected straight to the bedrock server, rockets work. When connecting through a proxy, rockets do not work. This is related to #118 , but in seems that the issue with shulker boxes has been resolved.

Analyzing the packets that are sent, nothing looks obviously incorrect - happy to help troubleshoot and work on this, but struggling to find a starting point.

[Sandertv]

Thank you for opening this issue.

This is a strange issue. I suspect there is something wrong specifically with the reading of item NBT, because where only the server part of gophertunnel is used (dragonfly, which implements a server using gophertunnel), firework rockets seem to work fine. Item NBT isn't really read from the server side, hence my guess it's on the reading side.

Other than that, I'm not entirely sure what the issue might be.

[jcarter3]

It is interesting - when I log the packets being sent:

• client -> server: *packet.InventoryTransaction (seemingly) correctly parsed with *protocol.UseItemTransactionData with NBT data that looks appropriate for a rocket TransactionData="&{0 [] [] 0 [49 63 41] 1 0 {0 {{524 0} 0 64 map[Fireworks:map[Explosions:[] Flight:1]] [] [] false}} [49.50128 66.62001 42.09192] [0.62794495 1 0.26797485] 10819}
• server -> client: *packet.InventoryContent that looks correct, but has the same item count as what was sent :point_up:

So the client says "i used a rocket at x,yz, i have 64 of them", the server is responding with "you have 64 rockets" (and some misc other packets). The server is definitely receiving information that an action was taken and responding to it, but maybe the *protocol.UseItemTransactionData is being marshalled incorrectly :thinking:

[jcarter3]

Finally got back to a place where I can investigate this further, and there seems to be a regression. When using server version 1.19.60.04 with gophertunnel v1.27.2, rockets would fail, but shulker boxes worked. With server version 1.19.71.02 and gophertunnel v1.28.1, rockets still fail, but shulker boxes also fail to open.

I'll try to dig into the raw data being sent with these packets and see where it might be failing, but I found the regression interesting as nothing around that seems to have changed in the code.

[jcarter3]

Continuing to dive deeper - I modified the protocol reader & writer to tee the raw bytes out, and when proxying packets, compare the raw bytes that were received then sent. If the raw byte arrays were different, I logged them.

I then went into a new game and ran around and everything worked fine (just to test I didn't break anything). Upon trying to use a rocket, I got a log that the InventoryContent packet that was written was different than the one received. And it differed by 1 single value.

Received:

[0 36 154 8 64 0 0 1 232 2 0 56 255 255 1 10 0 0 10 9 0 70 105 114 101 119 111 114 107 115 9 10 0 69 120 112 108 111 115 105 111 110 115 0 0 0 0 0 1 6 0 70 108 105 103 104 116 1 0 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 234 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 236 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 238 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 240 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 242 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 244 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 246 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 248 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 250 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 252 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 254 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 128 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 130 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 132 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 134 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 136 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 138 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 140 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 142 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 144 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 146 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 148 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 150 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 152 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 154 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 156 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 158 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 160 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 162 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 164 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 166 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 168 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 170 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 172 3 184 124 10 0 0 0 0 0 0 0 0 0 0]

Written:

[0 36 154 8 64 0 0 1 232 2 0 56 255 255 1 10 0 0 10 9 0 70 105 114 101 119 111 114 107 115 9 10 0 69 120 112 108 111 115 105 111 110 115 1 0 0 0 0 1 6 0 70 108 105 103 104 116 1 0 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 234 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 236 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 238 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 240 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 242 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 244 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 246 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 248 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 250 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 252 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 254 2 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 128 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 130 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 132 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 134 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 136 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 138 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 140 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 142 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 144 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 146 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 148 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 150 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 152 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 154 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 156 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 158 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 160 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 162 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 164 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 166 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 168 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 170 3 184 124 10 0 0 0 0 0 0 0 0 0 0 180 3 1 0 0 1 172 3 184 124 10 0 0 0 0 0 0 0 0 0 0]

Zooming in: Received: 69 120 112 108 111 115 105 111 110 115 0 0 Written: 69 120 112 108 111 115 105 111 110 115 1 0

You are correct it's in the NBT data -> 69 120 112 108 111 115 105 111 110 115 -> "Explosions". So it's messing up the first byte after that.

[Sandertv]

Apologies for the delay. Thank you very much for investigating this so thoroughly. Could you try the latest commit and see if the issue persists?

[jcarter3]

I tried the latest commit and it works! Thank you so much for following up on this. I meant to keep investigating but keep getting pulled into other things :sweat_smile:

[Sandertv]

Glad to hear it's fixed! Thanks again!