Description
alox-48 had a really nasty bug caused by adding an Instance's data to the table of previously deserialized objects. This meant that there were more objects being added to the table then there should've been, causing a desync which could lead to objectlinks linking to the wrong object.
I'm genuinely surprised was not caught earlier, but I stumbled upon this bug when alox-48 got stuck in a loop deserializing the same object and would blow the stack. There's now a check in alox-48 to prevent recursive object links (what was causing a stack overflow) as well so this shouldn't happen again.
Testing
I opened the map that caused me to find this bug and it no longer crashes.
Connections See this commit
Description alox-48 had a really nasty bug caused by adding an
Instance's data to the table of previously deserialized objects. This meant that there were more objects being added to the table then there should've been, causing a desync which could lead to objectlinks linking to the wrong object.I'm genuinely surprised was not caught earlier, but I stumbled upon this bug when alox-48 got stuck in a loop deserializing the same object and would blow the stack. There's now a check in alox-48 to prevent recursive object links (what was causing a stack overflow) as well so this shouldn't happen again.
Testing I opened the map that caused me to find this bug and it no longer crashes.
Checklist
cargo fmt.cargo clippy. If applicable, add:--target wasm32-unknown-unknown -Z build-std=std,panic_abortcargo build --releasetrunk build --release