Godot: When C# script extends Resource class, the resource doesn't show up in the "Create New Resource" menu

[sudoman281]

Godot version:
3.1

OS/device including version:
Arch Linux - newest

Issue description:
When C# script extends Resource class, the resource doesn't show up in the "Create New Resource" menu

Steps to reproduce:
Create a C# script, make it extend Resource class and then try to create a new resource of that type.

[PanzerRavana]

Please add this, people looking to swith from unity will have a much easier time adapting to godot

[akien-mga]

Extending Resource doesn't automatically register it as a resource usable in the editor.

class_name can be used in GDScript to register node types, but I don't know if it works for resources. There's no equivalent for C# yet that I know of.

[CJNA]

I have tackled this issue and this problem is harder than I think. Currently, there exists circular dependency between resourcePreview and Resource class, and thus at least in editor, it is unlikely to implement a way to bypass this circular dependency and add a generator on constructor of Resource.

Unless there is other way of calling resourcePreview when extending Resource class, it is required to restructure resource class implementation and hierachy to resolve this issue.

[scott-lin]

Is there a workaround for C# defined resources in the meantime?

In other words, how do I create a resource externally from my scene and save it as my resource type? Support for loading the resource via the editor is already in place it looks like. I just don't know how to create it in the first place.

[mysticfall]

I believe you can create a generic resource within Godot then attach your C# source which extends Resouce to the created asset.

[Spartan322]

Doesn't appear assigning a C# source to the Resource actually allows it to be edited.

[Reneator]

Maybe this issue is relevant:
https://github.com/godotengine/godot-proposals/issues/18#issuecomment-561864596

With a manually compiled godot project with the pull request by willnationsdev i am currently able to work with custom-resources in gdscript, but I am thinking about switching to C# (as its a language with features i might need for my project)

He stated that he has a C# implementation of it in the works.

[willnationsdev]

I have a WIP implementation of this ready-to-go (the latest commit on this branch of my fork), but I've hit a roadblock in that the ScriptClass class attribute I've added never gets detected by the CSharpScript class. I've asked for @neikeq's help on the matter previously, but I never followed up when he didn't reply because I saw that he was busy trying to work on Android/Web exports for the 3.2 release and didn't want to bother him.

If anyone can take the work I've done in that commit and figure out how to make C# actually parse and detect the attribute, then I can continue developing it and hopefully finish it for godotengine/godot-proposals#22. I already have a separate vs-script-classes branch for VisualScript and another WIP branch to export the ScriptServer as an engine singleton so that NativeScript/PluginScript bindings can presumably access the script class data too. At that point, every language would have full access to the script class system. There is also a pull request I made for allowing script classes to be exported as Resources in the Inspector (#32018).

[vitorbalbio]

This is a huge limitation of C# and force us to change code structs to workaround it. How's the development on it issue?

[vitorbalbio]

For anyone stuck on this, one workaround is to declare the class in GDScript extending Resources and call it in C#
example:

// data.gd
extends Resource
class_name Model_test
var Speed : int = 0;
var Size : int = 0;

// UseData.cs
[Export] public List dataList; // set data in inspector

But it's not a final solution since you will need to use Object.Get() to read variables and you can't manipulate it as a C# class. So is quite important that this feature be implemented anytime soon to improve the overall support of C# in Godot.

[Calinou]

This is a huge limitation of C# and force us to change code structs to workaround it. How's the development on it issue?

There's no ETA for fixing this issue, as nobody has made a fully functional fix yet.

[vitorbalbio]

This is a huge limitation of C# and force us to change code structs to workaround it. How's the development on it issue?

There's no ETA for fixing this issue, as nobody has made a fully functional fix yet.

That's sad but thanks for reply.

[willnationsdev]

