-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Adding a new scene from FileSystem dock can misfire if a Scene has an @export … PackedScene #94959
Comments
This does seem counterintuitive, however it is consistent with exports pertaining to assets. So this is just a case of PackedScenes pulling double duty (Can be instantiated by drag and drop, and can be assigned to exports by drag and drop where the latter takes priority in this case). # Drag and drop onto node from FileSystem populates
@export var my_texture : Texture2D
@export var my_scene : PackedScene
# Drag and drop onto node from Scene adds it as child
@export var my_node : Node |
Hello. I could not reproduce it in 4.2.2, I think the regression was introduced since the change on the cc @timothyqiu |
This is an intended behavior change rather than an regression, see #92004 (comment) But I guess we can add a setting to treat |
@timothyqiu This behavior definitely gets in the way if you want to compose your level by first populating levels with enemies, and then adding various component "modules" to them by dragging them from the FileSystem into each enemy (my case). In fact I'd argue the current behavior is inconsistent with the basic "add a child to a target scene" operation when drag and dropping a Scene into another Scene within Scene list panel. Right now, if I drag a scene C into scene P within Scene list panel, C will become a child of P as expected. But by the "add it to the export if possible" logic, if I drag a scene C into scene P within Scene tree, instead of C becoming a child of P, C would get plugged in into one of P's exports. Surely the latter behavior would be considered wrong. Same with copy / pasting a scene into another scene: if we follow the "add it to the export if possible" logic, the pasted scene would end up in one of the target scene exports. I think this would be very impractical. So even though we're performing the same "adding a child to a scene" operation (by drag and dropping it into another scene), the end result is different depending on where we added the child scene from (FileSystem or Scene list panel). |
We can examine the question of consistency from various perspectives, leading to potentially opposing conclusions, all of which are nonetheless valid 😛 I understand your concerns, so I have submitted a PR to restore the old behavior. |
Yes you are right. Thank you for the PR, it's appreciated! |
Tested versions
v4.3.rc1.official [e343dbb]
System information
MacMini M1 with newest MacOS
Issue description
If there's a Scene that has an
@export var my_scene : PackedScene
and I try to drag something from the FileSystem to it as a child, instead of getting added as a child the newly added scene will for some reason get inserted as a my_scene instead.
I understand this might be considered a feature, but then it's not consistent with how a dragged-in scene behaves when it's added to a scene that doesn't have an
@export
… PackedScene bit.This is super annoying when I have to drag lots of scenes from FileSystem panel into the various game levels and I want to drag them directly into Nodes in specific place in the list, but then I have to first drag them somewhere randomly (wherever there are no "
@export
… PackedScene"s) and then drag them manually to where they have to be.Steps to reproduce
In the attached project:
Drag the following scenes to the Scenes in the Scene panel directly from the FileSystem panel:
Here is the video showing it in action (right click and Save As to avoid stuttering):
https://archive.org/download/ShowFlowFleetingWorld/画面収録%202024-07-30%2021.24.43.mov
Minimal reproduction project (MRP)
adding-a-new-scene-gets-swallowed.zip
The text was updated successfully, but these errors were encountered: