How can I alternate between animations during user Input with a Animated Sprite3D node?[ANSWERED]

Which node is your script attached to again? Seems odd that the world would be transformed alongside the character.

Yeah, strange then indeed, I can't think of a reason why the world would be transformed along at all.

@KindosaurGaming said: Ok I am really sorry for making it confusing :'(

But yeah I just want it to happen like so: The character can move everywhere so you can use the walking forward(Backward, Left , Right and even the diagonals) can be applied on all coördinates in the field like how 3D-bodied characters do it (I have a 2D sprite with animations that need to do that trick)

The characters axis and the worlds axis are seperate from eachother, so this means that the character can move on it's own (with user input of course), but he isn't constrained on what the X and Z axis are for his world.

cuz what your code on October 17th was kinda working . I walked forward turned my camera all the way to the right and walked forward without a problem =), But then the backward and Left crashed my game. And with the new code you sent me it is completly stuck in one spot not able to move.

I think I see now, though it is strange that the new code is making the character stuck. I tried the code in a test project and it seemed to be working okay.

Can you post the code you have in your _process function? Maybe something with the formatting is off or something. The code crashing on the 17th makes sense, because there was a small typo, but the most recent code just amends that small typo, it shouldn't really change much of anything.

is that the character won't walk at all (animation do play and still do the toggle between states) and is now stuck on the location I have placed him on (weirdly enough :# )

Or A the controls don't do it anymore or B the whole plateau (my world) is moving together with my character. So my character does change position, but I can't see it because his feet are stuck to the plateau the moves in the same direction with the same speed.

So in short: The character moves with its local axis (so it's own axis, not the ones of the whole world :) )

I think the issue is likely something with the code is messing up the movement, though I suppose the world could be moving with the player depending on how the scene is setup.

The MeshInstance node, which I am assuming is the plateau, isn't parented to the AnimatedSprite3D in the scene layout you posted above, so it shouldn't be moving. My hunch is that the formatting of the code is slightly off or something, as the code on the 17th and the most recent code should be almost exactly the same, with lines 22 and 31 being the only difference (velocity.x -> velocity and velocity.z -> velocity)

Again I am really sorry if I am very unclear, I might make drawings of what I wan.t If this is still a bit fuzzy :/

No worries, it is all good! That said, if you want to make drawings, that might help clarify some things, but after reading the post I think I know what type of movement yo uare looking for.

@KindosaurGaming said: I thought it might be more handy to upload the full code of the AnimatedSprite3D ... the func _input(event) is for the 3D camera so I can move it

While I do not know for sure, I think the reason the code isn't working is because there isn't any code to move the player. You'll want to add something like global_translate(velocity * delta) or get_parent().move_and_slide(velocity) (assuming the parent node is a KinematicBody node) so the player moves relative to the velocity. You'll probably want to add the code around line 57.

Looking at the rest of the code, everything else seems to be okay. I haven't tested the code in a test project, but I don't see anything that looks like it would be causing an issue. If adding global_translate(velocity * delta) or get_parent().move_and_slide(velocity) does not fix it, let me know and I'll pull the code into a test project and see if I can figure out what is going on there.

The issue is likely how the AnimatedSprite3D node is moving.

Are you moving the AnimatedSprite3D with global_translate? The global_translate function will move the node through 3D space, but it does not account for physics, which is likely why it is going through things. You'll instead need to use either the move_and_slide or move_and_collide functions from KinematicBody. I think all you will need to do is remove global_translate(velocity) and replace it with get_parent.move_and_slide(velocity) for it to work.

Also, does the KinematicBody have a CollisionShape node? If not, then you will need to make a CollisionShape node for the KinematicBody to collide with the physics world.

If you are already using move_and_slide and it is not colliding (and there is a CollisionShape child node), then the issue might be something else. It is hard to say for sure what could be causing the issue in that case.

As far as gravity goes, you will need to add some form of gravity to velocity. There are several different ways to do this depending on your project and the intended gameplay. One of the most common ways is to do something like this (untested):

const GRAVITY = -18
# Other code here...

func _process(delta):
	# Other code here...
	# Before move_and_slide and/or move_and_collide:
	velocity.y += GRAVITY * delta

You can find an example of a working 3D platformer character on the Godot Demo GitHub repository that might be a helpful reference to look at.

Hopefully this helps a bit :smile:

Thanks for answering the questions, now I think I have a better idea on what is going on.

First, you need to remove global_translate(velocity) and replace it with get_parent().move_and_slide(velocity), which will move the KinematicBody instead of the AnimatedSprite. This should fix the issue with "get_parent not declared in the current scope", as get_parent() is a function and so it needs () at the end to be called. Hopefully that will allow the player to move around using physics.

You can get the gravity from the project settings using ProjectSettings.get_setting("physics/3d/default_gravity"). I have always defined the gravity of the player within the player script for fine tuning, so I'm not totally positive the code snippet above will work, but I believe that is how you get the gravity value from the project settings.

Great, I’m glad that everything, minus gravity, is going smoothly.

Solving the slow/floating gravity issue is something I have dealt with in several different projects and I haven’t discovered the best solution that completely solves the issue.

I have found that additive gravity is one of the most predictable ways to reduce the floating issue, but finding the right values can be tricky.

I’m away from my pc right now, but the code I’ve used before for additive gravity looks something like this (untested):

# You will probably need to change the values until
# it has the desired effect.
const GRAVITY = -12
const ADDITIONAL_GRAVITY =-8
var applied_gravity = 0

func _physics_process(delta):
    if (get_parent().is_on_floor() == true)):
        applied_gravity = GRAVITY
    else:
        applied_gravity += ADDITIONAL_GRAVITY
    velocity.y += applied_gravity * delta

Something like the code above is what I have most commonly used to reduce the ‘floaty’ feeling that can occur with constant gravity. It doesn’t always work and it can be tricky to find the best values that work with a project, but I have found it works pretty well for most projects.

Great, I'm glad it is at least somewhat working. :smile:

Is there also a way to maybe accelerate when falling

Technically that is what ADDITIONAL_GRAVITY is for. It should make the gravity value in applied_gravity increasingly stronger as the player is in the air. If you want to have other movement, like going forward, backward, left, or right accelerate when the player is in the air, then you will need code similar to how ADDITIONAL_GRAVITY is added to applied_gravity, but for the X and Z axis.

The only thing I need to figure out is how to set the code so that my character doesnt slide down hill This is alright if the slope is very steep but if the slope is very minimal it must not accure.

Yeah, that I'm not totally sure on. I haven't found a decent solution for slopes and sliding. I normally use a Raycast node to detect if the character is 'grounded', which can help with very minor slopes, but it can be inconsistent at times.