Remove support for built-in scripts in the editor

[Calinou]

Built-in scripts have many limitations that users tend to discover late in their project. This causes a lot of pain as scripts must be replaced by their non-built-in variants one by one.

Note that this only unexposes the ability to create and edit built-in scripts from the editor. It's still possible to save a scene that contains executable built-in scripts using PackedScene or external tools. (Removing support for built-in script resources is likely more involved, but it would be useful to make sending PackedScenes over the network more secure.)

This is a compatibility-breaking change, as built-in scripts need to be turned into non-built-in-scripts before upgrading a project to Godot 4.0.

This closes #31758, closes #5535, closes #29863, and closes #31364.

[KoBeWi]

I am entirely against this PR. It doesn't solve any real issue, it just removes an extremely useful feature, only because it has a few minor shortcomings.

90% of the scripts in my project are built-in. Each of them is tightly related to their scene and useless outside of it. Many are less than 10 lines long. Saving them to files means I will suddenly have hundreds of useless new files that I'd need to store somewhere. Built-in scripts (and actually any resource) lets you to avoid that bloat and are one of the best things about Godot.

Removing built-in scripts might fix some issues, at the cost of introducing severe usability problems. You suddenly can't just duplicate your scene and edit the new one, you have to make sure that your script is unique otherwise you can break your original scene. You can't just have small behavior scripts in your levels, now each of these scripts needs to be separate file and suddenly your level files are mixed with scripts, resulting in complete mess; well, unless you keep each level in a separate directory and are fine with having 100 directories, which are hell to navigate. You also can't just copy a scene to another folder/project, you need to remember about the script or everything breaks. I'm pretty sure lots of users use the built-in scripts and removing them would result in an outrage.

Built-in scripts have many limitations that users tend to discover late in their project.

You mean these?

Which are visible every time you create a built-in script? We could extend this to list everything (maybe as a tooltip or URL idk).

This causes a lot of pain as scripts must be replaced by their non-built-in variants one by one.

This doesn't make any sense. Which exactly limitation is discovered "late in the project" and forces you to replace the scripts? Like, there is zero reason to replace the built-in scripts. If you used them, they are already there and work perfectly fine. The only thing that comes to mind is encryption, but 1) this is not something that can't be fixed 2) we could just mention it in the tooltip 3) it's useless anyways.

So again, instead of completely destroying Godot's usability for many people, I'd rather focus on minimizing and better documenting the limitations of the built-in scripts. There aren't many of them and they aren't a very big deal (like, you didn't even link anything meaningful). Having built-in scripts outweights not having them by a lot.

[akien-mga]

I don't think the feature should be removed as many users find it useful (as exemplified by @KoBeWi's extensive use case), and the issues it has are fairly benign.

Several of those could likely be fixed easily, e.g. #29863 should be simple - if it's a builtin script, ignore the external editor setting. What built-in scripts need is maybe a maintainer that cares about this (wink wink KoBeWi).

[YuriSizov]

Built-in scripts do still have inherent limitations due to not being files in the file system. They do not work with external tools in any way, shape or form. They only support GDScript. They cannot be globally registered with class_name. And so on and so forth. Now, maybe powerusers like KoBeWi understand why those limitations are there and are not hindered by them. But a ton of users are confused by it. They don't understand what a built-in script is, how it's different from a normal script, and why some features of the engine don't work properly.

So even though they may help with some project organization, their usability is very low. If we are to keep them, they need to be improved significantly in a way that guides inexperienced users instead of leaving them confused like it is now.

[KoBeWi]

They do not work with external tools in any way, shape or form.

This is fine. If you use external tools, you just can't use built-in scripts, you need to use built-in script editor for that (I mean, this even makes sense if you look at it this way xd).
Also this applies to all resources, especially shaders. You can edit .tres files externally, unless they are built-in (which just makes it more difficult).

They only support GDScript.

We should also have an error message about that in script create dialog, if there isn't one already. btw VisualScripts also can be built-in, and it's the only way to have them saved as text.

They cannot be globally registered with class_name.

You are given an explicit error if you try to use class_name in a built-in script. I don't know how it could be any less confusing (assuming you do read the errors, which most people don't do from my observations; I wouldn't care about them though).

I'd actually like to see a list of features not supported by built-in scripts, to see what is fixable and what needs to be better documented.

[CsloudX]

I use GDScript all the time, and I always like use built-in script, for example:

I want make a ui diaplay much of info, like FPS, mem use etc.

If use built-in, I only 1 file info.tscn and I write code in each Label's built-in,
Now if I want remove the FPS, I only need delete the FPS label, It prefect!!!

