Expose ScriptServer & add all script class support.

[willnationsdev]

This is is 3.2 port of #40147 since there are presumably going to be core changes that make these features inapplicable to 4.0.

I've created a demo of it:

Demo_GP22_3_2.zip

Relevant code samples:

# main.tscn
- Node (main.gd)
    - Node "MyGDClass" (MyGDClass.gd)
    - Node "MyVSClass" (MyVSClass.vs)
    - Node "MyCSClass" (MyCSClass.cs)

# MyGDClass.gd
extends Node
class_name MyGDClass, "res://skill.png"
func _ready():
    print("MyGDClass")

// MyCSClass.cs
using System;
using Godot;

[Global("MyCSClass", "res://skill.png")]
public class MyCSClass : Node
{
    public override void _Ready()
    {
        GD.Print("MyCSClass");
    }
}

VisualScript sample:

# main.gd
extends Node

onready var gd = $MyGDClass
onready var vs = $MyVSClass
onready var cs = $MyCSClass

func _ready():
	if gd is ScriptServer.MyGDClass:
		print("gd is MyGDClass")
	if vs.get_script() == ScriptServer.MyVSClass:
		print("vs is MyVSClass")
	if cs.get_script() == ScriptServer.MyCSClass:
		print("cs is MyCSClass")

Output:

MyGDClass
MyCSClass
MyVSClass
gd is MyGDClass
vs is MyVSClass
cs is MyCSClass

It seems as though the is keyword doesn't like to cooperate with non-GDScript script types on the right-hand side. Should I try to incorporate that into the feature? Iirc, it worked fine in my 4.0 demo project.

Edit: Also, it looks like the C# glue generation code doesn't implement the Get() method for ScriptServer, so you have to use ScriptServer.GetGlobalClassScript("MyGDClass"), etc. instead.

[DarkMessiah]

Hi! It looks like something very useful, but I don't fully understand why :D Now all scripts with class_name register in ScriptServer and it will no longer be possible to write gd is MyGDClass or var gd = MyGDClass.new()?

[willnationsdev]

@DarkMessiah No, GDScript still has its global variables, but now there's an official Engine Singleton that makes these scripts available throughout the engine. So C#, NativeScript, and VisualScript can get a reference to the ScriptServer and do, e.g. in C#, var gdClass = ScriptServer.Get("MyGDClass") as GDScript;. Furthermore, every language now has the ability to define a language and icon for its classes.

[vitorbalbio]

That makes us close of proper Custom Resources in Editor using C# now that there's a reference for the C# Class names?

since there are presumably going to be core changes that make these features inapplicable to 4.0.

It's a temporary problem or it will never be done for 4.0 ?

[willnationsdev]

@vitorbalbio It means that, for this PR, it will never be done for 4.0. The feature itself, "being able to give names to classes and export custom resources" is something that may still happen for 4.0 or 4.1, but the way it will work will be different than how I'm doing it here because the manner in which this information will be gathered/tracked/updated/used by the engine will fundamentally change (but I don't know yet in what way).

[willnationsdev]

Also, maybe @Calinou you know(?), all of the failed builds complain about methods in the GDCLASS macro trying to override nonexistent base members, but idk what to do about that since I haven't touched any of that code. Is it just something that will resolve itself later?

[Calinou]

Also, maybe @Calinou you know(?), all of the failed builds complain about methods in the GDCLASS macro trying to override nonexistent base members, but idk what to do about that since I haven't touched any of that code. Is it just something that will resolve itself later?

I don't know why that's happening, sorry.

[willnationsdev]

This should be all ready for review now, afaik. I've worked out a lot of the kinks while developing and debugging custom resource support for all languages.

[willnationsdev]

Closing since this is now just included in its sequel PR #44879.