Ability to disable double-jump?

[Eccentricity]

In creating an "escape" style map for Fortress Forever I've run into a problem that severely and negatively impacts cooperative gameplay.

The double-jump ability lets players use doorways, railings, or even other players as a launchpad to reach areas that should normally be inaccessible. Creating cooperative puzzles that require more than one or two people can be circumvented, and difficult sections can be skipped entirely.

Is there a way for mappers to disable this ability within a map through an entity or LUA script, or a combination of both? Perhaps even a server or client variable that can be toggled? If the ability isn't exposed to modification through the LUA system, could it perhaps be implemented?

I have no qualms with double-jump being in "normal" FF play; rather only its impact on the old cooperative puzzle maps that were so popular in TFCs heyday. Using double-jump either negates the use of more than 1 or 2 players, or prevents a mapper from implementing simple design aesthetics (as they may be heavily exploited).

The ability to control double-jump's usage would be incredibly beneficial towards seeing a resurgence of escape-style maps in Fortress Forever.

[CHURCHMOUTH]

damn i never thought about that before, trimping kinda fucks over escape maps
unless you make an escape map that u need to use trimps in order to complete

[Hawk Eye]

Maybe there's a LUA callback for doublejump.. or perhaps you could restrict vertical speed on jump.

[Eccentricity]

Originally Posted by CHURCHMOUTH

damn i never thought about that before, trimping kinda fucks over escape maps
unless you make an escape map that u need to use trimps in order to complete

Though I'm not against creating escape maps that take advantage of certain movement mechanics (bhopping, trimping, longjumping, etc.) some are definitely more powerful than others; as they can be usable literally anywhere versus others that can only be used on certain terrain.

The problem introduces itself when the movement mechanic is too powerful (ie. it could be used almost anywhere). Double-jumping is one of those mechanics; as any surface that reduces a player's jump height, or is low enough to jump on becomes a platform for launching one's self much higher than can be reached with 1 or 2 players alone.

Though conscious mapping can reduce such occurances, it would lead to creating puzzles for the sake of their being puzzles - not puzzles that fit within a theme or setting; aesthetics would need to take a rather large backseat to the gameplay, since anything added for visual appeal could be used to exploit any carefully laid-out puzzles.

Even still, if a map author created a bare room with nothing in it in order to prevent double-jumping where one shouldn't - there is still a second player that can be used in place of a natural platform, thwarting the efforts described above.

Originally Posted by Hawk Eye

Maybe there's a LUA callback for doublejump.. or perhaps you could restrict vertical speed on jump.

Perhaps there is a callback, but I am unaware of it. Simply being able to toggle whether a mapper wants double-jump on or off in a map would be ideal.

[moosh]

Squeek should have some info on this...

[Eccentricity]

If I were to post this in the "public to team communication" forum, might I then get a response?

[moosh]

Go for it.

[Hawk Eye]

So I'm reading through player functions, and there seems to be no way to get the velocity of a player. There also isn't an onJump function, considering how many times that'd be called in a match, it's probably a good thing. I also couldn't find documentation of a doubleJump callback/function.

Since you can't get the velocity, you could theoretically do some sort of work around where you're constantly checking the position of the players, and generating a velocity based off the time between checks, but even then you can't just effect a player's velocity (that I can find).

Maybe squeek or pon would be able to tell you, but I can't find anything that says it's possible.

[squeek.]

Some answers:

• Currently, you can't disable double jumping in a straightforward manner. This, as far as I know, isn't exactly intentional, but it might not be a good idea to implement natively because we want a certain amount of consistency between servers. Completely disabling a movement mechanic changes the gameplay pretty drastically. It's not entirely out of the question, but it's also not going to be jumping up to the top of any priority lists without quite a bit of discussion.
• Adding a player_ondoublejump() or player_onjump() callback would be too expensive as they would get called very, very often.
• You can get player velocity using player:GetVelocity() (returns a vector) and set it using player:SetVelocity( Vector ). It'd take some creative coding, but it might be possible to disable double jumping in some fashion using them.

[Eccentricity]

Originally Posted by squeek.

Some answers:

• Currently, you can't disable double jumping in a straightforward manner. This, as far as I know, isn't exactly intentional, but it might not be a good idea to implement natively because we want a certain amount of consistency between servers. Completely disabling a movement mechanic changes the gameplay pretty drastically. It's not entirely out of the question, but it's also not going to be jumping up to the top of any priority lists without quite a bit of discussion.
• Adding a player_ondoublejump() or player_onjump() callback would be too expensive as they would get called very, very often.
• You can get player velocity using player:GetVelocity() (returns a vector) and set it using player:SetVelocity( Vector ). It'd take some creative coding, but it might be possible to disable double jumping in some fashion using them.

