Spawn Counter

This is simply an .rmf containing the spawn system cut out of my map in progress de_pophouse to be used as a counting system. Uses default textures but also a few color textures of my own so I have included a .wad file with them. I have removed extra entities such as the weapon equipping entities and inaccessible buyzones (although I left the armory entities intact) and I cut the spawns straight out of the map so that you won't have to do too much work to copy this into a map of your own. This contains some entities used with VHLT so make sure you have your tools up to date (using VHLT 34 with the included zhlt.fgd and the Hex 805 FGD). Feel free to use this and modify it to your liking. I'm sure it could even be made more efficient.

This system counts the number of players each round in Counter-Strike 1.6. What it does is spawn all the players "off-site" in a dark room and drops them through the triggers that count the players. Aside from the multi_manager and trigger_multiple that help to reset the counters each team has it's own set out counters so they can be counted independently, so I will only explain here how it works with one team (as it's just doubled over for the other team).

First, the players spawn in, they fall through a trigger_multiple that targets a multi_manager which targets both teams game_counter_set entities. A single team has 2 game_counter_set entities and when triggered they set the associated game_counter entities back to zero. Players continue to fall and eventually fall through their own separate trigger_multiple entities. These entities trigger one of three multi-manager entities which then trigger both game_counters. The reason there are three separate multi_managers is to avoid a single multi_manager being bombarded with too many triggers at once and failing to receive all of them. With this setup, two of the multi_managers are activated by 5 different triggers and one of them by 6 different triggers. The trigger_multiple entities themselves also have different delays to stagger their requests to the multi_managers to further avoid miscounts.

All three multi_manager entities target both the teams game_counter entities in .001 seconds. It's important not to set a delay here because if the multi_manager is waiting to trigger the game_counter then it will not accept requests from other triggers at the same time. The game counters are each set at a different limit value because they are set to trigger at different amounts of players. The first game_counter has a limit value of 6 which means once it is triggered 6 times it will then trigger whatever it is targeting and the second game_counter has a limit value of 11 so at 11 players it will trigger it's target.

The target in this case is a multi_manager that controls a set of lights and doors. The first game_counter triggers a multi_manager that opens the door and turns on the lights on the left side of spawn and the second game_counter triggers a multi_manager to do the same on the right side of spawn. The doors reset themselves each round and so do the lights. The only thing that needs manual resetting is the game_counters and that was already covered above.

Of course, let's not forget about the actual players! As all this is happening, the last trigger they hit as they fall through the darkness is a trigger_teleport which sends them to a corresponding info_teleport_destination in their "real" spawn area. All in all the players have a black screen for roughly a second before "spawning" in a place they can actually see.

I'm sorry, I'm really poor at explaining this in detail, but I hope in conjunction with the .rmf file it will make it clearer to you on how this whole thing works.

Some more other things:

Why are the trigger_multiple entities under the CT spawns higher up than the ones under the T spawns? I honestly have no idea why I had to do that. For some reason the lights and doors on CT side were not getting triggered consistently and raising the trigger_multiples up a little bit did the trick. Perhaps it has to do with the direction they are facing, I really don't know!

Why are the door speeds set to 500? Well, as it turned out, sometimes when the doors reset after a round they would not fully close in time before they were triggered again. It wouldn't always happen right away but when it did they would never open again (possibly because they were tied to a multi_manager, before I added the lights they were triggered directly by the game_counters and if they failed to open one round they would still work the next round).

Why use a trigger_multiple to trigger the multi_manager that triggers all the game_counter_set entities when a func_door would do that automatically each round? Well, for some reason, the func_door wouldn't always reset the counters in time. Leading to either no doors opening or only one door opening when both should have opened. The trigger_multiple blanketed directly under both teams spawns ensures that the counters will be reset by the time the players hit the other trigger_multiple entities that actually initiate the counting. I gave it an 8 second delay before reset to ensure a few spawns a couple seconds late wouldn't reset the counters too early.

Known issues with unknown fixes:

-Round 1 doesn't always count properly.

-Because people typically spawn in slowly on the first round (this includes bots in CZ) some people will spawn from the same spawn point (presumably since the previous player is already clear of the spawn since they fall away from it) and they will then teleport to the same point on the map. With bots I've been able to avoid death but I've had a few players die after teleporting due to this issue. This issue may also be the the reason round 1 doesn't always count properly (some players may be hitting the trigger_multiple that does the counting before it finishes it's 1.2 second delay before reset).

-When playing on my clan's server, I found that when teams first started hitting 12 players the doors wouldn't open. I assume this had to do with the PTB plugin that automatically balances the teams, because the teams kept shifting the 12th player back and forth. When both teams finally had a consistent 12 players, the 2nd set of doors opened as intended. To combat this in the final version of my map, I simply lowered the limit value of each game_counter by 1 for the final version. Not ideal, but in the specific case of my map it is better to throw the balance of weapon distribution off 1 player early than have a player without a weapon to pick up at all. This may have a bigger or smaller impact on your map depending on how you choose to use this counting system.

To see this system in action, check out de_pophouse_beta
http://twhl.info/vault.php?map=6145

I'm currently working on the final version, de_pophouse