TArray of UObjects resetting after editor restart

[Roy_Wierer.Seda145]

@Dealman

since you can’t work with categories

ha, you can’t? I actually had this experience with structs where nested categories would not show up or even cause properties to go invisible on a datatable editor. In short, if you need an object to just hold data, use a struct. A struct (being a class) can technically hold methods but this does not work properly with blueprints, in that case use UObject. When you need to add modules of logic to an actor, use components. There is no case in which this is not true, even though it might look inconvenient because of UE’s editor.

@Dealman

SceneComponent as a means of having categories seems counter-intuitive at best.

Consider it similar to sockets on a skeleton. While this seems overkill (“we only need a position and an ID here”), consider there are 999 things you get in this engine with UObjects and other types you don’t need but getting anyway. Performance won’t be affected.

Edit Don’t underestimate the power of sockets btw if you see a use for them on the skeleton itself. You can retrieve socket transforms by name of the socket. If you are building an actor with a mesh (or building an actor containing such actors) consider giving the spring skeletal mesh sockets so you can get your spring info directly from the mesh.

@Dealman

So my idea was to instead have 1 ActorComponent where you define each suspension via an array and since those will be based on a UObject they can have their own methods and whatnot. That way instead of relying on like 16 scene components all ticking individually, you have one actor component that ticks and loops through an array to do all the physics calculation (from what I can tell this is how the wheeled chaos vehicle works when setting up wheels, except their setup is 100 times more complicated).

You can disable tick per component and only update them when you want to. Make your own “Update()” method called by the 1 ActorComponent. Tick itself is not a concern for performance at all until you actually run into a measured performance hit. Right now keep it simple, optimize another day when it’s working and ready.

@Dealman

This all works exactly as I had intended it to except for the fact that once I edit the FVector via the widget and as such update the location via C++ - they break. If I instead alter the position of the spring via the vector entry in the detail panel - it saves as expected.

I have had the exact same experience in a project. I wanted to alter position of an object in the editor window, after changing a property. After user input some values would have to recalculate to find a position on a spline. I saw properties update visually but the new data would not be processed at all. I realized that what I was attempting to do was more of an “editor utility” (not proper game code) that didn’t play nice with the editor implementation and should be removed. I rewrote my code to work on BeginPlay and quit attempting to hijack the editor. I then found my solution at the cost of less editor visualization before PIE.

@Dealman

They seem to use some push model, marking properties as dirty but as far as I can tell - that’s for networking.

I think you refer to “UObject::Modify” which causes the “star” icon to appear on your asset to mark that it can be saved, but it doesn’t seem to do anything. I did that in the post you linked initially.

@Dealman

Here’s a screenshot that may explain it better than a thousand words;

I think you should make a copy of your project (backup) and go the component route, where a SceneComponent its position replaces your “SpringLocation” of that struct, so you can actually move it around in the editor. I think you can keep the rest of the struct as is, just put it on the component. This component will be your “SpringComponent”.

Components are not all bad, if you can look past the editor windows themselves. It would decouple the spring logic as well. One day you make a vehicle with no springs and have the 1 ActorComponent stuck with spring logic if you don’t decouple this.

If you really don’t want to go the component route, keep the logic and struct on your 1 ActorComponent but replace your “SpringLocation” property with a reference or ID to get a matching scenecomponent on your actor which does nothing else but exist as a position marker.