Spawn Sleepers In Range (Alpha 21 stable)

[vbnet3d]

Source: https://github.com/vbnet3d/SpawnSleepersInRange

 

Experimental mod for 7 Day to Die (Alpha 21) that forces sleeper volumes to spawn in sleepers within a certain range, even if the trigger is not yet activated. Intended to fix issues with pop-in spawning and clear quests failing to spawn in all zombies.

 

This is an entirely experimental mod. Use at your own risk. May affect frame rates if it spawns in too many zombies at one time. I would not recommend using on a server unless you've benchmarked it's affects on your FPS in solo.

Configuration

Mod options can be changed by editing Config.xml in the mod folder.

Installation

Download source to your 7 Days to Die mod folder (usually C:\Program Files (x86)\Steam\steamapps\common\7 Days To Die\Mods).

This is a Harmony (C#) mod. EAC must be disabled.

Edited August 8, 2023 by vbnet3d
Update title to include specific version (see edit history)

[rautamiekka]

Client ? Server ? Both ?

[ddraggy]

Pretty cool, and the config lets you do some QoL things with sleeper spawn behaviour.

 

Highlights:

- Control range at which sleepers spawn. Default is 30, but you can change it to something lower like 10.

- Switch spawn triggers on or off so, if you want, a roomful of zombies can still suddenly show up outside the range you set.

- Control whether spawned sleepers are aggressive right off the bat. Stealth is doable again.

 

👍

[MrSamuelAdams]

19 minutes ago, ddraggy said:

Pretty cool, and the config lets you do some QoL things with sleeper spawn behaviour.

 

Highlights:

- Control range at which sleepers spawn. Default is 30, but you can change it to something lower like 10.

- Switch spawn triggers on or off so, if you want, a roomful of zombies can still suddenly show up outside the range you set.

- Control whether spawned sleepers are aggressive right off the bat. Stealth is doable again.

 

👍

What does changing the value from 30 to 10 do exactly? 

 

I'm looking for, obviously less triggers and making stealth viable in buildings/quests again. Don't like all the pop up and trigger rooms when you sneak kill one zombie. 

 

Is that possible with this mod? 

 

 

 public float SpawnRadius = 10.0f;
        public bool DisableTriggers = true;
        public bool SpawnAggressive = false;

 

 

Would this be correct if that's what I'm looking for?

Edited August 6, 2023 by MrSamuelAdams (see edit history)

[ddraggy]

1 hour ago, MrSamuelAdams said:

What does changing the value from 30 to 10 do exactly? 

 

I'm looking for, obviously less triggers and making stealth viable in buildings/quests again. Don't like all the pop up and trigger rooms when you sneak kill one zombie. 

 

Is that possible with this mod? 

 

 

 public float SpawnRadius = 10.0f;
        public bool DisableTriggers = true;
        public bool SpawnAggressive = false;

 

 

Would this be correct if that's what I'm looking for?

Make the changes in the Config.xml, but those settings seem like what you're looking for.

 

Changing the SpawnRadius from 30 to 10 will change the distance at which the zombies are forced to spawn in from 30 blocks away down to 10 blocks away instead. 30 blocks away is a bit much and may cause framerate issues since that's a lot of zombies. It might spawn in the zombies in the POI next door too. Pick a number that works with how you play but won't kill your computer.

[zztong]

11 hours ago, ddraggy said:

Changing the SpawnRadius from 30 to 10 will change the distance at which the zombies are forced to spawn in from 30 blocks away down to 10 blocks away instead. 30 blocks away is a bit much and may cause framerate issues since that's a lot of zombies. It might spawn in the zombies in the POI next door too. Pick a number that works with how you play but won't kill your computer.

 

I'm curious...

• Is that both the vertical AND horizontal range? Or, is just the horizontal range?
  • For reference, my understanding is Vanilla is range 4 horizontal and range 0 vertical.
• Is that the distance to each potential sleeper or the distance to the zombie volume?
  • For reference, my understanding is Vanilla is range to a Volume, at which time the Volume selects the sleepers randomly.
  • If you're doing range to sleepers, how do you determine which sleepers in a Volume to place?
• What is the modlet doing with Passive Volumes?
• Does SpawnAggressive == False mean:
  • Attack Volumes are treated like Active Volumes?
• Does DisableTriggers == True mean:
  • Key Racks won't open doors?
  • Buttons won't open doors?
  • Trigger Volumes won't open doors?
• Does this in any way affect Generator Quests?

 

Edited August 7, 2023 by zztong (see edit history)

[vbnet3d]

On 8/4/2023 at 12:29 PM, rautamiekka said:

Client ? Server ? Both ?

 

Both. It's a Harmony/C# mod. EAC must be disabled.

[vbnet3d]

14 hours ago, zztong said:

 

I'm curious...

• Is that both the vertical AND horizontal range? Or, is just the horizontal range?
  • For reference, my understanding is Vanilla is range 4 horizontal and range 0 vertical.
• Is that the distance to each potential sleeper or the distance to the zombie volume?
  • For reference, my understanding is Vanilla is range to a Volume, at which time the Volume selects the sleepers randomly.
  • If you're doing range to sleepers, how do you determine which sleepers in a Volume to place?
• What is the modlet doing with Passive Volumes?
• Does SpawnAggressive == False mean:
  • Attack Volumes are treated like Active Volumes?
• Does DisableTriggers == True mean:
  • Key Racks won't open doors?
  • Buttons won't open doors?
  • Trigger Volumes won't open doors?
• Does this in any way affect Generator Quests?

 

• Right now I'm just using Vector3.distance, which is the radius in 3D space. If you feel it would be beneficial to allow the option to make it only horizontal, I could add that as a configurable choice.
• Distance to the volume center
• It flips the volume quickly to active then back to passive to force the spawn
• SpawnAggressive - sleepers are set to active to spawn, and not reset back to passive. This makes them much more alert and responsive to sounds
• DisableTriggers only turns off triggers for SleeperVolume, but not other classes. Most triggers still function as intended. Some newer POIs cannot be cleared with this set to true currently because the final spawn is a SleeperVolume trigger. I am working a a work-around for this.
• Not directly. If the POI would also have a final trigger spawn for a clear quest, the same issue would apply as above. Set DisableTriggers to false for now for these POIs

 

15 hours ago, MrSamuelAdams said:

 public float SpawnRadius = 10.0f;

 public bool DisableTriggers = true;
 public bool SpawnAggressive = false;

 

Would this be correct if that's what I'm looking for?

 

Yes, these are the settings you'd want. Just FYI currently there is an issue with some new POIs where they still require a trigger for the very last spawn, so they can't be cleared with triggers disabled. I'm looking at the code to see if there's a way to work around this.

[rautamiekka]

6 hours ago, vbnet3d said:

 

Both. It's a Harmony/C# mod. EAC must be disabled.

The title (or the keywords) is missing the game version as well.

[vbnet3d]

3 minutes ago, rautamiekka said:

The title (or the keywords) is missing the game version as well.

 

Good point. I don't see a way to edit these.

 

This was built and tested for A21 b324 (stable). If someone can tell me how to edit, I'll get that into the title and keywords

[zztong]

I'm mostly asking as I figure people using this modlet might seek out support as it relates to my POIs. I also see it as some nice experimentation, so I'm curious how it all works out.

 

11 hours ago, vbnet3d said:

Right now I'm just using Vector3.distance, which is the radius in 3D space. If you feel it would be beneficial to allow the option to make it only horizontal, I could add that as a configurable choice.

 

It's an interesting design decision.

 

I wouldn't say I know all of the compelling reasons why TFP doesn't do vertical distances, but as you walk through a skyscraper a vertical distance of 20-30 blocks could involve volumes 3-5 floors above the player, unlikely to be relevant.

 

On the other hand, if you talk about a POI like a grain elevator or silo, a volume 10-20 blocks below you could be very relevant. I assert those situations are rare, but they do happen and I know players hate dropping into a volume only to have it spawn around them.

 

The most common frustration with TFP's 0 Vertical distance is that people can't see zombies in an attic until they set foot on the attic's floor. We try to cover for that by having the volumes extend down a block or two into the floor below, but sometimes that isn't possible.

 

11 hours ago, vbnet3d said:

Distance to the volume center

 

Cool, so the volume-to-sleepers relationship remains intact.

 

This is interesting. In theory, you can have some really large volumes that are bigger than the distance. Or, forget theory. If you set the distance to 10, there will certainly be volumes that are larger than that distance so you'd have to enter the volume to reach that distance if you're measuring to the center. POIs with an outdoor component are the most likely to do this. I can think of two POIs in my modlet to test against: Stone Quarry and the ground level of the Vault. Among the TFP POIs, I wonder how the Trailer Court plays out. IIRC it has one volume that covers the most of the 42x42 plot and surrounds other volumes.

 

I could see where it might be better to test a range to the closest edge or corner of the volume to account for really large volumes, but that sounds like many more computations. I could see where distance configuration might be expressed both horizontally and vertically to try avoiding spawning zombies several floors above and below the player, but then even more computations. I'm a novice at this, but would that be calculations to 8 different points (each corner of the volume's cube) for both horizontal and vertical? Where as right now you have one 3D distance to calculate?

 

