• Godot Help

  • Rigidbody flips me off instead of flipping how I tell it to

I want my RigidBody2D to do a flip when it jumps by applying an off-centre impulse to it, precisely, on a point on either of the diagonals from its centre to its bottom corners. While this might not work, depending on the transform, I'll worry about that later, as the problem presently persists, even with correct orientation, that being, it doesn't spin at all >​;​( As to its origins, I speculate two possible causes:

  1. I may not be fully understanding how the moment of inertia is calculated by the engine (PhysicsDirectBodyState2D.inverse_inertia)
  2. I may not be fully understanding high school physics

Anywho, here's the code:

func _physics_do(_state: PhysicsDirectBodyState2D):
	if state_owner.tried_to_jump && !parent.contact_indices.is_empty():
		state_owner.tried_to_jump = false
		jump_force = sqrt(2 * max_jump_height * state_owner.gravity) * Vector2.UP
		state_owner.apply_impulse(jump_force, (_state.inverse_inertia * flip_angle / (4 * max_jump_height)) * Vector2(-1, 1))
		jump_time = -jump_force.y / state_owner.gravity
		emit_signal("jump", jump_time)

The whole thing is in a state machine that I somehow got working v W v , so the functions and variables are a bit weird, as in _physics_do(_state: PhysicsDirectBodyState2D) is a recreation of _integrate_forces(state) and state_owner refers to the node with the actual _integrate_forces function. Also, here's all the calculations made by my exerted cerebrum:

Everything is pretty standard, apart from the inputs, which are:

  • x, which is the local co-ordinates of the point on which the impulse is applied

  • h, the max_jump_height

  • theta, the flip_angle

    ...and my incredible handwriting, ofcourse u///u

  • xyz replied to this.

  • So... your beloved feline overlord has fixed the problem by himself v W v
    First of all there seems to be some sort of angular dampening that's inherent to rigidbodies and can only be turned off by switching the damp mode to 'Replace' from 'Combine' in the inspector, whatever that means. Also, apparently _state.inverse_inertia is the reciprocal of the moment of inertia. In hindsight, I should have thought so, given the 'inverse', but why? Why do you do this to me godot >:C

    Annoying-Cat What happens if you multiply jump_force with a large number?
    Btw if you want the body to rotate, consider using apply_torque_impulse() instead.

        xyz It jumps higher(?) I think you mean flip_angle, in which case, yes, increasing it does seem to have the intended effect, but only when the value is no less than 400000. So I guess I can make it work for now, but this just defeats the purpose of my maths, as I wanted things to be in clean radians, except that your second line does so equally well. Seriously, the heck is a torque impulse? Knowing this could have saved me so many braincells... Except, it does not: apply_torque_impulse(_state.inverse_inertia * flip_angle / jump_time) has the exact same effect :c At the very least, my maths is prolly correct uwu

          So... your beloved feline overlord has fixed the problem by himself v W v
          First of all there seems to be some sort of angular dampening that's inherent to rigidbodies and can only be turned off by switching the damp mode to 'Replace' from 'Combine' in the inspector, whatever that means. Also, apparently _state.inverse_inertia is the reciprocal of the moment of inertia. In hindsight, I should have thought so, given the 'inverse', but why? Why do you do this to me godot >:C

          i was playing with this earlier myself in a slightly different sense (multibody collision with different mass/bounce/gravity). Question i have is did altering the replace/combine do anything ill intended? such as interactions with other objects whilst this is occurring? i was getting odd collisions every so often, however i changed many variables at once, so I'm unsure what was the cause. P.S. i am a super noob and just trying to see leach some info here 🙂

            REVBENT I did some searching and found out that rigidbodies in Godot have linear and angular dampening by default, that can be changed in project > project settings > physics > 2D (so that can also be altered for the desired effect, which I'mma actually do, now that I think about it). As stated in the 'tooltip' (?) in the inspector, the damp mode 'Combine' adds onto that default value (and who knows what else), while 'Replace' overrides them with the value it's given. While they are probably useful for a global air-resistance effect and whatnot, in my case, they were a huge pain, because they were messing with how my player character moves, like those weird rotation problems that made me question my maths skillz and other weird glitches, like messing up my ground check with state.get_contact_count(), so no, the defaults certainly had to be changed in my case. Now of course it can't be that simple; I'm also quite new to the engine, so I don't know what else the damp mode influences, and besides, you're not really supposed to use rigidbodies for player movement ^_^; As for weird collisions, you could switch to one of the continuous collision detection modes in the rigidbody properties in the inspector, or create a new discussion here if you want to.

                Annoying-Cat thankyou for your input. i will check out the project settings as well. I too am going to use a rigid body as a "player extension" kind of like a moving shield. So allowing player impulses to move the object with them, but not effect how it collides with different "material". I wasn't trying to hijack your post either... my apologies. As one more side note: the handwriting is sick! i appreciate the discipline. Cant wait to see how the game turns out since you have the "eye" for detail.

                    REVBENT Being unable to set velocities is really limiting when working with rigidbodies, so, when it comes to manipulating them, I find PID Controllers really useful. I use one for my horizontal movement and plan to use another for airborne rotational control as well. You can check out this video for a good implementation of the principle. The Joint2D nodes could also be helpful for keeping the shield with your player, if you so want.
                    I don't mind helping, but I'm not really the most capable yet; that was just a heads up ^^ And, thank you for the kind words :​) Cursive is the norm for us felines, for our hands aren't as elegant with the pen as those of humans, though they are quick nonetheless >:​)
                    On the other hand, programming is more of an incipient hobby for me than anything, so I will use the converse philosophy for my game. But if you don't mind, I could send you a minimum viable product, hopefully by this month, if can finish that before my school reopens :​)

                    • xyz replied to this.

                        Annoying-Cat I'd almost never use a rigid body for a controllable character. It's just too unpredictable and unwieldy to be finely tuned into wanted player experience. It may work for certain types of games but in general it's better to go with kinematic motion.

                            id certainly like to check out the project, and if nothing else could offer the satisfaction of a "good job". You seem like a creative "creature" for sure, and have a good math understanding, so I'm very interested in how you apply those skills. Typically creativity and logic elude each other in design, but paired with the ability to program in another "universe", the possibilities become endless.
                            Also, the video was super educational! i had a grasp of the concepts but never checked into the applied math/logic. i will play with that regardless if i can currently apply this.
                            I don't know how well this would work/could work... but possibly an interesting theory to apply:
                            encapsulate a player body into a rigid body and allow its impulses to "apply" velocity to each respective location you want impulse. i don't know how to actually integrate this? maybe updating position of player body so it doesn't collide while its just moving along, then making a func that ads the movement via move slide/collide allowing for it to apply localized impulse. Maybe this is just NOT allowed in godot, but it makes sense to me "logically"

                              xyz
                              I agree that kinematic bodies offer way more precise control over design choices about player movement, but in the case of my game, I really don't like the prospect of computing collisions that involve rotation, because I don't know enough physics to believe myself capable doing so accurately. I may be being a bit naïve, but I think manipulating rigidbodies to follow player input isn't that difficult of a task for me to execute (plus it will be a good exercise for learning the engine :​D ... I'm gonna regret this aren't I ^_^;​) But yes, Godot's existing CharacterBody2D seems to be more than enough to serve the purposes of most platformers, which in general don't involve rotating hitboxes.

                                REVBENT Aww, thank you ^///^ I've always liked how videogames can bring together so many elements of design together so coherently in a constructive way. For this reason, I believe that gamedev is one of the most interdisciplinary fields there can be. I'm glad you liked the video. Typically, you don't need things to be so complicated when working with kinematic bodies, but they can only emulate reality so well.
                                Anyway, I don't really understand your 'theory' :/ Character Bodies seem to me as intended to be used in very different situations than Rigid Bodies, so I don't really get why you would want to 'encapsulate' one within another. Though I am making a platformer of sorts, the implementation of certain mechanics have to be very different than if I were to use a kinematic approach. I guess, in my case, moving the player with moving platforms, that aren't animated by forces, could be an analogue to what you are trying to describe (?) I think subtracting the velocity of the platform from the player's speed that is inputted into the PID and the target speed that the player has to match might have the intended result, though I haven't tested it yet...