Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make "add as sibling" the default when drag-and-dropping an asset into 3D View #9682

Closed
Nodragem opened this issue May 5, 2024 · 3 comments · Fixed by godotengine/godot#91874
Milestone

Comments

@Nodragem
Copy link

Nodragem commented May 5, 2024

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:

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.

@AThousandShips
Copy link
Member

For uniformity it should probably be changed in both 2D and 3D, as the 3D behaviour was taken from the 2D one

@ryevdokimov
Copy link

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.

@Nodragem
Copy link
Author

Nodragem commented May 12, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants