#hi how can flip a character whit all children nodes ?
60 messages · Page 1 of 1 (latest)
Well the rotation one is a bit cursed...Not sure what you thought that would do, but it's going to set your rotation to -90 (which...unless I'm very mistaken and it automatically detects you mean degrees somehow) will rotate your sprite around -14.3 times. Even if it knew you meant degrees, that'd still be rotating the facing direction by 90 which is a right-angle turn, not a flip (which would be 180 degrees).
The first function should work as intended, however, I have found that I need to do a simple check to make it work, myself, because it treats that assignment as if its *= instead of just =...which I have never understood the reasoning for.
If you do:
if scale.x > 0:
scale.x = -1
nested in the izquierda check and:
if scale.x < 0:
scale.x = 1
nested in the derecha check, it should work just fine. No need to fuss with rotating and flipping vertically, then.
Does the scale method works for you? I tried it one time and got a bug which flipped my character rapidly
So I use instead the flip_h method and use a pivot to rotate all I need (hitboxes and all of that for example), which is a pain but works wonders
However, I'd recommend doing input related stuff inside the _unhandled_input(event): function. This way, any events that aren't handled by ui controls are passed to here. Otherwise things that have focus in your ui and can accept an event you are using will, and it wont be passed to here. Here's the relevant documentation on that: https://docs.godotengine.org/en/stable/tutorials/scripting/overridable_functions.html
Godot's Node class provides virtual functions you can override to update nodes every frame or on specific events, like when they enter the scene tree. This document presents the ones you'll use mos...
It does, but I'm probably handling the input differently than you are.
I read that time that folks didnt recommend using scale.x, but I do not know for sure
I use physics_process to handle my inputs
I had to do some extra work for input for my game, because it's possible to use controller, keyboard or mouse to move in mine and moves in all directions, but only flips the sprite horizontally. This is JUST the input part:
I use the values from this in my _physics_process function, though, yes.
This whole setup ensures that inputs can always override any button being held down, and when one is released but another still held, the one being held will regain priority.
A tester's feedback lead me to making it work this way.
Yeah, then I don't know why that bug happened haha. I remember a person posted a question here one day asking about this bug, and when I tried this scale method I found the same bug.
I guess I'll just use my flip_h method so I don't have to deal with it
I've had that happen, too. Only when i've directly assigned a -1 to it.
Which is why I do think it's a bug in the interpreter.
You probably want to use
rotation_degrees = -180
For the rotation you're trying. Alternatively you can convert degrees to radians with the deg_to_rad(float) method.
rotation = deg_to_rad(-180)
Alternatively you can just use radians too, -180° are -PI radians
I think it's interpreting as *= -1, which would continuously flip it.
It doesn't make any sense for it to do that, but that's how it seems to behae with just -1 as the assigned value.
I believe it has to do with the way Godot handles the x scale property tbh. I read a bit of that
And it only seems to do this for the scale property.
Might be, yeah.
Godot basically does a flip v and rotates 180°, so it is a negative x scale
Yeah, that kinda sucks, tbh.
So trying to do a -scale x like 'tries to switch back its rotation again' and that ends up with a weird movement
It's hard to explain haha
Well...I have this in my _physics_process and it seems to work: $BillboardSprite.scale.x = movement_vector.x / abs(movement_vector.x)
Only makes sense if you look at how that Vector2 is set in the _unhandled_input function I previously posted.
It hasn't malfunctioned with this yet.
Granted, I'm sub-optimally setting this every physics tick, but it's not really that expensive.
Yeah, it is still a bit of a workaround, but glad it works for your game
flip_h works perfectly fine as well, but you have to have it in the event condition. I might switch to that if I'm ever hungry for optimization at some point.
Even if you're doing extra work, only take care of it if it truly starts to lag your game noticeable. If not, it's super fine
Or well...In an condition dependent on it.
Yup
Well, you're talking to someone who's deleted about 2000% more code that they've kept, so... 😛
But that makes perfection man, do it all the times necessary until you're happy with your code. It doesn't even need to be the optimal code, which is like, impossible, almost
You'd still end up sacrificing something in exchange of performance anyway
Oh, I'm sacrificing something alright. It rhymes with manatee.
Anyway, not to derail this fella's thread...I hope you got some useful answers @worldly fulcrum .
Can you show me your scene tree that has everything you want to flip?
I don't think you'll be able to flip the children by just flipping the parent, but depending on what nodes you are using, you might be able to flip everything one by one
Did you try what @terse verge suggested?
Seems like that bug I mentioned to me
Since your game is 2d side scroller, you can try the sprite.flip_h method, if you want
You can set it as true or false depending on which direction your character is facing.
To rotate your other nodes, you can try to use a pivot (node2d works fine) and put any other node there (as a child I mean) except the sprite, main collision (the one your CharacterBody2D uses), animationplayer, and any other node that doesn't need to be flipped.
Then once your character flips around, you can use the rotation on the pivot
node2d_pivot.rotation_degrees = -180 # or 0, depending on the facing direction
Just experiment a lot and tell us what you got. A lot of learning in godot is just to try and experiment until you find that thing you want
Even if you want, I can just tell you this setup in spanish if it's more comfortable to you
i will try your experiment 😄
and, I will keep trying and experimenting
i foun this solution and wooork
now i need someone can explainme this XD?
i wanna learn
It must be related with how godot handles negative scale x, iirc I read that godot applies a negative scale y and then a 180° rotation to apply that negative scale x
o wo aaa
That being the case, I'm a bit perplexed that my solution works for me. I must be causing the interpreter to branch into a different way of handling it somehow. I might take a look at the .cpp for it, now. This has me super curious.
I mean...I found where it does this, I think, but I barely understand it. Not without some comprehension, but there are still a lot of symbols in cpp I don't grok. Not to mention it appears to be indeed forcing things through a set_rotation_and_scale rahter than each independently. It even has a pipeline that does all three, as well... I can't figure out how I'm subverting it, though. Unless I'm causing it to apply the sign determinant after the fact, but I can't see how. If I'm not wrong, this is the function doing what I'm talking about, but I'm out of my league in terms of fully understanding how it gets here and where else it pipes through:
void Transform2D::set_rotation_and_scale(const real_t p_rot, const Size2 &p_scale) {
columns[0][0] = Math::cos(p_rot) * p_scale.x;
columns[1][1] = Math::cos(p_rot) * p_scale.y;
columns[1][0] = -Math::sin(p_rot) * p_scale.y;
columns[0][1] = Math::sin(p_rot) * p_scale.x;
}
It's in godot/core/math/transform_2d.h
This function appears to be doing exactly what you mentioned, if I'm not horribly mistaken (and I often am).
o wo!
wow
I'm not sure but I think this is that Transform2D property that some nodes have. I havent worked with it but have seen some use for it. Maybe you should give the transform2d a read to know the details