Suggestions

I didn't mention that before, as the previous post was only a bug report, since they for some reason belong in suggestions...?
...You're still doing it.

What you're suggesting is to change a core gameplay mechanic so that you have an easier time playing the game. This is not a bug report.


The way SRB2 works, and how it mimics the classic Sonic games is that if you're jumping and have (sufficient) upwards momentum, and you let go of the jump button, this causes your momentum to drop. (In practice, I believe SRB2 halves your momentum while the original games set it to a fixed value.) This mechanic exists to give you control over your jump height: the sooner you let go of the button, the quicker the momentum cap kicks in and the shorter your jump becomes.

However, the way this mechanic is implemented also means that if you jump on something from a great height and hold the jump button while you bounce back up, you will rise all the way back to your original height (plus the added force from your jump), since the bouncing physics simply reverse your vertical momentum. This is a very important tactic in advanced play, as it greatly increases the movement options you may have at any given time.

Those options then increase tenfold when you add in the momentum cap, since over such a long rebound, you have a wide range of points in which to let go of the jump button and dramatically change the height and shape of your jump arc. Sometimes it's useful to go back up to the height you started at so you can reach something which was at the same height, but too far away horizontally. Other times, it's more useful to cut your jump short so you can quickly go in a tunnel or hit an enemy or simply land on the floor quickly.


tl;dr Allowing you to CHOOSE how high you want to jump is much more important than saving you the chore of remembering whether you're pressing the jump button or not. And at the end of the day, SRB2 aims to emulate how the classic Sonic games played and the movement choices present therein, only straying away when balancing the characters for multiplayer purposes, such as Tails' downflight.


(Though one thing that's always bugged me is how easy it is to cancel a spindash. It was a one-frame trick in the originals, while in SRB2 it's actually easier to jump out of a spindash then launch one at minimum speed. Manual spindash charging when?)
 
What you're suggesting is to change a core gameplay mechanic so that you have an easier time playing the game. This is not a bug report.

The way SRB2 works, and how it mimics the classic Sonic games is that if you're jumping and have (sufficient) upwards momentum, and you let go of the jump button, this causes your momentum to drop. (In practice, I believe SRB2 halves your momentum while the original games set it to a fixed value.) This mechanic exists to give you control over your jump height: the sooner you let go of the button, the quicker the momentum cap kicks in and the shorter your jump becomes.

However, the way this mechanic is implemented also means that if you jump on something from a great height and hold the jump button while you bounce back up, you will rise all the way back to your original height (plus the added force from your jump), since the bouncing physics simply reverse your vertical momentum. This is a very important tactic in advanced play, as it greatly increases the movement options you may have at any given time.

Those options then increase tenfold when you add in the momentum cap, since over such a long rebound, you have a wide range of points in which to let go of the jump button and dramatically change the height and shape of your jump arc. Sometimes it's useful to go back up to the height you started at so you can reach something which was at the same height, but too far away horizontally. Other times, it's more useful to cut your jump short so you can quickly go in a tunnel or hit an enemy or simply land on the floor quickly.

tl;dr Allowing you to CHOOSE how high you want to jump is much more important than saving you the chore of remembering whether you're pressing the jump button or not. And at the end of the day, SRB2 aims to emulate how the classic Sonic games played and the movement choices present therein, only straying away when balancing the characters for multiplayer purposes, such as Tails' downflight.
I don't think you understood what I meant. If I jump from a high place and let go of the jump button with just 1 fracunit of upwards momentum, then hit an enemy very far down, I bounce all the way up again. If I let go of the jump button with just 1 fracunit of downwards momentum, however, the game first registers the "jump-break" when I start moving upwards again (or hit the floor), like if I hit an enemy. And that causes what I call "mini-bounces". I don't exactly think it's intentional the game only lets you change between "jumping" or not when you have an upwards momentum.

If you (or anyone else) feel(s) like experimenting with this, use "devmode 2" (or 3 or 7) in the console, and look at the "JM" text thing. Obviously, it's red/off when standing. Clearly, it's green when holding jump. But it only turns red again if having an upwards momentum while not holding the jump button (or standing on the floor).
 
Just to add to this, I know exactly what Zwip is referring to, and I'm 99% sure that it's a bug, because it doesn't make a lick of sense.

If you jump the highest your character can go, and then fall and hit an enemy while still holding the jump button, you bounce up to the same height. That's correct.

If you jump the highest your character can go, and then fall and hit an enemy but let go of the jump button before that, you do a short bounce. That's correct.

If you do not jump the highest your character can go, and then fall and hit an enemy, you bounce up to the same height. It doesn't matter if you're holding the jump button or not. There's no way to do a short bounce. That's not correct.
 
