In order to create a panel or button pop-up that has functionality within the editor you’d either have to extend the editor itself, or create a plugin.
As CleanCut suggests, you can add a variable that includes a widget in the viewport; but you can’t directly tie any special UI buttons or panel popups to it. It just gives you a handle to manipulate the variable value itself (i.e. with a vector you get a translation widget that updates the vector’s X,Y,Z values based on the handle’s location.
You might be able to do a bit of a workaround by using PostEditChangeProperty; you could create a vector and display a 3D widget:
UPROPERTY(EditAnywhere, BlueprintReadWrite, Meta = (MakeEditWidget = true))
FVector WallSpawn;
And then you can use the handle to modify the value, detect that change via PostEditChangeProperty, and trigger your spawn.
#if WITH_EDITOR
void AWallPiece::PostEditChangeProperty(struct FPropertyChangedEvent& PropertyChangedEvent)
{
//Get the name of the property that was changed
FName PropertyName = (PropertyChangedEvent.Property != nullptr) ? PropertyChangedEvent.Property->GetFName() : NAME_None;
//Check if it's the property we want
if ((PropertyName == GET_MEMBER_NAME_CHECKED(AWallPiece, WallSpawn)))
{
//trigger your desired action if it is
DoWallSpawn();
}
// Call the base class version
Super::PostEditChangeProperty(PropertyChangedEvent);
}
#endif
Basically you’re hacking the FVector value modification to behave as a button.
It’s quite a bit cludgy, though; and means your game object will be cluttered with unnecessary variables.
“Now obviously this would be possible with an editor extension, but then I’m putting a nice coupling between my gameplay objects and the editor which I’m not super happy with.”
You don’t have to modify your game object code at all. You can build the plugin/editor extension to just detect the presence of your target objects within the level (and could even check for multiple, different classes) and then build the widgets based on their location in the game world. They can be completely independent of the runtime elements.
You can build your plugin to respond to editor events and detect when objects of the type you like are selected, and then have the plugin trigger the visibility of the panels. But again, this isn’t tying your gameplay objects to the editor, it’s tying your plugin to the editor (but without the editor the plugin has no functionality or reason to exist).
Quite the contrary, building the functionality into your game actors more closely ties them to the editor, as with the PostEditChangeProperty method above. You can include #if WITH_EDITOR, but the code itself is still tied to Unreal’s editor.