If no built-in, I have 2 choose:

1. Create a info.gd for the root node, in this case, if I want remove the FPS, I need remove FPS Label and change info.gd, SO ugly.
2. Create each nodes .gd file, It make my file grow so fast. And if I want remove the FPS, I also need remove FPS Label node and FPS.gd, maybe I delete another .gd, so sad, Other, I need care each .gd files when I want move some scene to another project, Built-in not have care about this.

IMO, I accept built-in miss some feature, like no class name, I use built-in in a lots of case, It is a good feature!!!
Please don't remove support.

[gomaproi]

Something that I like about Gamemaker is the "Creation Code" script that you can attach to any object without creating any additional file, sometimes it's faster/less messy to set up variables or execute a function at the start of the game by code rather than exporting variables.

[YuriSizov]

@KoBeWi I’m not arguing if the limitations are fine or not right now, so there is no reason to dispute them. They are there and they trip people. We get user support requests from people using built-in scripts without realizing it all the time. I believe that you find them useful and are satisfied with them, but we do have a lot of users who get into problems from using them, often using them accidentally. In other words, we make it too easy to use them without realizing what that implies. This is what I’d like to see addressed instead of providing a rationale why no support for external tools is actually OK.

PS. Didn’t actually know it was possible to store VS in a text form. Still, we had a person ask for built-in C# the other day 👀

[KoBeWi]

often using them accidentally

Does it still happen after we added the warning label? I'm thinking, maybe we could hide the option to create built-in scripts behind an editor setting, if it's really that advanced feature?

[YuriSizov]

Yes, there are definitely people running into that after 3.2.2 🙃

I was thinking maybe we could add an icon or a badge to the script editor that would appear for built-in scripts and when clicked open a short explanation to the nature of the beast? Tool scripts could also use such a badge.

The idea is that when people work on a script, they may pay more attention than when they create it. Plus it can fit more details there about present problems.

[Calinou]

Closing due to lack of support.

[akien-mga]

I would suggest making a tracker for actual issues with built-in scripts, so that we can see how to solve or document them all. To be honest usability has improved a lot already and I haven't seen many user reports that would point otherwise in the past year or two (at least on GitHub, there might be more confused users on Discord/Reddit/Q&A).

[h0lley]

commonly, a snippet of game logic exclusively pertains to one specific node of one specific scene.
in such a scenario, having to add a separate file for each piece of code doesn't do anything but to introduce bloat.
this is where built-in scripts shine.

personally, if it weren't for the various bugs/limitations, then I'd likely default to built-in scripts for every script that isn't registered (contains class_name keyword). at least I wouldn't see any reason not to.

@KoBeWi

I'd actually like to see a list of features not supported by built-in scripts, to see what is fixable and what needs to be better documented.

• ok so first of all the class_name thing, but I think that's kind of a non-issue since the use-case for built-in scripts is not one where it makes a lot of sense to register it as class. the only thing I can think of is that maybe it would be cool to be able to register scenes that one uses as templates (instancing a scene as root node of another) as a Node class. that would enable you to have scenes appear in the "create new node" window and even have a little custom icon for them.

• next up is that changes in built-in scripts are not picked up and automatically reloaded during test play. "Persistent live editing" is one of the major selling points advertised on godotengine.org, so I think many new users are looking forward to using it and are then disappointed that it doesn't work in this case.

• built-in scripts cannot be properly searched. while they can be searched if you tick tscn in the ctrl+shift+f dialogue (which may be counter-intuitive to new users), after clicking on a line in the search result panel, the raw tscn file opens in the code editor instead of just the script resource.

• there is some jankyness with built-in scripts as tool scripts that I cannot properly define right now. It kind of works, but I remember having to reopen the script or even restart the editor every time after having made changes, or otherwise I got spammed with error messages. haven't tried it in a while though.

• then using them in external editors and version control friendliness, but that can be understood as limitation rather than as bug. I'm not sure what currently happens if one tries to edit a built-in script with an external editor. if it opens the scene file raw in the external editor, then that's just confusing and a bad experience. instead, it should always use the built-in code editor.

there may be more that doesn't come to mind right now but I think that summarizes it quite nicely.

[radlotus]

you can extend a built-in script if you set its resource_path property to something not occupied, like res://21739871 or res://built_in_script_base_enemy then you can extend from the script with extends "res://built_in_script_base_enemy", though, you have to clear the resource_path of the built-in script before saving the scene with the script otherwise you wouldn't be able to load the scene later because the resource_path points to no script file when the scene is loaded, and resource_path for scripts should only point to existing script files.