It sounds like maybe there's a performance trade-off here. The costs of spawning zombies to stand around or the cost of more math to avoid spawning zombies to stand around.

 

11 hours ago, vbnet3d said:

It flips the volume quickly to active then back to passive to force the spawn

 

Does that work? I mean, once they spawn does setting it back to passive let them activate or do they just stand there and drool? I'm wondering if the trigger that would have spawned them also gives them their initiative. I probably don't know enough to reasonably speculate possible side effects.

 

11 hours ago, vbnet3d said:

DisableTriggers only turns off triggers for SleeperVolume, but not other classes. Most triggers still function as intended. Some newer POIs cannot be cleared with this set to true currently because the final spawn is a SleeperVolume trigger. I am working a a work-around for this.

 

I'm glad to hear the other triggers still work. I regret I don't have a suggestion, but will be curious about the work-around.

Edited August 8, 2023 by zztong (see edit history)

[vbnet3d]

6 minutes ago, zztong said:

It sounds like maybe there's a performance trade-off here. The costs of spawning zombies to stand around or the cost of more math to avoid spawning zombies to stand around.

...

Does that work? I mean, once they spawn does setting it back to passive let them activate or do they just stand there and drool? I'm wondering if the trigger that would have spawned them also gives them their initiative. I probably don't know enough to reasonably speculate possible side effects.

