Make `resource_local_to_scene` behave as described in the documentation. (If I understand correctly, the following **instance** refers to **the instance of the sub-scene**.)
2e24b76535/doc/classes/Resource.xml (L70-L72)
If the resources of the sub-scene are modified in the main scene, the modified resources will be recorded in the `tscn` file of the main scene. And the root node of the sub-scene will be set twice.
1. In the main scene, when encountering a sub-scene, the sub-scene will be initialized first;
2. Then use the resources in the main scene to reset the root node of the sub-scene.
This may make `resource_local_to_scene` not work as expected. The resources cannot be shared between the sub-scene root node and other ordinary nodes in the sub-scene.
Yes, if the resources have `resource_local_to_scene` enabled, this patch treats the modified resources of the sub-scene root node as resources in the sub-scene, not in the main scene. Although the modifications are recorded in the `tscn` file of the main scene.
This PR implements:
* A new hint: PROPERTY_HINT_NODE_TYPE for variant type OBJECT, which can take specific node types as hint string.
* The editor will show it as a node path, but will set it as a pointer to a node from the current scene if you select a path.
* When scene is saved, the node path is saved, then restored as a pointer.
NOTE: This is a proof of concept and this approach will most likely not work. The reason if that, if the node referenced is deleted, then when trying to edit this the node will become invalid.
Potential workarounds: Since this uses the Variant API, it should obtain the pointer from the Variant object ID. Yet, this would either only really work in GDScript or it would need to be implemented with workarounds in every language.
Alternative ways to make this work: Nodes could export an additional property with a node path (like for which_node, it could be which_node_path).
Another alternative: Path editing could happen as a hidden metadata (ignoring the pointer).
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
Adds a new, cleaned up, HashMap implementation.
* Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing).
* Keeps elements in a double linked list for simpler, ordered, iteration.
* Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much
for performance vs keeping the key, but helps replace old code).
* Uses a more modern C++ iterator API, deprecates the old one.
* Supports custom allocator (in case there is a wish to use a paged one).
This class aims to unify all the associative template usage and replace it by this one:
* Map<> (whereas key order does not matter, which is 99% of cases)
* HashMap<>
* OrderedHashMap<>
* OAHashMap<>
Implemented by request of @neikeq to advance in the GDExtension version of Mono.
* If a Resource type is missing upon load, it will be remembered together with its data (Unless manually overriden).
* If a Node type is missing upon load, it will be also be remembered together with its data (unless deleted).
This feature makes working with GDExtension much easier, as it ensures that missing types no longer cause data loss.
Implements https://github.com/godotengine/godot-proposals/issues/4096
* Nodes can be marked unique to the scene in the editor (or via code).
* Unique nodes can be accessed via the **%** prefix at any point in the path. From that point in the path (depending on whether the scene of the path is), the unique node will be fetched.
* Implementation is very optimal, as these nodes are cached.
SConstruct change also makes it possible to outright delete the `editor`
folder in a `tools=no` build, which we use in CI to ensure no invalid
cross-dependencies are added.
When packing a scene node which is not the root, errors where caused
by internal checks in is_editable_instance method.
This check can be safely made outside instead.
At runtime, packed scenes with nodes marked as editable instance where
saved with node type tags, which prevented the scene to be then loaded
as an instance, causing duplicated nodes in the tree.
This change ensures nodes marked as editable instances and their owned
children are properly set as instances.
That doesn't make a difference in the editor, since such nodes where
already set as instances based on their instance state, but it helps
at runtime where instance states are disabled.
Co-authored-by: latorril <latorril@gmail.com>
Regression fix: update_exports is tool only and should be used only in
the editor, otherwise it can cause export variable overrides from
instances to be discarded in favor of the parent's value.
