* Make setting steallives to true respawn every game overed spectator.
* Make a minimum on the number of lives GetLives can get you.
* Add "You'll steal a life on respawn" to spectator screen.
* Make sure that a life theft always takes you from 0 (or less) lives to 1 life.
* Fix a bracket level typo that meant new Co-op style respawning was being done for all gametypes.
* P_GiveCoopLives bundles the coop lives reward for everyone versus reward for one person in other gametypes thing into one function. Available in Lua.
Needs a bunch of changes to HUD rendering, especially in splitscreen, which doesn't try to show spectator stuff whatsoever. Also, if you're the player whose respawn determines when the map reloads, you'll see the spectator text during the front half of the fade. Unless, of course, it's 2-player mode.
* cv_sharedstarposts - Makes everyone share starposts, defaults to "On"
* cv_respawntype - Defaults to "Starpost". If set to that, people respawn at the starpost you just hit (assuming cv_sharedstarposts is on - may have to combine the two variables later, but seperate for testing for now). The other option is the old, unrestricted spawning. We COULD add TD bubble spawning at a later time using this variable, though.
The level DOES reset if everyone dies, but not in a way which allows for Mystic Realm style non-resetting resets. I'll handle that later.
Ignore askinfoviams
Turns out PT_ASKINFOVIAMS is an obsolete packet type anyway, the MS doesn't send it at all. So let's just ignore it in the netcode then. (the online page just acts like a client and sends PT_ASKINFO, and is not part of the MS itself)
See merge request !191
Netcode hotfix
Various netcode fixes are included in this branch. Most important of all of course is a fix for the Net_CloseConnection invalid node -32769 detected message thing, or rather what actually caused that to occur.
It's a merge to master since everything here should be compatible with 2.1.18: the only main changes are related to recieving packets (whether you're the host of a netgame or a client), which AFAIK shouldn't cause desyncs if you played with these fixes on a 2.1.18-hosted netgame (or hosted a netgame with the fixes and 2.1.18-using players join you).
See merge request !185
A bunch of bugfixes about too many wads in netgames
Fixes:
* Having bunch of music WADs added and then breaching the file limit(s) through joining a server with important files added. http://mb.srb2.org/showthread.php?t=42662
* Having a bunch of music WADs added, joining a server, and then breaching the file limit(s) when the server adds a file. https://mb.srb2.org/showthread.php?t=34664
* Informing the adminplayer whenever they try to send a request addfile net command but the file limit(s) are reached.
Done into next because I might as well be 100% safe, even though this could probably work on master as well.
See merge request !187
Missiles 'n slopes
Fixed that thing where missiles like sliding up slopes for some reason.
This isn't a 1:1 fix compared to non-slopes - missiles still like stepping up over the borders of sloped sectors and will continue going as long as they never touch that ground again, whereas they can never step up on flat ones - but this fixes the most egregrious issue.
See merge request !181
* if you sent it to a client rather than the server, game over, your connection is closed
* if files that don't exist or are too large are requested are listed, game over, your connection is closed (they should have been checked on YOUR side beforehand, silly)
* if the server has downloading disabled anyway, ...yeah, you get the idea
Don't worry, I made sure Got_RequestFilePak cleaned up the full file request list for the node in case of failure
NiGHTS capsule color fix
This fixes the Egg/Ideya capsule from NiGHTS stages being given SKINCOLOR_RED as a color. Not really relevant for vanilla SRB2 (since it doesn't use green in the sprite), but it may be relevant for custom mods using a custom NiGHTS capsule sprite that happens to use green.
See merge request !189
Exit your server desync fix
This branch fixes this bug: https://mb.srb2.org/showthread.php?t=41811
Here's an explanation of how this bug is actually happening:
* Pressing Enter with "Start" selected calls `D_MapChange` to make a map change command. (Note that part of it is actually delayed because it's called from a menu, but this isn't relevant to the bug)
* `D_MapChange` itself calls `SV_StartServer` to start up the server, if you're supposed to be the server player.
* Pressing Esc while starting up a server like shown in the gif causes the server to be cancelled, and go back to the title screen.
* HOWEVER, since we're still in `D_MapChange`, the map change command is made anyway.
* Since we're not in a netgame as expected, no random seed is added, and the map change command has a total size of 9 bytes (1 for the id + 8 for the actual data). This is then stored in the net command buffer. The random seed would add another 4 bytes if it WAS added, note.
* Next time you start a server, and let it work as normal, two more net commands are added: an "add player" command (size 3), and a map change command (size 13, including random seed this time). Your net command buffer now has a total size of **25** (9 + 3 + 13).
* This net command buffer is then sent as a `PT_TEXTCMD` packet to yourself.
* SRB2 recieves the `PT_TEXTCMD` you sent to yourself, and some time later, tries to run the net commands stored in it.
* The first map command is read as if it's size 13 rather than size 9 (it isn't), mistakeningly thinking a 4-byte random seed is stored (since you ARE in a netgame now). This means your buffer reads what it thinks is the next net command starting from position **[14]** in the buffer.
* Bad luck, it gets an id of **0**, which doesn't correspond with any net command!
* This message is then printed in the console:
> WARNING: Got unknown net command [14]=0 (max 25)
* The game subsequently kicks you out the server with a "desynch" message.
tl;dr The game doesn't correctly cancel the map change when you cancel the server with Esc like that. This is not a good thing.
See merge request !188
