Project

General

Profile

Bug #2772

Non-existing class freezes the game

Added by bret curtis almost 3 years ago. Updated about 1 month ago.

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

0%

Reproducibility:
Have not tried
Operating system:
Other
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 Closed 09/18/2017

History

#1 Updated by bret curtis almost 3 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 almost 3 years ago

shouldn't

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

#5 Updated by Marc Zinnschlag almost 3 years ago

Okay with me.

#6 Updated by Marc Zinnschlag over 2 years ago

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

#7 Updated by Marc Zinnschlag over 2 years ago

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

#8 Updated by Marc Zinnschlag about 2 years 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 over 1 year ago

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

#11 Updated by Marc Zinnschlag about 1 year ago

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

#12 Updated by Alexei Dobrohotov 9 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 8 months ago

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

#14 Updated by Andrei Kortunov 8 months ago

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

#15 Updated by Andrei Kortunov 8 months ago

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

#16 Updated by Andrei Kortunov 8 months ago

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

#17 Updated by scrawl . 7 months ago

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

#18 Updated by scrawl . 7 months ago

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

#19 Updated by scrawl . 7 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 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.

#21 Updated by scrawl . 7 months ago

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

#22 Updated by Dark Locq about 2 months ago

Implementing this much sooner than 1.0 would be desirable, since it would clear out:
  • 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).

#23 Updated by Dark Locq about 2 months ago

As Chris Robinson put it in the essential-a-duplicate #4065:

I think this classifies as a bug since it works in vanilla Morrowind. At the very least, it shouldn't freeze the game (or really, abort the frame update part way through).

Yep.

#24 Updated by scrawl . about 2 months ago

  • Tracker changed from Feature to Bug
  • Reproducibility set to Have not tried
  • Operating system set to Other

#25 Updated by Alexei Dobrohotov about 1 month ago

  • Status changed from New to Confirmed

Also available in: Atom PDF