Download here

Here are four (formerly nine) particular places where I think the ways rabbits move around in JJ2 could be better. In this build, they are only available in local games. You cannot join multiplayer servers and use these physics changes to your (dis)advantage compared to people who are not running this experimental build. Part of giving feedback on these changes is saying under what circumstances you think they should or should not be available, which can include "always" and "never" at the extremes. You can give one answer for some and a different answer for others. You can also report that the changes aren't working as intended and have introduced other bugs to the game. Unless stated otherwise, none of these changes will be available in speedrun mode.

In an arbitrary order:

1. Made optional in 5.11
2. implemented in 5.11
3. Implemented in 5.12
4. Made optional in 5.12
5. If you do a double jump, land on the ground, and then walk off a cliff, you can do another double jump in the air while falling, even though you hadn't pressed the jump key again since your last double jump.
6. When landing from a buttstomp, you always show the dedicated animation for landing from a buttstomp, rather than randomly bouncing up into the air sometimes.
7. implemented in 5.11
8. You can double jump (or start copter earing) just by pressing jump once while falling, without having to double-tap jump or hold jump a long time before the final press. (Subject of this thread.)
9. The timing for being able to initiate a special move by pressing jump while holding down is made much more generous, not requiring you to come to a stop and hold down for several ticks.

The sticking to slopes fix is buggy with speed destruct scenery, increasing the speed you can plummet downwards in survivor28.

I ardently support all of these changes except 1 (faster poles), which I dislike, and 4 (sticking to slopes) which I skeptically support. So my answer is "never" for 1 and "always" for the rest. Details:

1 (faster poles). This is the only change here that I just don't like. Levels with poles - the levels good enough to actually get played, anyway - usually use them because you stick to them for a second, or are at least designed with the delay in mind. The original delay also feels more appropriate for the animation and sound in my opinion.
Furthermore, any level designer or server admin who does want faster poles can already get them with a few lines of Angelscript, no?

2 (one way sidekick). Yay bug fixed. I can't think of any level that relies on the current behavior, or any other downside.

3 (running up slopes against walls). Yay bug fixed. While the current behavior could be useful in levels with bouncer or electroblaster ammo, it's not really interesting, and I don't think any level uses it intentionally.
If you want to be really paranoid about it, one alternative would be to keep the player getting stuck in the running position, but make jumping work. It wouldn't make much physics sense anymore, but would avoid breaking any obscure level that does rely on this behavior.

4 (sticking to slopes). I support fixing this bug, but there are also strong cases against it. It feels weird to have this bug gone as a long-time player, and in this construction of tiles, crossing the gap is easier with the glitch around. One can also imagine sucker tube/pole/spring constructions that are broken by this fix, but I doubt any such system is used in a competition-relevant level.

5 and 8 (double jump/copter ears fix). In contrast to sticking to slopes, I got used to this change immediately, despite 24 years of vanilla Spaz double jump muscle memory. It's just so obviously the natural way for these things to work, and while we may all be used to working with the current behavior, it's an awful learning curve for new players.
Yeah, it makes Spaz slightly stronger, but we adopted fireball, seeker bug fixes, other things that change multiplayer balance, it's fine. Can always give some other advantage to Jazz and Lori if needed.
and I've definitely seen a hundred of us 10+ year players complain that the game "ate my double jump" in Survivor so let's not act too high and mighty

6 (buttstomp bounce fix). Yay bug fixed, nothing to complain about here. I was sure the fix would break survivor28 but I tested it and it didn't!

9 (easier special moves). Fantastic change, improves flow when playing as Jazz and it's a nice increase to the viability of special moves in multiplayer.

I think the faster poles should be a toggle, as I also think certain levels had that delay in mind (specifically I thought of enemies that follow you like bugs and float lizards and how they might be affected).
As for the double jump, I was certain muscle memory would screw me only to be pleasantly surprised when there was no adjustment period at all - I got the hang of it immediately.
Don't really have opinions on the rest.

Originally Posted by Violet CLM

The time spent spinning around hpole/vpole events is reduced (from a second to roughly a third of a second). The amount of speed gained from the pole remains unchanged.

When I read this I thought I would complain, but I think this is a surprisingly positive change in most contexts. It feels unnaturally fast so I would prefer a halfway point compromise but I do like this and can't name a level it would ruin.

Originally Posted by Violet CLM

If you do a double jump, land on the ground, and then walk off a cliff, you can do another double jump in the air while falling, even though you hadn't pressed the jump key again since your last double jump.

This is a buff. It should be disallowed in tests (I believe I have myself made a test level or two whose design relies in a major way on the current behavior) but aside from that I don't actually have a big issue with it.

Originally Posted by Violet CLM

When landing from a buttstomp, you always show the dedicated animation for landing from a buttstomp, rather than randomly bouncing up into the air sometimes.

This should be disabled in tests, as very many of them rely on the current behavior and are impossible to complete in this build. I don't think it has significant impact outside of them.

