วีดีโอ

for some reason even the default script wont work for me

Wait that is so powerful. Thank you for very clear explanation!

honestly one of the best things i ever learned in programming was to look for/keep in mind the hidden 'costs' of every line of code, in terms of processing, lookups, memory, etc. when i was a kid, computers were grossly underpowered, slow as shit, and memory was precious; if your code didn't take all this into account, it either ran poorly, or not at all. modern systems tend to obscure this (both a good and bad thing), but the fundamentals haven't changed. i'd love to see more developer content taking quick asides to explain "ok... so look at what's happening here *every single processing cycle*..." etc.

There's probably no difference between the performance of export and onready. If you look a the scene file and find the export property you'll see that a NodePath() is saved and not a reference. So, both export and onready use nodepaths. However, the export value is evaluated early and you can access it in the _enter_tree() function while the onready value is set later and available by the time _ready() is called. (Note: all nodes in a scene are created from the get go and then added to the tree from root to leaf. To verify add an _init() override that prints _init() was called for a node. Do likewise for _enter_tree() and _ready() to get a sense of the sequence.) Personally I use onready variables with unique names and just rename nodes to match what they are being used for making it less likely I'll rename them. Then moving them around wont break anything. I also don't like having extra exports hanging around when I child the scene into a level or something. This is especially true for very complex scenes where a lot of extra exports would be added and visible. But to each their own! If you like exports, by all means enjoy! While I personally don't do it, there's nothing really wrong with it.

Great, thanks for the help.

This is a cool feature. I still don't see the advantage of using this over @export var I guess the advantage is if you don't want to write a script, but I'm probably going to want to add some logic (aka a script) to it eventually anyways.

I have a beginner question, sorry if this sounds stupid Are there any pros and cons in the await create_timer VS timer node? Say, if I want to add a default timer on every single character animation (player, npc, objects, etc), which decides when the functionality activates and deactivates in an animation, in order to separate the functionality from the visual. Which is the better approach for this kind of purpose?

Thanks for the great content!

I have a question. I want to have a var texture in a resource and set the texture of a node inside its script. I tried it with texture = stats.texture but it doesn't work. Am I missing something?

so far this is the best video I've seen on resources. Great intro and very thorough, while not wasting any time at all. This is the resource video I needed. Thank you. Good editing too. I hope your channel grows.

is move_and_slide() needed to make the astar grid enemy move

are you planning to make a version of this but the enemy moves via tilemap and moves only on tiles that are on a certain data layer?

Hi! With inputting expressions, is there a way to bind a variable there (such as a global variable)? So whenever the variable changes that that field is updated too? Or can that only be done using code and callbacks or something?

good tutorial but you go way too fast

Nice 2D character movement script, just wondering are there 4.3 upgrade issues with the script 🤔

18:12 I genuinely didn't know you could use Astar without a grid. Otherwise does it work in 3d and do you know how to make stuff like jump and fall connections?

I never use $ or node paths in code. Always export variables.

Clear, concise and straight forward information. Resources are much more clearer now and their use-cases are brought to light, thank you.

Thanks for sharing this information.

You channel is gold! It's a missing category in Godot tutoriala, because most if the times videos are targeted at beginners or they just explain implementation if a certain feature. You, however, explain intermediate things about workflow and good practice. Keep up your good work, I'm sure it will pay off!

It's just a guess, but onready nodes should be worse because godot still calls get_node to get the reference while with export, it seems, you directly assign the reference via the editor

I was just wondering this a couple days ago. Thanks for sharing.

No one should give performance advise without measurements.

my gf said she would grind you

Great video idea with these short clarifications! If you haven't done it already, an explanation between some of the other virtual methods would be awesome. Like _process vs _physics_process or _input vs _unhandled_input. Stuff like that.

I use a mix of exports and onready, The exports i use for scripts that are shared between scenes. For instance, my playable characters all use a stats script that houses their health, stamina etc. I this allows reuseability, for logic thats shared between characters but not necessarily needing the exact same things like running speed etc.

Great video 👏 with the export method, would there be a significant performance difference if you dragged a file from a folder rather than creating a node in the scene tree for that variable? Example: an mp3 file. Do I have to create an audiostream node inside my scene tree or is it fine to just drag the file from my sounds folder?

It depends a lot on the type of project you're making and what it is you're doing with that node, what it's interacting with. Exporting some nodes can lead to issues with serialization and there are some other potential issues. For smaller projects this may be fine. But it is NOT something you should be doing with 100% of your nodes, at any and all times. And most certainly not something you should do with larger games.

As usual, the more static or predefined some info is, the faster it will be processed

DANG!! now I must rewrite 500 lines

Great job

Just a minor note, you don't really lose runtime flexibility with exported variables, and they don't have to be assigned in the editor. You can set default values in the script declaration, so if you forget to set them in the inspector it'll still work, and you can still set them again during runtime, nothing prevents it. The only downside is they will revert to the exported value when the game is rerun, so you'd need to save the value, and load it after to get the prior runtime value. Most games with save/load do that anyway, so it's not a real issue. Also, export is basically the same as onready + inspector access. There's not really a performance difference. Export does process before onready though, as it's more in line with _init(), while onready is with _ready().

Here's the info on Unique Names, since quite a few people mentioned this :) Unique Names are similar to exported references (in the sense that the scene tree position can change while retaining the path), although they still need to be accessed with the % symbol (the same as using the $ sign or get_node()). Pros of using Unique Names: - Similarly to exported references, you won't need to update your code when moving the node around in your tree - More readable paths inside your script Some Cons of using Unique Names: - For the best performance, it's still essential to store unique nodes inside of @onready variables, since they do still need to be obtained, and aren't properties - Uniquely Named nodes can ONLY be retrieved by a node inside the same scene. This means that instanced scenes with exported node references are much more flexible, especially when working with component systems. - If you have multiple nodes with similar names (especially in larger scenes), Unique Names can get tedious, and end up being more confusing than other methods. Performance of Uniquely Named nodes: - The performance is slightly faster than using static paths, but is still slower than using exported references Hope this helps! :)

It is still inefficient. The str() function should not be in _process

Thank you for creating this content. I like these kinds of videos: short, to the point, and covering the basics. As it was mentioned in other comments, I'd have liked to see an example using %unique_names, perhaps that could go in another video. Best regards.

The missing one is %cached_name Those are cached so are fast

Is there a difference between exporting nodes and setting them to "% Access as Unique Name"?