Random slope behavior

[GreenTeaSip]

compressed3.mp4

compressed.mp4

compressed2.mp4

In these examples, I am losing or maintaining speed when jumping up slopes. At higher speeds, I'm forced into a rampslide most of the time despite having space held. There is also randomness when jumping down slopes at no or very low speed.

I think the correct behavior would be to always lose horizontal speed the same way a trimp does. Also, having jump held when hitting a slope should always jump immediately instead of rampsliding with a delayed jump.

Sorry if I am misunderstanding something.

[YoYo178]

Thanks for pointing it out. I've noticed this as well (the ff_destroy slope specifically) but never really tried to figure out why that is. From what I can tell, it's been a bug since FF 2006.

[squeek502]

There are two issues here:

• The really high jump that occasionally happens is a bug where you trimp and double jump at the same time. This was not originally intended, but it was intentionally left unfixed since it is kinda cool and trimp maps were made that rely on it
• Sometimes when you are rampsliding while holding jump, you don't trimp. This is a 2013-specific bug that wasn't present in the 2006 version. I think it's probably related to what's described here

The fix for this in the old unfinished 2013 port was:

https://github.com/fortressforever/fortressforever-2013/blob/ae5b06cda37dc864b7b9245a6de72b4ecad50874/mp/src/game/shared/gamemovement.cpp#L4668-L4679

The fix in the current 2013 port is:

fortressforever-src/mp/src/game/shared/gamemovement.cpp

Lines 4911 to 4913 in cae6c63

	CFFPlayer* pFFPlayer = dynamic_cast<CFFPlayer*>(player);
	if (pFFPlayer->IsRampsliding() && pFFPlayer->m_nButtons & IN_JUMP)
	CategorizePosition();

IsRampsliding is not accurate/reliable enough for this use case (IIRC it was only intended for adding the spark effects while rampsliding, so it didn't need to be super accurate)

[BreakinBenny]

I wonder if this could require a LUA setting for restoring the "borked" double-jump+trimp specifically for the obstacle courses…

[squeek502]

If you're curious, here's what allows the double jump + trimp (noted when working on the unfinished 2013 port):

https://github.com/fortressforever/fortressforever-2013/blob/ae5b06cda37dc864b7b9245a6de72b4ecad50874/mp/src/game/shared/ff/ff_sh_gamemovement.cpp#L138-L139

(I personally don't think removing it would have much benefit, though; FF is built on things that were originally unintended)

[YoYo178]

This might have been fixed with edc1cf5 (need confirmation on this)

[GreenTeaSip]

This might have been fixed with edc1cf5 (need confirmation on this)

All of the issues are still present. The simultaneous dj+trimp is easier to reproduce at >600ups.

[squeek502]

All of the issues are still present.

There hasn't been a patch, so you'd need to compile from source to test it.

The simultaneous dj+trimp is easier to reproduce at >600ups.

I'd like to reiterate that I don't think this should be fixed. It's basically an intentional feature at this point, and fixing it would have gameplay consequences outside of trimp maps (e.g. DJ+trimp from destroy button ramp up to the cap point uses this bug).

[GreenTeaSip]

All of the issues are still present.

There hasn't been a patch, so you'd need to compile from source to test it.

The simultaneous dj+trimp is easier to reproduce at >600ups.

I'd like to reiterate that I don't think this should be fixed. It's basically an intentional feature at this point, and fixing it would have gameplay consequences outside of trimp maps (e.g. DJ+trimp from destroy button ramp up to the cap point uses this bug).

I compiled and tested from the dev branch.
If it's left in, it still shouldn't be random if it occurs or not.