You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, drag-and-dropping adds the scene as a child of the selected node. Hold Alt when releasing the mouse to add the scene as a child of the root node, or Shift to add the scene as a sibling of the selected node.
And thanks to this PR: godotengine/godot#84347, the latest added node is automativally selected.
As discussed here #9613, this accidentially creates the following behaviours:
default: add new node as child of selected node and select automatically the new node;
ALT modifier: add new node as child of root and select automatically the new node;
SHIFT modifier: add new node as sibbling of currently selected node and select automatically the new node.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
These accidental features are very exciting for level designers. But I would like to propose that we swap the SHIFT and default behaviour. Indeed, when editing a level, to add as sibling and select automatically the new node is what you want 90% of the time.
Alternatively, or in addition, the default, ALT and SHIFT behaviours could be changed in the Editor Settings.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Just need to a few variables in the code.
Then for having it in the Editor Settings, it might me more involved.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Nope, it is hard coded.
Is there a reason why this should be core and not an add-on in the asset library?
This is a small change on an existing feature.
The text was updated successfully, but these errors were encountered:
I don't have a strong opinion yet about what the default behavior should be in terms of sibling vs root, but after having used 4.3 for some time, I agree that child is not the right way to go.
Often you are dragging multiple of the same scene into the viewport and having each one be a child of the next is not what I would expect to be the desired behavior without a modifier. I'd be interested to hear what the reasoning was for having it be that way in 2D, as I don't use it as much.
My use case is 3D level editing but it should be similar for 2D level editing. I tried it and it is very productive to add as sibling by default and hold Shift whenever I need to add as child.
For instance:
I select a house, hold Shift to drag and drop a furniture as a child of the house,
This selects automatically the added node
Then I just drag and drop new furnitures as sibling (without holding any modifier keys), until I am done filling that house,
Result: All my furnitures are added as children of the house
Once I am done, I select another house and the cycle starts again.
To add as child of root is not really useful in this workflow.
Describe the project you are working on
Making a level for a 3D Top Down shooter: https://github.com/Nodragem/twin-stick-shooter-starter-kit
Describe the problem or limitation you are having in your project
In 4.3dev6, if I drag and drop a 3D asset in the 3D Viewport it is added as a child and automatically selected; which is not necessarily useful.
Thanks to this PR: godotengine/godot#87623, we've got the following behaviour:
And thanks to this PR: godotengine/godot#84347, the latest added node is automativally selected.
As discussed here #9613, this accidentially creates the following behaviours:
Describe the feature / enhancement and how it helps to overcome the problem or limitation
These accidental features are very exciting for level designers. But I would like to propose that we swap the SHIFT and default behaviour. Indeed, when editing a level, to add as sibling and select automatically the new node is what you want 90% of the time.
Alternatively, or in addition, the default, ALT and SHIFT behaviours could be changed in the Editor Settings.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Just need to a few variables in the code.
Then for having it in the Editor Settings, it might me more involved.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Nope, it is hard coded.
Is there a reason why this should be core and not an add-on in the asset library?
This is a small change on an existing feature.
The text was updated successfully, but these errors were encountered: