Script.resource_name always contains blank string

[damarindra]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
a26b36b

Issue description:
Whenever you try to .get_script().resource_name, the variable only contains blank string. However resource_path always return valid path.

Steps to reproduce:

1. Attach script with this line code
   print(get_script().resource_name)
2. See on the console, doesn't print anything

[damarindra]

Run this demo, resouce_name will not print anything, but resource_path is print the right path
Demo : resource_name_blank_string.zip

[leonkrause]

Is resource name used at all internally? Otherwise the field should just be removed

[vnen]

If you look at the script on the Inspector, you'll see that the resource name is empty. Since GDScript files contain only code, not metadata, it'll never save the resource name even if you set it. This is not the same for other types of resources, so it may be useful for those.

I don't know what you are expecting to get from the resource_name property of a script.

[damarindra]

Hmmm, If I remember correctly. I want to get the resource_name of the script to know if the node is Player or Enemy. So basically I have Script character_controller, then Player and Enemy inherit from it. But I found a solution, I can set_meta() to know what is the node type exactly.

[vnen]

get_script() returns only the current script, which knows nothing about the node it's attached to (because the same script can be attached to multiple nodes).

[neikeq]

I can't check right now, but I think built-in scripts do use resource_name.

[mhilbrunner]

@vnen Should we just document this then and close this and #14774 as not a bug?

[vnen]

@mhilbrunner I'm not sure. #14774 uncomments a line that would fix this, but I'm not sure why it was commented out in the first place.

[akien-mga]

The plan for 3.2 is to outright get rid of resource_name.

[Anutrix]

So are we still getting rid of it for 3.2 or moved to 4.0?

[akien-mga]

4.0 I guess, there is little need to break compat in 3.2 for it as it's only cosmetic.

[ghost]

I would actually prefer that resource_name be kept, since it serves a purpose in the inspector for local resources:

If it's removed, these resources would instead wind up looking like this:

As you can see, it's considerably more difficult to remember which resource is which, as I'm just memorizing some index on some array (which I'm probably not going to do and instead I'll wind up opening each resource one by one to get an idea of that resource's contents.) I could just save each resource to disk to give them a name but the idea here is to not clutter the file system with these little resources (as there's going to be hundreds of them in this game, and all they really do is provide some name and description.)

I think it would be better to make it clear in resource_name's tooltip that it's meant for editor-use only, rather than removing it all together. Better yet is to re-enable resource_name's functionality so I don't have to write export var display_name := "" in all my resources, and just exempt those resources which don't store resource_name, like .gd and .cs files, perhaps with a warning or error when attempting to get it.

[DarkMessiah]

I use resource_name in my custom editor and resource_name displays in inspector, when I call inspect_object(my_resource)

[ghost]

I make use of resource_name to figure out what Material I am looking at. If you remove this I would have to parse resource_path to try and infer the material name and if no resource_path then I would need to get shader_param texture path and parse that and extract the name from there. I would actually prefer the ability to (optionally) set resource_name on any game resource.

[cgbeutler]

Looks like exporting a script with export var script2 :Script currently (3.2) results in this editor display:

As noted in the bug, setting the resource_name of the script doesn't get saved. (It may show for a bit, till you restart the editor to clear the cache.)

If I'm not mistaken, the main issue is that the actual on-disk representation of the script is not a toml file, but just the script itself. Scripts have a custom importer that just uses the script itself. If I'm right, that would mean the resource_name would need to be saved somewhere in the script itself. Using class_name as the resource_name is a fairly obvious candidate. As a side note: Changing 'resource_name' in the inspector would still be problematic, as it would be way too hard to parse/edit class_name reliably (due to comments and \, etc.) By extension, subclasses would likely get their resource_name from class x:.

TLDR; Loading class_name into resource_name seems like a decent way to go.

[cgbeutler]

As a side note, I'm surprised that the class_name is not available anywhere on the GDScript object. I would have expected it to be a field there. I imagine if it isn't added as the resource_name, we may wanna make a feature request to add it. (Not sure it could be added to Script itself, as other scripting languages may not quite fit in that way.)

[akien-mga]

The plan for 3.2 is to outright get rid of resource_name.

So it turns out I was mistaken, resource_name is used by some nodes internally, and it's also useful for some users to identify their custom resources as shown in #13358 (comment). The new tiles editor uses it for example.

It is however only needed in specific cases so it's normal that most resources don't have it filled. The documentation already makes this clear, so we can close this.

[cgbeutler]

Yeah, this sort of morphed into a proposal.
For those wanting it to be filled with the class name or filename or something, maybe open a proposal for it.