This time without spare slots, because I don't see shenanigans like
WAD_MUSIC happening with skin indices. Verified to work by saving a
replay with 139 skins as the 133th skin and playing it back a few times.
Shouldn't cause issues with netcode either because there are no SINT8s
handling skin indices.
Now that 1.4 is out, maybe this will come in handy in 1.5, should 1.5 be
released. If not, I guess Ring Racers will make this branch redundant
once that comes out.
Implements W_VerifyPK3, thus allowing music PK3s - even those created
with an archiver, thanks to the preceding commit - to be loaded as
"unimportant" files, like music WADs can be.
Seems to be a regression in internal too. Requires more analysis on behaviour in the 2.2 engine, but essential for maintaining compatibility in 2.1 (such as with Opulence wobbly carpet).
- `cv_masterserver` - Replaces a hack checking for the original SRB2 MS addres every time, and additionally catches those who tested an early version of the http MS.
- `cv_usegamma` - This was previously WAY too easy to accidentially change. This way, a user who has had this accidentially happen will automatically return to baseline.
I originally wrote a ridiculous attempt at reimplementing the existing value rollaround. For one reason or another, that sidesteps net transmission. Let's just avoid all those hacks and limit our influence to changing the maximum allowed range.
Doesn't affect the conditions that allow entry -- just avoids pointlessly resetting the map if it occurs during the period where literally nothing can happen.
Notably implemented with a hack, but these have already or will be rewritten for Ring Racers, and backporting isn't viable or desirable, so functional is better than the alternative.
Because its z was being set but its old z wasn't being overwritten, at high enough refresh rates you can see it appear above its starting position for a single frame.
Done by modifying old_z instead of using P_SetOrigin for consistency of avoiding CheckPosition.
* Backport the fix to an interp-based crash caused by using a combination of interpolated and uninterpolated scale in renderer calculations.
* Between this and the last commit, I attempted a refactor of this and associated functions in order to find the cause of the above crash. Committed are the changes which resulted in increased performance.
