So some of you might know that it is possible to grant entities, including the player a unique name via the Targetname output such as by touching a trigger using an Addoutput on the !activator of the trigger. However, if you wanted each player on the server to have a specific name the issue becomes how to correctly distribute out the names and how to handle players leaving the server.
Fortunately 200 pointed out that the wacky fellow from TF2maps, boojumsnark had worked out a solution (
https://tf2maps.net/threads/egg-war-mechanical-logic-and-other-complexities.22398/#post-298742). The post is currently missing some pictures so I'd thought I would post my attempt to replicate what is described there.
What this doesWhen a player joins the server they activate a trigger around the spawn zone which will assign a unique name (p1, p2....p24) for up to 24 players. If a player leaves the server, the logic system evaluates which players are in the game still and if there is a free name it is made available for the next player to join the server.
Effectively, each of the 24 players in the server will have unique names. This is quite handy if you want to do interesting stuff like parenting specific objects to specific players or for filtering for each player.
If you just want the prefab grab the link below and copy all the entities into your map. Just make sure to position the spawn zone trigger ('player_namer') around where your info_player_teamspawn entities are, as well as making it sufficiently large that a player can't leave the zone before it has had time to fire. At this early stage I can't guarantee 100% certainty of this functioning perfectly online without further testing.
Link to current prefabhttps://www.dropbox.com/s/823bnq8xo6rb12t/player_naming.vmf?dl=0How this actually worksIf you want to know whats actually going on I'll attempt to describe it based upon my understanding of boojum's work.
When a player without a unique name activates the 'player_namer' trigger_multiple it will attempt to fire 24 relays which are initially all disabled. Each of these relays has outputs which target the !activator giving them a unique name and a specific Addoutput which tells the player entity when prompted to attempt to press a button corresponding to their relay (which looks like 'OnUser1 p_b_1:PressIn::0:-1'). Additionally the relay will turn on an env_laser which attempts to fire through a series of 24 button blocks (the same ones corresponding to the relays), after doing this the relay disables itself. When the laser damages a button it moves upwards, enabling the corresponding relay and then turning off the laser.
Overall this functions as a mechanical logic system which will sequentially enable each of the 24 relays as each button moves upwards, each corresponding to unique player names and OnUser1 commands, which are fired at the player_namer trigger. It should also be noted it is possible to do this with a logic_branch system also described in the linked post, but overall this method makes more sense to me, it also has an ingame visual indication which is handy for debugging.
When a player leaves the server they send an automatic Use input to an entity called 'game_playerleave' (this is handled automatically by the game itself), so by making a button with this name we can perform a roll-call of all the players. First when it receives a Use input the player_namer trigger is disabled as well as all of the relays, and all their corresponding buttons are moved back down. Additionally, the button fires a 'FireUser1' output to every named player; which tells each named player still in the server to send an input to their respective buttons moving them back upwards out of the path of where the laser would go. Any player which doesn't respond to the roll-call has their button remain in the down position in the path of the laser. After this the laser is reactivated to select the next available relay, (effectively making the names of players which leave available again) and then the player_namer is reactivated so the system can be used again (these delays can be adjusted on the prefab).
Lastly, a logic_auto on the round start initialises the system by firing the button 'game_playerleave' with a Use command which as described above will reset all the entities and fire the laser to pick the first relay.