You can always use any TWO with /setspawnpt. This isn’t a bug or exploit, its an undocumented feature (it existed in a slightly different form in RTCW too). It lets you do things that the UI wouldn’t let you, such as returning to autospawn mode after you have manually selected a spawn.
The ownership of a TWO has absolutely nothing to do with where you can spawn. If you don’t want players of the particular team to spawn in a particular place, you need to make those spawnpoint entities (team_CTF_<color>spawn) inactive. alerting the TWOs just changes the stuff for the UI.
Which TWO a player has selected (either in the UI, or with setspawnpt, the two are exactly equivalent) has nothing to do with where other players can spawn.
Which TWO a teams autospawn is set to has no effect on where the other team can spawn.
The above are very simple bits of code, and they just don’t interact in they ways that have been suggested.
What follows is a technical description of why the above is true:
A TWO provides
- a location that players can choose to spawn as near as possible to.
- a name for that location.
- a team specific icon on the limbo menu.
TWOs are read from the .bsp and assigned numbers (from 0 to N). This means they are fixed for a given .BSP file, but not in any predictable order, and not fixed over different compiles of the same map.
setspawnpt selects which TWO a player wants to spawn near, using the currently available team_CTF_<color>player entities. This selection is stored in the clients session data, so survives map resets, but there is code to make sure it is cleared on map changes. If you use setspawnpt X, it selects TWO #X-1. setspawnpt 0 is a special case which tells the game to use the ‘autospawn’ location.
The autospawn location is set by the script, and stored per team in a global variable, as a TWO number. It is reset to 0 on map resets (along with all entity state, including script state). This means if a player chooses autospawn, and spawns before the autospawn is set, they will get the equivalent of having done /setspawnpt 1, spawning as close as possible the first TWO in the .bsp.
It is worth noting that the autospawn does not change anything in the clients session data. It is checked when the client actually goes to spawn. It also does not affect the team_CTF_<color>spawn entities in any way.
If you setspawnpt to a number < 0 or > 15, it will be as if you setspawnpt 0. If you select a spawn point that doesn’t exist (say /setspawnpt 10, on a map that only has 5) it will be as if you set your spawnpoint to a TWO at the origin of the map.
There is one more factor that controls if you can spawn at a given team_CTF_<color>spawn. If the spawnpoint nearest your desired TWO would cause you to spawn inside another player, the game picks the next nearest, until it finds one that is clear. If it can’t find one, it just spawns you inside another player…
I did some more digging in the various maps. It turns out that, in supplydepot2, the 'first" TWO is the one for the allies first spawn. The way the map is laid out, this is very nearly equidistant between the flag and the axis back spawns. The first few axis players will always spawn at the flag (in the corner nearest that wobj). As these spawns fill up, the ones at the axis back spawn will be the nearest. (this seems odd, but if you go way up in the sky with noclip, it makes sense). That explains why not all players would spawn back.
To specifically respond to EBs post, there isn’t much to say. The general statements about bugs and timing are speculative, and don’t tell us anything about the problem at hand.
The only concrete statement I see is that one teams autospawn somehow affects the where the other spawns, but this simply isn’t true. If the supplydepot script with only the wait changes had a spawn problem, this wasn’t the cause. Lacking any other facts, I can only speculate that it was an error in testing. That can happen to any of us. When I first tested this, I forgot that ET always looks in .pk3s first, even if sv_pure is 0, and so tested the old script thinking I was testing the new one. Ooops :banghead:
The fact that some of the official maps get away with a 500 wait doesn’t mean anything in particular. Looking at them in more detail confirms what I have written above:
On radar the first TWO is at the CP. In this case, it means axis player will spawn at the flag, unless perhaps the flag room is really full. On fueldump, the ‘first’ TWO is the tunnel. On goldrush, the first one is at the tank.
So in other words, the maps that got lucky with entity order have long waits…
Furthermore, you can see the effect of players spawning before autospawn is set on the above maps. Players spawn in slightly different places on the first spawn of the map, compared to subsequent respawns.
