Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
"Also if I'm understanding correctly if I make my squads in the ini file all squads of 10 then we are more likely to reach the maxmonsters limit?(as long as they aren't killed at 10 a second)" This is accurate. However, this issue is, along with dynamic zed scaling/gradients, at the top of my todo list right now, so I'm hoping to introduce options to fix it in my next release.
Here's my (now fixed) code: https://github.com/amimoto/Dodeca/blob/master/Classes/DAISpawnManager.uc
My intention is to be able to allow map makers to script specific squads at particular KFSpawnVolumes. The actual spawning at the volume seems to be native so I had to reimplement that portion. Maybe some of the concepts in my code might be useful?
Darn fun to see the higher level play that dandyboy and folks do.
If you mean KFSpawnVolume.SpawnWave(...), yeah, it's native and it's annoying. The second parameter to that function is called bAllOrNothing (or something like that), but the function does not account for pawns failing the collision check and getting destroyed, so it seems pointless to even have that param. I also have my suspicions about their native implementation of custom projectile collision tracing, considering how husk fireballs behave these days... wish I could see that source.
Last night, I implemented the concept of a spawn cohort. This is a group of multiple squads that all spawn at the same time.
To the user, this exposes two new configuration dimensions:
* CohortSize: the maximum number of zeds the spawnmanager will spawn on any given wakeup. It may have to spawn less than this number if the map's spawnpoints are already saturated by zeds.
* MinSpawnInterval: this floating point number sets the minimum time, in seconds, between spawnmanager wakeups. This is not mutually exclusive with SpawnMod. SpawnMod=0 will cause the spawner to wakeup every MinSpawnInterval seconds; SpawnMod>0 means the spawner might sleep longer than MinSpawnInterval, depending on TWI's usual padding logic (which incorporates a time-varying sinewave, whether there's a pending leftover spawn squad, whether it's an early wave, etc.).
Internally, this works by sorting the list of available spawnvolumes from most to least preferred according to TWI's standard preference algorithm, then spawning one zed per volume until either the cohort size is reached or the list of eligible volumes is exhausted. It obeys MaxMonsters.
I've also added an option to disable KFAIController.bCanTeleportCloser.
I think this will alleviate bottlenecking, insofar as the map has sufficient spawnvolumes to accomodate zeds. For instance, on outpost, setting MinSpawnInterval=0.250 and CohortSize=48 resulted in over 154 zeds spawning in under a second when the first wave started (after the standard 5 second delay between wave start and first spawn, which has been in the game a long time and which I haven't altered).
Everything I described above is implemented locally, and now I'm just documenting and polishing it (adding chat commands, config options, etc.).
There's one more thing I'm contemplating adding -- what I'm about to describe below is not done yet. These options are useful new dimensions of control, but they also make it hard to estimate the real difficulty of any given CD configuration. I'm considering making CD keep running spawnrate statistics within each wave, then echoing them at the end of the wave. So, in trader time, maybe CD could automatically say what the average spawnrate, in zeds/sec, was over the whole last wave (really time of first spawn to time of last spawn, not beginning or end of the wave itself), 60 sec peak, 30 sec peak, or something like that.
Great work on overcoming the 1s delay, keep it up!