Attempt to save pointer to unhandled type Type

[Player701]

Thanks to this fix, changing the value of DecalGenerator for weapons is now possible, but there seems to be a problem now: introducing another field in a class to store a pointer to a decal generator will make any attempt to save the game to fail if an instance of such a class exists in the game at the moment of saving. (Introducing extra fields could be useful, for example, when initializing a second decal generator from another source and then changing between them depending on the weapon's attack mode.) This probably has something to do with the fact that the generator type is not exported to ZScript yet and thus its type is currently "voidptr".

Here is an example to reproduce this. Attached is a file with the following ZScript code:

Code: Select all

class Test : Inventory
{
    private voidptr _test;
}

Load any map, type "give test" in the console and try to save the game. This will make GZDoom produce an error message:

Code: Select all

Save failed
Attempt to save pointer to unhandled type Type

If it is not possible to resolve at run-time the type of the object a "voidptr" points to, then declaring non-transient fields of type "voidptr" probably shouldn't be allowed. In this case, I guess I'll have to re-initialize the variable every time, which is not a very good solution but possibly the only one until FDecalBase is exported to ZScript.

[Graf Zahl]

How can something be a bug that was never meant to work?

[Player701]

Well, if it was never meant to work, then it's a bug because GZDoom shouldn't let the example code pass as valid ZScript. Like I said earlier:

If it is not possible to resolve at run-time the type of the object a "voidptr" points to, then declaring non-transient fields of type "voidptr" probably shouldn't be allowed.

I guess this restriction should apply to non-native classes so as not to confuse the modder. Because it sure as hell confused me so I even had to bisect my mod repository to find out where things went south.

[Graf Zahl]

The compiler cannot determine that the code is invalid. In fact, it is perfectly valid to define such objects - the caveat is that pointers to such a type have to be explicitly declared as transient.

The only issue here is that the decal generator does not have a serializable type. The variable wasn't even supposed to be exported, it just got overlooked in the cleanup phase. This shouldn't be too hard, though.

[Player701]

The compiler cannot determine that the code is invalid. In fact, it is perfectly valid to define such objects - the caveat is that pointers to such a type have to be explicitly declared as transient.

Why not make them implicitly transient, then? Because it seems that in every case when a user-defined class has them, it will always make saving fail. I see in the compiler code that it can distinguish between gzdoom.pk3's scripts and third-party scripts, so it should be possible to implement this only for the latter. Or is it not going to work for some other reason?

[Graf Zahl]

That wouldn't be good because it'd silently ignore a potential problem that should be reported to the modder.

[Player701]

I agree that it's not the best solution, of course. Then maybe throw an error if such a field in user code is not declared as transient (as suggested in the first post)? Although I guess this restriction should not apply to all classes, since not every class can be serialized. (e.g., AFAIK, UI classes are not serialized, am I right?)

[Graf Zahl]

I guess this restriction should not apply to all classes, since not every class can be serialized. (e.g., AFAIK, UI classes are not serialized, am I right?)

Gotcha!
That's precisely why it cannot be done!

[Player701]

Never thought it would complicate things that much. Well, I guess you know better than me, since you are the one who wrote that code. Though I can see that the function that compiles fields has access to the type's scope flags, I guess there might be more special cases that can't be accounted for that easily.