Wises wrote:i think in regards to Teambased DM games ie; TDM and such , there are no need for flags - as its the first team to get to the desired fraglimit or the team with the most frags at the desired timelimit. Therefore no flags need to be accounted for. However having that ability is pretty cool - just not necessary.. therefore in essence all teams could be spawned antwhere in the map.
You misunderstand. This won't be adding any flags....
The presence and location of 2 or more actors of class FlagBase in the map, are the only
clues this mutator has as far as where the Teambases are. For both TDM and CTF.
If you rename a CTF map to DM, flags will not spawn. But the FlagBase actor is still in the
map and it's location used internally by the mutator to figure out where to spawn the 2 teams.
The FlagBase class itself will only spawn a flag if the game is CTF.
(FlagBase is a default UT class, and has not been altered by this mutator in any way...)
If you play TDM on the regular DM maps, both teams will spawn all over the map.
If you use a renamed CTF map or any map that has FlagBases in it, this will automatically detect the FlagBases, and try
to spawn the players for each team on their side of the map.
I may try to include a new TDM gametype that will use both DM and CTF maps in the available maps list by default.
This would eliminate the need to screw around with copying and renaming maps, and the horrible waste of space
that would require.
regarding the spawn close to other players option could you make this booleanable is saying that admins can perhaps adjust the radius in which players are spawned from each other?
just wondering about Sniper type games and such.. Unless you were to autodetect sniperarena and adjust it automatically idk.
You are on the right track with those questions. Here is how this mutator is handling that currently.
It calculates a number for the radius the spawner will use when it checks for nearby players that is a percentage of how big the map is.
(Caps it so it doesn't waste time with giant radius searches on huge maps....)
The mutator then does a search for a random, valid spawn location using that starting value that was calculated at map start.
If there is any other player in that area, it reduces the starting radius by 10%, and does another check.
It will repeat that up to 16 times, reducing the search radius by 10% each time.
This system is working remarkably well in testing.
It almost never gets close to 16 tries. Even when testing on maps like CTF-2vs2-Crates or DM-Morbius, with me
and 16 bots on. Last tests I did, it was actually taking less tries on CTF-2vs2-Crates than it was on CTF-Face.
Need to do more testing to find the optimal initial starting radius value on that bit.
I am trying to write this thing so it will handle anything like that internally, and not require any values
from an ini file.
It will be plug and play.
Not sure if that problem with the crate spawns on DM-Stalwart still exists in this version or not. It might.
The odds of it happening have been reduced considerably by the addition of many more possible spawn
locations.
I have also made considerable changes to the code that validates possible locations since RC4.
That is on the list of things I still need to test a bit. The amount of testing required to make this thing
work the way I want it to is crazy.
I spent at least 2 or 3 hours last night, just killing myself over and over and over again on CTF-Face and
DM-Hyperblast, to make sure none of the spawn locations were out over empty space.
Just a few more tweaks, and I am going to put it on my DM/CTF and AS/DOM servers and start some
online testing in "real" games. I have been using me and 16 bots in almost all my development testing
so far. It should run even faster with fewer players on.