Just to add to this, I know exactly what Zwip is referring to, and I'm 99% sure that it's a bug, because it doesn't make a lick of sense.

If you jump the highest your character can go, and then fall and hit an enemy while still holding the jump button, you bounce up to the same height. That's correct.

If you jump the highest your character can go, and then fall and hit an enemy but let go of the jump button before that, you do a short bounce. That's correct.

If you do not jump the highest your character can go, and then fall and hit an enemy, you bounce up to the same height. It doesn't matter if you're holding the jump button or not. There's no way to do a short bounce. That's not correct.
Please look at my user-title. You got it more than the other people, but not exactly what I'm reffering to. The first one to me is "correct". The second one to me is "incorrect" (but it would be correct if I'd just let go of jump the moment I bounce), since if I keep not holding the jump button while bouncing on stuff, I keep gaining height. The third one to me is "acceptable".
 
Here's what I would suggest, in as-specific-as-I-can-make-it list form:

*When the player jumps from the ground, turn player.jumping on.

*If the player lets go of the Jump button while player.jumping is on, cut the player's momentum and turn player.jumping off.

*If the player stops moving upwards and begins falling while player.jumping is on, turn player.jumping off even if they're still holding the Jump button. No matter what, player.jumping goes off at or before the peak of each jump.

*If the player makes contact with an enemy while player.jumping is on, do not flip their vertical momentum and keep player.jumping on. This is so players can jump upwards into flying enemies without worrying about being bounced back down into a hazard.

*If the player makes contact with an enemy while player.jumping is off and they are not holding the Jump button, do flip their vertical momentum and keep player.jumping off. In other words, if the player isn't holding Jump upon bouncing off of an enemy, the game will assume that their intention is to bounce to their maximum possible height.

*If the player makes contact with an enemy while player.jumping is off and they are holding the Jump button, do flip their vertical momentum and turn player.jumping on. By holding Jump as they make contact with an enemy that they want to bounce off of, the player signals to the game that they want to control the height of this bounce. This will cause the game to treat the bounce as if it were an ordinary jump, but with the player's new upwards momentum taking the place of their normal jump thrust. Since player.jumping is on, the same rules apply to this controlled bounce as to a regular jump, and the player's strategy is therefore the same: keep holding the Jump button as long as they want to keep ascending, and release it when they want their momentum to be cut.
 
Last edited:
I don't think you understood what I meant.
In theory, maybe, but not in practice. You're clearly right about the incorrect behavior, but the way you framed it made it seem that always bouncing high was the correct behavior and that the low bounce was the bug, when it's precisely the other way around.

If you do not jump the highest your character can go, and then fall and hit an enemy, you bounce up to the same height. It doesn't matter if you're holding the jump button or not. There's no way to do a short bounce. That's not correct.
This is in fact incorrect behavior. It seems the logic of the jumping/jumped flags is messed up somewhere in the code; it's the jumping flag that should reflect the jump button being pressed and should be checked when the player has upward momentum, the jumped flag should merely do the job of checking whether the player actually gained height from jumping and not just running off a cliff or something.

*If the player makes contact with an enemy while player.jumping is on, do not flip their vertical momentum and keep player.jumping on. This is so players can jump upwards into flying enemies without worrying about being bounced back down into a hazard.
This isn't even a problem because the momentum should only be reversed if the player is already travelling downwards. (Monitors in Sonic 1-3 used special code for bouncing the player down.) The check definitely should NOT be tied to the jumping flag because we don't want the behavior to differ depending on whether or not the player is holding any buttons.
 
Last edited:
This isn't even a problem because the momentum should only be reversed if the player is already travelling downwards. (Monitors in Sonic 1-3 used special code for bouncing the player down.) The check definitely should NOT be tied to the jumping flag because we don't want the behavior to differ depending on whether or not the player is holding any buttons.

I wasn't aware that we already had a system in place for dealing with that. Now that I think about it, it would be more intuitive for the player if the momentum reversal was tied to whether the player is falling rather than the value of player.jumping - which it already is, conveniently.
 
...I'm rather lost in this discussion, but all player.jumping even does is determine when letting go of jump is going to cut z-momentum when going upwards. However, when you go downwards and let go of jump button THEN, it stays on.

If you happen to bop a crawla with jump button not held and player.jumping still on, naturally the game will decide to cut z-momentum because, hey, that's exactly what you need to do this!
 
...I'm rather lost in this discussion, but all player.jumping even does is determine when letting go of jump is going to cut z-momentum when going upwards. However, when you go downwards and let go of jump button THEN, it stays on.

If you happen to bop a crawla with jump button not held and player.jumping still on, naturally the game will decide to cut z-momentum because, hey, that's exactly what you need to do this!