Thanks for the reply!

I completely understand wanting to maintain consistency - things could get rather muddled up if players were constantly guessing the game rules from map to map.

I also understand why an onjump callback would be rather detrimental to performance, considering it's aforementioned abundance in standard play.

As for get/setvelocity, how would I use this to essentially prevent a doublejump's height? The main issue I've discovered (with regards to escape style mechanics) is that the height that can be reached with a doublejump is so great that it makes some puzzles either tough to exploit-proof, or hard to design aesthetics around.

The speed at which players move isn't as much a concern; which is why I'm curious as to how a velocity modifier could help in effectively reducing doublejump height, unless of course one can also tell which direction a player is moving in addition to their velocity.

Could you (or someone else more fluent in LUA than I) perhaps lay out a simple way of controlling velocity in such a manner? Or should I ask this question in the LUA help section?

[squeek.]

GetVelocity() returns a 3d vector, which has x, y, and z components. The z component is the up/down direction of the velocity. As a note, horizontal speed (the speed shown on the hud_speedometer) is calculated by getting the length of only the x and y components of the velocity vector.

Here is a snippet that will stop up velocity entirely if the player is above a certain z velocity threshold while inside the trigger named no_doublejump:

function CapZVelocity( player, cap )
  -- get velocity
  local velocity = player:GetVelocity()

  -- if z velocity is too large, stop z velocity entirely
  if velocity.z > cap then
    player:SetVelocity( Vector( velocity.x, velocity.y, 0 ) )
  end
end

no_doublejump = trigger_ff_script:new({ })

function no_doublejump:ontrigger( trigger_entity )
  if IsPlayer( trigger_entity ) then
    local player = CastToPlayer( trigger_entity )
    CapZVelocity( player, 400 )
  end
end

I didn't test it, so hopefully it works.

[Eccentricity]

Hello again, squeek.

EDIT: It appears lowering the number to 200 created an appreciable effect; players can now doublejump wherever they please, though they get no height benefit. I'm assuming this is happening due to the integer being too low for a standard jump, thus causing a sudden drop, allowing a (height-deprived) doublejump to take place.

It looks like I just need to tweak the value to somewhere between 400 and 200. I'll let you know if I have any other questions! Thank you very much for your help!

EDIT 2: It looks like anything under 300 causes players to prematurely get capped in their Z velocity, though anything over 300 tends to let a doublejump slip through from time to time.

I have discovered only 2 anomalies with capping jump height in this fashion. The first and mostly inconsequential oddity I mentioned earlier, is that players can "doublejump" almost indefinitely as if perpetually under a platform (the "platform" being the Z cap), provided they continuously hold jump.

The second oddity which may or may not present a problem has to do with falling or flying; if a player falls from a great height, this method might make them stop several times in midair before reaching ground. Or conversely, it might periodically stop players traveling upwards in a fast-moving elevator.

I will of course test both situations above, though the best remedy would be to simply not cover such areas in a no_doublejump entity, as doublejumping in such situations wouldn't be beneficial.

I thank you again for your help, and greatly appreciate it.

ORIGINAL MESSAGE FOLLOWS;

I gave your LUA a spin, though it doesn't seem to prevent the tremendous height of the second jump in a double jump.

My method to test the jump height was to create a platform in the air that is slightly higher than standing player height, go underneath it while holding jump, and then slide out from under it. The forced reduction in jump height from the platform creates ideal circumstances to allow the player to doublejump once they're clear of the platform.

I'm assuming the "400" in your script is velocity of the player moving on the Z plane. Would reducing this number perhaps allow this to work, or is there something else that might need to be appended? Also, I assume the trigger_ff_script itself doesn't need to do anything but have the appropriate name.

I really appreciate you taking the time to lend me a hand with the LUA scripting, I'm sure it isn't easy trying to "break" a designed mechanic.

[squeek.]

Yeah, change the 400 to something that makes more sense. That was just an arbitrary value I chose.

You can put a

ConsoleToAll( "[SCRIPT] Z Velocity: "..velocity.z )

in CapZVelocity to see what the z velocities are while you play, but it'll spam the console quite a bit.

EDIT: Another method for capping would be to do:

player:SetVelocity( Vector( velocity.x, velocity.y, cap ) )

which would set your z velocity to the cap speed instead of stopping it entirely.

[Eccentricity]

EDIT: Whoops, didn't read your code before replying, you are basically saying I can change 0 to whatever integer I like. Thanks!