[VERSE] Unitialized Properties casues cook error even when being used correctly.

General Issues and Bug Reporting
, , ,
1

Summary

Unitialized properties on interfaces and/or classes crashes the cooking job even when it should not when using it correctly and initializating it later on the code.

This always worked fine on the past, and inheritance is a normal feature that is used on many projects by many devs.
Due to that, projects are softlocked unless doing workarounds such as always providing default values, even when not making sense to have one.

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

Try to instantiate from a interface or class that has a unitialized property. Even if you initialize it correctly on the child class, compiling will work, but will cause a cook error when trying to push changes or loading a session

my_interface := interface {
    SomeProperty : int
}

my_class := class(my_interface) {
    SomeProperty<override> : int = 10 # This will compile fine, but will give a cook error saying that it is unitialized when trying to load into a session.
}

The same happens with classes inheritance, regardless of the relationship with parents:

my_class1 := class<abstract> {
    MyProperty : int
}

my_class2 := class<abstract>(my_class1) {
    AnotherProperty : float = 10.0
}

my_class3 := class<concrete>(my_class1) {
    MyProperty<override> : int = 10 # Same cook error
}

my_class4 := class<concrete>(my_class2) {
    MyProperty<override> : int = 10 # Same cook error
}

Expected Result

Cooking should complete normally and work as expected, since the value is being initialized on child classes afterwards and not being left blank during runtime.

Observed Result

Cooking job fails with “Unitialized Property” errors on the code

Platform(s)

Epic Servers (Cooking Jobs)

Upload an image

image (3).png
image (3).png379×106 2.85 KB

Additional Notes

On the examples above I used <abstract> and <concrete> attributes on the classes, but note that even without using these attributes the same problem still occurs, not being related to it.

2

This problem started happening on v37.00. The same code worked fine on past versions.

This usage may be more common on Scene Graph projects, since we work a lot more with inheritance when using it.
And also more noticeable when working with classes that are exposed on editables, idk if it may have any relation with the bug, for example:

base_config_data := class<abstract> {
    BossHealth : int
}

config_data_easy := class<concrete>(base_config_data) {
    BossHealth<override> : int = 100
    ...
}

config_data_hard := class<concrete>(base_config_data) {
    BossHealth<override> : int = 750
    ...
}

some_device := class(creative_device) {
    @editable
    ConfigDataTest : base_config_data = config_data_easy{} # Cook Error here
    @editable
    ConfigDataHard : config_data_hard = config_data_hard{} # Cook Error here

    @editable
    MoreConfigData : []base_config_data = array{}  # Cook error here if array is not empty
}
3

FORT-951161 has been created and its status is ‘Unconfirmed’. This is now in a queue to be reproduced and confirmed.

4

has it not always been the case?
I think i had this problem in v36 etc when var a material, but then I cant add that var to a material_block var because it throws uninit.

something like

#pseudocode because i fr need autocomplete lol
my_block:class =
    mat:mats.mat = mats.mat{}
    var matblock:material_block = material_block{material:=mat} #nah
5

Thats not the same thing, I believe you’re having some other problem…

First, material classes does not need to initialize any values because they don’t have initialized properties. If you left it blank, it will use the default values set on the material asset itself. Due to that, it’s impossible to have unitialized property errors on material classes…

On the other side, leaving a material block (or any other class field) blank/unitialized is not supported and if for some reason compiler does not catch it, it will trigger a runtime error when running the code trying to access that field.
This is intendeed behavior, you should always initialize properties/fields to be able to use it properly.

The bug that I reported is not about runtime crashes or about compilation on editor, it is about a completely normal code that compile and works fine, but after 37.00 it started giving cook errors preventing from launching session. These cook errors are false positives and should be fixed/ignored since nothing is wrong with the code at all…

1 Like