Sprite2 changes
Some stuff!
* Lua access to sprite2.
* Introducing new Lua-exclusive function, P_IsValidSprite2(mo, spr2). Basically just a wrapper for (((skin_t *)mobj->skin)->sprites[spr2].numframes > 0), useful for creating custom sprite2 defaulting functions since hooking into P_GetMobjSprite2 wouldn't be worth it.
* FF_ANIMATE support for sprite2s. The var2 of the state works identically to normal FF_ANIMATE, but var1 is completely disregarded - it just runs all of the frames available to that one sprite2 animation set.
* As a result, a bunch of states which were either not previously animatable or had animated at constant speed now get animation without state changes.
* P_SetMobjState now supports sprite2 defaulting like P_SetPlayerMobjState does.
See merge request !51
Damage control + Match rebalancing
This is two branches in one since while I was working on damage-control's changes months back, I felt it was best Match rebalancing was merged in here too (thanks JTE for helping me do so).
Changes from damage-control:
* `player->health` (formerly the "HUD copy" of `player->mo->health`) is now `player->rings`, and is also now the player's actual ring count.
* `player->mo->health` (formerly rings + 1) is now always 1 when alive, regardless of ring count; if player with rings is damaged, this is untouched.
* P_RingDamage now includes ring spilling code.
* P_ShieldDamage now has a damagetype argument, allowing me to remove the last MT_NULL hack left in from the pre-damagetype days that I forgot about.
* The old "switch-to-seestate" enemy damaging behavior in P_DamageMobj has been removed. This was a Doom left-over and doesn't really affect SRB2's enemies anyway - see, Doom enemies had a random chance of using seestate or painstate, SRB2 enemies always use painstate.
* Other minor efforts to reorganise damaging code and have it make more sense, but otherwise nothing that should affect gameplay in general.
Changes from match-rebalancing:
* New weapon/ammo dropping behavior: if you have the weapon panel + ammo, you drop the panel (but not the ammo); if you don't, you just drop the ammo.
* New Match ammo consumption: Weapon rings can now be fired with no rings at double the ammo cost.
* New emerald behaviour: collecting all 7 emeralds no longer turns you super (read: Match super is dead now) but instead steal points from enemies and gives you and teammates invincibility + sneakers
* Tails ringslinger buff: Any character with CA_FLY will now throw rings 1.5x as fast.
See merge request !28
To that end, I've made MF_MONITOR *without* MF_SHOOTABLE act like MF_MONITOR does, and MF_SHOOTABLE allow for both missiles AND players to destroy. This has had the side effect of allowing MF_ENEMY and MF_BOSS to use MF_MONITOR as a substitute for MF_SHOOTABLE that doesn't allow missiles to cause them damage, which might be useful for Jetty-syns.
* All Lua-originated sprite2 settings are now forced through P_GetMobjSprite2. Makes sense because of SPR2_JUMP, which none of the main characters have sprites for yet all use.
* Cleaned up P_GetMobjSprite2 to not set irrelevant, otherwise-unused variable.
Console improvements
* Unused console backgrounds no longer take up memory
* Input cursor can now move left and right
* Support for selections (Shift-arrow keys, CTRL-A, etc)
* Clipboard support (CTRL-C to copy, CTRL-V to paste, CTRL-X to cut)
* Fixed handling of simultaneous modifier key presses
https://dl.dropboxusercontent.com/u/3518218/21/console.gif
None of this affects chat yet, that's not part of the console. I'll look at it later.
See merge request !133
MD2 vertex/frame/triangle/etc limits checking
Fix for this bug: http://mb.srb2.org/showthread.php?t=42099
The model reading code didn't properly check if the model had too many vertices, so models with higher counts freely broke the game. This fix now stops that and prints an error message if that is the case.
However, it seems some models happily exceed other limits such as texcoords without problem (to my knowledge), so I've not bothered with checking those limits for now. Perhaps this could be a time to discuss if we need to change such limits again or not? Either way, one can easily uncomment my lines for checking texcoords/skins/triangles limits later if needed.
EDIT: I've allowed checking for triangle and frame limits too now, after some discussion.
See merge request !132
