Attempt to save pointer to unhandled type Type

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Attempt to save pointer to unhandled type Type

Postby Player701 » Sun Nov 11, 2018 3:18 pm

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 allExpand view
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 allExpand view
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.
Attachments
zscript.txt
(58 Bytes) Downloaded 5 times
User avatar
Player701
You are now breathing manually.
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214

Re: Attempt to save pointer to unhandled type Type

Postby Graf Zahl » Sun Nov 11, 2018 3:27 pm

How can something be a bug that was never meant to work? :P
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Attempt to save pointer to unhandled type Type

Postby Player701 » Sun Nov 11, 2018 3:35 pm

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.
User avatar
Player701
You are now breathing manually.
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214

Re: Attempt to save pointer to unhandled type Type

Postby Graf Zahl » Sun Nov 11, 2018 6:25 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Attempt to save pointer to unhandled type Type

Postby Player701 » Mon Nov 12, 2018 12:34 am

Graf Zahl wrote: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?
User avatar
Player701
You are now breathing manually.
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214

Re: Attempt to save pointer to unhandled type Type

Postby Graf Zahl » Mon Nov 12, 2018 2:19 am

That wouldn't be good because it'd silently ignore a potential problem that should be reported to the modder.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Attempt to save pointer to unhandled type Type

Postby Player701 » Mon Nov 12, 2018 2:42 am

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?)
User avatar
Player701
You are now breathing manually.
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214

Re: Attempt to save pointer to unhandled type Type

Postby Graf Zahl » Mon Nov 12, 2018 3:28 am

Player701 wrote: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!
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Attempt to save pointer to unhandled type Type

Postby Player701 » Mon Nov 12, 2018 3:44 am

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.
User avatar
Player701
You are now breathing manually.
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214


Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest