Allow attaching scripts to nodes in the Advanced Import Settings dialog #103418
Conversation
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
dda1801 to
b09f94e
Compare
|
Problem with a script is you can only have one per node, every unique object type would require its unique script with lots of exported variables to allow custom behavior. With child nodes as components you can reuse and combine game logic in an artist-friendly way, a wider range of unique behaviors can be achieved for imported assets in editor without touching any code. One script approach is good for solo projects when everything is code, but won't scale that well to teams where programmers and game designers are separate people focused on solving different problems
Why one script instead of improving those workflows? Not only inherited scenes / editable children allow components, they also allow adding and previewing unique node types like particle systems and connect signals in editor |
|
Yes please I'm one of said advanced users :) |
|
@passivestar This isn't necessarily "instead of" those workflows, since those can and should be improved too. However, if a script requires a node type change, you can't change the type of existing nodes in an inherited scene, only add new nodes. Indeed customizing properties on these nodes and previewing their final appearance will require using the regular scene editor with the inspector on an inherited scene, since we don't want the advanced import settings dialog to do that. |
|
Fair, just wanted to confirm that this isn't intended to be a replacement, good to hear that we're on the same page |
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
b09f94e to
f5205c1
Compare
|
I like it, but why shouldn't we match the exact |
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
f5205c1 to
ab48f3d
Compare
|
@fire Done, now matches exactly. Tested and still works. |
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
2 times, most recently
from
18e39f1 to
52db05d
Compare
|
I think it's good, but I haven't done any testing. |
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
52db05d to
5a2cb03
Compare
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
5a2cb03 to
363a991
Compare
There was a problem hiding this comment.
Looks good. We should continue testing this in beta.
I ran into a problem where it doesn't change the node type if I assign a "New GDScript" (a blank script??) from the dropdown and change the type at the same time. Technically such a script is not valid for nodes, since it is treated as extends RefCounted. The problem is that the custom node type is also lost in this case.
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
363a991 to
9997e10
Compare
|
@lyuma Done, good suggestions, I've fixed all of those. Did the renames, fixed the type being lost when an invalid script is set (it will now check that the script extends |
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
9997e10 to
10b771c
Compare
| @@ -65,6 +65,9 @@ | |||
| <member name="nodes/root_scale" type="float" setter="" getter="" default="1.0"> | |||
| The uniform scale to use for the scene root. The default value of [code]1.0[/code] will not perform any rescaling. See [member nodes/apply_root_scale] for details of how this scale is applied. | |||
| </member> | |||
| <member name="nodes/root_script" type="Script" setter="" getter="" default="null"> | |||
| If set to a valid script, attaches the script to the root node of the imported scene. If the type of the root node is not compatible with the script, the root node will be replaced with a type that is compatible with the script. This setting can also be used on other non-mesh nodes in the scene to attach scripts to them. | |||
There was a problem hiding this comment.
Needs a rebase.
Also:
If the type of the root node is not compatible with the script, the root node will be replaced with a type that is compatible with the script.
What does this mean in practice? Will I lose my gdscript?
There was a problem hiding this comment.
The opposite, the GDScript is kept whenever possible.
There was a problem hiding this comment.
As an example, if it's a standard Node3D, and I choose to attach a character_controller.gd script (which extends CharacterBody3D), the Node3D will be upgraded to a CharacterBody3D
aaronfranke
force-pushed
the
adv-imp-attach-script
branch
from
10b771c to
a3daba2
Compare
TokageItLab
moved this to Approved, Waiting for Production
in Asset Pipeline Issue Triage
github-project-automation
bot
moved this from Approved, Waiting for Production
to Done
in Asset Pipeline Issue Triage
|
Thanks! |
The Blender Project DogWalk team has been using scenes with an imported glTF scene as a child node in order to attach scripts to the nodes and save that. This is a good use case for inherited scenes, and the editable children checkbox, but there are currently some issues with those.
Regardless of improving imported scenes, being able to attach scripts to nodes in imported scenes within the import process itself is a highly useful feature. We already allow customizing mesh nodes with common things like physics, but other nodes are missing customizability. For many things like physics, ideally users would use glTF extensions. However, there will always be a need for custom game-specific scripts that do not make sense to store in the glTF at all.
This PR adds the ability to use the Advanced Import Settings dialog to attach scripts to nodes so they are available when directly dragging the glTF into the scene. Here's a video showcasing using this feature. The node type will automatically change to accommodate the script if needed, or will use the user-specified type when possible.
adv_import_dialog_attach_script.mp4
Essentially, for any node type or script that can't be determined in the green circle, this PR allows attaching the script or setting node type in the orange circle, instead of using an inherited scene or other scene to attach the script. Also, in the red part, you can't change the type of an existing node if the script would require a different base Godot node type.