Movement clearly bugged, or feature?
asker
Join Date: 2012-01-29 Member: 142449Members, WC 2013 - Silver
Hi!
Long time pre-orderer here, just got into beta testing.
I just have a question regarding the movement. The forward / backward momentum gained from pressing the movement keys seems to be a vector perpendicular to the y-angle of my aim. This results in the forward/backward movement speed being slower the more sloped my aim is, until being completely nullified if I aim straight up or down.
It seems such an easily spotted mistake that it should've been caught early in the engine development cycle, unless it was the intended behaviour. It's incredibly annoying, coming from the HL1 mod which features incredibly solid and smooth controls.
Edit:
This happens only when you move forward (or backward) and strafe at the same time. The strafe speed remains constant but the forward momentum depends on your aim slope.
So, bug or feature?
Long time pre-orderer here, just got into beta testing.
I just have a question regarding the movement. The forward / backward momentum gained from pressing the movement keys seems to be a vector perpendicular to the y-angle of my aim. This results in the forward/backward movement speed being slower the more sloped my aim is, until being completely nullified if I aim straight up or down.
It seems such an easily spotted mistake that it should've been caught early in the engine development cycle, unless it was the intended behaviour. It's incredibly annoying, coming from the HL1 mod which features incredibly solid and smooth controls.
Edit:
This happens only when you move forward (or backward) and strafe at the same time. The strafe speed remains constant but the forward momentum depends on your aim slope.
So, bug or feature?
Comments
And of course the increased downwards momentum from crouching while jumping.
Actually, the total speed seems to remains constant, but the direction of movement depends on the vertical aim.
Is this for marines? Skulks? Or everyone?
I have a feeling it has something to do with this line
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> local moveVelocity = viewCoords:TransformVector( move ) * accel<!--c2--></div><!--ec2-->
or at least the function it is found in
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->function Player:ComputeForwardVelocity(input)<!--c2--></div><!--ec2-->
or input.move itself:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> local move = GetNormalizedVector(input.move)<!--c2--></div><!--ec2-->
but I don't really know what TransformVector does, or how input.move is expressed, so...
Edit: Oh right, I get what TransformVector does, it takes a vector (move) expressed in a reference frame (viewCoords), then transforms it so that it's expressed in the absolute frame (moveVelocity). Since the y-axis for viewCoords moves back as you pitch upward or moves forward as you pitch downward, it causes the x-z-component of moveVelocity to become less than 1.
Ignore Edit2.
<img src="http://i.imgur.com/KjY8B.png" border="0" class="linked-image" />
The solution is to create another frame of reference (referenceCoords) that rotates the player's viewCoords back so that the referenceCoords.yAxis lines up with the absolute yAxis, or else find another frame of reference that meets the same criteria: y-axis vertical-world-up, z-axis horizontal-player-forward, x-axis horizontal-player-right.
The problem that's occurring is that forward movement is being converted to upward/downward movement as you pitch up/down.
I could be wrong, though.
On a side-note, is it just me or is the forum clock late by about 3~4 minutes?
1) Hold forward and strafe left or right
2) Aim downwards or upwards slowly.
3) Notice how your forward speed is reduced all the way down to zero depending on your aim angle.
Being a competitive game, these movement kinks should really be ironed out to give the most precise and predictable movement.
On a related note, and this is more of a suggestion, holding forward+strafe and then jumping nullifies the side momentum. This might be intended, but it doesn't feel quite right. I think this happened after the movement was rebuilt to support Gold Source-like air control.
Edit: This thread is old and nowadays probably placed in the wrong sub-forum. Mods activate!
I've been playing this game for over 3 years now, and I've NEVER noticed that before! Bravo sir, I'll look into it.
EDIT: Alright, put a fix in to our testers. Might be seeing this in the next patch.
How I will be able to get on top of the digital totem in Terminal if this is "fixed"?
If anything it should be easier now.
It was a bug because it was basically trying to move in the direction you were looking... which sounds great until you're staring straight at the ground. What it should be doing (and is now, with the fix) is moving you in the direction you're looking but only taking the yaw into account.
Here's hoping this new fix doesn't mess with the alien movement, I'm guessing skollwallwalkin', lorkflappin and fadeblinkin'. They actually need this movement to work like this.
Yes. Onos needs leap. Fades need charge. Lerks need slide. Gorges need flight. Skulks needs blink.
Marines need a segway. If nobody else does an edit for this, I can later on.
Nah, it actually differentiates between movement that should stay on the ground and movement that can move vertically... I actually screwed up the fix the first time around by not realizing this, so I broke wall walking! XD Fixed moments later...
Well... We've got this...
RIP Pogostick.
Now we have to walk, like normal plebs. *sigh*
Please test this properly! Any negative change woulld be utterly devastating..
You can test it as well anytime you want using the public beta branch on steam.