#hi how can flip a character whit all children nodes ?

60 messages · Page 1 of 1 (latest)

worldly fulcrum
#

I was trying these two methods by modifying the scale, but both give me a bug, where "izquierda" changes to both positions

terse verge
#

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.

timber trellis
#

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

terse verge
#

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

terse verge
timber trellis
#

I use physics_process to handle my inputs

terse verge
#

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.

timber trellis
#

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

terse verge
#

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.

timber trellis
terse verge
#

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.

timber trellis
terse verge
#

And it only seems to do this for the scale property.

timber trellis
#

Godot basically does a flip v and rotates 180°, so it is a negative x scale

terse verge
#

Yeah, that kinda sucks, tbh.

timber trellis
#

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

terse verge
#

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.

timber trellis
#

Yeah, it is still a bit of a workaround, but glad it works for your game

terse verge
#

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.

timber trellis
#

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

terse verge
#

Or well...In an condition dependent on it.

terse verge
#

Well, you're talking to someone who's deleted about 2000% more code that they've kept, so... 😛

timber trellis
#

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

terse verge
#

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 .

random oxide
#

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

random oxide
#

Did you try what @terse verge suggested?

worldly fulcrum
#

yep but the same bug keep here one key make flip en two directions xD

timber trellis
#

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

worldly fulcrum
#

i will try your experiment 😄
and, I will keep trying and experimenting

worldly fulcrum
#

i foun this solution and wooork

worldly fulcrum
#

now i need someone can explainme this XD?
i wanna learn

timber trellis
#

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

worldly fulcrum
#

o wo aaa

terse verge
#

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.

terse verge
#

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).

worldly fulcrum
#

o wo!
wow

timber trellis