I meant to fix the previous method, but I didn't even understand how it knew it was in a vote or not... so I just did it my own way :V
(Shouldn't FLUSHMAPBUFFEREARLY be on now...?)
This makes it so that if the SPB'd person is passed, then the person who's getting SPB'd won't get the increased item odds for the weird feedback loop.
Unfortunately, the code didn't turn out nearly as nice as I'd desired, but things don't always work out.
In addition: For some reason, I rolled Tinkerer's Arena twice within three hits of the Dice voting option, so something's wrong and this branch needs proper, rigorous investigative testing but I don't know what and I'm way too tired (both physically and metaphysically) to investigate any further.
This makes rubber-burn turning even more useless, but I don't think there's a way to fix the rubber-burn turn without breaking demo playback, so let's just do the part that is needed for now. I kinda want to redo how that mechanic works anyway.
* Save gamedata in Y_UpdateRecordReplays(), so that you never unfairly lose out on your spoils by setting modifiedgame before the game ends.
* Always save your matchesplayed/totalplaytime increase at the successful completion of a level.
* M_SkyScroll optimization with still speeds; refactor background drawing
* Music (in time attack screens so far)
* FadeStrength
* HideTitlePics
* Scrolling backgrounds in Time Attack (moved F_SkyScroll to m_menu)
(Huge change: NO_MIDI is now a define, simply because that makes it easier for me to resolve merge conflicts if I can see the original code and the new code. Also means that people who REALLY miss MIDI can compile & fix it themselves :P)
A more detailed explanation:
* P_CheckPosition is the function which determines collisions.
* In Vanilla, collisions do not happen between players unless tailspickup is off (which it basically never is).
* Even with tailspickup off, on-spawn player collisions do not affect momentum.
* However, in kart, player collisions cause the player to get bumped.
* It would succeed at the P_CheckPosition call because players aren't *solid* solid, even though they cause bumps.
* It would fail at the K_CheckPlayersRespawnColliding call, but that would be too late, *as the player already has been bumped.*
* The player would therefore be moved to a new location, but still retain bump momentum, and the bump sound would have played for both players.
* Therefore, the obvious solution is to swap P_CheckPosition and K_CheckPlayersRespawnColliding, so that it checks for players BEFORE it performs object collisions at that spot.
* The reason we didn't see this MUCH before is that it can only ever happen in the case of ties.
I could've easily done this into master, but obviously I figure yalls'd at least like to check this first.
