Child resource class initialized before parent resource class

[compmstr]

Godot version

v4.0.beta2.official [f8745f2]

System information

Linux (Pop OS), NVIDIA GeForce RTX 2060, Video Drive v 470.141.03

Issue description

If you have a base class that extends Resource with some exports, and a Child class that extends that base class, the order of initialization on loading the resource seems backwards.

If the child class attempts to reference any values in the parent class during it's initialization, it will find that the parent class hasn't been set up yet.

The class init appears to be called with all default parameters (if the export values were passed here, I could pass it along to the parent constructor). Then a second step sets the exported values from the resource file. The second step appears to be called on the child class values before the parent class values.

I would expect that the parent class would have it's exported values set before the child class.

Steps to reproduce

• Set up a Base class that extends Resource, that has at least one export
• Set up a child class that extends the Base class, with it's own export
• Have the child class try to reference one of the exported values on the Base class when setting the export value
• Load a saved version of that child class
• The base class value hasn't been set when you get to the point where the child class value is being set.

In the minimal reproduction product, I have an assert set up that will fail due to the parent class not being set up yet, so you should be able to just run it.

Minimal reproduction project

ResourceInheritBugTest.zip

[compmstr]

If it helps, I can work around the issue by manually editing the resource file and putting the resource parameter values in the expected order.

They do revert again when I save, but I am able to get the code to run.

[vortexofdoom]

I was just gonna do some digging on this and I did not find an official release for win64 where the MRP behaved "correctly" (I didn't test EVERYTHING back to alpha 1, but I did test it, and a few further back in order from the alpha 12 that @kleonc said worked). I might have done something incorrectly, but I think it may not be a regression?

[kleonc]

@vortexofdoom I've re-tested and indeed the behavior seems to be the same in both 4.0.alpha12 and 4.0.alpha14 (as well as in v4.0.beta17.official [c400205]). No idea how exactly I've tested it before but I'm assuming I've mistaken something and that's me who made something incorrectly in here. Sorry and thanks for the correction!

[EAinsley]

The problem does not lay in the initialization order. The _init was called in expected order. The problem seems to be the value stored in .tres and .tscn files are in unexpected order. Other nodes also share the same behaviour. I'm not sure if this behaviour is a bug, since both .tres and .tscn files do not preserve inheritance structures, and you cannot tell if the property comes from base or derived class.