...

I'm glad to hear the other triggers still work. I regret I don't have a suggestion, but will be curious about the work-around.

 

1. Distance computations in 3D space are considered expensive because they rely on the square root... but if we think we're only calculating for a handful of SleeperVolumes at a time, adding a couple more calculations *shouldn't* be overly expensive. I could take the 4 corners of the bounds, plus the center. 5x more calculations, but also much more flexible.

 

2. Yes, because it resets them to their normal sleeper state. They'll still wake based on normal sound/movement. If you don't reset the passive flag then they are extra alert, and wake too easily. That being said, I left it as a config option because some people said they preferred it that way.

 

3. I found the workaround and pushed it in a new version. Essentially the triggers do 3 different things: set the trigger type flag, set the player as having touched the volume, and then call logic that triggers any spawns. The former 2 are responsible for the auto-attack trigger mechanism, best I can tell, so I created an additional option to still allow clear quest trigger spawns, which so far has worked on the 2 POIs I flagged as my test cases. It probably needs more testing and tweaking, but it's progress/

[zztong]

11 hours ago, vbnet3d said:

1. Distance computations in 3D space are considered expensive because they rely on the square root... but if we think we're only calculating for a handful of SleeperVolumes at a time, adding a couple more calculations *shouldn't* be overly expensive. I could take the 4 corners of the bounds, plus the center. 5x more calculations, but also much more flexible.

 

Is it just and handful? Some POIs have 50+ volumes. How often does the game do this check?

 

