Announcement

Collapse
No announcement yet.

Editor Utility Widgets Feedback

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by Rosium View Post

    That's great!!
    I have a question though, im working on a project that is still in 4.22, is there anyway getting a reference of the Editor Utility Widget within a regular widgetblueprint? right now, I get warning that it can not access the variable called EditorWidget (a variable ref to my editor utility widget)
    Hi! So, as early as 4.22, we began enforcing a stronger line between editor code and runtime code. It's safe to reference runtime code in editor code, since you have to have it for things like Play In Editor testing. It's not safe to reference editor code in runtime code, as you may be trying to access data that doesn't exist and could crash, etc. You can reference a regular widget blueprint in an editor widget blueprint, but the case you are trying won't be supported.

    Leave a comment:


  • replied
    Originally posted by Shadow.Storm View Post

    In 4.23 Preview, the Editor Utility Subsystem has a function SpawnAndRegisterTab that should be able to help with that, and it just takes the Editor Utility Widget Blueprint as an input.
    That's great!!
    I have a question though, im working on a project that is still in 4.22, is there anyway getting a reference of the Editor Utility Widget within a regular widgetblueprint? right now, I get warning that it can not access the variable called EditorWidget (a variable ref to my editor utility widget)

    Leave a comment:


  • replied
    I was wondering if it's possible in any way with the current Editor Utility mechanics to compile the lights for a level (and get notified when it's done), would be really great for automatizing the process of rebuilding multiple levels when some global setting, actor, material or sublevel changes.

    Leave a comment:


  • replied
    Amazing! Thanks

    Leave a comment:


  • replied
    Originally posted by Oskar Świerad View Post
    Hi! Thanks for the amazing system! I come here with a problem though I can't spawn a tab from C++.

    I put a plugin on the Marketplace and a customer let me know that it's hard to find it in the Content Browser. It turns out that it's a part of Engine Content when installed from Marketplace. So what I'm trying to do is to add a menu button to the level editor (Window -> My tool) that will spawn the Utility Widget.

    The linker complains:


    Is it on purpose that EditorUtilityWidgetBlueprint.h is not a part of BLUTILITY_API? If yes, then at least an exposed function for that purpose would be very useful.

    I based my function on AssetTypeActions_EditorUtilityWidgetBlueprint.cpp. I also followed the invaluable tutorial by IsaraTech, but they just skipped the spawning part (probably due to the same problem)

    Below is the part of my code that causes trouble:

    Code:
    if (!LevelEditorTabManager->CanSpawnTab(RegistrationName))
    {
    IBlutilityModule* BlutilityModule = FModuleManager::GetModulePtr<IBlutilityModule>("Blutility");
    UEditorUtilityWidgetBlueprint* WidgetBlueprint = Cast<UEditorUtilityWidgetBlueprint>(Blueprint);
    WidgetBlueprint->SetRegistrationName(RegistrationName);
    LevelEditorTabManager->RegisterTabSpawner(
    RegistrationName,
    FOnSpawnTab::CreateUObject(WidgetBlueprint, &UEditorUtilityWidgetBlueprint::SpawnEditorUITab)
    ).SetDisplayName(DisplayName).SetGroup(BlutilityModule->GetMenuGroup().ToSharedRef());
    
    BlutilityModule->AddLoadedScriptUI(WidgetBlueprint);
    }
    In 4.23 Preview, the Editor Utility Subsystem has a function SpawnAndRegisterTab that should be able to help with that, and it just takes the Editor Utility Widget Blueprint as an input.

    Leave a comment:


  • replied
    Hi! Thanks for the amazing system! I come here with a problem though I can't spawn a tab from C++.

    I put a plugin on the Marketplace and a customer let me know that it's hard to find it in the Content Browser. It turns out that it's a part of Engine Content when installed from Marketplace. So what I'm trying to do is to add a menu button to the level editor (Window -> My tool) that will spawn the Utility Widget.

    The linker complains:
    error LNK2019: unresolved external symbol "private: static class UClass * __cdecl UEditorUtilityWidgetBlueprint::GetPrivateStaticClass(void)"
    error LNK2019: unresolved external symbol "public: class TSharedRef<class SDockTab,0> __cdecl UEditorUtilityWidgetBlueprint::SpawnEditorUITab(class FSpawnTabArgs const &)"
    Is it on purpose that EditorUtilityWidgetBlueprint.h is not a part of BLUTILITY_API? If yes, then at least an exposed function for that purpose would be very useful.

    I based my function on AssetTypeActions_EditorUtilityWidgetBlueprint.cpp. I also followed the invaluable tutorial by IsaraTech, but they just skipped the spawning part (probably due to the same problem)

    Below is the part of my code that causes trouble:

    Code:
    if (!LevelEditorTabManager->CanSpawnTab(RegistrationName))
    {
        IBlutilityModule* BlutilityModule = FModuleManager::GetModulePtr<IBlutilityModule>("Blutility");
        UEditorUtilityWidgetBlueprint* WidgetBlueprint = Cast<UEditorUtilityWidgetBlueprint>(Blueprint);
        WidgetBlueprint->SetRegistrationName(RegistrationName);
        LevelEditorTabManager->RegisterTabSpawner(
            RegistrationName,
            FOnSpawnTab::CreateUObject(WidgetBlueprint, &UEditorUtilityWidgetBlueprint::SpawnEditorUITab)
        ).SetDisplayName(DisplayName).SetGroup(BlutilityModule->GetMenuGroup().ToSharedRef());
    
        BlutilityModule->AddLoadedScriptUI(WidgetBlueprint);
    }
    Last edited by Oskar Świerad; 07-24-2019, 05:04 PM.

    Leave a comment:


  • replied
    Originally posted by Jerome Parent View Post

    There's no real bug, the ForceHiddenPropertyVisibility flag is doing what it's supposed to, it's just that if you want to only show properties that are marked as InstanceEditable (in BP) or EditAnywhere (native), you can't.

    Based on some quick testing in editor:
    • Every Property created in Blueprint has CPF_Edit regardless of their other flags.
      • When a BP property is marked as InstanceEditable, it loses the CPF_DisableEditOnInstance flag (which seems to be a flag specific to Blueprint properties)
    Personally I think it would be nice to change the ForceHiddenPropertyVisibility flag into an enum where you have:
    • Show everything
      • Current ForceHiddenPropertyVisibility=true
    • Show properties with CPF_Edit
      • Current ForceHiddenPropertyVisibility=false
    • Show only instance editable properties
      • BP: CPF_Edit && !CPF_DisableEditOnInstance
      • Native: Whatever CPF_Edit + EditAnywhere is. Not sure what combination of flags represents an EditAnywhere native property.
    I just don't see the DetailView in its current form being that useful unless you use it only on classes where everything is fully exposed (BP InstanceEditable or native EditAnywhere), because you can't actually change those non-exposed properties if you click on them in the DetailView widget from my experience.

    For example, with these 3 Blueprint properties in a UMG DetailView with ForceHiddenPropertyVisibility=false, I see all 3 properties but only the first one can be changed. The other 2 just don't respond and I have no way of hiding them without moving them into a different category and starting to whitelist the categories instead of showing all properties.
    Click image for larger version

