Describe the bug

Sorry for the mouthful of a title but this is quite the hard one to describe. I was setting up a logistics network which deals with keeping a PC stocked with a Pneumatic Jackhammer. While setting up the network, I accidentally right-clicked the Logistics Module with the Logistics Configurator (slip of the fingers, it happens). When I clicked on the Requester Frame after this mistake, my game crashed.

I went into a test world to try to reproduce this and I struggled, but I think I found a way to easily reproduce it...

How to reproduce the bug

1. Place down a chest or barrel.
2. Place a Requester Frame on the top face of the chest.
3. Place a Pressure Tube with a Logistics Module above that, with the module pointing toward the Requester Frame.
4. Place a Creative Compressor above that, set it to 5.0 bar.
5. Grab any random Logistics Frame from JEI, and configure it with Shift+Right click. The specifics of the configuration don't matter, just that it has a configuration.
6. Now, set the Logistics Frame from step 5 as the Item configuration for the Requester Frame in step 2.
7. Grab a charged Logistics Configurator from JEI.
8. Pretend to accidentally right-click the Logistics Module with the Logistics Configurator.
9. Attempt to right-click the Requester Frame with the Logistics Configurator.

If you still can't reproduce it, give it a few more tries. I'm not sure if the bug is 100% able to be deterministically reproduced, but this is the easiest way I could come up with to reproduce it.

Expected behavior

The game should not crash.

Additional details

• NB: The game did not produce a crash report, so I cannot provide one.
• The game also didn't log anything relating to this.
• The crashing seems to persist between relogs.
• I think it's something to do with nested NBT. Which explains why a configured logistics frame or a pneumatic jackhammer causes it, but regular items don't.
• This happens regardless of what the Requester Frame's NBT matching settings are.
• I think this may also be an issue in 1.19 based on a past conversation I've had with someone who experienced a similar bug, but they dismissed it as a one-time thing so I wasn't concerned.

Which Minecraft version are you using?

1.20

Which version of PneumaticCraft: Repressurized are you using?

6.0.7

Crash log

No response

Yeah, I can reproduce it, but the logistics frame part is a red herring; you don't need to click that first to trigger the problem.

It is indeed a nested NBT issue, with a (configured) frame inside a frame. Could be tricky to debug, though...

Oh I see what you mean, I had just assumed it was related to first clicking on that because that's the one conistent thing in all my successful attempts at trying to get a decent reproduction.

Did the game also just crash for you without generating a crash report? I've never seen that happen so I was a bit surprised.

Also - is there any reason for a logistics frame that isn't configured to do any nbt matching to be looking at NBT data?

Ah, I did not get any client disconnect error - the game crashed straight to desktop and the only thing in the logs was the typical initialisation stuff, with no crash report, nothing about network disconnects or anything like that. I can think of a reason to use frames inside frames for some kind of dynamic frame config in a drone program where a drone swops frames out with other frames, but I am aware I'm probably the only player who would attempt something like that 😂 The original issue that got me to make this report was not a frame inside a frame however - it was a Jackhammer (Diamond Drill Bit + Silk Touch + Magnet, Speed, Volume upgrades) inside a frame that caused it, which is far more of a normal use case than a frame inside a frame. Glad we at least know what it is now - in the meantime I'm going to stick to pre-configuring frames in my inventory

Actually, it's not NBT in this case. There's some problem with the serialization of the frame's data to a byte buffer when sync'ing from server to client related to nesting a frame within a frame, basically. That part of the code probably needs a bit of a rewrite, I was never totally happy with it (and now I know why!)

Network sync problems can leave the original problem masked, I've found. In this case I get a client disconnect with an error about not being able handle the ClientboundDisconnectPacket, which is probably masking the original error. Only way to know for sure is stepping through with an IDE debugger, but as I mentioned, I'm inclined to redo some of the sync'ing there from scratch.

Well (if I'm right) that was way simpler than I thought... just a matter of a too-small byte buffer.

Fixed in current release