Metadata on resources that are saved as non-Godot resource files (such as GDScript or text-based shaders) aren't saved

[donn-xx]

Godot version

v4.2.beta4.official [93cdacb]

System information

Godot v4.2.beta4 - Ubuntu 22.04.3 LTS 22.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (nvidia; 535.129.03) - Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz (6 Threads)

Issue description

I want to put Metadata on a gd script. The Editor lets me do this:

Saving the project, closing and re-loading it results in this:

Steps to reproduce

Create a gd script. Double-click it. Go into the Inspector and add metadata. Save project. Close. Open the project and go back to that script in the inspector.

Minimal reproduction project

None required.

[YuriSizov]

This is expected. GDScript is saved as a plain script file, it doesn't have a place to store metadata. Unlike resources saved as RES/TRES, which can save arbitrary data with them.

We should probably disable the section on the inspector for scripts, and document this somewhere.

[donn-xx]

Why not invent an @metadata command that can hold that data?

It's quite handy for plugins and in-editor things. Vars and exports are fine, but they behave in certain ways. To have data that applies to a script as a whole, despite its inheritance etc. is useful. The metadata becomes like vars for that specific class and not for anything that extends it. And you don't need to new() it only load() it (as a resource).

But, yeah, to keep complexity down, the button to add Metadata should not be there for a script.

[YuriSizov]

Why not invent an @metadata command that can hold that data?

That implies modifying scripts from under your feet. This may not be desirable.

[donn-xx]

Well, it would be you, the dev, making the metadata, so not that surprising. However, I bow to your experience.

[dalexeev]

• See also ResourceName not saved #82333 and Document that resource_name is not always supported #82406.

[Johnrobmiller]

This is expected. GDScript is saved as a plain script file, it doesn't have a place to store metadata. Unlike resources saved as RES/TRES, which can save arbitrary data with them.

We should probably disable the section on the inspector for scripts, and document this somewhere.

Be careful when saying things like "This is expected". For whom is it expected for? Is it expected for the developer, who implemented the solution and has the correct mental model of the system's behavior? Or, it is expected for the user, who was never provided with an interface with good enough usability for them to learn the correct mental model?

It is expected for the former, but not the latter. Therefore, it is not really correct to say things like "This is expected".

There are a huge number of things in Godot that ought to be redesigned (by real UX designers, not programmers) such that the behavior of the system is "expected" from both perspectives, both the engineer who made it and the user who uses it.

Apologies for putting you on the spot, I know it's common to say "This is expected" so it's not fair to pick you out like that.

[YuriSizov]

It is the expected behavior of the system given the limitations and considerations that is contains. Whether it is intuitive or not, whether it is convenient or not, whether it is communicated well or not are all different questions. When we say "This is expected" we are teaching the user that this is what they should expect to happen in this case. As learning the system is a part of building that mental model that you are speaking of.

In any case, I don't think sophism is helpful here. Let's stick to the technical argument.

[Calinou]

Note that this limitation applies to any resource type that is saved as a file type that isn't derived from .res or .tres.

This means that text-based .gdshader can't contain persistent metadata, but VisualShader can as it uses the .tres format. Built-in GDScripts can also contain persistent metadata for the same reason.

An easy way to implement this in the inspector is to hide the Add Metadata button if the resource path doesn't end with .tres, .res or one of the many custom file extensions used by binary resources (i.e. not standard file formats like PNG). This may not be ideal for extensibility though.

[Zireael07]

1. It's worth changing the issue title so that people know it's not limited to gdscript
2. It's worth documenting unless you act fast and hide act metadata button before next release

[Johnrobmiller]

It is the expected behavior of the system given the limitations and considerations that is contains. Whether it is intuitive or not, whether it is convenient or not, whether it is communicated well or not are all different questions. When we say "This is expected" we are teaching the user that this is what they should expect to happen in this case. As learning the system is a part of building that mental model that you are speaking of.

In any case, I don't think sophism is helpful here. Let's stick to the technical argument.

Fair enough. It may be pedantic, but I still make the point because engineers have a tendency to view things from the perspective of an engineer (as they should), but problems arise when they fail to view things from the perspective of a user, which is required to engineer the usability of a product.

Terms such as "expected behavior" only reinforce these bad habits, and so it's a pet peeve of mine when they are used.

If it's a big company and there are dedicated designers and dedicated engineers, then engineers don't need to think about usability. However, when the engineers are also the designers, they need to spent significantly more effort trying to forget about their engineering knowledge and view things purely from the users perspective so that they can design.

After all, who is the behavior expected for? The engineer or the user? If the engineer is also the designer, then it ought to be for the user.

You're right that I derailed, but I couldn't resist saying these things. I'll be quiet from hence forth.