Wandering common density still varies greatly from round to round on 2.2.0

[GoogleCodeExporter]

The num_reserved_wanderers cvar doesn't seem to do what we thought it did.

Wandering common density is still uneven on 2.2.0.

Possible fixes:
1. Find how the director allocates common, and coerce it.
2. Control director start-of-round rage, or throughout-round rage

Original issue reported on code.google.com by prodigysim@gmail.com on 7 Aug 2010 at 8:39

[GoogleCodeExporter]

Try cvar z_wandering_density and versus_wandering_zombie_density. They default 
to 0.03 and 0.027 respectively. ZombieManager::OnFlowDistancesInitialized() 
seems to use these along with a randomInt calculation to spawn up an amount of 
wanderers. I don't know the full details of the calculation (it's late), but 
it's likely that setting them very high could coerce wanderer density.

Original comment by prodigysim@gmail.com on 7 Aug 2010 at 9:10

[GoogleCodeExporter]

Resetting of director "frustration" can also be done by doing a quick 
director_stop / director_start so the commons "match" for both teams upon round 
start. (sv_cheats 1, local host, director_debug 1 to see it reset)

Like how the first team gets 0 commons around start area, where second team 
gets all 30 spawned right out of the door.

z_wandering_density often fucks up the "rushing" part of the game. Or at least 
in L4D. When density is too high and survivors are making their way through the 
wanders, you can see the director go into relax mode almost instantly, causing 
the next ~200ft to be clear of commons. However setting the director relax 
cvars to 0 doesn't really affect anything. Maybe its different in L4D2, cvars 
of interest:

director_relax_max_flow_travel 3000
director_relax_max_interval 45
director_relax_min_interval 30

Also maybe try setting it to 1, it might be like z_mega_mob where it can't be 0 
but 1 works perfectly.

Besides that you could possible look into population. I believe the director 
spawn commons/wanders as its population rules is. E.g. first team got about 200 
wanders, the next team will get ~200 wanders as well but it possible does it in 
random areas.
A cvar that might tell something; z_debug_population.

If population is truly the cause of something, it may be possible to edit. 
There is a hidden cvar called z_population which contains the string "default". 
The desc of the cvar: "Default population on the current map (saved/loaded in 
the nav mesh)". However that sounds like custom nav meshes is required :/
Other cvars: z_show_population_density
Cmd: z_reset_population_counter

Just throwing ideas out there.

Original comment by MrZer...@gmail.com on 20 Aug 2010 at 3:12