classes/class_nodepath

[giscus[bot]]

classes/class_nodepath

A pre-parsed scene tree path. Description: The NodePath built-in Variant type represents a path to a node or property in a hierarchy of nodes. It is designed to be efficiently passed into many buil...

https://docs.godotengine.org/en/stable/classes/class_nodepath.html

[DevBorisElkin]

Please explain why node path to the property is
.:PropertyName
instead of
..:PropertyName

in the scenario where I reference path to the property for MultiplayerSynhronizer

-> MyNodeThatHasPropertyAndExecutesCode
-> -> MultiplayerSynchronizer

[Export] public string ActiveWeapon = "GravityGun";
    
private MultiplayerSynchronizer ActiveWeaponSynchronizer;

public void Initialize() {
    ActiveWeaponSynchronizer = this.InstantiateAndAddAsChild<MultiplayerSynchronizer>("ActiveWeaponSynchronizer");
        
    var config = new SceneReplicationConfig();
    config.AddProperty(".:ActiveWeapon");
    config.PropertySetReplicationMode(".:ActiveWeapon", SceneReplicationConfig.ReplicationMode.OnChange);
    ActiveWeaponSynchronizer.ReplicationConfig = config;
    // ...

https://forum.godotengine.org/t/godot-4-2-add-a-property-on-multiplayersyncho/38949/7?u=boriselkin

[GeminiSquishGames]

I'm not certain in C#, but "." is probably like the keyword this in C# or keyword self in GDScript.

".." is the parent node of the node the script is attached too. "..:property_name" is pointing to a property on the parent of the node that the script is attached to. similar if I want to change a directory in many disk operating system prompts, it's usually cd ../ to go to the parent directory, and ./ is usually the current directory, or .\ in windows.

Further, MyNodeThatHasPropertyAndExecutesCode has this script and ../MyNodeThatHasPropertyAndExecutesCode is the parent of MyNodeThatHasPropertyAndExecutesCode. So if you add property using "..:property_name" you are adding that property to MyNodeThatHasPropertyAndExecutesCode's parent, not ActiveWeaponSynchronizer you are trying to instantiate. We use the hierarchy of Godot Editor in this case. You may be trying to use C# as you would in a .NET project or Unity, and not Godot which is a deal different given the editor's Nodes being slightly separated from C# classes in scripts compared to the native GDScript implementations. It's not 1:1 and causes me confusion, I can say that much.

The way it is written, it looks like you are trying to make MyNodeThatHasPropertyAndExecutesCode a class of private MultiplayerSynchronizer ActiveWeaponSynchronizer. That class should be on a script attached to the MultiplayerSynchronizer you are trying to make a new class of, or at least define private MultiplayerSynchronizer ActiveWeaponSynchronizer; in another script so that it should show up as a Node in the Editor's Add Node Dialogue. the private MultiplayerSynchronizer ActiveWeaponSynchronizer doesn't make sense to me, though, and I don't see using Godot or class ClassName { class properties and methods } so I'm not certain about what you are doing.

The structure of your code should follow the manual example:

using Godot;

public partial class YourCustomClass : Node
{
    // Member variables here, example:
    private int _a = 2;
    private string _b = "textvar";

    public override void _Ready()
    {
        // Called every time the node is added to the scene.
        // Initialization here.
        GD.Print("Hello from C# to Godot :)");
    }

    public override void _Process(double delta)
    {
        // Called every frame. Delta is time since the last frame.
        // Update game logic here.
    }
}

[jamonholmgren]

@DevBorisElkin The reason is because the MultiplayerSynchronizer class automatically sets its root_path to ..; thus, the relative paths are not relative to the synchronizer itself, but rather its parent.

https://docs.godotengine.org/en/stable/classes/class_multiplayersynchronizer.html#class-multiplayersynchronizer-property-root-path

If you set the root_path to . instead of .., you'd have the behavior you expected and could do ..:PropertyName, although I don't know why you'd want to do that. Typically, it works best to think of the paths as relative to the node you're mounting the synchronizer onto.