The problem is that if you cut the momentum during the first jump, then bop a crawla afterwards, the momentum won't be cut a second time -- it's like you're perpetually holding the button until you jump again.
 
Well, time for a suggestion. Make it possible to mark Lua console commands/variables as "cheats", to make them modify the game, to disallow one to get emblems/unlockables/secrets in a mod with custom data, if said command is used/variable is altered.
A possible way to make it might be if the command/variable returns true/yes/on/1, then it counts as a cheat. (Like with player specials hooks/MobjCollide overriding default behaviour if the hook returns true.)

Edit: I have to say, I don't know if that already happens. I only checked the Wiki, I didn't test it in-game, and the Wiki doesn't state anything about marking new console commands/variables as cheats.
 
Last edited:
You can KIND of do that right now by making it set devmode, that's what I did for one of my cheats. I think devmode 0 sets cheats on without actually using any of the devmodes.
 
You can KIND of do that right now by making it set devmode, that's what I did for one of my cheats. I think devmode 0 sets cheats on without actually using any of the devmodes.
...Huh. That seems like a way to do it. In that case, I really hope "devmode 0 is a cheat" doesn't get "fixed".
 
For HUD objects, add support for sprites in the same manner as any other graphic, and add color/skin arguments so they can match the player.
 
and add color/skin arguments so they can match the player.

I second this. For Jasper, I had to recolor HUD elements for all the 25 different skincolors in the game and had to make them change accordingly, eating up a grand total of 389 lines of Lua (had to make them switch to the other side of the screen when playing a lifeless gametype too) just to get them all defined. This could easily be squished down to 15 if a simple function existed for changing the color of a HUD element and would definitely save space for future wads.
 
I second this. For Jasper, I had to recolor HUD elements for all the 25 different skincolors in the game and had to make them change accordingly, eating up a grand total of 389 lines of Lua (had to make them switch to the other side of the screen when playing a lifeless gametype too) just to get them all defined. This could easily be squished down to 15 if a simple function existed for changing the color of a HUD element and would definitely save space for future wads.

I know Jasper isn't finished yet and you usually only share work-in-progress stuff with a select group of people, but would you mind linking to that part of the script so I can take a look at it? I'm not sure what method you're using, but I have one in mind that'd probably only require around 100 lines of code without HUD color changing.
 
I know Jasper isn't finished yet and you usually only share work-in-progress stuff with a select group of people, but would you mind linking to that part of the script so I can take a look at it? I'm not sure what method you're using, but I have one in mind that'd probably only require around 100 lines of code without HUD color changing.

...I'll be honest, I'm pretty bad at optimizing code. I ended up checking for super every time I had to check for color when I could've just done it once. Jasper's built on a lot of trial and error and I haven't gotten around to cleaning stuff up yet. Still, the point of the matter still remains that even with a very condensed code, you're still left with around 90 more lines of code compared to using a function and you still have all of those seperate recolored HUD elements taking up space. This is even more of a problem for something Jay wants to do, seeing as the HUD elements he's making are using pre-existing sprites found in character files.
 
...I'll be honest, I'm pretty bad at optimizing code. I ended up checking for super every time I had to check for color when I could've just done it once. Jasper's built on a lot of trial and error and I haven't gotten around to cleaning stuff up yet. Still, the point of the matter still remains that even with a very condensed code, you're still left with around 90 more lines of code compared to using a function and you still have all of those seperate recolored HUD elements taking up space. This is even more of a problem for something Jay wants to do, seeing as the HUD elements he's making are using pre-existing sprites found in character files.

I definitely agree with you that more flexibility with custom HUD graphics would be great. I just didn't want your script to be unnecessarily bloated even for the system we have now.
 
When we do that, it'll be handled via colormaps, just like the rest of the source handles color-changing. That's what the [(unimplemented) colormap] argument for v.draw / v.drawScaled is for, but currently there's no proper support for colormaps in Lua.

Also you don't have to necessarily use a whole bunch of lines of code for switchable HUD objects. With the proper naming setup you could set up every patch as a color prefix + name (C##_RING, C##_SCOR, etc).
 
Last edited:
[Suggestion] Voting

Hello there
i have a little suggestion about Multiplayer mode :
* You know what's voting,we need this Features in the game
all what the player have to do is to type in the console maybe "callvote (type) (value)"
for example :
Callvote kick SSNTails
and when player gets kicked he'll be banned for about 1H from server.
The reason why we need this feature is
when a Game host isn't Online Players in the server
can still change current Level,Gametype,or kick annoying Players
that deppends on what Votes types are allowed by the Host
isn't that a good idea ?​
 

Who is viewing this thread (Total: 5, Members: 0, Guests: 5)

Back
Top