My entity setup for a pistol fy map in progress. Yes, I know, I know, so many fy/aim maps, but they get a lot of playtime early in the night on my clan's custom map server and I need to make some that aren't ugly and aren't remakes of remakes.
So that is why, this particular fy map, has this entity room. It's not quite finished, there may be a few more light_surface entities in there but basically here's what you're looking at:
The metal block in the bottom left corner is a func_train that perpetually bounces between those two path_corner entities. Passing one of those two path_corner entities triggers something periodically that I will get back to in a moment. The giant block of yellow is a whole bunch of VHLT light_surface entities for various textures on the map, except for one which is an info_sunlight, which ties into the func_train setup that I'll explain now. You can see there are two light_environment entities. One is the regular lighting from the sky, the other is a bright light with a custom style that gives it a lightning flash look. It has a name and is set to be initially dark. The two multimanagers next to it are triggered by the func_train periodically and are used to turn the "lightning" light_environment on and then off again as well as trigger an ambient_generic that plays a thunder sound. This unfortunately created a problem where regardless of on or off the lighting light_environment caused all models including viewmodels to be lit up extremely bright at all times. The info_sunlight counters this using the same values as the primary light_environment. This unfortunately means that models don't get lit up more by the lightning, but it's a better trade off than all model shining brightly 100% of the time in a dark-ish map.
"Okay, but that was just the bottom left corner, what about the big array of..."
Ah, but I'm saving the big one for last! Next we have in the top left corner an info_map_parameters to restrict buying from both teams, an env_rain to add rain to the map, and a small unassigned buyzone to make sure buyzones aren't auto generated at spawn points. Just below that is a small array of player_weaponstrip entities that will be triggered by trigger_multiple brushes set up in a hallway. Why so many of them? People can throw weapons through one trigger brush, so making them pass through 4 at semi-close but unequal distances from each other will make it really difficult for players to smuggle weapons through.
So now, on to that big array of entities. You already know players are getting stripped of all their weapons. They will be forced to run through these triggers leaving spawn. They will then be presented with some func_buttons that will equip them with a knife, a pistol, and ammo. This array is a 12 round setup. It cycles through all 6 bistols, each getting two rounds at a time. Every odd number round will open doors to a lower part of the map and every even number round will open doors to an upper level of the map, so it's two maps in one, as well! The little concrete cube in the top right corner is a func_door that is used to trigger each round. It starts off triggering a 0th round (which you see slightly apart from the rest of the array near the func_door). This is to allow for a unique first round welcome message using two game_text entities and also because of a trigger_hurt that needs to be on every other round (so when it cycles from round 12 back to round 1, the trigger_hurts need to be switched off, however, for the FIRST round 1 they are already off, so triggering them would turn them on which is unwanted). The trigger hurt is to stop players from dropping from the upper map to the lower map safely into some shallow water(whose exact setup will be revealed when I release the map). The trigger hurt needs to be on when on the upper map to kill falling players but off when the lower map is in use so that players running through the water don't get insta-killed.
The 0th round then triggers the round 1 sequence trigger_changetarget that changes the target of the func_door to the round 2 multimanager, so on the next round the round 2 sequence begins. This cycle is then designed to loop through rounds 1 through 12 multimanagers forever. Each round multimanager also triggers a game_text entity that displays the type of pistol available for that round. Every odd number round opens the lower map and triggers a multimanger that then triggers another 2 multimanagers to then trigger the trigger_changetargets that change the targets of the buttons to the proper game_player equip to equip them with the corresponding pistol and ammo. The reason there are so many of them is to ensure each button has it's own equip entity to avoid any hangups (I had issues early on in testing de_pophouse where trying to consolidate certain entities lead to it not triggering for certain players because two or more players might trigger them at the same time). The odd number rounds also turn the trigger_hurt entities off (except, again, for the 0th round entity for the very first round). Every even number round turns the trigger_hurt entities back on and it opens the doors to the upper map instead of the lower map. It doesn't need to trigger all the changetargets for the buttons because it uses the same weapons as the previous round.
Edit: I forgot to mention the trigger_auto in the top right near the func_door that opens the lower map for the warmup before the first round. I also forgot to mention the trigger_auto that kickstarts the lightning controlling func_train when the map loads.
This setup isn't as complicated as it appears, there are just a lot of entities in use (in part because I wanted to ensure smooth operation by giving every button that can be used at once it's own dedicated equip entity). With the button system you could probably easily get away with consolidating equip entities but I'm not anywhere near hitting the entity limit so it will be fine. This is, however, the most organized I've had all my background entities set up on a map and I was really proud of how neat and orderly it all looks.