Looks like you're not logged in

Login or Register to continue

Lesson Q&A

Use this space for questions related to what you're learning. For any other type of support (website, learning platform, payments, etc...) please get in touch using the contact form.

  • Setting steering_vector.y to zerostained-wolverineIm not understanding why setting steering_vector.y to 0.0 is needed. Im playing with the code and when i remove this line it indeed gets wrong, the player falls slowly, so setting as 0.0 does solve the problem, but i dont understand this behavior, could someone help me to understand this please? steering_vector.y = 0.0 1 1 Aug. 20, 2024
  • move_and_slide handles the delta by defaultstained-wolverineI saw in the docs saying: *# "move_and_slide" already takes delta time into account.* [https://docs.godotengine.org/en/stable/tutorials/physics/kinematic_character_2d.html#moving-the-kinematic-character](https://docs.godotengine.org/en/stable/tutorials/physics/kinematic_character_2d.html#moving-the-kinematic-character) So why do we need to manually multiply by delta if it already does the job? 2 1 Aug. 20, 2024
  • Given the Code Reference, isn't diagonal acceleration faster than horizontal and vertical?NPGameDevConsidering this: ```gdscript func _physics_process(delta: float) -> void: # Calculate movement based on input and gravity. var input_vector := Input.get_vector("move_left", "move_right", "move_up", "move_down") var direction := Vector3(input_vector.x, 0.0, input_vector.y) var desired_ground_velocity := max_speed * direction var steering_vector := desired_ground_velocity - velocity steering_vector.y = 0.0 # We limit the steering amount to ensure the velocity can never overshoots the # desired velocity. var steering_amount: float = min(steering_factor * delta, 1.0) velocity += steering_vector * steering_amount move_and_slide() ``` Wouldn't the player accelerate faster when moving diagonally? If so, wouldn't we need to normalize the direction when calculating the desired_ground_velocity? ```gdscript func _physics_process(delta: float) -> void: #... var desired_ground_velocity := max_speed * direction.normalized() #... ``` Update: I did some testing and the diagonal acceleration seems to be the same when calling normalized() or not, after reading through the documentation (as I should have done before asking this (?) turns out it's because the Input.get_vector method returns a normalized input vector. Snippet from the documentation: “The vector has its length limited to 1 and has a circular deadzone, which is useful for using vector input as movement.” 2 1 Aug. 03, 2024
  • Where to read input vs where to react to itNPGameDevHi, I've always wondered where is the best place to read user input, at least when that input involves physics calculations in the physics update process, so my questions are: - Where is the best place to read the user's input? - How to determine where to react to it, to ensure the best UX possible? - What about when you want to disable _process, you might expect that to disable the input processing which, in this case, would only happen if you disable _physics_process, but you might want physics to still be processed even when there is no input? - Is there a rule of thumb for all of these scenarios? Using this lecture as an example, the main logic that usually confuses me is this: ```gdscript func _physics_process(delta: float) -> void: # Calculate movement based on input and gravity. var input_vector := Input.get_vector("move_left", "move_right", "move_up", "move_down") # Apply input_vector to apply_input_vector(input_vector) # To avoid copy pasting the entire physics snippet ``` Vs this: ```gdscript var input_vector = Vector2(0,0) func _process(delta: float) -> void: # Calculate movement based on input and gravity. input_vector := Input.get_vector("move_left", "move_right", "move_up", "move_down") func _physics_process(delta: float) -> void: # Apply input_vector to apply_input_vector(input_vector) # To avoid copy pasting the entire physics snippet input_vector = Vector2(0,0) # We need to reset it to avoid carrying the old value, now that it's global ``` Thanks in advance! 3 1 Aug. 03, 2024
  • Need to multiply by deltastained-wolverineIn this piece of code `var steering_amount: float = min(steering_factor * delta, 1.0)` I think the default value 1.0 in the min function needs to be multiplied by delta too, like this: `var steering_amount: float = min(steering_factor * delta, 1.0 * delta)` Am i correct? as 1.0 defines the velocity not the distance, so at high framerates the 1.0 could result in unwanted movements. 4 0 Aug. 20, 2024
  • Small typoTJHi! Just mentioning to help you guys out, I found some small typos. I indicate possible fixes/interpretations with square brackets: (1) Steering the character velocity **invol[v]es** mostly three steps (2) We'll also **[be]** using **[it]** for AI movement in the next module. 1 0 Jul. 17, 2024
  • Velocity used before being definedJanne`var steering_vector := desired_ground_velocity - velocity` ` steering_vector.y = 0.0` ` # We limit the steering amount to ensure the velocity can never overshoots the` ` # desired velocity.` ` var steering_amount: float = min(steering_factor * delta, 1.0)` ` velocity += steering_vector * steering_amount` ` move_and_slide()` I get an identifier error in which velocity has not been defined in the current scope. I notice that "velocity" is used in the steering_vector calculation, but no where was it defined earlier in the code hence the error. Am I missing something? 3 0 Jul. 11, 2024
  • Capping the direction to 1.0MarcJAs I recall in the past we capped the direction vector to 1.0 if it exceeded 1, for example so you don't move faster when you move diagonally. Is there a reason it wasn't done here? 1 0 Jul. 03, 2024
Site is in BETA!found a bug?