@vitorbalbio Just an FYI, I've been gradually putting together a branch on my fork to implement various parts of godotengine/godot-proposals#22 (my P22/script-classes branch). The C# part hasn't been done yet, but I've updated my ScriptServer singleton inclusion and my VisualScript script class support. Just need to take the time to get a Mono build going again and see if I can't get things working in 4.0 (I never managed to make it work in 3.2 either since the script class attribute would never get detected. But we'll see what happens).

[vitorbalbio]

@vitorbalbio Just an FYI, I've been gradually putting together a branch on my fork to implement various parts of godotengine/godot-proposals#22 (my P22/script-classes branch). The C# part hasn't been done yet, but I've updated my ScriptServer singleton inclusion and my VisualScript script class support. Just need to take the time to get a Mono build going again and see if I can't get things working in 4.0 (I never managed to make it work in 3.2 either since the script class attribute would never get detected. But we'll see what happens).

Hi willnationsdev! Thanks for your hard work, i'm a game developer working on indie studios in Brazil for about a decade (with Unity) and now we're giving a chance to Godot. Most of what we do can be done in godot (C# support is a must) but some paper cuts like this are stopping us to make a full jump on board. I will keep following Godot close and see how things evolve with time. Thank you.

[vickylance]

@vitorbalbio Just curious why just creating a generic resource and manually adding the resource script to the tres file not working for you?

[vitorbalbio]

@vitorbalbio Just curious why just creating a generic resource and manually adding the resource script to the tres file not working for you?

It kinda works and is what i'm using mostly of the time. But once your data struct is too heavy you will need tons of tres files in your project. In my case: I have files for "units" (spaceships) each unit have "skills", each skill have "pattern". For each spaceship i have something like 15 tres. My game will have something like 20 of those so hundreds of .tres files to manage while it would be just 20 files if i was using GDScript and i quite doubt that i won't need more until the end.

[willnationsdev]

@vitorbalbio You should be able to create Resource properties ON resources which you can attach scripts to. Then, when you load the resource, it also loads the other resources embedded within it.

So, e.g. you could have a SpaceshipData resource that has exported Resource properties. You create a resource in the Inspector, add the SpaceshipData script to it. Suddenly, those exported resource properties (for, e.g. skills, pattern, etc.) are displayed. Then you create new resources in each of those and drag the respective resource scripts onto each of those properties (SkillData, PatternData, etc.). The sub-inspectors for those properties now have the scripted properties displayed. Once you have everything configured, you save the resource as a single file. And now, if you do GD.Load("spaceship1.tres"), you end up with a full SpaceshipData that contains all of the embedded resources.

[vitorbalbio]

"You should be able to create Resource properties ON resources"
I can

"which you can attach scripts to. Then, when you load the resource"
I can't. This option is not exposed

"You create a resource in the Inspector"
I can

"add the SpaceshipData script to it."
I can't. This option is not exposed.

See:

data is: "[Export] public Resource data;"

I can indeed set it as a new Resource in inspector:

But after that i can't set any script or class to it:

[willnationsdev]

@vitorbalbio Oh, wat. That's weird. If you make a Resource individually in the Inspector, the script property shows up under a Reference category section. But that entire category section seems to be omitted in that dropdown. That feels like it should be considered a bug. All one would have to do is make sure that the script shows up in there and then you can assign a value there again. With that said, you CAN do it in 3.2.1 (where I tested it), but you have to, as you said, make individual resource files and then drag them over into the properties rather than being able to just inline it all in the Inspector/sub-Inspectors.

[vitorbalbio]

"If you make a Resource individually in the Inspector, the script property shows up under a Reference category section."
This is exactly how i create the data files. I add a new "Resource" in the project and set the script in inspector. But as you can see i can't do it without create a new file first. By the end i will have a lot of .tres data files.

I don't think its a bug either since you can't select the script for any "sub inspector" in godot. But it would be great if only it was exposed in inspector!

[willnationsdev]

I don't think its a bug either since you can't select the script for any "sub inspector" in godot.

Doesn't mean we shouldn't interpret this as a bug, hehe. At least, I would see it as a bug. It's silly that you can change the type of a resource at the top level, but not in a nested level.

[vitorbalbio]

I would love to see this implemented anyway ;)

[SimplyMiha]

What is the status of C# custom resources?

[Calinou]

@SimplyMiha As far as I know, nobody has started implementing this yet.

[willnationsdev]

@SimplyMiha the missing pieces are my two existing PRs that are both WIP (one for custom resources export, one for adding script class support to other languages). However, despite that, I've been having trouble even getting a functioning mono build of the master branch on Windows. Every time I build it and run, the engine closes almost immediately. Can't even test whether my class attribute is working or not.

Anyway, once we have script class support on C# classes and the ability to export custom resources in general, then we will may need an additional PR to ensure that exporting a script class named C# resource works in the C# language.

[vitorbalbio]

@SimplyMiha the missing pieces are my two existing PRs that are both WIP (one for custom resources export, one for adding script class support to other languages). However, despite that, I've been having trouble even getting a functioning mono build of the master branch on Windows. Every time I build it and run, the engine closes almost immediately. Can't even test whether my class attribute is working or not.

Anyway, once we have script class support on C# classes and the ability to export custom resources _in general_, then we will may need an additional PR to ensure that exporting a script class named C# resource works in the C# language.

This looks a lot of work. There's one contributor working exclusively in C# support right? Maybe someone can poke him to help about it.

[Neotoon]

https://github.com/godotengine/godot/issues/15210
recreated the steps they did here and was able to create a c# script that extends resource class.

P.S if this comment violates any rules please let me know and kindly remove this.

EDIT:
was able to create a custom object from a C# script that extends resource class