Where should I store immutable data?

Some data aren’t supposed to change mid game, in my project I used to store that data in Data Tables, using structures too, it works but it’s buggy, when modifying structures it breaks Data Tables, when I changed from UE4 2.27 to UE5 EA2 it breaks, when I change from UE5 EA2 to UE5 it breaks too.

Example of data: In my project have character classes and a leveling system, each class start with different values for attributes, as well as different values for attributes gaining with level up.

So, where am I supposed to store that data?

You’d normally store them in datatables. Perhaps you could test migrating from UE4 to UE5 by eporting your datatables to CSV and importing them into UE5 as CSV. Since CSV is just an excel sheet data will not corrupt in that format.

It will be useful if you can tell us how and when these structs corrupt exactly. Many users reporting problems with corrupting struct are also using the Hot Reload feature of UE which corrupts things in the first place.

1 Like

I was not using Hot Reload, maybe, I really do not know what it is. My structures are kind complex, some times I use structures of structures, does it cause problems? How big can one structure be? I kind worried about it.

Example: I have one structre corresponding do character attributes: HP, MP, MovSpeed, AS, CritRate and so on. ~10 attributes. When I add another attribute, it breaks the DataTable, so I have to manually recreate all the rows.

I read that you should plan your Structures first, and I kind of agree with that. But that is a little unpractical, I wish I can add the attirubtes I need, or delete ones that I don’t need more without those problems.

Hot Reload is basically when you have both Unreal Engine and Visual Studio open at the same time and compile your c++ in VS. UE will then make a “techno / beep” sound while “hot reloading” the changes. This is an experimental feature which only creates trouble. So, close Unreal Engine whenever you compile c++ code.

If this is not a nested struct, I can assure this should never happen. It is not normal to break when you add a property to a struct, be it a UAsset struct or a c++ struct. If it is a nested struct, I have not tested that enough.

Planning structures can only be done to some point. What you are doing (adding an attribute to a struct later on) is OK and should not create the trouble.
I only very rarely nest structs, often it is more useful to add a FDataTableRowHandle (c++ name for datatable row) property to my structs, pointing to another datatable. This way you can set up one datatable with attributes from the FS_Attribute struct and one datatable from the FS_Character struct, which references attribute rows from the attribute datatable. This way you can easily reuse data and you do not have to nest structs .

1 Like