August 15th, 2026
I've spent the last six hours using freely available tools to decompile/reconstruct both Stormworks v1.15.19 and v1.15.20 to compare what changed and try to shed light on the cause of the bug.
Relevant memory addresses if you want to compare v1.15.19 (Broken) to v1.15.20 (Hotfix) yourself.
0000000140498CE0
000000014021C7D0 (1)
00000001405481A0 (1)
000000014049F550 (2)
0000000140783120 (1)
00000001404A06D0
There are 3 individual if statements that skip decoding payloads over 10 MB instead of throwing an error.
Related to: Multiplayer network packet decompression now rejects corrupt or implausible payloads.
This is very likely to be the reason vehicles weren't spawning.
_fdclass has new validation logic that appears to run on every collision, based on its location and context, but I can't confirm this myself. This is gone in the fixed version, so it might have been reverted entirely, or located somewhere else.
Related to: Multiplayer corrupt vehicle bodies fall back to the reported world position and/or Multiplayer stale/duplicate body transform updates no longer discard the rest of an event batch.
This is likely to be the cause of the extreme slowdown with some vehicles over 10 MB.
Here's what I think happened, but this is entirely speculation.
The decompression size cap, intended for Multiplayer, was likely only tested against realistic multiplayer packet sizes, not singleplayer. If vehicle loading shares this same function between both singleplayer and multiplayer, that would be why it also broke massive singleplayer vehicles that would never have been tested for, as it is a multiplayer fix.
The corrupt transform detection might have been correctly flagging data as invalid, but the data was only corrupt because the 10 MB limit was passing through incomplete data. If so, both bugs would be linked. Bug 1 would produce bad data, and Bug 2 would try to reject it, only to fail because the vehicle doesn't exist anymore, causing it to endlessly repeat itself.