https://youtu.be/FhwWfE64P4Q
To explain what you're seeing, this is regular ZK being saved and loaded by the engine with barely any work required from the game developer.
The engine saves the synced lua states in their entirety and loads them back virtually unchanged.
Note that at the moment saving more complex games might crash.
While lua seems to be successfully saved and loaded, the rest of the engine is not there yet as there are some remaining bugs to squash.
The future is here
Moderator: Moderators
The future is here
Last edited by hokomoko on 19 Mar 2019, 15:15, edited 1 time in total.
Re: The future is here
https://youtu.be/wkkNPynIj5Q
Bugs seem to be gone
Feel free to test saving and loading on your games and report what you find.
Make sure to use 104.0.1-1118-g89a6f16 maintenance or later (I'll put a link when the buildbots build it)
Bugs seem to be gone
Feel free to test saving and loading on your games and report what you find.
Make sure to use 104.0.1-1118-g89a6f16 maintenance or later (I'll put a link when the buildbots build it)
Re: The future is here
Monumental.
Re: The future is here
Out of interest, how is it saved, how is the lua state restored?
Re: The future is here
The code is actually not very sophisticated:
https://github.com/spring/spring/blob/d ... aState.cpp
I've mirrored all of lua's data structures and integrated spring's serialisation framework (creg) in the mirrors, that does all the pointer following and saves the easy stuff.
Some things inside lua were more tricky - obviously it holds pointers to spring's API which is C functions, so these are automatically registered according to their name ("Spring.Whatever" etc.) which gives us a two-way dictionary for serialising and deserialising.
One of the last issues was when deserialising tables. While you can't use pairs() on a table with tables/functions/etc. as keys, you can still hold one (and I suspect lua makes some as well for its own use), that means that the location of the key/value pairs in the hash table vector depends on the pointer.
When serialising, I just dump the table as is (which helps preserve sync in tables with sane keys).
When deserialising, the keys still point to the same functions/tables, but the addresses changed, so they have to be reinserted.
Other than that, restoring is really just reading everything back from the file. You end up with a fully functional pointer to a lua state that you just assign to the right places in spring and that's it more or less.
Re: The future is here
Stupid question inbound.. Can one serialize this human readable? Basically like a lua coredump?
Re: The future is here
This version should have save/load: https://springrts.com/dl/buildbot/defau ... -g19e9a8c/
please test and come back with reports
please test and come back with reports