Fix resource shared when duplicating an instanced scene#64487
Fix resource shared when duplicating an instanced scene#64487Repiteo merged 2 commits intogodotengine:masterfrom
Conversation
c6f8718 to
661579b
Compare
661579b to
f2afbb6
Compare
RandomShaper
left a comment
There was a problem hiding this comment.
Looks good. There's just the comment about structure to improve readability.
f2afbb6 to
a3af0c7
Compare
a3af0c7 to
c4f6fe5
Compare
|
There is also a similar situation here #64999 (comment) I suggest to review #65011 first, this pr also needs to use a similar structure. |
c4f6fe5 to
e8e727f
Compare
|
The build seems to fail. |
|
Yes, here uses the |
|
@Rindbee, you may want to rebase this PR on top of the other one this depends on so CI build passes. When the other one is merged, this one will get automatically trimmed down to the only additional commit. |
e8e727f to
f8398dd
Compare
|
I think there are fewer records about the correlation between resources between tscn. All the related (merged and not yet merged) PRs are based on a judgment: Resources with local-to-scene enabled on the same property of the same object that recorded in the main scene, is a shared copy of the source resource with local-to-scene enabled which recorded in the sub-scene. In most cases, this may be correct. But in fact, this situation cannot be ruled out: Really hope to use new resources to cover the resources on the scene root. |
|
Needs rebase. |
f8398dd to
01becb4
Compare
8e68044 to
ff6a538
Compare
|
Okay, the cases of enabling/disabling Editable Children has been completed for scene initialization and node duplication. I think it's ready to be reviewed again. |
e58ae4b to
498e3fc
Compare
|
I'll try to modify the mapping logic there later. |
498e3fc to
4b56fe2
Compare
4b56fe2 to
4f81116
Compare
4f81116 to
2737783
Compare
This is a follow-up to godotengine#65011. For scenes with **Editable Children** enabled, the main scene will record more information and resource mapping will be valid for multiple nodes.
KoBeWi
left a comment
There was a problem hiding this comment.
Gave it some testing and it seems to work correctly.
Might need core re-review after latest changes.
For resources with `resource_local_to_scene` enabled in the sub-scene, the resource is already set when the sub-scene is instantiated, so does not need to be set again. Just needs to update the property of the resource according to the value in the main scene.
| for (KeyValue<Node *, HashMap<Ref<Resource>, Ref<Resource>>> &KV : resources_local_to_scenes) { | ||
| for (KeyValue<Ref<Resource>, Ref<Resource>> &R : KV.value) { | ||
| if (R.value->is_local_to_scene()) { | ||
| R.value->setup_local_to_scene(); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
This ensures that local-to-scene resources in newly copied child scene instances are effective when Editable Children is enabled.
The cache is now only cleared only when a new copy begins. As users edit the scene, it may lead to the use of released node instances as keys.
|
Thanks! |
Fix #45350, fix #47918.
Depends on #65011.
For resources with
resource_local_to_sceneenabled in the subscene, the resource is already set when the subscene is instantiated, so does not need to be set again.