Issue Description

Updated to pyrotech-1.12.2-1.4.4 from pyrotech-1.12.2-1.3.13.jar. If any player so much as looks at a pyrotech machine with fuel in it, they are immediately disconnected with a client error due to TOP choking on the packet. If it has no fuel, this does not happen, but I do notice the burn time meter has a garbled symbol and the string gui.pyrotech.waila.burn.time across it as if it can't load a string. Did not experience any disconnects/crashes prior to updating pyrotech.

This does not occur in singleplayer which shows the burn time properly.

What Happens

• Move close enough to have TOP attempt to show information regarding a fueled kiln.
• Disconnect from server.

Crash Log

https://pastebin.com/5FERTdD2

Affected Versions

• Minecraft 1.12.2
• forge-1.12.2-14.23.5.2838
• CraftTweaker2-1.12-4.1.19
• dropt-1.12.2-1.16.1
• pyrotech-1.12.2-1.4.4
• athenaeum-1.12.2-1.17.4
• theoneprobe-1.12-1.4.28

Thanks for the report!

Unfortunately, I'm unable to reproduce this and there isn't much actionable info in the log.

The test environment:

| ID           | Version       |
|:------------ |:------------- |
| minecraft    | 1.12.2        |
| mcp          | 9.42          |
| FML          | 8.0.99.99     |
| forge        | 14.23.5.2838  |
| pyrotech     | 1.12.2-1.4.4  |
| dropt        | 1.12.2-1.16.1 |
| crafttweaker | 4.1.19        |
| jei          | 4.14.4.264    |
| athenaeum    | 1.12.2-1.17.4 |
| patchouli    | 1.0-20.108    |
| waila        | 1.8.26        |
| theoneprobe  | 1.4.28        |
| ctgui        | 1.0.0         |
| bookshelf    | 2.3.566       |
| gamestages   | 2.0.108       |

My guess is it's because I don't have waila since the string it's looking for seems to be from waila? I'll try later when I can restart server again.

No. Waila support was written first and TOP simply uses the same strings.

Is there a way to disable the top support? Any ideas why it might fail only in a server environment and not singleplayer? I removed TOP Addons, but that did not resolve it and I can't imagine what other mod might be causing any compatibility issue between them. Everything worked fine with Pyrotech 1.3.13.

There currently isn't a way to disable the ToP integration.

The code that governs the ToP integration for the Stone Kiln hasn't been changed since July 12, 2019.

This means one of three things:

1. Something else changed and is interfering with the integration,
2. This is a flaw in Pyrotech that has existed since the ToP feature was introduced but it hasn't been reported yet, or
3. Something was changed in Pyrotech between versions 1.3.13 and 1.4.4 that has had an unexpected or overlooked side effect.

If you can answer any of these questions it may help:

• Does the crash occur when looking at a fueled Brick Kiln, Stone Oven, or Brick Oven?

• If you roll back only the Pyrotech mod from 1.4.4 to 1.3.13 does the crash occur?

• When you updated Pyrotech from 1.3.13 to 1.4.4, did you also update any other mods, configurations, or scripts?

• Can you provide any more log information around the crash? For example logs/latest.log

• Can you reproduce this using only ToP, Pyrotech and its dependencies in a minimal instance?

Any ideas why it might fail only in a server environment and not singleplayer?

Yes, the single player environment likely serializes and de-serializes packets, but doesn't actually route them through the network layer and there are indications that something could be failing on the network layer.

The point of failure indicated in the logs reveals ToP reads an int from the byte buffer coming in from the network layer and retrieves an element factory. The element factory it retrieves is null and an exception is thrown because, assuming from the lack of a null check, ToP never expects this value to be null.

Since this does not happen in a single player environment, I don't think that element serialization / deserialization is to blame. I think either something is interfering with the packet payload on the network layer or something is interfering with the registration or registration order of the element factories on either the server or client causing incorrect ids.

More log info may help.

Pyrotech was never explicitly told to load after Waila or ToP and maybe, in your case, the client is loading Pyrotech before ToP and failing to load the integration which would fail to register the element factories.

Again more logs might help.

Here is a test build that ensures Pyrotech loads after Waila and ToP:
pyrotech-1.12.2-1.4.4-1-g407aa94.jar.zip

Try the test build and if it doesn't work, please provide more logs and answer the questions above and we'll go from there.

Please update to 1.4.5 and let me know if the new version solves your problem or not.

Seems to have solved it for us. Thank you!

You're welcome! :)

Leaving this here for reference: ea0c321