I have added a boolean to a struct (image attached) and any time i try to change its type to anything fitting for a 1 line text description, string or text, unreal 5.3 crashes. I’ve attached the log file because maybe someone can make sense of what’s wrong. This log file was generated just now when the engine crashed when I tried to change the boolean to an integer type.
Update: I deleted the boolean and created a new member, then switched it to text type. The engine lagged a bit and then miraculously didn’t crash and accepted the change.
Update: I just tried to move the new text member up to below the BuildingIcon member and it crashed again.
Still an issue worth looking into. Hopefully log file will help! SpaceColonySurvival.log (546.8 KB)
Hey there @WolfTechRob! Is this a hybrid C++ and Blueprint project by chance? When forcing the compile so all classes can see the struct, it may hitch just a bit regularly. That said, it’s uncommon for it to crash unless some code already relies on the struct already.
this is an extremely old and unresolved problem with blueprint structs, if you search the forum you will find best practices for modifying structs but its never been resolved.
my advice is to plan exactly what you want in a struct and hopefully never change it, otherwise if you have a crash on startup you may have to delete the offending UAsset and recreate it
This is a blueprint only project. A programmer friend of mine saw some errors in our log and mentioned something to the sound of, when adding, modifying, or re-organizing members of a struct that is referenced, this hick-up is from updating those references. The crash is a result of variables that aren’t compatible when trying to update that reference. In my case, switching a boolean to a text that was in the same place as the ConstructionTime float, caused enough of conflict to crash the engine.
So 5 possible non-solutions:
1.) Compile all blueprints that reference the struct with each step of adding/changing member type.
2.) Disconnect the references as you make those same changes to the struct.
3.) Just know Exactly what you’re struct will contain from the initial implementation and don’t plan to modify the struct at all.
4.) Keep your structs small to possibly decrease the chances of a crashes and durations of hick-ups.
5.) Don’t use structs.
Finally a suggestion:
Do not nest structs! Related to the instability of structs, another issue I just had was a struct that had 3 nested structs, got completely reset to 0s. Not even defaults! Total members that got reset is around 25, and these values were referenced by about 80 units (making an RTS, struct contained vitals, costs, and other values).
5.) Don’t use structs. lol
I am having the same issue, I removed a variable from a Struct and now if I use Make Instanced Struct to build the struct as a payload for a StateTree, it crashes the engine.
I’m also making an RTS! I have +20 structs and lots of nested structs, I planned everything pretty well, but that made this even worse. As I never had to change anything, they worked perfectly for a long time, but now that I need to change a few things, it crashes. I can’t even change a float for an integer, crashes immediately.
Did you continue with the project? What did you use instead? I have seen other alternatives but they mean re-creating everything and re-writing a lot of code.
Laurino has reached out to me already, but updating for anyone else who finds this. I went the route of no more nested structs and using data tables. So the reference chain looks like this
BP_Building>DataTable>Struct_BuildingStats.
Each building uses a row from the data table!
This solves 2 things
No lag/crash when adding a member to the struct, because all units in project no longer directly reference the struct, now only reference the data table. So adding a member (struct value) does not require all references to get updated.
Since doing this, the struct has not reset to default. If it does, hopefully would only happen to a row in the data table instead of for all actors referencing the struct.