Actually, now that I think about it, if you first compare the character's elevation to the elevation of the volume's two defining points, you wouldn't have to do a distance calculation. You'd just establish if the character was at a viable elevation to worry about the distance, or not, and potentially get away with just subtraction.

 

Example: If the two points of the volume's bounding box have Y's of 20 and 30, but the player was at elevation 15, then the volume is 5 blocks above the player. If you have a vertical tolerance of something like +/- 2, then you compare 5 to 2 and determine you don't have to worry about the distance to the volume.

 

Err, well it works in my mind, but that doesn't mean I'm not full of... something.

[vbnet3d]

6 minutes ago, zztong said:

Is it just and handful? Some POIs have 50+ volumes. How often does the game do this check?

 

My impression, and this is a bit rough, is that it runs all the volumes in the current chunk, during each Tick() cycle. I don't know how many times Tick() is run per second. I have considered optimizing by only running the logic every other Tick(), but it seems to me that the actual spawn logic is actually what hits performance rather than the checks.

 

For perspective - 50-100 distance checks is still pretty trivial for most systems - but of course in the downtown of a city with multiple T5's, we might have 5-10x that number. I really need to benchmark that. So far I've been benchmarking in regular random-gen downtowns. Probably need to do so in a really dense custom map.

 

I'll look into the additional calculation options. It's a good idea.

 

 

[zztong]

26 minutes ago, vbnet3d said:

My impression, and this is a bit rough, is that it runs all the volumes in the current chunk, during each Tick() cycle.

--

For perspective - 50-100 distance checks is still pretty trivial for most systems

 

I see. These volume checks, they would be per-player, right? If so, then 8 players means 50 becomes 400? Perhaps not that bad if players are moving around together. Then maybe you can mark a volume and avoid processing it again, somehow... err, that sounds problematic though I'm not sure why. (Probably because players rarely stick together by distances that would be relevant in this case.)

 

I'm trying to imagine a "worst case" ... 8 players, each driving a 4x4 at top speed through their own city's downtown district. They're all changing chunks quickly and there's a large number of volumes per chunk. Obviously, some servers allow more than 8 players, but uhhh, yeh.

 

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time. I think hitting that shuts down sleeper spawns. If that's true, then oddly enough, maybe it could also be a signal to shut down the evaluation of some kinds of zombie volumes, or maybe that's bad...?

 

Quote

I have considered optimizing by only running the logic every other Tick(), but it seems to me that the actual spawn logic is actually what hits performance rather than the checks.

 

Would it help if, after you determined distance and found a volume to be far away, that you flagged it to "skip" some number of ticks before being evaluated again? Like, if it's 100 blocks away, skip the next 3 ticks, but if it's 50 blocks away just skip the next one.

Edited August 8, 2023 by zztong (see edit history)

[vbnet3d]

39 minutes ago, zztong said:

These volume checks, they would be per-player, right

 

Yes. I don't think there's a clean way around this. You'd have checks, but not additional spawns. Marking the volume as "processed" isn't ideal because if you go back out of range the zombies will despawn.

 

41 minutes ago, zztong said:

Then, IIRC, there's a limit to the number of sleepers the game can have at any one time.

 

Yes there is a limit, although I don't remember it off the top of my head. It is spawns that actually hit performance hard though rather than the checks, so I think the true concern is the number of spawns - which reducing the range mitigates to a degree.

 

42 minutes ago, zztong said:

Would it help if, after you determined distance and found a volume to be far away, that you flagged it to "skip" some number of ticks before being evaluated again?

 

This might be feasible. I'd want to benchmark the cost of the checks vs the cost of tracking ticks per volume. The latter is probably more efficient, but it's hard to say.

[zztong]

I wonder if it makes any sense not to check volumes if a player is riding in a vehicle. I say this having driven a motorcycle through buildings, even repaired stairs so that I could bring it with me as I explored a large building. But, I'm thinking when a player is driving a vehicle around on the ground between destinations, is it really worth processing a volume to spawn zombies to get left in the dust.

 

