by Player701 » Sun Nov 11, 2018 2: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 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.
- Attachments
-
- zscript.txt
- (58 Bytes) Downloaded 100 times
Thanks to [url=https://forum.zdoom.org/viewtopic.php?f=7&t=62520]this fix[/url], 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]class Test : Inventory
{
private voidptr _test;
}[/code]
Load any map, type "give test" in the console and try to save the game. This will make GZDoom produce an error message:
[code]Save failed
Attempt to save pointer to unhandled type Type[/code]
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.