Closed GoogleCodeExporter closed 9 years ago
It didn't work because we pushed up a new .z8 file to red-bean. It's a
completely
different executable now, so the savefile won't work. Basically, a 'savegame'
file is
just a snapshot of the VM's memory state. And now because it's a new .z8 file,
the
whole z-machine state is completely different from the start -- so the snapshot
can't restore properly.
To really test this, try saving, closing the browser tab, then restoring in a
new
browser tab.
Original comment by suss...@google.com
on 28 Jan 2010 at 9:39
It restores OK in zoom, but not in parchment. I see that Ben actually brought
this issue
up (#88 on the parchment issue tracker) last May.
There's a big bunch of text after hoosegow.z8 in that url, and I'm not sure if
that is
some kind of giant hash tag identifying the saved game file or if it actually
is the game
state (in quetzal format?) What ever it is, it is huge, like 5216 characters. I
don't think
most HTTP GET's allow that large an argument to be passed, so I think we're
getting
hung up at that level even if everything were working.
Original comment by dhakajack
on 28 Jan 2010 at 9:45
That data is the base64 encoded quetzal save file. I've never had any problems
with
it being too long. The hash isn't actually sent over HTTP remember...
A long term plan of mine is to alter the proxy server so that it will store old
versions of story files. Then if you need to restore a save file after the
story file
has been updated, you can request the specific version it needs.
Original comment by curiousdannii
on 27 Feb 2010 at 2:50
Original issue reported on code.google.com by
dub...@gmail.com
on 28 Jan 2010 at 8:51