Everything about development and the OpenMW source code.
3 posts • Page 1 of 1
Backward compatibility shouldn't be too hard to do (e.g. for the 'attributes should be floating point' issue, just read the integer version if it exists to handle older savegames). Forward compatiblity (which I have been arguing for) is much harder though. I would prefer we batch up some format changes and then apply them all at once, so as to cause as little disruption as possible. We could also introduce reading support for the new state now, but still write the older (compatible) version until a set time in the future (e.g. the release after the one where reading support was introduced; that way, it should be possible to jump back and forth between the last two versions no problem). Alternatively, or in addition, a case could be made to change the ESM reader so that it ignores unrecognized (sub)records instead of throwing an error, though this won't work for everything. It should work for #2326, though (the 'last equipped weapon' field would just be unrecognized state that's ignored, it won't break the loading of the game).
We just added backward compatibility, no forward compatibility. But the last format change was a long time ago I think, back when OpenMW was a lot less popular than it is now.And how did we solve such issues before?
Would this allow for more records in .esm files coming from OpenMW's editor? Specifically, I've been interested in the future possibility of being able to edit UI within the editor and save as a .esm which would let players mix and match UI element mods together like they would any other kind of mod.