Objects instanced in c++ can't be bound to typed gdscript variables

[norton-corbett]

GDNative:

class MyCustomType : public godot::Node
{
    GODOT_CLASS(MyCustomType, godot::Node);
public:
    void calling();
    void functions();
    void works();
    void fine();
};

// ...

class Manager: public godot::Node
{
    GODOT_CLASS(Manager, godot::Node);
public:
    MyCustomType* make_custom_object()
    {
        auto object = MyCustomType::_new();
        add_child(object);
        return object;
    }
};

The .gdns file:

[gd_resource type="NativeScript" load_steps=2 format=2]

[ext_resource path="res://bin/test.gdnlib" type="GDNativeLibrary" id=1]

[resource]
class_name = "MyCustomType"
library = ExtResource( 1 )
script_class_name = "MyCustomType"

GDScript:

var o = Manager.make_custom_object()

o.calling()
o.functions()
o.works()
o.fine()

var test:MyCustomType = o #error

Also, if the variable is a function parameter, e.g.:

func broken(param:MyCustomType):
    pass

# ...

var o = Manager.make_custom_object()

broken(o)

...then no runtime error is produced, but param will be null

[Zylann]

I'm not sure if that's a problem with C++ bindings. You gave the global class name through the .gdns, I assume it doesn't actually matter if it's implemented with C++ bindings, C API or even Rust. Could be a Godot bug.

[norton-corbett]

Good point. I understand GDScript is being re-implemented currently so maybe I'll wait before reporting it.

[alessandrofama]

A workaround that works for me is to wrap Manager.make_custom_object() (for example) in an autoload script that returns your typed variable:

# Test.gd, name "Test" in Autoload

extends Node

func make_custom_object() -> MyCustomType:
	return Manager.make_custom_object()

Then it should work I think:

var o:MyCustomType

func _ready():
	o = Test.make_custom_object()

At least it does for me, but I also have a .gdns for each class, don't know if it makes a difference.

[Zylann]

I don't understand how an autoload solves this tbh.
At some point, you are assigning a value to var test: MyCustomType, which can fail if the cast is invalid, and that will happen with or without an autoload. Unless I misunderstood some strange detail?
The cast is also supposed to occur if you return an untyped value from a function with -> MyCustomType, so if that works then that's another problem lol

[norton-corbett]

Yeah this autoload workaround doesn't make any difference for me. Are you also using Godot 3.2 stable?

[alessandrofama]

Yeah, 3.2.2. after testing it again it seems that it only works for me if the variable is not directly assigned when declared. Sorry, I'm missing some technical knowledge about why it would work or not, still relatively new to GDNative and trying out stuff :)
In my case I have a GDNative class named EventInstance, I create an instance here :

godot::EventInstance* Fmod::create_instance(const String path)
{
// stuff 
	godot::EventInstance* eventInstance = godot::EventInstance::_new();
	return eventInstance;
}

In GDScript:

# Wrapper.gd
extends Node

func create_instance(event_path) -> EventInstance:
	return Fmod.create_instance(event_path)

# Test.gd 
extends Node 
var instance:EventInstance

func _ready():
	instance = Wrapper.create_instance("event:/Music")

	var newInstance:EventInstance
	newInstance = Wrapper.create_instance("event:/Music")
        newInstance.start()
	

This works and I can call the methods registered in the EventInstance class (they also show up in auto complete).

This doesn't work, giving the error Trying to assing value of type " to a variable of type [...]:

# Test.gd
func _ready():
	var instance:EventInstance = Wrapper.create_instance("event:/Music")

Both Fmod.gdns and Wrapper.gd are in AutoLoad and created an additional gdns for the EventInstance class (Class Name & Script Class Name are the same). In any case not a solution or viable workaround, would be very cool if it could work btw.

[norton-corbett]

For me the error still occurs regardless of whether or not the assignment is separated from the declaration. I guess it's a bug either way. Since I opened this issue the new GDScript has been released on the master branch but I haven't tested to see if this is still an issue.

[Zylann]

It would seem that the problem comes down to the fact the NativeScript API in Godot doesn't allow us to provide the names and types appearing in function signatures, which includes return types. That means Godot always sees return values of NativeScript functions as Variant, and as such cannot be typed properly in GDScript.

This is something I wanted for a long time in Godot because using NativeScript in GDScript is very error prone, coders are basically in the dark as no static checks can ever run.

[LennyPhoenix]

I think the issue comes from how the custom objects are instantiated.
The object's parent type is first instantiated (built-in types do not have this problem), then a new NativeScript object is created, set to the correct values and assigned to the object, essentially creating an instance of the custom object.
The problem arises as this NativeScript is actually different to the user-created one, meaning they are technically different "types" to GDScript.
The error gives the variable a blank type name, because the type name would be derived from the NativeScript's file name, but because the created NativeScript object is not saved, it has no file name and the typename is just left blank.
As for how this can be resolved, it would probably need a better solution to instantiate custom classes from the GDNative API,

[Zylann]

Ah true, we had to do this because there is no way the C++ bindings could guess where the gdns files are.
To resolve this, the whole GDNative system needs to be rethought to not need those gdns files in the first place IMO. Which I think is going to happen in Godot 4.

[LennyPhoenix]

As a temporary workaround (for the workaround), we could add a static property GODOT_CLASS macro which can optionally contain a path to a .gdns file. In create_custom_class_instance, we could check if the class has a script_path set, and if so we can load that script instead of creating a new one.

[Zylann]

@LennyPhoenix There are two problems with this:

• It has to be thread-safe. If you do a just-in-time initialization, it has to be guarded by a mutex somehow, and I'm not sure we can store that in a header without requiring an implementation part in the cpp file
• We still need a path to a valid .gdns file in case non-binding sources load that resource (otherwise it will mismatch the one we would instantiate), and the bindings cannot know where you put them. Either you have to hardcode a path, or ask Godot where it is somehow (again without breaking thread safety)

I think that reliance on .gdns file should just go away in Godot 4, it's quite troublesome. Class definition must be fully settled by the time register_class is called.