Attempt to instantiate abstract class ThinkerIterator

This occurs very rarely and only when loading a saved game when a mod using ThinkerIterators is loaded; it's as if the save game loader can't retrieve the correct type information.

I would happily construct a test example if I knew how, but it's so rare that I cannot provoke it deliberately; if it is any help, in the most recent crash, there would have been one such iterator created to seek things with statnum STAT_STATIC, and a few created to seek things with statnum STAT_DEFAULT and here is a link to the savegame

EDIT: I hacked open the save file and at the end of the map JSON was this (reformatted); no type information, just the abstract class name.

Code:

        },
        {
            "classtype": "ThinkerIterator"
        },
        {
            "classtype": "ThinkerIterator"
        },
        {
            "classtype": "ThinkerIterator"
        }
    ]
}

As a purely practical matter, pending a possible fix in GZDoom, presumably if an iterator exists purely inside a function, would making it STAT_INFO reduce the risk of this?

Last edited by MartinHowe on Sun Jan 17, 2021 12:33 pm, edited 1 time in total.

Are you storing the iterator in a class? In that case, this is user error - you need to use the "transient" specifier on the variable so that it's not saved to save games. This applies to all iterators, and also applies to CVar structs.

No, none of them are; all of these iterators are used in functions to search for things and (should) self-destroy when the functions exit (i.e., when they go out of scope); none of them is a class member of anything. (Though I'll look up the transient specifier you mention (never heard of it) for future reference).

Do you have some code producing this error?

Sure, I hadn't posted it yet because there's a lot of it. This has happened with various maps, so I'm sure that if it isn't an engine bug, the problem is in the mod itself: Text file Download. Of course it could be both. If I'm doing anything silly, feel free to let me know. (Referring to the code in the archive, the 'mobbing' module wasn't in use at the time so is unlikely to be the cause).

As an aside I hadn't realised that ".zds" was being used for save files until today, I'm using it as "zdoom script" (in the archive), so guess I'll have to change that some day. (I don't use ".zs" as I prefer 3-character filename extensions like we used to have in DOS).

Are you storing the iterator in a class?

This would probably cause the saving process itself to fail, so it's not user error even if there were class fields of such types in the mod.

UPD: and indeed there are! In mixin class M426_Nibbles there is a field of type ThinkerIterator called foodFinder. That GZDoom attempts to serialize it is probably an engine bug. The saving process should abort. To mitigate the issue right now, the field should be marked transient.

In mixin class M426_Nibbles there is a field of type ThinkerIterator called foodFinder. That GZDoom attempts to serialize it is probably an engine bug. The saving process should abort. To mitigate the issue right now, the field should be marked transient.

Thanks very much for spotting this Some time ago I purged all my code of iterators stored as class fields, dunno how I missed that one The value of a 'fresh pair of eyes'

This would probably cause the saving process itself to fail, so it's not user error even if there were class fields of such types in the mod.

I would say correct; the engine should not have tried to serialise it. Also if a field declared as a class member is abstract, but not marked transient, maybe the engine could issue a warning if, referring to the linked thread, its scope isn't UI?

(I fixed the mod, made that iterator local to the function; just watched a cat snacking on a dead imp, saved, played a bit, reloaded and it was fine; no iterators in the save game file either)

It's not that easy. The compiler cannot detect if a class is supposed to get serialized or not, so it cannot warn. But this should surely be detected on saving not on loading a savegame.

It's not that easy. The compiler cannot detect if a class is supposed to get serialized or not, so it cannot warn.

But the engine does know if a class is non-serializable, right? Adding a warning if such a type is used for a non-transient field won't break existing mods, since scripts will still compile. And getting rid of the warning would be easy, just by marking the field transient.

That would add a flood of warnings because it still does not know if that class actually gets used in a serializing context.
The entire menu system is not serializable, i.e. all its classes are transient so you'd get a lot of noise from non-game contexts that do not need the 'transient' keyword.

The entire menu system is not serializable

It's been mentioned before that UI-scoped classes should be ignored during the checking process.

Not all play scoped classes are serializable, so the issue still stands.