You need to keep posting content - your future is bright on youtube; your teaching style is intuitive and clear. Your examples are fantastic. Most importantly, your progression through solving the problem enables viewers to understand the purpose behind the design decisions. As a dev with 20-years experience, I can tell you know your stuff based on how well you explained it. This just opened the floodgates in my mind as to what I can do in the editor. It's like you've connected the dots, finally... signals were useful, but the in-editor steps felt off and lacking. It's like I just leveled up in godot. Your examples will teach millions one day, just you wait... thank you!
genuinely great video and teaching style, good usage of cuts and speedups, and the subtle green glows when you want to highlight some code is really nice. fantastic work
This video is incredible. You got me lost somewhere in the flags though as they don't seem to be that intuitive but I'm sure that it would be easier to implement than it feels :) Thank you so much, this is so helpful for me!
This is just what I needed. I've done a lot of tooling to make the systems I code more user friendly to devs that don't. My current project is solo but old habits die hard. Thanks for the vid! To those having trouble finding use cases: the @tool line makes the code executable in the inspector!
This is absolutely wild. I have been subbed to you since you posted your dragon IK stuff. I've also moved onto godot, and I'm watching your tutorials again!
Wow! I'm honestly surprised that anyone has stayed subbed to me that long. Thank you so much! And I hope each new video I make is better and better for you
I just learned so much from this video. Some of it not even things you were trying to explain. 😅 I hope you make more videos! I really like your teaching style.
This is exactly what I wanted to do. Learn how to customize & understand the basics of using tool scripts to aid in the development process. Thank you so much. I’ll be making my first game soon & this gives me the ability to start out strong!
Brother I watched an entire video on "components", and it was a huge waste of time, but your 20 min video is exactly the concepts I was looking for. This is great for straight forward workflow, and especially a solo developer like myself. Much appreciated.
Wow this is exactly what I needed. And how to do this isn't exactly straightforward to find online. Thanks for this tutorial. I am itching to try it out.
Hmm, I've gotten a lot of mileage out of using tool scripts and exports both, but I've never gotten my head around using _get_property_list effectively to make it all work better. What I've been able to do without it is very similar to what you're doing here, but you took things a couple steps further in terms of usefulness that I very much appreciate being informed of! Thanks! Also, I've been plagued with issues with my tool scripts using export vars. Maybe doing it this way helps alleviate some of those... I'll have to test it out to be sure, one-way-or-the-other.
Grate video, but I hear some strange unplesent noise in bg. Most of this can be done with @export - as you have diffrent types of exports - read the docs. And also using typing and setters and getters also help a lot with that. But I see that this method is more powerful. I think you can cobine it with normal exports. You don't have to realy on _process() to update visualisers - this ids bad way of doing this, yes resoures dosn't has _process(), but it has signall `resouce_changed`. Is this method allows to hide in Inspector properties of build in classes ? Is there way to don't use `1
Hi, great & helpful video, thank you so much! I didn't really understand why you did the bitflip when storing the Enum classes values (Timestamp: 6:45). Could you explain, how that is helpful or why it makes sense to do so? Thanks :)
I use [tool] for lerping UI, saving and loading a position into a resource array. I'm not sure if this is the correct approach since I'm new to Godot, but it works. But only after using Godot's Array since regular arrays don't serialize well, and both script AND resource must be marked as [tool]. Otherwise, closing and opening the editor will reset the array.
Yesterday I was trying to learn this and you drop this amazing video. SUB+ But what I'm trying to do is create a 3x3 (without the middle) of Texture2Ds, I'm trying to make it easy to set up 8 directional sprites for my game. Do you know how to do this?
I'm happy to help but this sounds like a longer conversation than in youtube comments... Message me on reddit or join my discord subreddit and we can discuss!
Dont get me wrong, I learned a lot and the advanced method seems to have deeper control over the whole process, but you can achieve the same thing with just the "basic" exports and an visualzer, over the resource method. basic_resource_gd: @tool extends Resource class_name BasicResource @export var teamColor: Color func colorThis(rect: ColorRect): rect.color = teamColor _____________________________ basic_visualizer_gd: @tool extends Node2D @export var parentNode: Node2D var basicResource: BasicResource func _process(delta: float) -> void: if Engine.is_editor_hint(): if is_instance_valid(parentNode): basicResource = parentNode.basicResource basicResource.colorThis(parentNode.get_node("ColorRect")) _________________________________ basic_export_test_gd: @export var basicResource: BasicResource = BasicResource.new() ________________________________ Just add the Color Rect as a child to the parent node this doesnt solve the categories problem, but you dont need to write the dictionary, what could be a quick and dirty solution to sketch out stuff(Correct me if I am wrong, I am relatively new to Godot xD) Anyways, thanks for this Video, it helped me a lot to structure my scripts :D (Maybe first comment was tagged as spam because I used dots ffor the script names xD)
I used a ColorRect in this example because the auto creation of a collision shape didn't even work with the dictionary method right now for me, maybe its just one character wrong spelled xD but I guess this is possible too then
@furio_faerfax So I agree that there are multiple ways to achieve results in Godot, which is awesome for us devs! And if you have a method that works great for you then more power to you! I like to think of this as another tool (no pun intended) in your dev toolbox, and one that I particularly like! There is however, no way in Godot (currently) to auto-annotate dictionaries and arrays with basic exports in a tool script. And that is ultimately what led me to learning about advanced exports and using them extensively in my projects. An example is for my utility AI I need to have a auto-keyed dictionary that can house multiple different types of resources that are all variable and used to populate the AI. And those resources all have nested inspector variables that auto-update based on changes I make as I create the NPC. I am happy to show anyone that wants to see what I'm talking about if you'd like. I didn't show much in the beginning because I didn't want to waste people's time in a tutorial showing off what I was doing, but it's much more complicated that the examples I gave. I wanted to get straight to teaching people how to do it themselves! Thanks for the comments! The Godot community is always lovely and engaging
@@Leif_in_the_Wind That sounds incredibly cool, I dont wanted to judge your decision for the tutorial, you can indeed (at least I think it will work, based on your comment and my imaginmation of whatz should be possible) automate this process with workarounds via the possible borders in Godot, or even running an external programm, maybe what you specificly coded for that purpose. I like coding because of the fact that you can in most cases, do things in different ways. And that you can automate or make things at least easier by yourself for your work :D After finishing your video in the middle of the night, I thought "that should be possible on the quicker path as well" and then I tried it out. :D I commented with my solution, if someone is just searching for an easy and quick setup to get export variables organized and combined with the toolscript to visualize in Editor :)
For some reason, my Trained Classes and Potion Bag enums don't populate. The enum keys lists are correct, and my code matches yours. The items are displayed in the inspector, but are blank. I'm on Linux, but that shouldn't make a difference. Edit. Never mind. Forgot the "if something doesn't work, exit Godot and restart" rule. Works now. Reloading the project didn't work, strangely enough. Edit 2. BTW, while trying to fix it, found the potion bag hint_string can be simplified to: "hint_string": "%d:%d/%d:%s" % [TYPE_ARRAY, TYPE_INT, PROPERTY_HINT_ENUM, potions_list],
Did you write it yourself or download the project from github? If you haven't downloaded/copied the code from github you can try that. If you are working directly off the project then it might be an issue with Linux, though I'm not sure. Just now I copied and pasted the code I wrote off github into my personal game project and it works as intended. Is it giving you any errors, or is it just blank? I will also say that sometimes tool scripts just act a little off. I think there are some sneaky bugs in the godot engine, but I have times where the enums wouldn't work until I deleted the code, restarted the project, and rewrote it. You're welcome to message me on reddit or on my discord. Those locations are a bit easier for me to help debug stuff. Edit: Glad to see you figured it out! Edit2: Oh that's interesting! Good job finding that out. There's definitely some parts of hint_strings that I still don't understand!
I’ve noticed sometimes using Godot 4.2 that it doesn’t always update the editor properly. Try making a change to the file where the enum is saved and resave it. Then click to a different scene and revisit it. Then click the dropdown for the enum and it should be updated. If not, just reload the project and it should be fine
I don't think it's an either/or! I honestly believe tool scripts pair really well with resources, offering increased available complexity and flexibility of the inspector! It really depends on your coding style, but an obvious use-case is what I mention in the intro. Reusable components with large scene trees that don't need to be sifted through every time they are reused.
This is pretty interesting, but can't all of this already be implemented with @export? I typically just use setter functions on exported properties in a tool script, I guess I'm wondering what the pros are for doing it this way?
Yes and no! You cannot change what the inspector displays with regular exports even if it's a tool script, like how I can make the Wizard Spell subgroup appear and disappear based on a variable flag. And there are a number of variable types and implementations that are unavailable with regular exports, such as nested array custom resources. I also don't show it in the video, but I have pretty complex methods and logic for how my inspector displays and what variables I'm using to do what. That being said, godot is very versatile and there are many different ways that similar things can be achieved! So if you find your particular implementation of @export works for you, more power to you! I just wanted to share my way of populating and controlling the inspector, as I find it very powerful and super simple once I got past the learning stage.
That would be pretty weird since I don't have FB. But overall I'm not super happy with the audio of this video, and will improve on the next one. Thanks!
This is a bit beyond my level so while I find it very interesting, I am struggling to see it in the larger picture. How would you use this in a real project? Are these advanced exports limited to the inspector or can they be used in the final product?
Essentially, like regular exports, it is used during the creation of the game. For example, I have a bunch of NPCs that I want to create (or maybe I have another designer that is creating the NPCs while I work the background code); I don't want to have to dig into the component nodes or code for every NPC. I want to be able to just throw all the components into my NPC, then go over to the inspector and set the relevant info for each of them, then move on to the next NPC. This also lets the designers that aren't working the back-end code a lot! Also when it's late and I'm tired, I want the inspector to only show my relevant inputs (such as the wizard spell example in the video). Or even if you have a team of people. It helps reduce confusion between what needs to be inputted and what doesn't. Another example of what's possible: in my own NPCs; I have a dictionary that I populate with "action inputs" via the inspector. Those inputs then tell my UAI what node to actually add to itself at runtime, and the nodes use the inputs that I created to set themselves up. This allows me to craft the NPCs "action nodes" without adding them manually every time. This saves me a ton of time and clutter. Essentially you are crafting the engine/inspector to help your workflow the best. There's a bit of up-front time to get things started, as you have to code all of it first. But in the long run, at least for me, it has helped a ton with my work flow.
You use the variables that match the property names you specify in _get_property_list properties array. _get_property_list lets you customise what would normally get automatically created by using @export annotations
@@Leif_in_the_Wind Thanks for the great reply, it helped clarify the purpose of using these tools. As I understand it now, it's very useful for prototyping and experimenting with ideas - especially so with less technical team members being able to use these tools. Follow up question - let's say after using these tools to test out different spells or enemies with the @tool variables provided: How would you go about making the final product of the tested spell / enemy?
@@starbarzs7160 Not just prototyping actually! Anything that's set in the inspector can also run just the same in the game. So in my case, the three enemies that I show in the beginning all have the same exact node trees. The difference is in all of their settings in the inspector. So the slime has it's attack loop set to "melee charge" whereas the fireskull is set to "ranged fireball" etc etc. So I've set up my inspector and nodes in such a way that I can change whatever I like about their components just from the inspector, without having to open up the components or dig into the code. Unless I'm adding something completely new, obviously If you want you're welcome to join my studio's discord and I can share my screen with my editor. It would be much easier to just walk you through how I set up my stuff rather than in youtube replies. But totally up to you!
Great vid but if you didn't edit this with headphones you should because you need a noise gate on the audio. You might not be able to actually hear it but there's a really high pitched whine in the background of the audio track.
Is there a way to hide inherited properties from superclasses? I am tired of the 'shape' property/resource being editable in the sidebar for my things that inherit from CollisionShape3D but generate the shape dynamically. Especially as whenever the shape is unset it puts a warning in the editor even though it's fulfilled at runtime by resource loading and I can't seem to suppress it, and even if I set it by default in the scene it's still unset when dragging the scene into the editor.
And I don't think the CollisionShape3D can be a Resource because it needs to be a local child of the *Body3D node (e.g. RigidBody3D, StaticBody3D) otherwise the editor complains about that too.
My concrete use case is automatically converting models (right now blender.blend files) into CollisionShape3Ds so we can develop 3D scenes physically with fast iterations, and I want that to be available as an editor workflow with minimal jank/tedium.
My own npcs don't get their shapes until runtime, and so the editor complains about it but I just ignore it. I know why the warning is there and it's not important as the shape gets moved when it needs to be. For removing things from inheriting nodes/classes, the only thing I can think of right now is to just have that variable be visible if a boolean is checking. Basically just a setVariable:bool that you check if you want to change it, and unset it if you don't. Otherwise, you could use the get_property_list in both the scripts, so that you'd be overwriting it in the inheriting script. Though I haven't tested that myself.
@@Leif_in_the_Wind i think it is important because if I have others in my team use my abstractions the warning can be confusing. At the very least I should be able to set a default shape whenever the extending scene is imported as a node and then swap that out with the dynamic value onready, but it seems to forget any properties on the root node in a scene when imported
@@MagicGonads You might have luck here: docs.godotengine.org/en/stable/classes/class_node.html#class-node-private-method-get-configuration-warnings But this isn't something I've messed with yet myself. I think your script would have to be a tool script though
An external editor allows you to have multiple windows up. I am typically working between multiple scripts and it helps a ton to be able to see them all at once. The Godot editor is fine, but there's a lot more features that I like in VSCode.
@@Leif_in_the_WindThank you so much, I don't know how I never thought about 😢 that was my biggest problem with Godot, although, I may try using jetbrains IDEs with Godot (idk if it works)
There is great documentation here: docs.godotengine.org/en/stable/contributing/development/configuring_an_ide/visual_studio_code.html That's all I used to get started (along with downloading the godot tools extension), it's pretty simple thankfully!
![ปฏิเสธไม่ไหว (Crush on you) - LIPTA feat. No One Else [Official MV]](http://i.ytimg.com/vi/NBw1jF342vw/mqdefault.jpg)
I kinda am lost, but I think this is incredibly helpful in some situations. Please make more advanced tutorials like this to broaden noob godot minds.
Thanks for the compliment! If you need more help please join my discord or message me on reddit!
You need to keep posting content - your future is bright on youtube; your teaching style is intuitive and clear. Your examples are fantastic. Most importantly, your progression through solving the problem enables viewers to understand the purpose behind the design decisions. As a dev with 20-years experience, I can tell you know your stuff based on how well you explained it.
This just opened the floodgates in my mind as to what I can do in the editor. It's like you've connected the dots, finally... signals were useful, but the in-editor steps felt off and lacking. It's like I just leveled up in godot.
Your examples will teach millions one day, just you wait... thank you!
This is a huge compliment! Thank you for the encouraging words!
I spent a good four hours last week trying to figure out how to do what you did with the CollisionShape. Glad I clicked on this video! :)
genuinely great video and teaching style, good usage of cuts and speedups, and the subtle green glows when you want to highlight some code is really nice. fantastic work
Thank you for the insight into what you liked about the video! Still developing my editing and teaching style, so this helps a lot
This video is incredible. You got me lost somewhere in the flags though as they don't seem to be that intuitive but I'm sure that it would be easier to implement than it feels :) Thank you so much, this is so helpful for me!
This is just what I needed. I've done a lot of tooling to make the systems I code more user friendly to devs that don't. My current project is solo but old habits die hard. Thanks for the vid!
To those having trouble finding use cases: the @tool line makes the code executable in the inspector!
This is absolutely wild. I have been subbed to you since you posted your dragon IK stuff. I've also moved onto godot, and I'm watching your tutorials again!
Wow! I'm honestly surprised that anyone has stayed subbed to me that long. Thank you so much! And I hope each new video I make is better and better for you
I just learned so much from this video. Some of it not even things you were trying to explain. 😅 I hope you make more videos! I really like your teaching style.
This is exactly what I wanted to do. Learn how to customize & understand the basics of using tool scripts to aid in the development process.
Thank you so much. I’ll be making my first game soon & this gives me the ability to start out strong!
You're very welcome
this is awesome. I come from unity and was looking for something similar to editor scripting in Godot. And this feels perfect.
thats a neat way to customize script panel!
Very clear explanation, thank you.
Thank you for the comment!
Well, that fixes so many issues with a project I was working on. Thanks, and Yoink.
Haha, I'm happy to help
You are just brilliant. Wow.
this is outstanding
Brother I watched an entire video on "components", and it was a huge waste of time, but your 20 min video is exactly the concepts I was looking for. This is great for straight forward workflow, and especially a solo developer like myself. Much appreciated.
Make sure to include @tool in the description so TH-cam has an easier time recommending the video to people looking to learn about it directly :)
Great content. Been looking for more advance ways in gdscript I can reuse in other projects. Thanks. :)
Wow this is exactly what I needed. And how to do this isn't exactly straightforward to find online. Thanks for this tutorial. I am itching to try it out.
This is awesome, im definitely using this
Great video, both in content and style! Instantly subscribed!
Hmm, I've gotten a lot of mileage out of using tool scripts and exports both, but I've never gotten my head around using _get_property_list effectively to make it all work better. What I've been able to do without it is very similar to what you're doing here, but you took things a couple steps further in terms of usefulness that I very much appreciate being informed of! Thanks! Also, I've been plagued with issues with my tool scripts using export vars. Maybe doing it this way helps alleviate some of those... I'll have to test it out to be sure, one-way-or-the-other.
Wow, thank you!
thx. very informative and well explained. you just got a new sub
Grate video, but I hear some strange unplesent noise in bg.
Most of this can be done with @export - as you have diffrent types of exports - read the docs.
And also using typing and setters and getters also help a lot with that.
But I see that this method is more powerful.
I think you can cobine it with normal exports.
You don't have to realy on _process() to update visualisers - this ids bad way of doing this,
yes resoures dosn't has _process(), but it has signall `resouce_changed`.
Is this method allows to hide in Inspector properties of build in classes ?
Is there way to don't use `1
Hi, great & helpful video, thank you so much!
I didn't really understand why you did the bitflip when storing the Enum classes values (Timestamp: 6:45). Could you explain, how that is helpful or why it makes sense to do so? Thanks :)
I use [tool] for lerping UI, saving and loading a position into a resource array.
I'm not sure if this is the correct approach since I'm new to Godot, but it works.
But only after using Godot's Array since regular arrays don't serialize well, and both script AND resource must be marked as [tool].
Otherwise, closing and opening the editor will reset the array.
advanced but good!
Gosh I’m too new to godot for this. I’ll stick to basic exports for now
Yesterday I was trying to learn this and you drop this amazing video. SUB+
But what I'm trying to do is create a 3x3 (without the middle) of Texture2Ds, I'm trying to make it easy to set up 8 directional sprites for my game. Do you know how to do this?
I'm happy to help but this sounds like a longer conversation than in youtube comments... Message me on reddit or join my discord subreddit and we can discuss!
Impressive
wow, much appreciated
i think im more interested in those custom nodes than inspect tools seeing this
The ones that make up my NPCs? I was thinking of talking about them during my next devlog for Dungeon Survive!
Dont get me wrong, I learned a lot and the advanced method seems to have deeper control over the whole process, but you can achieve the same thing with just the "basic" exports and an visualzer, over the resource method.
basic_resource_gd:
@tool
extends Resource
class_name BasicResource
@export var teamColor: Color
func colorThis(rect: ColorRect):
rect.color = teamColor
_____________________________
basic_visualizer_gd:
@tool
extends Node2D
@export var parentNode: Node2D
var basicResource: BasicResource
func _process(delta: float) -> void:
if Engine.is_editor_hint():
if is_instance_valid(parentNode):
basicResource = parentNode.basicResource
basicResource.colorThis(parentNode.get_node("ColorRect"))
_________________________________
basic_export_test_gd:
@export var basicResource: BasicResource = BasicResource.new()
________________________________
Just add the Color Rect as a child to the parent node
this doesnt solve the categories problem, but you dont need to write the dictionary, what could be a quick and dirty solution to sketch out stuff(Correct me if I am wrong, I am relatively new to Godot xD)
Anyways, thanks for this Video, it helped me a lot to structure my scripts :D
(Maybe first comment was tagged as spam because I used dots ffor the script names xD)
I used a ColorRect in this example because the auto creation of a collision shape didn't even work with the dictionary method right now for me, maybe its just one character wrong spelled xD but I guess this is possible too then
@furio_faerfax So I agree that there are multiple ways to achieve results in Godot, which is awesome for us devs! And if you have a method that works great for you then more power to you! I like to think of this as another tool (no pun intended) in your dev toolbox, and one that I particularly like!
There is however, no way in Godot (currently) to auto-annotate dictionaries and arrays with basic exports in a tool script. And that is ultimately what led me to learning about advanced exports and using them extensively in my projects. An example is for my utility AI I need to have a auto-keyed dictionary that can house multiple different types of resources that are all variable and used to populate the AI. And those resources all have nested inspector variables that auto-update based on changes I make as I create the NPC.
I am happy to show anyone that wants to see what I'm talking about if you'd like. I didn't show much in the beginning because I didn't want to waste people's time in a tutorial showing off what I was doing, but it's much more complicated that the examples I gave. I wanted to get straight to teaching people how to do it themselves!
Thanks for the comments! The Godot community is always lovely and engaging
@@Leif_in_the_Wind That sounds incredibly cool, I dont wanted to judge your decision for the tutorial, you can indeed (at least I think it will work, based on your comment and my imaginmation of whatz should be possible) automate this process with workarounds via the possible borders in Godot, or even running an external programm, maybe what you specificly coded for that purpose.
I like coding because of the fact that you can in most cases, do things in different ways. And that you can automate or make things at least easier by yourself for your work :D
After finishing your video in the middle of the night, I thought "that should be possible on the quicker path as well" and then I tried it out. :D
I commented with my solution, if someone is just searching for an easy and quick setup to get export variables organized and combined with the toolscript to visualize in Editor :)
For some reason, my Trained Classes and Potion Bag enums don't populate. The enum keys lists are correct, and my code matches yours. The items are displayed in the inspector, but are blank. I'm on Linux, but that shouldn't make a difference.
Edit. Never mind. Forgot the "if something doesn't work, exit Godot and restart" rule. Works now. Reloading the project didn't work, strangely enough.
Edit 2. BTW, while trying to fix it, found the potion bag hint_string can be simplified to:
"hint_string": "%d:%d/%d:%s" % [TYPE_ARRAY, TYPE_INT, PROPERTY_HINT_ENUM, potions_list],
Did you write it yourself or download the project from github? If you haven't downloaded/copied the code from github you can try that. If you are working directly off the project then it might be an issue with Linux, though I'm not sure. Just now I copied and pasted the code I wrote off github into my personal game project and it works as intended.
Is it giving you any errors, or is it just blank?
I will also say that sometimes tool scripts just act a little off. I think there are some sneaky bugs in the godot engine, but I have times where the enums wouldn't work until I deleted the code, restarted the project, and rewrote it.
You're welcome to message me on reddit or on my discord. Those locations are a bit easier for me to help debug stuff.
Edit: Glad to see you figured it out!
Edit2: Oh that's interesting! Good job finding that out. There's definitely some parts of hint_strings that I still don't understand!
I’ve noticed sometimes using Godot 4.2 that it doesn’t always update the editor properly. Try making a change to the file where the enum is saved and resave it. Then click to a different scene and revisit it. Then click the dropdown for the enum and it should be updated. If not, just reload the project and it should be fine
@@Nobody6146 Try Godot 4.3 ;-)
Like, huge thing
This is nice but man boiler plate is already crazy in Godot.
This seems neat, but I'm struggling to understand the use case or advantages of this vs a Resource.
I don't think it's an either/or! I honestly believe tool scripts pair really well with resources, offering increased available complexity and flexibility of the inspector!
It really depends on your coding style, but an obvious use-case is what I mention in the intro. Reusable components with large scene trees that don't need to be sifted through every time they are reused.
well done
subscribed!!
This is pretty interesting, but can't all of this already be implemented with @export?
I typically just use setter functions on exported properties in a tool script, I guess I'm wondering what the pros are for doing it this way?
Yes and no! You cannot change what the inspector displays with regular exports even if it's a tool script, like how I can make the Wizard Spell subgroup appear and disappear based on a variable flag. And there are a number of variable types and implementations that are unavailable with regular exports, such as nested array custom resources. I also don't show it in the video, but I have pretty complex methods and logic for how my inspector displays and what variables I'm using to do what.
That being said, godot is very versatile and there are many different ways that similar things can be achieved! So if you find your particular implementation of @export works for you, more power to you! I just wanted to share my way of populating and controlling the inspector, as I find it very powerful and super simple once I got past the learning stage.
is no one else hearing him get messenger notifications. . . it's driving me crazy (great video though)
That would be pretty weird since I don't have FB. But overall I'm not super happy with the audio of this video, and will improve on the next one.
Thanks!
This is a bit beyond my level so while I find it very interesting, I am struggling to see it in the larger picture.
How would you use this in a real project? Are these advanced exports limited to the inspector or can they be used in the final product?
Essentially, like regular exports, it is used during the creation of the game.
For example, I have a bunch of NPCs that I want to create (or maybe I have another designer that is creating the NPCs while I work the background code); I don't want to have to dig into the component nodes or code for every NPC. I want to be able to just throw all the components into my NPC, then go over to the inspector and set the relevant info for each of them, then move on to the next NPC. This also lets the designers that aren't working the back-end code a lot!
Also when it's late and I'm tired, I want the inspector to only show my relevant inputs (such as the wizard spell example in the video). Or even if you have a team of people. It helps reduce confusion between what needs to be inputted and what doesn't.
Another example of what's possible: in my own NPCs; I have a dictionary that I populate with "action inputs" via the inspector. Those inputs then tell my UAI what node to actually add to itself at runtime, and the nodes use the inputs that I created to set themselves up. This allows me to craft the NPCs "action nodes" without adding them manually every time. This saves me a ton of time and clutter.
Essentially you are crafting the engine/inspector to help your workflow the best. There's a bit of up-front time to get things started, as you have to code all of it first. But in the long run, at least for me, it has helped a ton with my work flow.
You use the variables that match the property names you specify in _get_property_list properties array. _get_property_list lets you customise what would normally get automatically created by using @export annotations
@@Leif_in_the_Wind Thanks for the great reply, it helped clarify the purpose of using these tools.
As I understand it now, it's very useful for prototyping and experimenting with ideas - especially so with less technical team members being able to use these tools.
Follow up question - let's say after using these tools to test out different spells or enemies with the @tool variables provided: How would you go about making the final product of the tested spell / enemy?
@@starbarzs7160 Not just prototyping actually! Anything that's set in the inspector can also run just the same in the game. So in my case, the three enemies that I show in the beginning all have the same exact node trees. The difference is in all of their settings in the inspector. So the slime has it's attack loop set to "melee charge" whereas the fireskull is set to "ranged fireball" etc etc. So I've set up my inspector and nodes in such a way that I can change whatever I like about their components just from the inspector, without having to open up the components or dig into the code. Unless I'm adding something completely new, obviously
If you want you're welcome to join my studio's discord and I can share my screen with my editor. It would be much easier to just walk you through how I set up my stuff rather than in youtube replies. But totally up to you!
Great vid but if you didn't edit this with headphones you should because you need a noise gate on the audio. You might not be able to actually hear it but there's a really high pitched whine in the background of the audio track.
Haha yeah... I noticed it a few days ago after someone else pointed it out. I'm definitely still a novice when it comes to video editing! Thanks
Is there a way to hide inherited properties from superclasses? I am tired of the 'shape' property/resource being editable in the sidebar for my things that inherit from CollisionShape3D but generate the shape dynamically.
Especially as whenever the shape is unset it puts a warning in the editor even though it's fulfilled at runtime by resource loading and I can't seem to suppress it, and even if I set it by default in the scene it's still unset when dragging the scene into the editor.
And I don't think the CollisionShape3D can be a Resource because it needs to be a local child of the *Body3D node (e.g. RigidBody3D, StaticBody3D) otherwise the editor complains about that too.
My concrete use case is automatically converting models (right now blender.blend files) into CollisionShape3Ds so we can develop 3D scenes physically with fast iterations, and I want that to be available as an editor workflow with minimal jank/tedium.
My own npcs don't get their shapes until runtime, and so the editor complains about it but I just ignore it. I know why the warning is there and it's not important as the shape gets moved when it needs to be.
For removing things from inheriting nodes/classes, the only thing I can think of right now is to just have that variable be visible if a boolean is checking. Basically just a setVariable:bool that you check if you want to change it, and unset it if you don't. Otherwise, you could use the get_property_list in both the scripts, so that you'd be overwriting it in the inheriting script. Though I haven't tested that myself.
@@Leif_in_the_Wind i think it is important because if I have others in my team use my abstractions the warning can be confusing. At the very least I should be able to set a default shape whenever the extending scene is imported as a node and then swap that out with the dynamic value onready, but it seems to forget any properties on the root node in a scene when imported
@@MagicGonads You might have luck here: docs.godotengine.org/en/stable/classes/class_node.html#class-node-private-method-get-configuration-warnings But this isn't something I've messed with yet myself. I think your script would have to be a tool script though
Why use external code editor? There's one built into the editor?
An external editor allows you to have multiple windows up. I am typically working between multiple scripts and it helps a ton to be able to see them all at once. The Godot editor is fine, but there's a lot more features that I like in VSCode.
@@Leif_in_the_WindThank you so much, I don't know how I never thought about 😢 that was my biggest problem with Godot, although, I may try using jetbrains IDEs with Godot (idk if it works)
can you do a video on how to step Godot with vscode? 😊
There is great documentation here: docs.godotengine.org/en/stable/contributing/development/configuring_an_ide/visual_studio_code.html
That's all I used to get started (along with downloading the godot tools extension), it's pretty simple thankfully!
@@Leif_in_the_Wind 👍
8:20 percentage what, sir?
Something about deez I think
I know the pieces fit
im lost
I'm happy to help but that's kinda vague
Magic properties and "hints" are a big L for SDK design...
I can't say that I love how this is all implemented either. I didn't come up with it though, I'm just showing people how to use it if they want to :)