Add and suggest script templates based on the node/object type

[fabriceci]

Describe the project you are working on

Physic improvement.

Describe the problem or limitation you are having in your project

I wondering how to avoid common mistakes I often see in issues, plus, as move_and_slide has changed a lot in 4.0, limit the transition frustration.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Currently the template (which should perhaps be simplified) is always the same:

I think it will be great to add template according to the node.

For example, with the CharacterBody, we can add the minimal code to move a body:

• get the direction
• apply gravity
• apply speed/acceleration
• call move_and_slide

This is the most common code with this type of node.

Benefits:

• This will avoid common mistakes (like forgetting to store the result of move and slide) (and so issues)
• This will act as a mini tutorial for beginners
• This will save time for quick prototyping
• This will make the transition easier for 4.0

I thought about CharacterBody but this can be used for other nodes as well.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I'm not familiar with the editor code, but we can store the template code in a folder (/editor/template/xxx.gd), and simply read the template according to the classe.

Each department could add his own node template if needed.

If this enhancement will not be used often, can it be worked around with a few lines of script?

no.

Is there a reason why this should be core and not an add-on in the asset library?

it's core.

[YuriSizov]

We actually have 2 more default templates. We can probably add a couple more options there, if you think it's going to help, see

https://github.com/godotengine/godot/blob/475facb517d3cbe600ca5d62a51e58c47d870497/editor/editor_settings.cpp#L763-L798

[jmb462]

Would it be possible to allow user to customize the templates ?

[YuriSizov]

It is already possible. You can follow into your editor settings directory and edit those templates, add new ones in the script_templates folder. And you can add script_templates folder to your project's root to define, in a similar manner, custom templates for that specific project.

[fabriceci]

The idea was to change the default one according to the type of node (not to add a new one) as most users will use the default one. However, if you have a new idea, we can complete the proposal.

Have you suggestions on the best way to do this?

[YuriSizov]

as most users will use the default one

I don't think this justifies some automagical transformations, as they are not expected or controlled from the UX perspective. Maybe we should consider the discoverability of the script templates instead, as that would be the proper way for users to make per node/per need adjustments. And so I would create additional default templates to be shipped with the editor. They should probably be extracted from the linked file though, as inlining a bunch of templates is going to be messy.

As far as automation goes we could, however, make changes to the attach script dialog. Maybe we can add a meta file to the script_templates folder that would make association between template files and object types they are best suited for, and based on that we can change the default value of the suggested template.

But ultimately, I'd just leave it to the user to pick the template. I enjoy that the dialog remembers my last choice, and I appreciate that the resulting file is going to be exactly as I expect it to be.

[fabriceci]

I don't think this justifies some automagical transformations, as they are not expected or controlled from the UX perspective....

Thanks for your input.

I don't think that having a default template that matches the type of node you are creating is going to cause confusion (often what is blamed on magical things), it's rather the opposite I think.

However, your idea has the advantage of allowing several templates per node (and also make the template button option more useful). You can even filter the templates displayed by nodes to make things simpler.

We were thinking of adding advanced template in form of addons later (which can be a node with children nodes & scripts), so in this case, I thought about a basic thing.

Do you have a use case in mind where it would be interesting to have several templates for a node and/or one where a template could be used on several nodes?

And so I would create additional default templates to be shipped with the editor.

Can you explain a bit how this can be done?

[YuriSizov]

Can you explain a bit how this can be done?

See the linked code snippet, it's pretty straightforward. When editor settings are created, _create_script_templates is called and uses the inlined code of the templates to create files in the file system. The "Attach Script" dialog in turn works off of those files (and that's how users can create their own templates easily).

Though, as I've stated above, you would probably want to move the inlined text of the templates somewhere else, maybe just a separate file with template definitions. Maybe a part of the gdscript module even.

Do you have a use case in mind where it would be interesting to have several templates for a node and/or one where a template could be used on several nodes?

I mean, your proposal is the example of both. There are several types of physical bodies that can share templates, yet each type can have a unique template. Same can be said about other generic nodes, e.g. Controls. Are you not satisfied with your own examples?

