Pretty much just copy+pasted from Snap the Sentinel!!
- Hold left/right to adjust the momentum angle after hitlag, up to 22.5 degrees. (Only angle can be adjusted, so you can't adjust your speed, only your direction.)
- It's relative to your angle, so sometimes you need to use forward/back, or even diagonals (forward/back throws now store full analog data for this to work)
- Bananas flip DI direction, to make them not baby easy mode
- Tumble has x3 DI (so angle adjustments of 67.5!!), and hitlag on each bounce to allow even more control.
Cuz bot ticcmd generation is kinda chunky, and was curious how much time it takes. (It's actually a lot less than I thought ... still pretty hefty though)
While I finally pushed to do this because of the epic Blue Sphere reference, I was kinda thinking about doing this for a while, because it gives more room for bots to level up during Hard GP.
I thought about just making the new level cap go up normally, but I decided on keeping the bots' passive buffs (like top speed & ring boosts) go up linearly, while rubberbanding range is kept the same.
I don't think I can properly explain it, but this basically means level 13s are a touch harder than old level 9s before, and new level 9s are touch easier than old level 9s. Basically think of it as more level range than actually making the bots harder.
The expanded range means that Hard GP can start off easier, but end harder. (And of course, Master is even more ridiculous c:)
I think it was the realtics check...?!
The issue is still here but significantly better... I THINK?? I can't tell if I just hate this code so much I'm telling myself that it's better so I don't have to look at it anymore
- Disabled VSync, due to the numerous problems it has.
- Instead, added an FPS cap.
- Frame interpolation is now tied to fpscap != 35.
- By default, the FPS cap is set to the monitor's refresh rate.
- Rewrote the FPS counter.
* Rename TICQUEUE to BACKUPTICS.
* Add CLIENTBACKUPTICS to limit the time gap players can send tics in at once
* This likely means freezes are more possible, and this variable could be raised later, but prevents some potential duplication in the extrapolerated tic.
This will be necessary when newmenus comes around and it is no longer advantageous to have a menu for testing bosses, given they won't be a headline feature in v2 or accessible via multiplayer at this time.
Previously interpolated from last 35th of a second, which
may be offset from game time due to connection lag.
Consider this the proper fix to 6ecac4159a too.
Previously interpolated from last 35th of a second, which
may be offset from game time due to connection lag.
Consider this the proper fix to 6ecac4159a too.
- Add menu control fallbacks.
- If it could not find a bind using your existing keys, then it looks at default controls.
- If it could not find it then, and you're P1, then it looks through gamepads, and then lastly settles for keyboard.
- Changed around the order of operations on the character select menu, to accommodate for this change.
- Added initroutine to menu_t, which is called every time without question when going to a new menu. This solves many, many minor bugs you could experience in the character select menu when changing between menus, due to things only being properly reset when selecting the character select menu option.
Ultra mega hacked in, by saving all "discarded" joysticks to an array so they don't get totally closed & we can still poll them. Events now properly send the device number instead of the player number, which means we can store all controllers pressing buttons, and thus, can detect when ANY controller is pressing anything, and THUS we can make the character select work like we wanted to :V
Did not bother fixing any of the bugs, however. First of all, the opening menus do not properly fallback to default controls. Yet again, we may need a more robust system -- storing all keys from gamekeydown separately? Additionally it seems like when I input gamepad it makes me use keyboard anyway, so I think something fishy is up.
* Don't overwrite the first player's name when joining with multiple local splitscreen players. (resolves#151)
* The defaults for unprovided names are now consistently "Player A/B/C/D" as opposed to some being letter-based and some being number-based.
* Send local player info once per local splitscreen player, rather than n^2 times (where n is the number of local splitscreen players).
* Since the packet *requires* four names to be sent every time you join a server, send dummy names for local splitscreen players who aren't connecting, instead of your actual cvars (no data leakage you didn't ask for!)
Events have a player ID instead of adding billions of keys for separate gamepads. Axis movement (mouse movement, analog sticks) now are counted as keys, so axes don't need to be separately implemented for all controls. Game controls emulate a Saturn controller (some of the external functions like screenshot / gif should be readded, but I got lazy)
This will allow later us to save a config for a controller that can be reused for any player slot, which is one of the main goals for profiles.
Only just enough was made to use the new input system to make it compile. Menus in this branch should aim to move to using PlayerInputDown entirely, instead of using hardcoded keys & simply remapping to those