Originally Posted by Violet CLM

You can double jump (or start copter earing) just by pressing jump once while falling, without having to double-tap jump or hold jump a long time before the final press. (Subject of this thread.)

As I mentioned before, this makes the game really hard to play for me, and despite that is a major buff to Spaz in general. I constantly double jump when I don't want to, there are certain jumps that this change makes outright impossible (encountered in actual test levels in the wild), and many more jumps that used to be impossible that this enables. This should be disabled in tests and should also have a client-side switch at minimum.

Originally Posted by Violet CLM

The timing for being able to initiate a special move by pressing jump while holding down is made much more generous, not requiring you to come to a stop and hold down for several ticks.

I didn't think I'd complain about this but I do. I hate this. I unintentionally performed a sidekick more times than I could count when running this build - when trying to quickly stop my momentum by buttstomping or when trying to buttstomp a crate. It also seemed to weirdly let me initiate a sidekick slightly off the ground on one occasion? I constantly use this set of inputs to buttstomp and the reduced delay on sidekick screws me over, albeit somewhat randomly. I want to say this should be scrapped wholesale as I personally see no point in changing the current behavior, but if not, it should have a client-side switch and possibly be disabled in tests.

Everything else looks good aside from the issues already raised.

I think 1 is too extreme of a change, though the spin time can probably be decreased by a smaller amount. I like the other changes mostly, though I've only tested them in Single Player (since that's what I mostly play). The 'running down slopes' change feels a bit weird and I'm not entirely sure I like it but in levels with big slopes that clearly were intended to be run down (looking at you, Easter) this does clearly improve things.

However, given the earlier response to a vaguely similar request I wonder whether these changes would not be better implemented as a mutator, assuming we can at some point load mutators in single player easily too? I think the position articulated in that thread ("JJ2+ will not itself rebalance character abilities") is a healthy one and some of the changes here do seem to go in another direction.

tl;dr
1 - Tone it down, then probably OK
2, 3 - OK
4 - Probably OK, though like minmay I have some lingering doubts
5, 6, 8, 9 - OK for the part of the game I play, but I think these may be too controversial to change across the board
7 - I don't 100% understand this one but it seems fine?

Originally Posted by Stijn

However, given the earlier response to a vaguely similar request I wonder whether these changes would not be better implemented as a mutator, assuming we can at some point load mutators in single player easily too? I think the position articulated in that thread ("JJ2+ will not itself rebalance character abilities") is a healthy one and some of the changes here do seem to go in another direction.

I haven't tried for any of them, but I have my doubts whether 2, 4, 7, and 8 in particular could be implemented as mutators. Even if they can, I don't like the model of people not knowing whether any number of things will work one way or another, invisibly, at someone else's random whim, until they join a random server and try them out.

I think these may be too controversial to change across the board

Finding out whether they would be controversial is the function of this thread

This is my feedback based on a Turbo playthrough from Dungeon Dilemma to Bad Pitt using Spaz. My thoughts are purely about the Single Player experience.

1. Bad change, or at least it's way too fast. Gives you very little time to think your next move. Also, some SP levels would have to suffer from this (such as Blacky's "A Nightmare Before Christmas" with its poles segment).
2. Sure, it's a bug fix.
3. Also good. A bit unrelated but this would be nice for the Queen boss as well, as to not build momentum while running into her.
4. Very happy with this change, I can't think of any levels that could be negatively affected by this. It makes playing TSF less frustrating.
5. I haven't noticed it. No idea.
6. Fine change, one less bug out there.
7. Not noticeable so I suppose it's ok?
8. I really like this change, it feels a little weird at first but it's pleasant once you get used to it. It would be even better if this was a toggleable feature though.
9. I'm not a fan of this change, I sometimes found myself performing special attacks when I wasn't intending to.

I like 1, but then again I always despised poles so breezing through them is fun to me. I can't be the only one who never liked poles, right?

5 feels fantastic.

My take on poles is there are surely some levels that effectively use them as traps, but that doesn't feel fun and it's certainly not their intended function in the game. They're supposed to be things you use to gain speed! It sucks to see a pole and think "oh, I want to avoid that."

Originally Posted by Violet CLM

My take on poles is there are surely some levels that effectively use them as traps, but that doesn't feel fun

That's not your call to change that though...

No, and that's why this is a public thread, to see what people think.

Update: #1 (poles) has been rejected as a universal change and is now available in 5.11 as an event parameter instead. #2 (one way slopes) and #7 (vines and h-springs) have been implemented in 5.11. All others remain up for discussion.

I've updated the build to be based on 5.11 now, just for convenience.

Initially I was against changing the core physics of our beloved rabbit game, but I changed my mind. I hope all of this gets implemented!

If you really think about it these changes are for the better and the old mechanics aren't used for anything remarkable, they are annoying all the time.

