Some Major Movement Issues

[FDR]

So I was working on a competitive duel game with some mates and I've noticed a few quirks/bugs regarding the engine's movement physics...

1. When you attempt to jump while ducking it merely makes you stand. This largely hinders a lot of mobility of the player (such as being able to crouch jump through a hole, or similar environments).

I tried fixing this several ways, one of which was using this code in my UTPlayerController extension named UDNPlayerController:

if (Pawn != None && Pawn.bIsCrouched == True)
	{
	Pawn.bCanJump = True;
	Pawn.bJumpCapable = True;
	Pawn.DoJump(bUpdating);
	}

Sadly... no such luck with that or many variations.


2. At least from me and my mates experience typeing walk in console causes a brief 'bump' in the player's movement. Like a type of mini-jump. Also if we spam our crouch key it causes mini-hops on occasion as well.


So I was hopeing if anyone might know how to remedy these 2 situations?

On the non-bug related side and personal preference side of the project from what we can tell, bunnyhopping and its effectiveness in the engine seems limmited if at all existent.
The same goes to strafe jumping, it doesn't seem to actually benefit the player's movement speed when performing a strafe jump.
In most FPS games both bunnyhopping and strafeing do lead to movement speeds increasing (even if they WERE originally considered bugs long ago they are widely accepted now).
Is there anyway I can re-invent these mechanics?

It'd also be useful to know how to code a 'counter' that would display your movement speed in units in real time so that I could know if bunnyhopping and strafeing was actually working for debugging purposes.

Any and all help is appreciated guys! Take care.

[meowcat]

Here is some input from my experience on UT2k4, it should be at least partially applicable to your goals here in UT3 too.
1. The native code automatically reset's the pawn's size every time the pawn's physics transitions from PHYS_Walking to PHYS_Falling. To get crouch jumping to work I edited the PlayerController PlayerWalking state ProcessMove function to NOT check for PHYS_Falling (the CheckJumpOrDuck function needs to be modified in your case). In my case I wanted the pawn to crouch EVERY time the player jumped, so I manually set the collision size to the crouched size (plus 0.5 for the height!) in the pawn DoJump function. I then modified the Landed event to check to see if the player's collision height was equal to the crouched collision height plus 0.5, and if so, properly reset the pawn's collision height (and in my mod's case a few other variables too...). You can probably modify the CheckJumpOrDuck function to look for crouching when falling, and then use the ShouldCrouch function to manually set the collision size when Physics==PHYS_Falling.

2. The native code kills/zeroes out any "momentum" you may have the very first tick that your pawn's physics change from PHYS_Falling to PHYS_Walking. Also, the UEngine clamps the velocity vector (no matter which direction) to the maximum speed (ground, air or water) unlike some other engines which simply clamped the velocity vector on each of the player's axis (but allowed a 1.414*maxspeed when combining strafing with moving forward or backwards). You could try storing the air momentum in a variable each tick while the pawn's physics is phys_falling, and then re-apply it (addVelocity ?) as soon as the physics changes back from phys_walking to phys_falling provided not too much time had been spent on the ground.

3. I don;t know how to do this UT3, but for my UT2k4 mod I simply spawned a HUDOverlay from a mutator that just drew my overall velcoity vector magnitude as text on my screen (among other debug info not normally shownh via the 'showdebug' console command).

[evr]

On the non-bug related side and personal preference side of the project from what we can tell, bunnyhopping and its effectiveness in the engine seems limmited if at all existent.
The same goes to strafe jumping, it doesn't seem to actually benefit the player's movement speed when performing a strafe jump.
In most FPS games both bunnyhopping and strafeing do lead to movement speeds increasing (even if they WERE originally considered bugs long ago they are widely accepted now).
Is there anyway I can re-invent these mechanics?

It'd also be useful to know how to code a 'counter' that would display your movement speed in units in real time so that I could know if bunnyhopping and strafeing was actually working for debugging purposes.

Any and all help is appreciated guys! Take care.

Sure, I'll give you a few pointers.

I'll start with the "counter" thing you want to implement because that is the easiest part. What you want to do is override the function DisplayDebug in an extended Pawn class which you will have to create. Just have it do something like:

Canvas.DrawText("Velocity: "$VSize2D(Velocity));

As for the strafe jumping, this is tricky but doable. There are two things preventing you from implementing strafe jumping.

The first thing the engine does is to always clamp the Pawn's velocity to its GroundSpeed. As long as the Pawn's GroundSpeed variable is set to X, the Pawn can never have a velocity higher than X on the ground.

The second thing is that every time a Pawn lands, its 2D-velocity is set to its previous 2D-velocity multiplied by 0.1. So if a Pawn had a 2D-velocity of 440 right before landing, its new velocity will be 44.

Once you have fixed these two things, you will have to actually implement strafe jumping (or the bug, rather, that enables someone to strafe jump).

[unrealloco]

why not look at the matrix moves mutator for ut3