Access Blueprints through the Details Panel

I wanted to bring up the possibility of allowing users to access and modify the blueprint default values through the Details Panel that is a part of the level editor (there is an important distinction to be made because within the blueprint editor there is also a details panel, I’m specifically referring the Details panel that is opened through Windows > Details).

The screenshot shows the two details panels, ideally you would be able to select a blueprint in the content browser and see its details in the standard details view:

My reasoning for this request is that when you are working with blueprints that aren’t placed in the level, but instead spawned at runtime, you need to be modifying the default values, not the values of particular instances. Currently the process is to open the blueprint editor which by default fills the entire screen, you can make your changes but then you have to close or minimize that editor, then you can hit play, and then you have to either reopen the blueprint editor or maximize it (if you minimized it), these extra actions are very grating when working on iterating default values. The benefit of this change is that it would allow a programmer to set default values without needing to dance through the blueprint editor which is what I currently find myself doing all the time and it feels very weak in terms of workflow / user experience.

I hope that this change will be seriously considered, it would immensely improve my happiness when working with the editor and I think a lot of other people would feel the same (even if they never find this post to write so). Thank you for taking the time to consider this.

The ideal would allow me to select in the content browser the item I want to editor and in the details panel the default values would pop up (instead of the nothingness that pops up at this point in time):

I think it’s a decent idea to have a quick way to edit properties of objects in the content browser. The thing is, all details panels are attached to a specific editor (level editor, blueprint editor, etc) and are specialized for displaying the details of things in that editor. So the details panel in the level editor is specifically for editing placed actors. If you try to drag it out, it can’t be docked at the top level, because it is attached to the level editor. The content browser has no such attachment, it basically exists at the root level of a project.

So I don’t think it would make sense to use the level editor details for this - after all, it’s possible to have an actor in the level selected and simultaneously something selected in the content browser. They could though add a separate content details window, which was attached to the content browser and just showed the basic properties of anything selected, be it a blueprint, a material, static mesh or whatever.

That limitation makes sense and technically your work around sounds pretty good, but the point of the change is that the workflow slows down when you have to move to a different section of the editor and adding a new details panel would only further crowd the editor, which would likely greatly reduce the benefits of the proposed change. And while I agree that theoretically allowing you to select something in the editor blurs the purpose of the details panel in the level editor you can already see a successful implementation of this general purpose details editor in the Unity engine.

So perhaps a good hybrid approach would be that you could set a level-editor-details-panel and a content-details-panel in the same location (two tabs sitting next to each other):

Then in your editor options you could have the option to “Change Focus on Selection” which would allow you to have the editor change the focus from the level-details panel to the content-details panel when you make a selection in either the content browser or the level editor:

(Yes this is just a second level-details panel, the purpose being illustrated is that you could have the two tabs swap when stacked together like in the images)

So for example if you are working in the scene the level-details panel is available and then if you decide you need to edit an asset you click the asset in the content browser and the content-details panel will be brought to focus (set it to be focused when the tabs are part of the same frame) and then once you’ve made your changes you can select something in the scene and it will swap you back to utilizing the level-details panel.

As a heads up, you can configure Play to open in a new window (in the drop-down next to the button). When working on my laptop I usually dock the BP I’m working on into the same well as the level editor, set PIE to be in a new window and use Alt+P to launch whenever I need to test, never going back to the level editor unless I need to adjust the position of something.

Michael Noland

Oh. Well that’s a useful work around that I haven’t tried.

However, while it solves part of the problem there is still the issue that you can’t dock the blueprint editor in the level editor which causes a great deal of annoyances, for one, it seems like when I open a new blueprint I get random behavior, sometime it will open the blueprint as a tab next to the level editor, sometimes however, it will spawn the blueprint editor as a floating panel, but always at a terrible size, nothing resembling the size I always have to then increase it to, then when I have a tab open it will slot the next few blueprints in the floating windows, BUT then once the bar is filled it puts it as a tab next to the level editor (don’t misunderstand me here, this happens when tabs can’t be placed in the floating window at full size anymore, instead of the more reasonable choice of instead of just reducing the size of the tabs as a group), which is a pain because the floating windows now blocks that content that was just placed as a tab next to the level editor so you have to minimize or grab the new tab and manually place it in the floating window. The problem is inconsistency, when I open a blueprint I have no idea where I’m going to be looking, this makes the process highly disjointed and results in a irritating pause in my workflow whenever I have to open a blueprint as I usually have to move or realign the blueprint editor window to suit my needs.

The ideal is that I can have a dedicated panel IN the level editor, since that’s the primary work interface in the Unreal Engine, that will display (and allow me to edit) blueprint default values, which responds to me clicking a blueprint in the content browser (single clicking) and then if I need to further edit the blueprint I should be able to continue with the current workflow (double click). I’m not certain what a person who actually uses the blueprint editor for creating blueprints would get from this process but for myself, when I’m working it’s mostly with code, which means when I do transition back to UE4 its to create a blueprint based on the code, or modify something in an existing blueprint, which usually only involves modifying/setting up the default values of the Blueprint. However, working with the blueprint editor in this type of workflow is just a torturous experience; slow, uncomfortable and disorienting.

The benefit of this suggestion is that when working with different blueprints it wouldn’t be necessary to have a hundred different blueprint editors open, floating around the screen or sitting in tabs, instead they would be funneled nicely through the “Blueprint Details Panel” which would be dockable WITHIN the level editor [hopefully with the ability to have the system intelligently focus the “Blueprint Details Panel” when you single click on a blueprint, so that you can set the Details Panel and Blueprint Details Panel nicely next to each other and have their focus change depending on what you have selected] instead of a tab (which sucks because it blocks off access to the level editor) or as a floating window, which is a pain itself (blocks content when active and if I minimize it I have to dance between windows minimizing and maximizing ad nauseam).

It’s been a couple of days and this post got pushed down, I won’t pop this back up after this, but… Does this workflow not seem extraordinarily inconvenient to anyone else? Especially with the annoyances presented in the above post? I feel like the entire UE4 system is made to work with Blueprints but modifying the default values of blueprints is a hassle, even an option like “Show Currently Selected” would be a massive improvement in workflow, where the blueprint editor would be set in a particular window to display the blueprint that is currently selected in the content browser without the need to open an additional blueprint editor tab / manage a mass of blueprint editor tabs. This would make it quick to change to the next blueprint without littering the workspace with tons of abandoned blueprint editor tabs.

Feels? Ideas?