Capping player momentum mid-air

I'm (still) screwing around with a fork of Eternity for my own purposes.

I disabled friction when you're in mid-air. Problem is, the player speeds up like crazy. What is a good method to cap the momentum without adversely affecting external influences such as a missile hitting the player?

On a related note, what formula should I use to determine the max speed the player can move when going forward when on the ground?

I think it's as if you launched the player into space - momentum never drops so the player drifts at a constant speed, or speeds up, but never slows down.You've got to subtract some constant from momentum (air friction). Nice cat. I like the single blink myself, maybe a little bit faster :)

One thing you could do is just put in an if statement somewhere to apply friction anyway if velocity is too high and then if it gets below the threshold the object will continue to drift without friction.

Could be like in physics with the concept of terminal velocity where objects exceeding a certain speed will slow down during a fall due to there being too much air friction.

Eruanna said:

One thing you could do is just put in an if statement somewhere to apply friction anyway if velocity is too high and then if it gets below the threshold the object will continue to drift without friction.

That's what I ended up doing anyhow.

I just recently decided to switch to using a fork of QZDoom instead of Eternity. It worked fine in Eternity, but not in QZDoom for some reason.

http://pastebin.com/RTEYJq4w

The check on line 4 is failing. I wonder why?

That's base ZDoom code (that QZDoom inherited) - so it might be better to ask Graf.

That being said, from what I know with manipulating objects in ZDoom's source code is there are a TON of if statements and just because it looks like a block of code is being executed doesn't mean it actually is - there might be a different block somewhere else in the code that's actually being executed instead, and there are instances where it is not obvious if a block of code is going to be executed in a given situation (especially considering the code is full of hacks and exceptions to cover all sorts of different situations and compatibility modes).

The best thing to do is to look for all instances of friction (I use grep -r to do this, but everyone has their favorite tools) to find out where it is being applied, and then apply your code to all of those instances.

More often than not, with ZDoom, there's at least 2 instances of the same code you are looking at, more or less copy-pasted from the one you are looking at (or the one you're looking at is the copy-pasted one - doesn't matter - still the same messy situaton :P).

Blastfrog said:

That's what I ended up doing anyhow.

I just recently decided to switch to using a fork of QZDoom instead of Eternity. It worked fine in Eternity, but not in QZDoom for some reason.

http://pastebin.com/RTEYJq4w

The check on line 4 is failing. I wonder why?

Your comment "or if travelling faster or equal to running speed while in midair" does seem to match what the if statement is checking. Should say ""or if travelling faster or equal to running speed IN MID-AIR OR NOT". Don't know how ZDoom handles the friction: is '* friction' proper? Maybe making it '* 0' would help debugging it.

Good luck.

How many times did you go back and forth between EE and ZDoom for that custom engine?

Gez said:

How many times did you go back and forth between EE and ZDoom for that custom engine?

Less than you'd think, actually. Maybe 2 or so times.

I've accepted that I'm not going to get what I need out of EE, I'm most likely going to stick to ZDoom-based at this point.