Name:	Properties2.jpg
Views:	182
Size:	6.5 KB
ID:	1645172
    Thanks for the detailed breakdown! We'll look into this on our end.

    Leave a comment:


  • replied
    Originally posted by Shadow.Storm View Post
    Hm - there actually is an advanced flag on the details view to Force Hidden Property Visibility. If that's not on and you're still seeing this behavior, could you report it through the bug tracker? Thanks!
    There's no real bug, the ForceHiddenPropertyVisibility flag is doing what it's supposed to, it's just that if you want to only show properties that are marked as InstanceEditable (in BP) or EditAnywhere (native), you can't.

    Based on some quick testing in editor:
    • Every Property created in Blueprint has CPF_Edit regardless of their other flags.
      • When a BP property is marked as InstanceEditable, it loses the CPF_DisableEditOnInstance flag (which seems to be a flag specific to Blueprint properties)
    Personally I think it would be nice to change the ForceHiddenPropertyVisibility flag into an enum where you have:
    • Show everything
      • Current ForceHiddenPropertyVisibility=true
    • Show properties with CPF_Edit
      • Current ForceHiddenPropertyVisibility=false
    • Show only instance editable properties
      • BP: CPF_Edit && !CPF_DisableEditOnInstance
      • Native: Whatever CPF_Edit + EditAnywhere is. Not sure what combination of flags represents an EditAnywhere native property.
    I just don't see the DetailView in its current form being that useful unless you use it only on classes where everything is fully exposed (BP InstanceEditable or native EditAnywhere), because you can't actually change those non-exposed properties if you click on them in the DetailView widget from my experience.

    For example, with these 3 Blueprint properties in a UMG DetailView with ForceHiddenPropertyVisibility=false, I see all 3 properties but only the first one can be changed. The other 2 just don't respond and I have no way of hiding them without moving them into a different category and starting to whitelist the categories instead of showing all properties.
    Click image for larger version

