Hoist allows you to select which properties of a nodes children/grandchildren should be editable from the scene root. Essentially an augmentation to Editable Children.
Why? Other than not having to click the child node in the scene tree to edit a variable, I’m not seeing a lot of benefit here. The drawbacks I see are that you have to make each child scene editable, and you can’t use typed variables, because you have to type them as Hoist? Unless I’m misunderstanding your documentation. also scenes marked as editable that have any changes made to them no longer propagate changes from the scene they inherit from.
One can already do this by just exporting the variable and then creating a setter that propagates the values down the tree if you want it that tightly coupled. No need to make the scene editable.
1 Like
Other than not having to click the child node in the scene tree to edit a variable, I’m not seeing a lot of benefit here.
That’s really the primary benifit. At least that basic benifit is pretty often requested, e.g,: How can I expose child node properties to editor without using "editable children"?
The secondary benifit is that it allows you to define the intended public API of the scene when while authoring it. Often it’s really only acceptable to to edit a handful of properties of the children, but the scene may contain a bunch of internal stuff you shouldn’t touch; hoist allows you to mark these important properties so they’re easy to find.
There are various open proposals to improve this workflow, like this proposal with 115 upvotes: Improve usability of Editable Children · Issue #3248 · godotengine/godot-proposals · GitHub. This proposal is a bit simpler, because it works for entire-nodes, not specific properties.
because you have to type them as Hoist?
That’s just a missunderstanding. The @export var hoist : Hoist is used in the root as a data container, and the target for the editor customization. All other variables would be written or typed as you normally do. I haven’t tested it, but I suspect I even support properties defined via _get_properties_list
The blog post contains more detail than the github readme, if you’re interested.
2 Likes
Yeah, but Godot already does that with @export variables. I mean props for trying to solve a problem, but IMO this is a case of the user not always needing another way to do something - even if they think they do.
Again, you can accomplish that with @export_group or @export_category.
That proposal is 4 years old. @export_group was just added in 4.6. At this point you can do all those things yourself with a simple tool script. If people want to use your plugin that’s cool.
The blog post link also took me to GitHub.
1 Like
I can’t help but feel you’ve missunderstood the point of the plugin. In any case, the link to the blog post has been updated..
Export vars, groups, and categories are useful for categorizing the exported properties of the root script of your scene, but don’t have anything to do with enabling the editing of children properties.
I know people often use a set/get pattern where an exported property of the root sets children properties, but I don’t view this as always suitable.
That’s fair.
Very interesting read. (In the section “A brick wall”, the last word is spelled “dormant”.)
From a technical perspective, it’s really interesting seeing what you did under the hood as an implementation.
We may have to agree to disagree here, because I see them as exactly the same from an architecture perspective. Both approaches are creating an abstracted interface to otherwise encapsulated values deeper in a complex object made up of smaller objects.
That’s fair, and a valid answer IMO as to why you did this.
I’m still processing how I feel about this approach personally. Hence my questions.
I made a CurvedTerrain2D Plugin that is a Path2D with 4 child nodes that are created at runtime: Polygon2D, Line2D, StaticBody2D, and CollisionPolygon2D. The original version was made by following some tutorials and making a scene that could handle it. But I wanted a Node I could add through the Add Node dialog. It’s a better user experience. So I have to raise up all the properties I want accessible because they’re not visible in the editor.
What interests me is the possibility of raising up values like this programmatically in the editor so that I don’t have to figure out which ones a person might want to edit. But I don’t see that as a use case for what you’ve constructed. Unless I’m misunderstanding again.
At any rate, it’s a neat project from a technical perspective.
Thanks for taking a look at the blog post! I guess we understand each other much better now!
As I alluded to in the post, this plugin was something that’s been WIP for ages. I did something similar in Unreal Engine for my company once, and i wanted to try it in Godot. I’m actually not even positive how useful I would find the final result 
Path2D with 4 child nodes that are created at runtime: Polygon2D, Line2D, StaticBody2D, and CollisionPolygon2D.
So, technically hoist could be used for this. No, I don’t actually suggest it. But the idea is you would provide a Path2D scene not a plugin. Users would instantiate this scene (instead of adding a node), and edit the exported properties there. It all gets extremily stupid though, because Hoist doesn’t provide any way of mapping the curve data from a single property to all the children nodes. That’s where the set/get workflow is far superior.
What interests me is the possibility of raising up values like this programmatically in the editor so that I don’t have to figure out which ones a person might want to edit.
That’s an interesting idea. But for your specific use-case, you sort of still run into the issue of the child-nodes not existing at editor-time… What you’re doing is probably best
1 Like
Yeah already a dealbreaker for me. I want it to be a normal node that can be extended, not a scene.
1 Like