Difference between revisions of "Talk:Movement:Jumping"
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | All of the old problems regarding jump height and duration have been fixed thanks to Mirv. | |
| − | + | ==New Areas of Discussion== | |
| + | How should we best penalise people who hold the jump key excessively? I.e. we need to make jump timing a non-mindless skill without making it so hard that people just resort to either scripting it or cheating (like TFC). | ||
| − | + | '''We can release the mod WITHOUT''' this stuff being implemented, as Q3 semi-pogo is a decent compromise as it is'''. This stuff is just extra and could potentially be cool. It might suck. We don't know. | |
| − | + | ===Ideas=== | |
| − | + | * Reduce air control if player holds jump for too long | |
| − | + | * Reduce jump timing accuracy if player holds jump for too long | |
| − | + | ||
| − | + | Problems with these ideas: | |
| + | Firstly, how would we tell how long a player has been in the air? | ||
| + | |||
| + | Example: Say we code it so that a player cannot hold jump for longer than half of the time they're in the air, or over 0.5 seconds. | ||
| + | They both sound reasonable, however.. say a player is making two jumps in quick succession (jump at the base of a ramp, then into the ramp surface). The player might be airborne for 0.2 seconds. Under the first model, the player would have to time his jump to an accuracy level of 0.1 seconds which is not possible to do consistently. Under the second model it's ok, but there's probably other situations where this may cause problems. | ||
| + | |||
| + | Can we even store / access the time a player has been airborne? | ||
| + | If we can.. | ||
| + | |||
| + | ===Another Idea=== | ||
| + | Have two cases. Each rule is run depending on the circumstances. | ||
| + | |||
| + | The first case is in effect when the jump timing is impossibly tight, so that if a player's time spent between jumps (i.e. airborne for 0.'''x''' seconds) is very small, no penalty is brought against the player regardless of how long they held jump. Example: The 0.2 second case. 0.2 seconds is way too small a time to have any kind of accuracy, so if the player holds jump for 0.15 seconds of that 0.2 second period, we don't penalise for it. People aren't robots. | ||
| + | |||
| + | The second case is when the player is airborne for a decent period and has plenty of time to time their jump. Example, a regular jump. The player has 0.7 seconds in which to time the next jump, so we should perhaps penalise the player if, during the 0.7 seconds spent in the air, he holds jump for over 0.4 seconds of that. | ||
| + | |||
| + | ===What contributes towards the jump timing?=== | ||
| + | |||
| + | Old jump commands should be '''ignored''' as they are worthless anyway. I.e. if a player jumps and continues to hold jump without releasing the key and pressing it again, then don't count that +jump command towards the total time spent pre-jumping. Under semi-pogo rules, the player must release & press the jump key for each new jump. I.e. an 'old' jump press is useless, so it shouldn't penalise the player or count towards the time spent holding +jump between jumps. | ||
| + | |||
| + | Just some ideas. | ||
| + | -- [[User:Defrag|Defrag]] | ||
Latest revision as of 13:56, 15 February 2006
All of the old problems regarding jump height and duration have been fixed thanks to Mirv.
New Areas of Discussion
How should we best penalise people who hold the jump key excessively? I.e. we need to make jump timing a non-mindless skill without making it so hard that people just resort to either scripting it or cheating (like TFC).
We can release the mod WITHOUT this stuff being implemented, as Q3 semi-pogo is a decent compromise as it is. This stuff is just extra and could potentially be cool. It might suck. We don't know.
Ideas
- Reduce air control if player holds jump for too long
- Reduce jump timing accuracy if player holds jump for too long
Problems with these ideas: Firstly, how would we tell how long a player has been in the air?
Example: Say we code it so that a player cannot hold jump for longer than half of the time they're in the air, or over 0.5 seconds. They both sound reasonable, however.. say a player is making two jumps in quick succession (jump at the base of a ramp, then into the ramp surface). The player might be airborne for 0.2 seconds. Under the first model, the player would have to time his jump to an accuracy level of 0.1 seconds which is not possible to do consistently. Under the second model it's ok, but there's probably other situations where this may cause problems.
Can we even store / access the time a player has been airborne? If we can..
Another Idea
Have two cases. Each rule is run depending on the circumstances.
The first case is in effect when the jump timing is impossibly tight, so that if a player's time spent between jumps (i.e. airborne for 0.x seconds) is very small, no penalty is brought against the player regardless of how long they held jump. Example: The 0.2 second case. 0.2 seconds is way too small a time to have any kind of accuracy, so if the player holds jump for 0.15 seconds of that 0.2 second period, we don't penalise for it. People aren't robots.
The second case is when the player is airborne for a decent period and has plenty of time to time their jump. Example, a regular jump. The player has 0.7 seconds in which to time the next jump, so we should perhaps penalise the player if, during the 0.7 seconds spent in the air, he holds jump for over 0.4 seconds of that.
What contributes towards the jump timing?
Old jump commands should be ignored as they are worthless anyway. I.e. if a player jumps and continues to hold jump without releasing the key and pressing it again, then don't count that +jump command towards the total time spent pre-jumping. Under semi-pogo rules, the player must release & press the jump key for each new jump. I.e. an 'old' jump press is useless, so it shouldn't penalise the player or count towards the time spent holding +jump between jumps.
Just some ideas. -- Defrag
