* Re-fix chat HUD position, and make it not move in match (which it needed to do in 2.1).
* Fix HU_drawPing for the new palette.
* Change the condition for greying out players, since the current one was buggy.
* Allow for tokens on the coop MP HUD, and use the small emeralds so there's space for them.
* Fix the mapping between skincolours and name colours in new chat, specifically to take into account every possible text colour (as opposed to the port previously done, which only used the 2.1 text colours and looked like ass as a result).
* Smoothen Pity Shield animation to go with sphere's updates to Nev3r's sprites.
* Added LHRT object, designed to be summoned with CA2_MELEE.
* Gives a pink Pity Shield (SH_PINK) on same-team player contact.
* Deals damage to non-player enemies.
* Harmlessly fades into nothing when touching an enemy player, players with SH_PINK already, and players capable of applying SH_PINK to others (through non-Lua methods).
* Basically, you-know-who is the Healer of the party whenever they're around. Fun consequences for the Co-op and CTF metas.
Also, the start of my improvements to CA2_MELEE. Users of that abiliy can only damage enemies/monitors if they touch the front of the player object, but to make up for it, the player is no longer forced away from the direction of the screen at bigger movement speeds.
* Takes function(player, mo) input.
* Return TRUE for stating that yes, the player is in a state that can cause contact damage, do with that what you will.
* Return FALSE for stating that no, the player is weak and vulnerable and cannot cause contact damage, do with that what you will.
* Return NIL for allowing the function to continue regular operation.
Fills a different ideological niche than ShouldDamage - that's for determining whether damage dished between two objects should happen, this is for determining which way around damage should be dished when considering a player-object interaction.
Or, in other words, think of it as "ShouldDamage is whether damage that has been requested should be granted, for object-object interaction, while PlayerCanDamage is for whether global player properties should cause damage to enemies and monitors in the first place, like spinning, hammering or stomping."
* Move HUD text's anchoring to underneath STR instead of above Lives.
* Adjust chat position slightly, to take advantage of SRB2's HUD layout having less content towards the bottom (unlike Kart, where it has roughly equal).
* Fix Match emeralds not displaying while in tab rankings with all-seven invuln/shoes bonus active.
* Port across the additional colour translation maps, including mobj-level support for "colorized" objects.
* Make Fangboss and both Metal Sonic objects greyscale if, on spawn, there is a player in the game who is not a spectator whose skin is that character.
* Allow bosses with MF_GRENADEBOUNCE to opt out of the MF2_FRET colour-flashing tomfoolery, and give this flag to Fang.
* Like Kart, remove cv_precipdensity.
* Like Kart, replace "Infinite" draw distance value with "None".
* Better thinker with more return optimisation.
* Better placement of thinking in rendering, to avoid ceiling-mounted sprite glitches.
Vissprites are now only clipped against their respective portal's geometry obtained from their BSP run.
Additionally, if a portal is provided, they're clipped to the portal's clip boundaries.
The work on this branch should conclude after a pair of remaining glitches are fixed.
The drawnodes are now fully grouped in separate lists, and then sorted individually. This fixes sorting problems caused by portals belonging to differently perceived scales (skyboxes for example).
Drawsegs and vissprite/drawnode sorting require the viewz, so the viewz is stored for each portal/view, and then restored when needed; without this, the rendering process erroneously sorts the elements, and draws some at wrong positions.
Each shall eventually have its specific vissprites/drawsegs; currently only drawsegs are stored in their correct list, vissprites are stored in the first list as a placeholder.
The idea is to sort each list individually, and then render their masked elements, starting from the last drawnode list.
This retains a non-recursive function calling method while still rendering things in order.
It seems to screw up the portal rendering in odd ways if it's in the wrong position. I apologize for not even knowing what it's meant to do nor how it works.
The skybox rendering process has been replaced with portals instead. Those are generated after the first BSP tree pass by looking for existing sky visplanes at the time, and their windows are used to define new portals.
The skybox portals are still incomplete and cause visual glitches when masked elements are involved.
Split portal-related code to its own source files.
Most of the 2-line-specific setup has been moved to the function which adds a 2-line case. The portals should render as they used to so far, anyway.
toaster