Feature/multiplayer things spawn options

[UnreallyHard]

Option is available for all netgame types
Added Multiplayer Things Spawn Type to setup menu
Added Cmd Line Parameter mpspawntype
Added netgame functionality
Added mobjtype_weapons array is_weapon function
Closes #681

Options for Multiplayer Things Spawn Type are:

• All (0) - Default
• All except weapons (1) - The most often asked variant, ex. (Suggestion) Don't spawn multiplayer weapons in co-op mode #681
• Only monsters (2) - One step further. Nothing multiplayer related is spawned except monsters. This option can be used to remove mp only ammo spawns
• None (3) - Nothing multiplayer related is spawned at all

[fabiangreffrath]

Sorry, but before you put even more effort into this, it'd be only fair to tell you that I am not convinced of this concept and I am not going to merge it like this. The difference to DM3-support is that this added a single command line parameter and one or two more checks in the code. The approach here, however, adds a new command line parameter with different arguments and even modifies the netgame protocol. That's a no, sorry.

The one feature that's been asked for is "coop without additional weapons", so I'd suggest to implement this and either call it -coop2 in analogy to -dm3, or -no_coop_spawns in analogy to -coop_spawns - but nothing more, please.

[fabiangreffrath]

Please try to restrict the amount of changes to the ones in this PR:

0272030

[UnreallyHard]

Please try to restrict the amount of changes to the ones in this PR:
0272030

@fabiangreffrath I would like to make less changes but I don't think it's feasible to both keep code clean and do it.

src/doom/d_net.c
The main problem is that the code considers any deathmatch value greater than 0 to be a deathmatch game so it's applies deathmatch logic to the new value deathmatch = 4. But that doesn't work in our case as we are making a new coop mode. I described this problem in the previous comment #1175 (comment)

Since any deathmatch value greater than 0 means that it’s a deathmatch game, a lot of code changes would be made for deathmatch = 4 to work as coop game. So instead, there is only a small code changes that modify deathmatch value. Net operations continue to use a deathmatch original value and if deathmatch == 4 then everything else uses deathmatch = 0 and coop2 = true values.

So Because of all that, I made a change to src/doom/d_net.c to convert a net deathmatch value to a global var and vice versa. I moved conditions to the separate functions to make code cleaner.

netgame_modes_t
I added netgame_modes_t typedef to fix the issue with code maintainability as new deathmatch mode means that developer needs to change maximum value in both src/net_common.c and src/setup/multiplayer.c. Furthermore, using constants instead of integers is much better in my opinion, since it's much easy to find changes introduced by the deathmatch mode.

boolean coop2
It was added to get rid of a deathmatch value dependency in the base code.

Please tell me, If you have any ideas how to make less changes and support high maintainability?
If having the less changes is the main priority then I guess netgame_modes_t typedef can be deleted in exchange for the less code maintainability and the less readability.

[UnreallyHard]

Please try to restrict the amount of changes to the ones in this PR:

@fabiangreffrath I additionally removed netgame_modes_t enum (to have less changes) in an exchange for the less code maintainability.

[seascape]

Features suggested here would help make Crispy Doom's multimonitor support more usable in single-player... which is just what I was hoping to find.

Problem: To have "observer drones" showing one or more additional views of the gameworld you need to be in networked multiplayer, even though all Crispy clients may be local to your own computer. This creates disruptive differences from normal single-player: multi-only monster and weapon spawns, and the player respawns into the same world state upon death (no death penalty). (Also can't easily load savegames, but that's another thing.)

The unwanted/different enemy/weapon spawns sound like they could be resolved with some of the changes suggested in this pull request, specifically
None (3) - Nothing multiplayer related is spawned at all

So that's one (unusual) reason this'd be a cool feature to have... it'd make multimonitor mode better for single-player.

(That said, I have also felt a desire for option 1 when doing co-op several times in the past:
All except weapons (1) - The most often asked variant, ex. https://github.com/fabiangreffrath/crispy-doom/issues/681
)

Closing note, though I haven't found it documented anywhere, Crispy Doom already has a great improvement over vanilla/Chocolate Doom in this area because its automap seems to update (add new lines) while the automap is visible/open. This eliminates a key blocker (automap not updating itself until closed and reopened) that prevented using multi-monitor mode to run a dedicated automap client instance on a second screen.

Related issue for the automap-on-dedicated-screen use case: #142

[fabiangreffrath]

Do we èven need this? What if we simply track "coop2" as "deathmatch == 4"?