Allow to define and load script templates per project

[Xrayez]

Closes #19145 and likely closes #31037.

Summary

1. Put your script templates in res://script_templates or other place within a project.
2. Use them via script create dialog normally, potentially overriding built-in templates.

Description

Previously it was only possible to create custom script templates per editor instance which could lead to certain collisions, but now one can create such templates per project tailored for specific use cases.

The default path to search for custom script templates is defined in project settings via editor/script_templates/paths setting as res://script_templates path, but this can be overridden.

Also added template override mechanism as described in #31111 (comment), later revised in #31111 (comment).

Issues

1. GDScript parser treats templates as invalid. The project runs fine but this could lead to some confusion I believe. These templates must be ignored somehow. (can be salvaged by including .gdignore in template folder).

2. Supporting multiple folders in project resulted in Allow to define and load script templates per project #31111 (comment), so the feature was dropped.

Warning

Backup your editor settings before testing this PR!

Test project

script-templates-project.zip

[Xrayez]

GDScript parser treats templates as invalid. The project runs fine but this could lead to some confusion I believe. These templates must be ignored somehow.

Figured this can be salvaged by including .gdignore in template folder manually for now. Perhaps a template itself needs some meta signature to describe that it's actually a template.

[aaronfranke]

Helps #19145 (doesn't override templates)

For the overriding behavior, perhaps we can make it behave similarly to how Linux handles such things: Local scripts are preferred and hide global ones if the names are the same, and you can disable a global script locally by creating a symlink to /dev/null.

[Xrayez]

Yeah currently it makes little distinction between the origin of those templates. Once solved, overriding could me made possible.

So from local to global, script paths could have this priority:

1. Project specific:
   • res://script_templates/, ...
2. Project editor settings at local path:
   • %APPDATA%/Godot/projects/my_project-%md5%/script_templates/
3. Editor script templates:
   • %APPDATA%/Godot/script_templates/

[Xrayez]

Managed to override templates with the same name to prefer project templates over editor ones (also grouped them):

It makes sense to me to have project-specific templates to be at top, don't you think? The default one is always at the top.

See how Empty template is overridden by project template, so the editor template is skipped. Not sure if this would be intended behavior, could be turned off by removing just one line of code.

Honestly there should be some kind of script template manager but I'm not willing to make one until it proves to be useful. 🙂

[Xrayez]

Fixed override stuff with updated architecture.

Perhaps just disabling overridden templates would be enough, provided that extended template can visually tell that those are in fact overridden. That signifies that those template are still there but inaccessible due to extended template used:

So I feel like the ground work is done. Again, a lot of this code could be moved to a dedicated (yet non-existing) ScriptTemplateManager at some point, I made it work to remain override info, could be useful.

Namely, ScriptTemplateInfo structure holds quite a bunch of template info which could be listed in manager (directory, origin, name, overrides, extension per language etc).

[Xrayez]

Noticed that one could have duplicate project-specific script templates across different folders, so those don't show up in template popup, which can and will lead to confusion.

So what could be done instead is to have only one project-specific folder for custom script templates, this also allows to define PROPERTY_HINT_DIR so you could select a folder much easily that way:

This would also promote consistency as editor templates cannot have more than one folder, too, and makes the code a bit less complex.

@groud would agree we'd rather avoid over-customization. 🙂

Also feel free to suggest a better project setting category/name for this.

[akien-mga]

Seems good overall, but I wonder if it's worth supporting both user-specific project templates and res:// project local templates. I think only the latter might be sufficient, I can't really see a use case for having both editor-wide templates, user-specific project templates and project-wide shared templates.

If someone really wants user-specific project templates, they can add a symlink in their res://script_templates and gitignore it.

[Xrayez]

This could possibly allow users to override script templates imposed by a project, possible use cases:

1. Overriding author name in license text
   • this should be part of template logic though which is currently missing (and other placeholders).
2. Experimental/productivity templates used by individuals working on the same project which are not yet part of the project but are likely to be versioned later. This also could be handled by the project by incorporating gitignore templates naming conventions perhaps.

But yeah I'd leave res://script_templates alone then, this would simplify implementation quite a bunch. It's just those user-specific project templates (Project Local) was the first thing I managed to get to work.

[Xrayez]

Removed user-specific project templates (Project Local), so at most two origins now:

I haven't really stripped much, let the backend be extensive imo, besides it's been tested in my project.

There's another side effect I've noticed, namely if you don't have project templates, you'll have this:

Which is fine imo, this should signify that there could be possibly project templates as well. And the Default "template" is not actually present in the filesystem, but always generated by the ScriptServer dynamically.

[akien-mga]

Thanks!