Using a for loop within a state machine

mrcool982

Alright, so, I have a currently working state machine. I had this set up earlier, but I modified and saved it, and now the for loop does not work. I have a while loop under another state and another state without a loop that all work. Any ideas? Thank you!

to further clarify, when I remove the loop, it functions, and the burst_mode var is an export var

for n in burst_mode:
	fire()
	weapon_fired.emit()
	await get_tree().create_timer(r_p_m).timeout

kuligs2

mrcool982 the spacing does not show up in this post for some reason, but I do have proper spacing

use ``` tags at the top and bottom of the script.

as for whats wrong, idk, cant really know for sure with so little information.. maybe the await thing in loop is not working because why you awaiting in loop? why not create static timer and connect a function to timeout signal?

mrcool982

kuligs2 I've completely removed the timer and it still does not run the fire function. Referenced fire() function below

func fire():
	current_ammo -=1
	current_ammo_changed.emit(current_ammo)
	muzzle.show_flash()
	
	if aim_raycast != null and aim_raycast.is_colliding():
		var hit_object = aim_raycast.get_collider()
		if hit_object:
			if hit_object.has_method("hit"):
				hit_object.hit(damage)
			var cp := aim_raycast.get_collision_point()
			var cn := aim_raycast.get_collision_normal()
			bullet_impacted.emit(cp, cn)

mrcool982

I know, double post, but new update: I replaced the export var burst_mode int with a manual int (I just typed in the number 3) and it works just fine. Here's my export var which is created at the very top of the script, not sure why it's having issues. I tried initalizing it as simply the number 3 and it works, but then the export part doesn't work lol. What on Earth? It's only referenced one time in the script after it is created

@export var burst_mode: int = 3

@export var burst_mode = 3

^ This does the same thing

burst_mode_test = burst_mode

Adding this new variable ^ to the ready function to try and initialize the export variable, and then using the new initialized variable within the for loop still produces 0. I even printed the export var, comes back as zero

I've looked up the issue, seems to be a common problem with Godot that export variables are reset when running a game. Going to try and look more in depth where I can, but I have completely isolated the issue to this problem.

xyz

mrcool982 Never use await inside _process(). Especially if you're dealing with state machines.

trizZzle

mrcool982

If you have an export var like this: @export var burst_mode: int = 3 and change the value in the inspector, the value from the inspector is being used to initialize the value.

Basically you define the default value and if you decide you want to have another value to start with you can change it in the inspector.
When exporting variables it is always good to define the type, so you don't accidently assign unwanted values to it.

Was this your question? I didn't completely understand what you were saying in your update post.

You can also use @export_range() to define the min and max value and even the steps the value should increase:

@export_range(2, 5) var burst_mode : int

https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html

mrcool982

xyz In this case it is a made function being called by an _unhandled_input(event)

xyz

mrcool982 Still bad. I'll rephrase: Don't use await at all, ever.

trizZzle

xyz mrcool982 Still bad. I'll rephrase: Don't use await at all, ever.

How would you handle this scenario without await?

#Node A:
@onready var some_child_node

#Node B:
func _ready():
      await get_tree().root.ready
      node_a.some_child_node.do_something()

Without await it is possible that node_a's _ready hasn't been called yet and therefore some_child_node is null.

Sorry for the offtopic.

xyz

trizZzle How would you handle this scenario without await?

I haven't got a clue 😃

What I wrote was supposed to be taken in the context of this thread, not as a general claim. I already explained several times in the past why beginners should completely stay away from await. Some other people have done it as well. I don't have time to type the same thing over and over. Moreover, explaining coroutines to a beginner who haven't even yet learned how _process() works - is pointless. It will just go over their head and possibly confuse them some more. So I just give them a blunt reduced version 🙂. If someone is really interested in finer points, they can always ask.

So yeah; if you're a beginner and you're not fully familiar with the concept of coroutine, never ever use await. Conversely, if you know what you're doing, go ahead and blast yourself with awaits all day long. More power to you.

As for your example; it looks a bit contrived. Firstly, which real life situation would require a call order like this, and secondly some_child_node will be null anyway because you haven't initialized it.

The "proper" way to do it would be to respect the order of node initialization and put the dependent code into a place that runs after its dependency has been initialized. If something needs to run after the node is ready - put it in that node's _ready(), not in some other node's _ready(). The latter will just needlessly spaghettify the execution. As if that isn't bad enough, you then try to remedy it by turning this _ready() into a suspended coroutine, which spaghettifies the execution even more, not only in space but in time as well. Double whammy.

Instead, just arrange your code so it respects the order of initialization. The solution for your example is hence trivial:

# Node A
@onready var some_child_node = $Child
func _ready(): 
	some_child_node.do_something()

# Node B
func _ready(): 
	pass

trizZzle

xyz

Ok, I understand why you said not to use await at all. I thought there was something I was missing here.

And yes of course it should be @onready var some_child_node = $Child I shouldn't read/create posts when I'm actually in a hurry.

I believe my example was an issue I had with a statemachine, that entered the state and wanted to access some child node of the controlled object which wasn't assigned yet due to the order in which _ready gets called.

xyz

trizZzle I believe my example was an issue I had with a statemachine, that entered the state and wanted to access some child node of the controlled object which wasn't assigned yet due to the order in which _ready gets called.

Whatever it was it's 100% doable without awaiting for other node's ready signal.

mrcool982

I fixed it. I ended up transferring all the weapons to an autoload globals script, and then making an instance of those weapons within a loadout, which then apparently pre-loads the export variable before it is used within the game. It works now anyway!