godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.12k stars 69 forks source link

Add a project setting to make subresources unique when creating new resources #3072

Open elvisish opened 3 years ago

elvisish commented 3 years ago

Describe the project you are working on

A menu system for a game.

Describe the problem or limitation you are having in your project

I duplicate labels (rather than creating each one from scratch) with Area2D's and collision polygon children to create various clickable options for menus.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It's frustrating to have to keep selecting each child object and choosing Make Sub-Resources Unique for every collision polygon.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

A simple setting in Preferences that allows every duplicated node to automatically be unique.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, it would be a Godot setting.

Is there a reason why this should be core and not an add-on in the asset library?

It would be a Godot setting.

YuriSizov commented 3 years ago

The reason why this is not the default is because duplicating everything by default would cause a lot of performance issues which would be perceived by the engine newcomers as an issue with the engine rather than a setting they need to tweak.

Calinou commented 3 years ago

See also https://github.com/godotengine/godot-proposals/issues/1848.

I think a better way to solve this is to make the "shared" or "unique" status more obvious in the inspector, like Blender does when displaying the number of users next to each resource.

elvisish commented 3 years ago

The reason why this is not the default is because duplicating everything by default would cause a lot of performance issues which would be perceived by the engine newcomers as an issue with the engine rather than a setting they need to tweak.

I didn't mean for it to be a default setting, but a toggle-able one for those who know the ramifications of turning it on.

See also #1848.

I think a better way to solve this is to make the "shared" or "unique" status more obvious in the inspector, like Blender does when displaying the number of users next to each resource.

This would also be greatly helpful in addition to the ability to have new resources be their own new instances by default (if turned on by the user).

Calinou commented 3 years ago

This would also be greatly helpful in addition to the ability to have new resources be their own new instances by default (if turned on by the user).

For the aforementioned reasons, I wouldn't provide an option to do it by default, but we can add a modifier key that you can hold (such as Ctrl) when clicking the New (Resource) button. This would enable Local To Scene automatically on the newly created resource.

That said, this wouldn't resolve your particular use case with duplicating labels (since no new resources are being created here, and Local To Scene only works with scene instancing).

Zireael07 commented 3 years ago

See also #904 which is what @Calinou mentioned regarding ux.

elvisish commented 3 years ago

This would also be greatly helpful in addition to the ability to have new resources be their own new instances by default (if turned on by the user).

For the aforementioned reasons, I wouldn't provide an option to do it by default, but we can add a modifier key that you can hold (such as Ctrl) when clicking the New (Resource) button. This would enable Local To Scene automatically on the newly created resource.

That said, this wouldn't resolve your particular use case with duplicating labels (since no new resources are being created here, and Local To Scene only works with scene instancing).

How about a new menu option/key modifier that allows for a duplicate object with unique resources? Although I think the ability to toggle this in the editor somewhere would make this a lot easier (so it could just be switched off for some mass duplication work and switched back on again).

golddotasksquestions commented 3 years ago

Also see this related issue: https://github.com/godotengine/godot-proposals/issues/317

I think the most common and biggest issue is with collision shapes or shape resources in general and animations. We really ought to do something about it.

jordanlis commented 2 years ago

Maybe 2 different options when duplicating nodes depending on the use case ?

This could be done in different ways :

As mentionned by Calinou, I think it shoud be hilighted when a node has shared ressources and explain in a popin what it implies why it's done like that. ressources_shared

Finally, we also ought to be adding an option in the menu to make all ressources unique for all nodes that are concerned instead of making the ressources unique and/or local only for the selected nodes. node_menu

I feel this is not enough, and we should directly add a menu to handle it directly in the node, because this node menu is so tiny and all users do not know its existence, and this doesn't allow to handle each case. I would do something like this

  1. Display a button that leads to a new window manage_ressources_button

  2. Allow users to handle subressources in this new window (for example) manage_resources

I hope it helps ;p

lukostello commented 2 years ago

I posted my solution in the issue just mentioned but I'll restate it here: the solution is more (different?) flags for duplicate DUP_LOCAL = 1 for if you want to duplicate resources marked local DUP_NOT_LOCAL = 2 for if you want to duplicate resources not marked local DUP_SUB_LOCAL = 4 for if you want to duplicate sub resources recursively if they are marked local DUP_SUB_NOT_LOCAL = 8 for if you want to duplicate subresources recusively if they are not marked local VAR_BY_REF = 16 if you want to you want the nodes variables to just hold a reference to the value held at the original's variable's location except for transform because otherwise they would be the same thing in the same place (I think this is what DUPLICATE_USE_INSTANCING is suppose to do but I'm not sure I've been testing it and it doesnt seem to do anything) I don't really know why there is even a DUPLICATE_SCRIPTS flag right now, just set the script as local_to_scene if you want it copied. Then I think we would still need DUP_GROUPS (32) and DUP_SIGNALS (64) too Then you could even have shorthand for common flag combinations such as: INSTANCE = 1 UNIQUE_INSTANCE = 1 + 2 =3 DEEP_INSTANCE = 1 + 4 = 5 SHALLOW_COPY = 1 + 2 = 3 DEEP_COPY = 1+2+4+8 = 15 COMPLETE_INSTANCE = 1 + 2 + 4 + 8 + 32 + 64 = 111 or whatever the naming conventions are. Frankly Im confused about the words being thrown around here but I'm pretty sure whatever people mean can fit somewhere in these flags. This is just for code, for in the inspector my solution to solve the default duplicate behavior/UI here is this: when you hover the mouse over duplicate in the right arrow menu there would be a secondary subdropdown that would show on the side with the same common means of duplication shown above i.e. deep instance, unique instance, shallow copy, deep copy. That way everyone can have the behavior they want as well as the flexibility to do other ones. These same flags and conventions could be used for .instance() as well

Gathub22 commented 1 month ago

Also see this related issue: #317

I think the most common and biggest issue is with collision shapes or shape resources in general and animations. We really ought to do something about it.

That's my current biggest issue with Godot. I'm experimenting with procedural deformation and I have a scene with a mesh and a linked script for the physics. It's frustrating that when I have multiple copies of the same scene, they share the same deformed mesh.

It would be a great help if Godot can make scenes unique or not with a global setting that makes working much easier in these really special cases where shared resources are an inconvenience.