Name:	Properties2.jpg
Views:	182
Size:	6.5 KB
ID:	1645172

    Leave a comment:


  • replied
    Originally posted by JeromeParent View Post
    Thanks.

    Another question, is it expected that the new DetailsView widget shows all properties even if they are Private (the behavior is the same for native or BP properties)? They cannot be modified in the DetailsView if they are not Public/Instance Editable which makes sense, but the fact they are displayed is pretty weird since they look editable but just don't respond to interaction.

    Is the intended use of that widget to expose one or a few specially-crafted categories of properties and it's up to us to make sure we don't have private properties in there?
    Hm - there actually is an advanced flag on the details view to Force Hidden Property Visibility. If that's not on and you're still seeing this behavior, could you report it through the bug tracker? Thanks!

    Leave a comment:


  • replied
    Thanks.

    Another question, is it expected that the new DetailsView widget shows all properties even if they are Private (the behavior is the same for native or BP properties)? They cannot be modified in the DetailsView if they are not Public/Instance Editable which makes sense, but the fact they are displayed is pretty weird since they look editable but just don't respond to interaction.

    Is the intended use of that widget to expose one or a few specially-crafted categories of properties and it's up to us to make sure we don't have private properties in there?

    Leave a comment:


  • replied
    Originally posted by Jerome Parent View Post
    Does anyone know which .ini contains the settings for which Editor Widget is opened? It's possible (especially with list views) to create situations where the editor will crash when a widget is created, and since it re-opens any opened Editor Widgets on boot, you don't really get a chance to close them before the editor just crashes again.
    Code:
    \Engine\Saved\Config\Windows\EditorLayout.ini
    saves the entire editor layout, so if you had a tab open that was causing issues, clearing that ini should allow you to boot with the editor's default layout.

    Leave a comment:


  • replied
    Does anyone know which .ini contains the settings for which Editor Widget is opened? It's possible (especially with list views) to create situations where the editor will crash when a widget is created, and since it re-opens any opened Editor Widgets on boot, you don't really get a chance to close them before the editor just crashes again.

    Leave a comment:


  • replied
    New/different things to try out in 4.23 Preview:
    • Editor Utility Blueprints (formerly known as blutilities, but renamed to match other editor utility functionality) are now on by default.
    • Marking a function as "Call in Editor" in Editor Utility Blueprints no longer makes a button in the details panel. Editor Utility Widgets enable you to create much more flexible UIs, so we wanted to unify the locations UI would be expected.
    • You can base Editor Utility Blueprints on any editor-only class that isn't a widget. There are some base classes like EditorUtilityActor and EditorUtilityObject to get started with, but editor-only classes in your project will work as well.
    • The functionality from GlobalEditorUtilityBase and PlacedEditorUtilityBase have been moved to default engine libraries like EditorUtilityLibrary, as well as the EditorScriptingUtilities plugin (so remember to enable that).
    • Double-clicking now opens the Editor Utility Blueprint for editing, to match other asset behavior.
    • Editor Utility Widgets now have single property rows and details panels so you can easily expose properties for editing without needing to remake editor UI. A helpful hint is to set "this" node for the Object of these widgets, and then any public properties will show up. (I'll try to get an example of this mocked up).
    • You can add a Run function to any Editor Utility Blueprint or Editor Utility Widget which will run on editor start. This will create an instance and allow for binding to stateful editor events.
      • In EditorPerProjectUserSettings.ini add a section:
        [/Script/Blutility.EditorUtilitySubsystem]
        +StartupObjects=/Game/ExampleStartupObject

    Please report any bugs you find through the bug reporter, and keep showing us your awesome examples!
    Thanks!
    Last edited by Shadow.Storm; 07-12-2019, 09:26 AM.

    Leave a comment:


  • replied
    I made this basic tools using the editor utility widgets, thanks for making these amazing tools .

    The level management stuff doesn't work, I couldn't find any nodes to make duplicating work
    But it's pretty cool that you can make tools right in the engine now.

    Edit : I just have to use Spawn Actor from class to duplicate lol, I am so dumb

    Last edited by Εxtrone; 07-17-2019, 11:23 PM.

    Leave a comment:


  • replied
    Originally posted by Spoondog View Post
    I'm also getting a crash if I try to save a savegame file from an EUW (I submitted the crash via crash reporter).

    I save the state of just about every input to a savegame file when the widget is closed, and restore when it opens... which worked ok on 4.22.
    Will add this to the list to investigate - thanks!

    Leave a comment:

Working...
X