Non-existing class freezes the game
While this is a "bug" in the Ashes of Apocalypse Mod, and can be easier fixed by adding an additional class, this means that the original AoA is not playable by default.
It seems that Morrowind will work around the missing Class by mapping it to the first in the Class list.
Can we do this in OpenMW as well? This would fix AoA and any number of other mods.
#4 Updated by bret curtis almost 3 years ago
Apparently "Farmer" is the default dumping Class, so if there is no class or class doesn't exist, can we set it automatically to "Farmer"?
- Subject changed from Non-existing faction freezes the game to Non-existing class freezes the game
Apart from the issue with classes/factions, there is really a more general issue that demands a general solution. We've also 'fixed' similar issues with invalid Enchantment references in the past, and I'm sure there are many more unfixed similar issues.
Currently, references to other ESM records are stored by ID string, and it's up to every user to resolve them to the actual record whenever they're used. This, apart from being cumbersome, causes error handling inconsistencies (should an invalid reference log a warning, or throw? How do we ensure this warning/exception isn't raised every single frame?).
In the original game, IIRC there's a post-loading pass that resolves all ID references to their actual record. Invalid references are logged as a warning once, then replaced by a null reference so the actual game code no longer has to differentiate between 'null' and 'invalid' references. This would be one possible solution, but I'm not sure if its performance overhead is acceptable, nor do I think verification is something that the game should do (we have the verifier in OpenCS).
A different solution might be replacing all ID fields by a 'smart' data field that holds both an ID and pointer, with the pointer being retrieved from the game's store on first use, and further uses just use the stored pointer. Warnings will not be logged more than once, the game will only use the pointer, and both 'invalid' and 'null' references will just be seen as a null pointer. This is functionally the same as the first solution, except that we're not wasting any time resolving records until they're actually used.
#20 Updated by Chris Robinson 7 months ago
scrawl . wrote:
This is functionally the same as the first solution, except that we're not wasting any time resolving records until they're actually used.
Wouldn't the cost then be passed onto run-time? Any time it needs to access an ID reference it would need to check if it's been resolved, resolve it if not, then give back a pointer. Checking the IDs once at load-time sounds like a better option to me than checking if you need to check an ID every time it's accessed.
#22 Updated by Dark Locq about 2 months ago
- An entire class of mod failures, making lots more mods compatible without modification.
- Innumerable crashes and other problems caused by removal of no-longer-wanted mods; this may well be the no. 1 mod-related problem: you take a crappy mod out, and your game is wrecked because something (e.g. a soul in a soul gem) isn't resolveable.
The game needs to be able to handle this circumstance without coughing up its own skull.
Marking this a "feature" request is iffy. "Not falling apart under common gameplay conditions" isn't a feature, it's basic functionality – especially given that the Bethesda engine doesn't have these failures (though it can have others, like doubling of objects if you change load order).