I don't think that having a default template that matches the type of node you are creating is going to cause confusion (often what is blamed on magical things), it's rather the opposite I think.

I also don't think that having a default template that matches the type is confusing. I do think, however, that it is confusing if the template picked from a list of templates automatically changes based on the base node type. That breaks anticipation from the "Attach Script" dialog, even if at a surface level it seems to help some inexperienced users.

Inexperienced users can learn. Experienced users have to live with the automatic adjustments their entire timespan using the engine. Which is my main argument against doing hidden things and in favor of leaving it to the user. (But providing users with more suitable options out of the box costs us very little and is a good idea).

[fabriceci]

See the linked code snippet, it's pretty straightforward. When editor settings are created, _create_script_templates is called and uses the inlined code of the templates to create files in the file system. The "Attach Script" dialog in turn works off of those files (and that's how users can create their own templates easily).

It's indeed straightforward in the inline way but I was talking about the way to put the templates into separate files, that's the things I'm not sure how I should do it.

I mean, your proposal is the example of both. There are several types of physical bodies that can share templates, yet each type can have a unique template. Same can be said about other generic nodes, e.g. Controls. Are you not satisfied with your own examples?

I am never satisfied with my own stuff 😄 (joking) that being said, as move_and_slide exists only in CharacterBody and the code in 2D is not the same as the one in 3D. My example is not an example of both, it's a template for only one node.

[YuriSizov]

It's indeed straightforward in the inline way but I was talking about the way to put the templates into separate files, that's the things I'm not sure how I should do it.

I'm not exactly sure either. I guess we could just store them as files in a subdirectory next to EditorSettings. Ideally, we'd want templates to be connected to the language they are written in. That means that built-in template files should probably be created in the gdscript and mono modules.

We currently have other problems with how inflexibly the templates are implemented, which can probably be handled with the same swoop. For example, when you create an editor plugin a script is generated from a template, but there is no template for C# and so the default one is used, which is no suitable.

See godotengine/godot#37867 and godotengine/godot#28799.

[pouleyKetchoupp]

This can be very helpful for both new users and experimented users.
It's definitely needed for physics, but what's important to discuss is how to implement it in a way that's flexible enough for other node types.

Inexperienced users can learn. Experienced users have to live with the automatic adjustments their entire timespan using the engine. Which is my main argument against doing hidden things and in favor of leaving it to the user. (But providing users with more suitable options out of the box costs us very little and is a good idea).

@pycbouh I get your point, but I think you're discarding newcomers' experience a bit fast.
If we propose a specific script template for characters, it can't be hidden in a list, otherwise lost of users might never know they even have this option.
I didn't notice there was this list of templates before this discussion.

So in order to address the issue you're mentioning for experienced users, which makes sense, here's what I would propose:
What about remembering the user's choice for specific node types?
The logic would be:
-By default, if there's a type-specific template, it's the one chosen in the list
-If you select one the the other templates instead, it will remember you don't want the specific one for this node type
-It could also help if there were several templates for a given node type to remember which one is preferred

[YuriSizov]

I didn't notice there was this list of templates before this discussion.

Yes, I've mentioned that we can work on the discoverability of this feature.

So in order to address the issue you're mentioning for experienced users, which makes sense, here's what I would propose:
What about remembering the user's choice for specific node types?
The logic would be:
-By default, if there's a type-specific template, it's the one chosen in the list
-If you select one the the other templates instead, it will remember you don't want the specific one for this node type
-It could also help if there were several templates for a given node type to remember which one is preferred

I'm okay with that, I proposed as much above (sans the remembering part, as that is already a thing). We can definitely add type-specific templates and we can maybe auto-select them somehow.

I think at some point I figured that this proposal wanted to automatically transform the single default template, but upon rereading the discussion, I can see that's not the case. I was only against that part, but I must've misread something. I'm on board with having more templates, specific to some common use-cases.

[YuriSizov]

By the way, I thought about some other cases where this can help. I often create scripts that extend Object or Reference, and default templates have methods that have no significance for those. Same for, say, EditorScript. So it's not just for nodes, can be useful for a lot more cases than that.