Page 1 of 1

[Rseding91] [for 0.17] [0.16.39] Serpent bug, fix inside

Posted: Tue May 01, 2018 8:00 pm
by tristynstimpson
TL;DR: Update serpent from version 0.30 to verison 0.302 to apply the following patch:
https://github.com/pkulchenko/serpent/c ... a5afe08b91

---------

Oh man this bug was hard to track down. In my mod a random table object deep within `global` was deserialized to nil after saving/loading. And I've written the mod to handle not persisting metatables/threads/functions/upvalues so this was very strange.

I included a copy of my mod which has been modified to easily test the latest 3 versions of serpent as well as the version shipped with Factorio. To use it, start a new game and press the `TAS` button, then press any of the `test v0.xxx` buttons to see if serpent.dump/serpent.load has the correct output.

I love Factorio BTW!!!

Re: [0.16.39] Serpent bug, fix inside

Posted: Wed May 02, 2018 6:04 pm
by Rseding91
It's on my to-do for 0.17 :) https://github.com/pkulchenko/serpent/issues/28

Just FYI though: avoid using tables as keys since it's a bad idea anyway.

Re: [0.16.39] Serpent bug, fix inside

Posted: Thu May 03, 2018 4:23 pm
by tristynstimpson
Rseding91 wrote:Just FYI though: avoid using tables as keys since it's a bad idea anyway.
Thanks for the advice, I'm using tables as keys in a couple places where I don't need to, I'll change that. Could you explain why exactly? I imagine it causes desyncs because each client allocates the table at a different address so that it's hash function and therefor iteration order is different?

As one example I have a deep copy function that uses a `visited` table with table keys to handle cyclic references. It's discarded after and never get's enumerated or stored in `global`. I don't see how this case would be an issue.