- Following Oni's proposal. This means taunts are split into 2 types for offensive items and boost, 2 less hurt sounds, and there's another clip for using invincibility item (or whatever other powerful items we want to apply it to later; maybe size-down?)
- Win/lose quotes are played at full volume for the person who said it.
- A new sound effect plays when you hit someone with voices disabled.
- Reduce amount of RNG being called from the vanilla P_Play[whatever]Sound functions
- Added our skin sound constants to the dehacked list.
- Unrelated: finish line sfx plays in splitscreen
- different min/max on capped spring pads
- turn the normally almost-useless "non-ramp sector" type into "wall sector", which disables both stepup AND stepdown instead of just stepdown
Less grow, less invinc, less ballhog, just a teensy bit less triple orbinaut, and SPB odds no longer scale with lower player counts like other power items do
Also features jittering of the intermission elements because I thought it'd be fun, plus some better handling of players leaving (and then new ones joining) mid-intermission.
* Make MT_GHOST's encoremapping depend on whether the source was encoremapped.
* Revamp how sector typegroup 2, type 15 inverts the encoremapping (so planes don't get awkwardly desynchronised).
* V_DrawFixedPatch and ilk:
* Change the offset of V_FLIP so it's not one screen-pixel off where its non-flipped sprite would have started being drawn from.
* Write to x and y as well as desttop so that anti-screen-overflow checks later in the function behave properly with non-green resolutions.
* V_DrawFill:
* Reduce number of operations performed upon `c`.
* V_DrawString and ilk:
* Offset the left and right boundary checks in non-green resolutions such that you can actually draw stuff to the left of basevid screen x coordinate 0.
* Stop orphaning their memory. They ARE PU_LEVEL, so they'll disappear eventually, but, like... it's not good memory management practice to just *orphan* them when you're literally never going to do anything with them ever again. Y'know?
* Make ghosts spawn properly on slopes.
* Fix that thing where ALL transparent FOF planes were continuously fullbright unless encased in a fog which disables sprite fullbrightness, which was long-hated by many people in the community!
* For backwards compatibility, setting flag 1 in that fog field (which is probably the most common "in-the-wild" usage of this feature) will continue to make objects un-fullbright.
* For situations where you desperately want the behaviour to be enabled, you can apply fog flag 2.
* Change the fadestart and fadeend range in which colormaps are generated.
* The problem HERE was that the darkest light level reached by generated colormaps was actually slightly brighter than the darkest level reached by normal colormaps.
* The typo I fixed does have SOME basis in fact - standard colormap lumps are 34 (33 in 0-indexing) long rather than 32 (31), but whoever wrote this didn't realise that the code for generating them didn't do it DooM style, just bright-to-dark with no extras on the end...
* They're clearly not quick enough at the job, since it causes a bunch of silly race conditions.
* Instead, K_UpdateHnextList and K_CleanHnextList are in charge of removing them, which are called in the circumstances itemamount (and itemheld/eggmanheld) is changed.
* Also, tweak a few places so that trailers AND orbiters can use the same system.
Also, some minor thingies.
* Turn all the useless ```if (a) { A } else if (!a) { B }``` bullshit into ```if (a) { A } else { B }``` bullshit.
* Fix up some minor inaccuracies in the playerarrow stuff that doesn't result in creating more sprites.
* The tab and intermissions rankings...
* ...now have parity in behaviour!
* ...now properly handle player counts over 8, and no longer supports player counts over 16!
* The Item Arrow in Battle...
* No longer develops any extremely stupid bugs due to Orbinaut sprites that makes all objects in state S_INVISIBLE develop <!>'s! (Ask me about this if you're curious as to how it affected everything else too.)
While I cannot guarantee the class of glitches that allows for additional items to be thrown/dropped has been completely obliterated, this DOES prevent the class of exploits that allows for "infinite items" (really just negative quantities not completely bounds-checked for).
