Minecraft Version

1.12.2
Modpack:
allthemods 3 v.5.7c

Forge Version

14.23.1.2587

Mod Version

1.12.2-0.3.1-125

Describe your problem, including steps to reproduce it

I had 3 similar but still different crashes. The crash report is for the first crash:

1: I made a Programm with 2 Coordinate Operator with a coordinate pice with coordinates attached. I named the first coordinate Operator "1" and the second "2". Then i made a dig piece with an area piece. In the Area piece i used the "1" and "2" as coordinates. After i closed the programmer the game crashed.
Maybe i used the pieces wrong but even if it was wrong i dont think my game should crash.

2: I made the requirements to use the function to autamatic convert used coordinates into relativ coordinates. After that i made one dig piece with an area. after i klicked on the butten to convert the coordinates, the game crashed.

3. I imported a programm from pastebin. I could import this programm: http://pastebin.com/ZevQ0Guj
   but if i import this programm: http://pastebin.com/qLMM2w04 and i went back with "esc" the game crashes.
   The first programm isnt using relative coordinates in an area piece, but i think the second is using them. (couldnt really look into it, because the game crashed)

Any other comments?

Crash report:
https://pastebin.com/Zm6xv4N1

To answer 3: The 2nd pastebin( http://pastebin.com/qLMM2w04 )is old code/program from minecraft version 1.7.10. It isn't compatible with the latest version at all. As for 1 and 2 I have a hunch that the change "The size limit for programming puzzle piece areas is now validated in the Programmer before the drone is programmed, instead of forcing a drone with an over-large area to suicide after it's placed." to the latest version of the mod may be the culprit causing the crashes. How big are the modifiers that you used (ie +x30 +z30 -y30)? from 2: Can you upload the program to pastebin before using the auto convert to take a look at?

@Tekstack is right about the recent size limit validation change being at fault here. I'm working on a fix now.

However, it should be possible to import old 1.7.10 saved programs, since the save format hasn't really changed. I'll check that as well.

So, the problem is that variables are handled via the AI manager of a live drone, and aren't available at all in the programmer. I'll add a short-term fix now to get round this problem - size validation won't be done at compile-time for pieces using variables, but will have to be done when the drone starts up, like it used to be.

@gamelnderGamler can you try this build: http://jenkins.k-4u.nl/job/PneumaticCraft-Repressurized/lastSuccessfulBuild/artifact/build/libs/pneumaticcraft-repressurized-1.12.2-0.3.1-126.jar

It should resolve the crashes you're seeing in points 1 & 2.

As for point 3: when I tried to import http://pastebin.com/qLMM2w04 it didn't crash, but I got a client kick with "Payload may not be larger than 32767 bytes". Is that what you saw too?

@desht

Thank you very much, the build you posted fixed my problems under 1&2.

You are right with point 3. I get the same message (Payload may not be larger than 32767 bytes)
But i think thats because the problems under 1&2 are fixed.
This time i could see a part of the loaded programm and the game did freez. The last time the game crashed after i tried to leave the "loading overlay" in the programmer.

Point 3: the client tries to send a CPacketCustomPayload (which is from sending a PacketProgrammerUpdate packet) to the server with a size of 35457 bytes, which is too large. Either 1.7.10 was looser about these packet size limits, or the program encodes to a larger data payload in 1.12.2 for some reason (shouldn't be the case; this part of the code hasn't really changed).

The raw JSON size for this program is about 31050 bytes, so it looks like the NBT overhead is pushing that over the 32767 limit. To fix this problem I think we'll need to modify the protocol here to allow the program to be sent over to the serverside Programmer tile entity in potentially multiple packets. @MineMaarten thoughts on this?

The simplest solution I'd think is to deal with it at the binary level. Take your NBT, serialise it into your own buffer. Then chop that up into 30k segments. Prepend a count/total byte pair to that, and send in packets. Then at the receiving side, allocate a an array, store the payloads, and when you have them all concatenate and deserialise.

Yeah, MineMaarten has some code in IGW to do basically that already, we'll most likely adapt that for PNC.

OK, point 3 should be resolved by this build: http://jenkins.k-4u.nl/job/PneumaticCraft-Repressurized/128/artifact/build/libs/pneumaticcraft-repressurized-1.12.2-0.3.1-128.jar

Could you give that a go and play around with that very large program (http://pastebin.com/qLMM2w04) ?

It is working now.
Thank you :)

Excellent, going to mark this as done.