Why use randi() and not randf for PathFollow2D in the tutorial "Your first 2D game"

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Xiouzzi


I’ve been following the tutorial, and I can’t understand something in the tutorial “Your first 2D game/The main game scene” at The main game scene — Godot Engine (stable) documentation in English .

The part:

func _on_MobTimer_timeout():
    # Create a new instance of the Mob scene.
    var mob = mob_scene.instantiate()

    # Choose a random location on Path2D.
    var mob_spawn_location = get_node("MobPath/MobSpawnLocation")
    mob_spawn_location.progress_ratio = randi()

    # Set the mob's direction perpendicular to the path direction.
    var direction = mob_spawn_location.rotation + PI / 2

    # Set the mob's position to a random location.
    mob.position = mob_spawn_location.position

    # Add some randomness to the direction.
    direction += randf_range(-PI / 4, PI / 4)
    mob.rotation = direction

    # Choose the velocity for the mob.
    var velocity = Vector2(randf_range(150.0, 250.0), 0.0)
    mob.linear_velocity = velocity.rotated(direction)

    # Spawn the mob by adding it to the Main scene.

In: mob_spawn_location.progress_ratio = randi()

Progress_ratio is supposed to be a float between 0 and 1 (cf PathFollow2D — Godot Engine (stable) documentation in English)
And randi() “Returns a pseudo-random 32-bit unsigned integer between 0 and 4294967295 (inclusive)” (cf RandomNumberGenerator — Godot Engine (stable) documentation in English).

Everything is working when playing the game but I don’t understand why they give an int when I would have given a float… Any explanation?

Edit: it seems to work with randf too. Then what is the difference? And why in this case it’s not important to use either randi or randf? Are there performance differences?

:bust_in_silhouette: Reply From: jgodfrey

Agreed. This should probably be randf() since it returns a value in the 0-1 range, exactly like the progress_ratio property expects. Looking that the 3.5 docs, I see this part of the tutorial has been changed for the 4.0 release (from using offset to using progress_ratio).

I only assume the randi() I call should have been switched to randf() but was missed.

Further, I assume the engine must bounds check the value and push it within a valid range - though I’d expect that to always be at the END of the defined path (as a guess).

Bottom line, I assume this is a documentation bug.

If you’re interested, here’s some docs on ways to contribute to documentation improvements:

Thanks for the answer. It makes a bit more sense to me now.

Xiouzzi | 2023-03-05 10:27