* Explain where it should be used, with examples.
* Clarify that it should _not_ be used everywhere, only where needed.
* Supersedes #57720
This PR is the result of the discussion that happened in a contractor meeting, and it attempts to clarify the intended use for this macro for other contributors.
As a personal note, It is my view that other approaches to using SNAME (like having a global or per class table of string names) are mere overengineering without any real benefit (performance remains the same, and usage of stringnames becomes more cumbersome. Additionally, there was not any significant amount of errors in name mismatching as a result of using strings since Godot was open sourced).
This was changed in #56943 to allow adding new importers from plugins that
take precedence over built-in ones, but this should be opt-in, not the default
behavior.
Fixes#57730.
* Vector2i and Vector3i mul/div by a float results in Vector2 and Vector3 respectively.
* Create specializations to allow proper bindings.
This fixes#44408 and supersedes #44441 and keeps the same rule of int <op> float returnig float, like with scalars.
Now correctly erases old instances.
The code will likely need overhaul anyway to be usable.
It doesn't apply to editor runs, there's a bunch of inconsistencies on
how to clients are handled, and I don't really understand why multiple
instances are created for a single client/server.
Now uses two interfaces so it can be overridden in the future, and
core no longer depends on Node.
The interfaces are implements in scene/multiplayer.
Replaces root_node with root_path.
Remove all Node references from MultiplayerAPI.
Some were declared as structs (public by default) and others as classes
(private by default) but in practice all these math types exposed as
Variants are all 100% public.
Initial implementation of the MultiplayerReplicationInterface and its
default implementation (SceneReplicationInterface).
New MultiplayerSpawner node helps dealing with instantiation of scenes
on remote peers (e.g. clients).
It supports both custom spawns via a `_spawn_custom` virtual function,
and optional auto-spawn of known scenes via a TypedArray<PackedScenes>
property.
New MultiplayerSynchornizer helps synchronizing states between the local
and remote peers, supports both sync and spawn properties and is
configured via a `SceneReplicationConfig` resource.
It can also sync via path (i.e. without being spawned by a
MultiplayerSpawner if both peers has it in tree, but will not send the
spawn state in that case, only the sync one.
First, we should not insert into cache if the hostname resolution has
failed (as it might be a temporary internet issue), second, the async
resolver should also properly insert into cache.
Took the chance to remove some duplicate code with critical section in
it at the cost of little performance when calling the blocking
resolve_hostname function.
