Duplicating inherited scenes: Weird behaviour

trizZzle · April 28, 2024, 12:57am

Setup:
I have a base tower scene from which I create inherited scenes. For example beam tower:
tower

TestScene:

BeamTower4 is a duplicate (ctrl+d) of BeamTower3, everything else was intantiated using the instantiate button.

Issue:
The Firepoint of the duplicate tower 4 is the same object (same object id when running) as the tower 3s. The beam from tower 4 (bottom right) therefore fires from tower 3 (bottom left) firepoint. Targetfinder and other things are different objects.

Is this expected behaviour?

If so, why is only the firepoint the same object? Because it’s not a packed scene? And how would you quickly create “real” duplicate instances? pressing ctrl+d 10x is faster than draggin them into the tree one by one.
This is confusing. What purpose does this behaviour serve?

If not: hmmm, don’t know.

Sweatix · April 28, 2024, 2:05pm

You’re not the only one that’s confused about this mode of behaviour for duplication in Godot.

Duplicating a node should result in either a true Instance or true unique copy, not a mix of both · Issue #317 · godotengine/godot-proposals · GitHub
Always duplicate internal subresources on node duplicate (except when it does not make sense to) · Issue #4672 · godotengine/godot-proposals · GitHub

Unlike most software, Godot uses the same references (external and sub-resources) from the source object that is being duplicated. While it makes perfect sense for external resources, it is quite confusing when a duplicated object references sub-resources from its source.

Here are my suggestions to avoid this issue:
For packed scenes: use Ctrl+Shift+A to add a scene instance

For unique objects: use Ctrl+D and then make sub-resources unique

Alternatively, you could opt to not use sub-resources but instead external resources only.
This should avoid the issue of having objects that are “linked” through shared sub-resource references.

EDIT: I just realized that the problem you’re having is with an actual node being used across instances, not a resource. Perhaps this is an actual bug?

In case this has been changed in the future: please dismiss this post.

trizZzle · April 28, 2024, 8:10pm

Thank you for your help! I will test this behavior further when I have time.

EDIT:

This one was opened 2 days ago if someone is interested:

github.com/godotengine/godot-proposals

Node / Resource duplication usability improvements

opened 01:10PM - 26 Apr 24 UTC

reduz

topic:editor

### Describe the project you are working on Godot ### Describe the problem… or limitation you are having in your project Duplicating nodes in Godot can be really confusing: * It is not clear when internal subresources are duplicated or remain shared. * Even after duplication, when loading a scene, telling the amount of users of a subresource is hard. Just choosing whether to share or copy internal resources (like in Blender) is not enough for Godot. Some resources (like Meshes or materials) you never want copied. Others (like particle parameters) it may depend. Animations, when making a duplicate, most of the time you want them copied, but not always. ### Describe the feature / enhancement and how it helps to overcome the problem or limitation This proposal describes a set of usability improvements to make duplication of internal resources more user friendly. * A pop up (toaster like) that shows what is being duplicated. * A way to see who else is using a sub-resource *in the current scene*. ### Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams ### Duplication sharing control Every time the user duplicates something (ctrl-d), a small toaster like popup will appear at the bottom left corner of the viewport: ![image](https://github.com/godotengine/godot-proposals/assets/6265307/13c74cb5-5db9-47c5-900d-c20f707d867a) The popup shows: * The types of internal resources that are part of the duplication process that are being duplicated as par as the duplication action. * By default, some resources that you should never copy (like meshes) will be grayed out to show the users these will always be shared (if you really want to duplicate something like this, do it from the resource inspector). * Other resources work depending on their default behavior, showing shared or copy. * Remember *external resources are not even tracked here* (textures, etc) this is only for internal ones. Changing these values will call undo and then redo the duplication automatically with the new options. These options are remembered while the editor is open. ### Shared resource usage tracking Community asked several times why Godot can't show an amount of "users" in a resource. The answer is complicated: The resource is just a reference counter and it may be referenced from other loaded scenes, or even exist in the undo-redo stack, clipboard, etc. Due to this, estimating the number of users is hard (the reference count is misleading). To do this properly, we will do as follows: * For **internal resources** that are part of the scene will be shown by the inspector. * This will only be implemented **for resources that belong to a node**, as others are impossible to track. In practice, this solves far most users issues (As this is what users want duplicated). * When the scene changes (nodes are added / removed) or when the undo/redo modifies a property in a node, the editor will scan the current scene to track a map of resources and which nodes uses them (likely something as a HashMap<ObjectID,List<NodePath>>). The code in [this PR](https://github.com/godotengine/godot/pull/91006) already makes it easy to access properties only that are resource containers, so we may want to merge it before. With this information, resource properties of nodes would display like this: ![image](https://github.com/godotengine/godot-proposals/assets/6265307/6b7c73f7-5471-4df4-8204-7f70cc85e21a) (ignore the fact this is a texture, its just a mock-up). Clicking the number will show the other nodes in the scene tree currently using this resource. ### If this enhancement will not be used often, can it be worked around with a few lines of script? No ### Is there a reason why this should be core and not an add-on in the asset library? This is core