The consensus with #4 (sticking to downhill slopes) seems to be that it usually feels good but it's possible there are a handful of levels (although I don't think anyone has identified any?) where it would go poorly. What about a jjPlayersStickToSlopes property, set to true at the start of every level, which that handful of levels could be edited to set to false? Similar to how This Level is Untitled has a script now to make it use vanilla-like copter code?

(assuming the Speed Destruct Scenery interaction gets fixed, of course.)

Originally Posted by Violet CLM

The consensus with #4 (sticking to downhill slopes) seems to be that it usually feels good but it's possible there are a handful of levels (although I don't think anyone has identified any?) where it would go poorly. What about a jjPlayersStickToSlopes property, set to true at the start of every level, which that handful of levels could be edited to set to false? Similar to how This Level is Untitled has a script now to make it use vanilla-like copter code?

(assuming the Speed Destruct Scenery interaction gets fixed, of course.)

I support this idea.

Finally got around to do some more testing:

1. Great
2. Great
3. Great
4. Good on paper, but still breaks some sucker tubes in levels without a floor. Last time I checked Nature's plot of land by Ragnarok, and the exit sucker tube throws you into a floor below. Hopefully fixed in 5.13.
5.Great
6. Great
7. I can't find notes on what 7 used to be, but I guess it's fine.
8. Great change, although in one use case i would like it to be a bit less generous. When running off a platform and edging a jump, it's bad when you miss the jump, but then also immediatly waste your doublejump because you missed it. It feels like a double punishment for trying and missing the jump from an edge and can seriously mess up your trajectory. I think if you run of an edge, there must be like 1 or 2 frames where pressing jump does nothing. Same issue goes for immediatly using copter ears off a ledge instead of jumping.
9. This felt bad and strays too far from game physics. Gives too much unnecessary powe to special moves. Also allows spaz to chain sidekicks within 0 frames. Trying to wallclimb with /quirks on makes you unintentionally special move. Jumping just high enough to buttstomp on a platform makes you uninentionally special move. Jumping needs to take priority a few frames when sliding or landing. I'm in favour of not introducing this at all, not even as a toggle, for jj2 consistency in behavior.

Originally Posted by FawFul

4. Good on paper, but still breaks some sucker tubes in levels without a floor. Last time I checked Nature's plot of land by Ragnarok, and the exit sucker tube throws you into a floor below. Hopefully fixed in 5.13.

Please see this thread for continued slope detection revisions

Hello. I have given the new build a go.

It is my opinion that #5 and #8 (double jump fixes) are insanely good. I only tested on single player but I don't think it gives any edge on competitive play, top players already live and breathe the old behaviour anyway. For me this has always been the most painful part of JJ2.

I think that it would be amazing to publish these two (especially #8) in in a normal release. It will make singleplayer and multiplayer games more enjoyable for everyone.

#6 (buttstomp fix) feels good, doesn't break anything. I think it should be implemented.

#9 (easier special move) is very nice for Jazz, makes him feel more lively and closer to Spaz.

I wasn't aware of this public test build at all until today, and holy shit.... this fixes soooo many grievances I had with the jumping controls going back years!

I play tests a lot, so many of the issues related to double jump availability and timing, as well as the completely random nature of buttstomp recovery, hinder the experience a lot.

#5, #6 and ESPECIALLY #8 are absolute godsends in terms of making the movement feel good and consistent. Not having to worry about jump button buffering when doing short hops, or trying to time copterear double-taps gives so much added precision to the movement that I honestly have a hard time going back. Seriously, why is this still not in the mainline builds?! Consider adding this as a toggle for the next monthly update, please!

#9 definitely feels powerful, but is arguably a bit too lenient. A few bugs I encountered are that it's possible to chain the Spaz sidespecial just by holding the jump button after doing the first one for as long as you don't leave the ground, and it's possible to do all the sidespecials *after* jumping for a few frames if you jump from an entity (like a morph monitor, for example). This one I can live without, but it could be implemented in a way that only allows you to do it with a low velocity threshold (no higher than the regular walk speed, I suppose).

Overall, very good changes for the jumping controls. Get them into mainline!

Seeing this again, I want to elaborate on #8 further.

I think a less controversial way to implement this is to think of it as a doublejump reset fix. Avoid 3 having to jump 3 or more times for a single airtime doublejump (jump, release, jump, release, jump again close to pressing doublejump, release, doublejump scenario). What the players not want is to instantly doublejump off a ledge.

The rule is simple: If you haven't used a spring or jumped off a floor, you haven't used your jump, so you have to waste that jump first, and then doublejump, as how it is. But what this could fix is having to press jumps while falling to reset your doublejump and #5 where you don't regain your doublejump when landing. So focus on making the second press to be always be a doublejump with springs being an 'autojump' that is the only odd thing out. This keeps everything as close to 'normal' as possible.

So in conclusion: 1st press: Waste the jump (or spring) or press jump once after running off a ledge 2nd press: always a doublejump (unless it was a spring). 3rd press: Never relevant. Rename the whole change to "Generous doublejump reset" instead of advertising for a double jump fix.