Maybe it's along the lines of ...

 

If the player is riding in a vehicle AND if the vehicle is currently on a terrain block, then skip. Or maybe there's a nice way to compare the vehicle's Y to "ground level." Alas, that probably means it will check volumes when crossing a bridge or ramps off of something. heh

 

Hmm, I suspect you could avoid checking volumes for players who are not driving a vehicle they are riding in. That is a passenger is going to be at the same location as the driver.

Edited August 8, 2023 by zztong (see edit history)

[vbnet3d]

9 minutes ago, zztong said:

I wonder if it makes any sense not to check volumes if a player is riding in a vehicle.

 

I like this idea. Maybe there's a way I can get the POI bounds, and if the vehicle isn't inside the POI bounds for the volume, I skip

[vbnet3d]

Based on conversation with @zztong, I made the following additions and changes:

 

• Added the option to split proximity checks into horizontal and vertical checks. This means that you can have only one or two floors spawn in at a time in a large multi-story POI if desired
• Added the option to only spawn zombies if the player is within the bounds of the POI. This reduces spawning of volumes in neighboring POIs. Useful in big cities.
• If a player is in a vehicle, the vehicle must be within the bounds of the POI to spawn zombies, as above. This reduces the spawns you get while driving through crowded areas.
• If the spawn radius is 15 units or fewer, the corners of the SleeperVolume are also used for proximity checks, in addition to the center of the volume. While this adds more points to check, it also ensures that larger volumes don't suddenly spawn in when the player is inside them.

Edited August 9, 2023 by vbnet3d (see edit history)

[Zentropy]

On 8/7/2023 at 8:42 PM, vbnet3d said:

 

1. Distance computations in 3D space are considered expensive because they rely on the square root... but if we think we're only calculating for a handful of SleeperVolumes at a time, adding a couple more calculations *shouldn't* be overly expensive. I could take the 4 corners of the bounds, plus the center. 5x more calculations, but also much more flexible.

 

Don't use square root for these and problem solved!  Squared magnitude is fine for comparisons and makes the checks incredibly fast instead.  Square whatever distance number you're checking against and use that.  You only need to finish the distance formula if you're trying to display a "real" number to the player or otherwise need actual distance, which this doesn't.

 

[vbnet3d]

15 minutes ago, Zentropy said:

Don't use square root for these and problem solved!  Squared magnitude is fine for comparisons and makes the checks incredibly fast instead.

 

I may end up doing this if needed. I benchmarked with square magnitude and it didn't seem to make a perceptible difference. The real performance hit is the zombies themselves. The actual number of distance checks isn't high, so I felt comfortable sticking with the standard Vector3.distance method for the time being.

[MrSamuelAdams]

Everything seems good. 

Besides that jolt/hitch when they all spawn in. 

I love using this mod though. 

[MrSamuelAdams]

Is there any update on this mod. I may have to remove it, since I have died a few times due to the hitching/stuttering that happens when you walk by POIs. Is there anyway to tone that down or is that just part of the mod? 

[vbnet3d]

9 hours ago, MrSamuelAdams said:

Is there any update on this mod. I may have to remove it, since I have died a few times due to the hitching/stuttering that happens when you walk by POIs. Is there anyway to tone that down or is that just part of the mod? 

 

I'd recommend turning down the spawn radius in Config.xml (mod folder). A lot of people have had success with SpawnRadius at 10 and HorizontalSpawnRadius at 5.

 

The hitch is the actual internal spawn-in logic, which I'm not sufficiently familiar with to try to optimize, but most likely you're seeing that stuttering due to too many zombies being spawned in at one time. Reducing the range will help with this.

[Rotor]

On 8/30/2023 at 8:02 AM, vbnet3d said:

The hitch is the actual internal spawn-in logic, which I'm not sufficiently familiar with to try to optimize, but most likely you're seeing that stuttering due to too many zombies being spawned in at one time. Reducing the range will help with this.

 

This is true even in vanilly with a less than super duper system like mine.  If I am head down doing something and  the "hitch" happens, I know nothing good comes after it :).