We have a large TArray full of definitions of spawnable objects that will be selected to spawn when various conditions occur. It has a struct with numerous informational items and the class to spawn, but most importantly, the spawn location and rotation where it will go if spawned. The designer can drag the class in the world to where he would want it, then copy the FVector and FRotator and paste it back into the array, but this is very cumbersome. The A new, community-hosted Unreal Engine Wiki - Announcements and Releases - Unreal Engine Forums looked like the perfect solution to this, only FComponentVisualizer is only for components, and this array is just a TArray of structs in the C+±extended Level Script. I created an editor module and started to code this, and then realized, I can’t get there from here, the editor would only call my module if it were a component. The DrawVisualization wants to get called on a UActorComponent.
Is there an editor module class (or some other idea I haven’t thought of) that is made to just place a translation widget in the viewport so I can allow the designer to drag the widget around to set the FVector and FRotator for spawn location and rotation. That Wiki example is really close, in fact made to accomplish the same concept, but my class is not a component. Been mulling this over and searching for a solution for months now.
I haven’t tried it for ages and just going from memory, but I believe you can add the following to some property types (maybe FVector, FRotator, FTransform?):
UPROPERTY([stuff here], Meta = (MakeEditWidget = true))
FVector MyProp
And that *should *create a gizmo in the level editor that you can move and rotate to edit the property. Not certain how it works with arrays though.
Thanks for that, it appears to be a start possibly. If it is placed on a FVector Property within an actor, it will appear (with the variable name) when the actor is placed in the Level. It doesn’t appear in the viewport for that blueprint though, and given that my properties are in an array in the level blueprint, there is no object to place in the level. What that does though, is give me some engine code to browse through and see how they are doing that. Then possibly, an editor module could do something similar. Just running through testing this, makes me realize the scope of what a module would have to accomplish. One has to drag the blueprint out of the main window to expose the editors level window, then editing the FVector in the (now detached) blueprint window, would have to affect the translation widget in the level editor window, which would be in conflict with whatever is clicked in the outliner. I’m wondering if that would even be possible.
It also made me think of a fall back if nothing else works. If I move the array into an Actor class (existing only to hold the array), then dragging it into the level at 0,0,0, may allow the designer to observe and manipulate the entire mess of objects, move them around etc, then I would have to write the values back into the original staticclass array via the editor module. Sounds hacky, but might work.
But you have given me a place to look for code that may do part of it, or directly a part of a solution.
Why does the array need to be on the level blueprint necessarily? It’s quite normal to create an actor class for special actors/managers that you place just one of into your level. You can then easily access a reference to that actor from the level blueprint if needed.
You’re correct, the Level Blueprint isn’t magic to this application. We were just discussing this, it was just a convenient place to toss in the array for scenario data for a level. The scenario array that holds all these dynamic objects can go into an actor class that will not have a visual presence in the world during gameplay, but would hold the array. Then that actor could be placed and remain in the level for development and placement, and used at runtime for the data it provides. This could make it a complete “meta” solution without having to use an editor module. I will prototype this today.
Since the meta solution as discussed would put a couple of hundred “SpawnLocation” words in the level editor, it will have to use meta to pick the unique name of the object out of the array, there is likely a way to do that (something similar to the meta = (TitleProperty = “InternalName”) we currently use to identify array slots). This solution also involves changing X,Y,Z values rather than dragging things around, but that’s not unworkable for the designer as long as you can see where things are moving, and this method does that just fine.
Okay, I’ll take a look as that is another avenue. I’d never heard of Bluetility. I guess I should be reading the forums more.
I implemented the prototype of a meta only solution using the MakeEditWidget and while crude, the designer feels it’s workable. I created a new actor class with nothing but a constructor and the array in public:. The array is a an array of structs containing and Internal Name and other structs. Two levels down in the structs is the spawn location. The MakeEditWidget provides the Array index, the second level struct name and the variable. I created a BP of the class, pasted our array in and dragged it into the level. All the array entries immediately show up with clickable translation widgets. These allow moving the object which alters the values in the SpawnLocation variables.
The property looks like this:
TitleProperty Meta did not work at that level because looking at the code, it doesn’t appear that it is designed to work backward up the chain of structs. What appears in the level by each Translation Widget, is Scenario[x].ObjectDetails.SpawnLocation where the Scenario is the top level TArray name, x is the index of the array, ObjectDetails is the second level struct, and SpawnLocation is the actual property name. Though this is workable, I will attempt to place the real mesh there for each object (if one exists in that object) and maybe get the Internal Name we have on the elements to display. I’ll explore this other Bluetility to see if it is simpler. This was shockingly trivial though.
I noted that there are far more meta available in the code than are documented, and even more specifiers than the wiki list provides. It’s like a candy store.
Thanks again for these ideas. Should have posted months ago.