Project

General

Profile

Feature #2772

Non-existing class freezes the game

Added by bret curtis over 2 years ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Game Mechanics
Target version:
Start date:
07/14/2015
% Done:

0%

Severity:
Normal

Description

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.


Related issues

Related to OpenMW - Bug #4065: Handle non-existing faction Rejected 09/02/2017
Related to OpenMW - Bug #4111: Crash when mouse over soulgem with a now-missing soul Confirmed 09/18/2017

History

#1 Updated by bret curtis over 2 years ago

We should keep logging as a warning that the Class doesn't exist, but it should hang OpenMW as a result.

#2 Updated by bret curtis over 2 years ago

shouldn't

#3 Updated by bret curtis over 2 years ago

  • Target version set to openmw-0.37
  • Reproducibility changed from Have not tried to Always
  • Severity changed from Normal to Major

#4 Updated by bret curtis over 2 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"?
http://elderscrolls.wikia.com/wiki/NPC_Classes_(Morrowind)

#5 Updated by Marc Zinnschlag over 2 years ago

Okay with me.

#6 Updated by Marc Zinnschlag about 2 years ago

  • Target version changed from openmw-0.37 to openmw-0.38

#7 Updated by Marc Zinnschlag almost 2 years ago

  • Target version changed from openmw-0.38 to openmw-0.39

#8 Updated by Marc Zinnschlag over 1 year ago

  • Target version changed from openmw-0.39 to openmw-0.40

#9 Updated by Marc Zinnschlag over 1 year ago

  • Target version changed from openmw-0.40 to openmw-0.41

#10 Updated by Marc Zinnschlag 12 months ago

  • Target version changed from openmw-0.41 to openmw-0.42

#11 Updated by Marc Zinnschlag 7 months ago

  • Target version changed from openmw-0.42 to openmw-0.43

#12 Updated by Alexei Dobrohotov 3 months ago

  • Tracker changed from Bug to Feature
  • Subject changed from Error in framelistener: Class 'Farmer' not found to Fallback "Farmer" class
  • Severity changed from Major to Normal

#13 Updated by Alexei Dobrohotov 3 months ago

  • Subject changed from Fallback "Farmer" class to Fallback to "Farmer" class

#14 Updated by Andrei Kortunov 3 months ago

  • Duplicated by Bug #4065: Handle non-existing faction added

#15 Updated by Andrei Kortunov 3 months ago

  • Duplicated by deleted (Bug #4065: Handle non-existing faction)

#16 Updated by Andrei Kortunov 3 months ago

  • Related to Bug #4065: Handle non-existing faction added

#17 Updated by scrawl . 2 months ago

  • Target version changed from openmw-0.43 to openmw-1.0

#18 Updated by scrawl . 2 months ago

  • Subject changed from Fallback to "Farmer" class to Non-existing faction freezes the game

#19 Updated by scrawl . about 2 months ago

  • 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 about 2 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.

#21 Updated by scrawl . about 1 month ago

  • Related to Bug #4111: Crash when mouse over soulgem with a now-missing soul added

Also available in: Atom PDF