Exporting modified types to a savefile fails with a bad output.
These things are far too useful to not be able to be dumped to and loaded from savefiles.
ID:2194530
Dec 31 2016, 10:11 pm
|
|||||||||||||
| |||||||||||||
Dec 31 2016, 10:53 pm
|
|
Curious. I'll have to look into what's going on with that.
|
I'm not able to reproduce this. This is what I'm testing:
mob/verb/ModSave() The save does not produce a "bad output" message and the text version looks correct--although it is not a modified type in the savefile, just a normal obj with the var set. |
I'm sorry I didn't get to this sooner, but the code you tested isn't a test case for this problem.
mob/verb/ModSave() |
I can confirm this. I see where it's happening and, thanks to what I was working on with the map foo, I can see why.
The problem is that a modified type is not the same object type as other type paths; it's a POP_REF, referring to a map pop, and a pop is basically a type path plus init proc combination. The current savefile format offers no way of saving a pop; it would have to convert the pop's init proc to a var/value list and then save a new kind of indicator that it was a pop. On load it'd have to create a new pop by creating the requisite init proc (unless it found a match). Upping the savefile version isn't something I take lightly, though, because currently there's no mechanism to force it into a new version only when new features are used. (If I up it outright, the problem then becomes that anyone using 512 suddenly can't drop back down to 511, ever, and their savefiles become incompatible with other servers running 511.) That might be something I can add; I'll have to see. It's definitely due for an upgrade because the appearance code has changed so much. |