Announcement

Collapse
No announcement yet.

Editor Utility Widgets Feedback

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

    #61
    Originally posted by Spoondog View Post



    I posted a suggestion in that thread that may get around your issue.

    However, "on map load / unload" events would be much appreciated here too.
    thanks. I'm going to investigate your advice a a solution.

    As for the editor events, check out elgsoft's plugin linked in this post:
    https://forums.unrealengine.com/deve...00#post1618600

    Comment


      #62
      Is it possible using editor widget to change other blueprints default variables within editor and not in game? Also can it make new blueprints in content browser? Like a child of a blueprint, but with different default variables?

      Comment


        #63
        I Think this feature is one of the best features ever made inside UE4, really it's very powerful and could elevate the Engine to a new level.
        Thanks for people who're working on this, You did a great job really.

        Comment


          #64
          In 4.23 preview 1, if I attempt to save my EUW while that EUW is open, it will not save because it is "linked to an external package". If I close the widget and then save the EUW blueprint, then it will save successfully. This happens even with a new, blank EUW, and it happens when the editor tries to autosave. Saves work ok in 4.22.

          I went to log a bug, but I can't select 4.23 as the version so here it is:

          Reproduction steps:
          1. Create an new Editor Utility Widget and add anything to it (e.g. an image). Save it.
          2. Run the editor utility widget.
          3. Open the editor utility widget in the blueprint/widget editor.
          4. Try to save the widget. Note you receive an error.
          5. Close the running editor utility widget.
          6. Try to save the widget again. Note it saves successfully.

          Saving will fail with an error message like this:
          EditorErrors: Warning: Object 'WidgetX /Temp/Untitled_1.Untitled_1:WidgetX_C_6' is in another map
          EditorErrors: Warning: Can't save WidgetX.uasset: Graph is linked to object WidgetX /Temp/Untitled_1.Untitled_1:WidgetX_6 (CreatedUMGWidget) in external map
          Last edited by Spoondog; 07-11-2019, 02:40 AM.
          Dev Blog
          Twitter: @TheRealSpoonDog
          150 FREE Blueprint functions for your project

          Comment


            #65
            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.
            Dev Blog
            Twitter: @TheRealSpoonDog
            150 FREE Blueprint functions for your project

            Comment


              #66
              Originally posted by Spoondog View Post
              In 4.23 preview 1, if I attempt to save my EUW while that EUW is open, it will not save because it is "linked to an external package". If I close the widget and then save the EUW blueprint, then it will save successfully. This happens even with a new, blank EUW, and it happens when the editor tries to autosave. Saves work ok in 4.22.

              I went to log a bug, but I can't select 4.23 as the version so here it is:

              Reproduction steps:
              1. Create an new Editor Utility Widget and add anything to it (e.g. an image). Save it.
              2. Run the editor utility widget.
              3. Open the editor utility widget in the blueprint/widget editor.
              4. Try to save the widget. Note you receive an error.
              5. Close the running editor utility widget.
              6. Try to save the widget again. Note it saves successfully.

              Saving will fail with an error message like this:
              EditorErrors: Warning: Object 'WidgetX /Temp/Untitled_1.Untitled_1:WidgetX_C_6' is in another map
              EditorErrors: Warning: Can't save WidgetX.uasset: Graph is linked to object WidgetX /Temp/Untitled_1.Untitled_1:WidgetX_6 (CreatedUMGWidget) in external map
              This should be fixed in the next preview. Thanks for calling it out!

              Comment


                #67
                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!

                Comment


                  #68
                  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.

                  Comment


                    #69
                    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.

                    Comment


                      #70
                      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.

                      Comment


                        #71
                        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.

                        Comment


                          #72
                          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?

                          Comment


                            #73
                            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!

                            Comment


                              #74
                              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:	60
Size:	6.5 KB
ID:	1645172

                              Comment


                                #75
                                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:	60
Size:	6.5 KB
ID:	1645172
                                Thanks for the detailed breakdown! We'll look into this on our end.

                                Comment

                                Working...
                                X