Boidster

You may want to read the description more closely. It's pretty useful once you have a supply of AP ammo. Multiple kills per bullet.

The XML implies that there's a different sound, but of course the actual .wav could be identical! <property name="SoundAlert" value="Enemies/Base_Zombie_Male/zombiemalealert"/> <property name="SoundSense" value="Enemies/Base_Zombie_Male/zombiemalesense"/> <property name="SoundHurt" value="Enemies/Base_Zombie_Male/zombiemalepain"/> <property name="SoundDeath" value="Enemies/Base_Zombie_Male/zombiemaledeath"/> <property name="SoundAttack" value="Enemies/Base_Zombie_Male/zombiemaleattack"/> Edit to add: I extracted the sound files and learned a) there are 3 different 'sense' sounds, 6 different 'alert' sounds, and 10 different 'attack' sounds for the standard template zombie male (there are variations and special sounds for some types of zombies i.e. crawler, screamer, demolisher) b) 'sense' sounds are obviously different; 'alert' and 'attack' sounds are quite similar. I can't see any but the most focused player knowing, in the midst of a group of zombies plopping out of ceilings & closets, which sounds signify a real targeting/attack vs. which are just alerted zombies coming to investigate. I actually think the game would play just fine if the 'sense' sounds were used for both 'sense' and 'alert'. You know a zombie is awake and aware - if it starts moving your way you'll know it's been alerted to a noise or whatever. Save the more vicious-sounding noises for real attacks.

Yeah, the numerous tests, accompanying screenshots, debug info, and faatal's own confirmation in this very thread put the lie to this myth. It is perfectly possible to stealth an attack volume. Copious evidence right here in this thread. (It has nothing to do with noise levels, though.) If the argument is that it should be easier, or require lower perk levels, to successfully sneak into every attack volume in every POI, that's fair. Maybe the balance isn't right.

Well, I can't say every single time I guess because I haven't done exhaustive testing of every POI. I've mainly been using warehouse_06 for recent testing, but they've been consistent in my tests there. The distance an attack sleeper can 'see' you is hardcoded to a range of 3m to 15m* though and in the example above I was far enough away (11.1m) to not be detected at my illumination and stealth skill. In a different attack volume, where the Zs are closer when I trigger them? I might get detected. So definitely, stealth is not an always-works thing, and it shouldn't be IMO. 3/5 was good enough to do okay in the ground areas of warehouse_06. Might not be in other POIs. But I think that's alright. I'll try to go through the entire warehouse to see how different volumes react. I actually do wish the Zs would shamble out even if they don't target the player. The game uses different sounds for when the zombies hear something vs. when they target something, which is an organic way to indicate the situation but hard to catch every time. I can't tell every grunt and groan from every other. Roland's idea of bringing back the eye icon is good, as an option or a mod at least. If the player has (and wants to have) a way to know if they're currently targeted, then having the Zs bust out, but not really have a target, would make for exciting duck-and-cover. *Kinda. I'm simplifying a bit.

I probably misunderstand the issue, but I think we've shown that a moderately-perked player (3/5 FtS) can successfully enter an Attack sleeper volume and not a single zombie will stir. What is the evidence of stealth failure that is compounded by having many/most POIs with Attack-style volumes?

Can you expand more on this idea? If you have awakened a group of sleepers (they are in 'active' mode), what is it that would cause you to be right on top of them before they can see you (if the room is lit)?

We play MP and stealth and the only perk we regularly disregard is Pack Mule.

I've thought of doing this and removing them from loot. But I'm my game's engineer/crafter so I'm biased towards "best stuff should be hand-crafted".

I wrote a mod (really, my first actual useful DLL-based mod, yay!) which adds instrumentation to the stealth code: Right now it only logs when you first trigger a sleeper volume, and then for 'attack' volumes, the results (and math) for each zombie's "can I see you" check. The above example is with 3/5 From the Shadows. The key value is the LightAttackPercent, which is used as a way to translate your visibility into a sort of special attack-zombie-only "distance they can see you" number (ignoring line of sight!). That number ranges from 3 to 15 meters (hardcoded) and the game uses linear interpolation (lerp) to calculate the value. If your LightAttackPercent were 0 (very stealthy player), then the "lerp" you see above would be 3. If your LightAttackPercent were 1 (not stealthy at all), then the "lerp" would be 15. All the ranges between 3 and 15 are dependent on your stealth skill (and also environment light I think, but I want to confirm that). The game compares actual distance ("distance to player" in the log) with the lerp - if the distance > lerp, you are undetected (but zombie goes 'active'). Otherwise, ATTACK! I can add arbitrary logging into this, so if you have any ideas let me know. I will add a couple of more things myself and then publish to Nexus a little later.

Kinda. I guess the way I'd put it, which really is just restating what Faatal said I think, is that attack volume Zs get a special chance to 'see' you (disregarding LoS so...weird) which uses different logic from a normal zombie. If they see you, then they also have a different path to the "attack the player" AI behavior, which uses that 1200 ticks hard-coded duration (and which Faatal is reducing to 400 it seems). The other two functions, not used by sleepers, also end up with "attack the player", but they get there after passing through the From the Shadows perk enhancements to chase time. Regardless of how a Z gets into the "attack the player" AI behavior, from then on it's the same code running the show. In all cases, the fixed-1200 ticks and the 1200-ticks-modified-by-FtS-perk are used for exactly the same thing. Your testing seems to show what Sithdarth suggested, though - that changing the AI task to a different flavor of "see and attack" can reset the counter to something lower.

Interesting! I am mostly poking around for two reasons, 1) to learn in more detail what's going on and 2) to support other evidence or claims of certain behaviors. As a former coder myself, I place much higher weight to what the code says is going on vs. what I think I see going on when I play. All that means is if the play test appears to do X, but the code says it should do Y, then I'm more likely to distrust my own interpretation of the play testing. That's not really fair; it depends on how confident I am in the code interpretation, which is kinda your point. Different perspectives. Of course it is difficult to piece everything together because the code is HUGE. And, of course, there are no comments available.

Aaand I'm back. So the Entity object has a function, CalcInvestigativeTicks(), which uses the EnemySearchDuration modifier from the From the Shadows perk. The perk looks like this: <passive_effect name="EnemySearchDuration" operation="perc_add" level="0,1,2,3,4,5" value="0,-.17,-.33,-.5,-.58,-.67"/> Since this is a percentage adjustment, the perk descriptive text is very dependent on a base search time of 60 seconds. And luckily there are only two "attacking the player" places where search time is given, and they both work out to 60 seconds. They get there a bit differently. The CalcInvestigativeTicks() function works like this: Actual Ticks = [Base Value Ticks] * (1 + [EnemySearchDuration %]) So if you are at perk level 2 (adjustment -33%) and the event sends in a base value of 400 ticks (20 seconds), then the actual search duration would be: 400 * (1 - 0.33) = 400 * .67 = 268 ticks = about 13 seconds. Okay, makes sense. So now where does the 60 seconds base come from? The CalcInvestigativeTicks() function is only called in three places: In each case a different value is passed in as the "base value", but the two attacking-the-player ones both work out to 60 seconds, which means the perk will work: SetAsTargetIfHurt: this.theEntity.CalcInvestigateTicks(1200, revengeTarget); -- 60 seconds SetNearestEntityAsTarget(Continue): CalcInvestigateTicks(Constants.cEnemySenseMemory * 20, this.targetEntity) -- that constant is 60, so this is also 1200 ticks or 60 seconds SetNearestEntityAsTarget(Seek Noise): this.theEntity.CalcInvestigateTicks((30.0 + this.RandomFloat * 30.0) * 20, player)); -- random 30-60 seconds, but this is "I heard something" searching (following breadcrumbs), not actively targeting Final point - none of these functions seem to be used when a sleeper wakes up and targets you, that I can see. So the perk will have nothing to do with how long a grumpy sleeper will chase you. Maybe if you hit it, you trigger the "SetAsTargetIfHurt" AI function, though, and then the perk applies?

So, lot going on I think. First off, I don't think the ground-floor zombies of warehouse_06 are in an 'attack' volume, even though they seem really intent on attacking you. I say that because Faatal and the code both say that if it's an attack volume, as soon as you touch the volume (the SleeperVolumeTouch() function I posted just above) then every zombie is going to wake up and at least be in Active mode. If they can 'see' you (using that hard-coded, line-of-sight-be-damned math) then you get targeted. I'm going to open it up in the POI editor and snoop around the volume to see what I find. Anywho, if it is not an attack volume, then I think the "wake" numbers you're seeing relate to this (from the zombie template): <property name="SleeperWakeupSightDetectionMin" value="-40,5"/> <!-- Indiv.Random. sight capability - "I see you" light value at point blank --> <property name="SleeperWakeupSightDetectionMax" value="340,480"/> <!-- Indiv.Random. "I see you" light value at "SightRange" --> <property name="SleeperSenseSightDetectionMin" value="-10,0"/> <!-- same for groaning, not waking --> <property name="SleeperSenseSightDetectionMax" value="200,300"/> That 200 may very well be the wake detection threshold at <distance to you>. Does it change when you move closer? The XML above sets a range from <point blank> to <limit of Z's sight> for visual detection. (Sound is a bit different, because it emanates from you and does not attenuate by distance - max volume is 'heard' to the item/action's sound range.) So maybe your janitor had these values: Illumination of theFlu Required To Wake Up Point-blank range: 1 Max sight distance: 380 They use linear interpolation to compute the "light required to wake up" at various distances in-between. It's in the [math] stuff that I left out before. So if you were, say, 50% of the way between point-blank and max-range, I'd expect the "light required to wake up" to be (380-1)/2 = 189.5. Move closer, it gets smaller = less light on you is required for the zombie to see you & wake up. Is that how the "wake" number behaves? Or is it just stuck at 200 regardless of how you move? I'm going to chase this expectation and perk benefits down if I can. Faatal gave us the standard function which is called when the player is set as the target (same for sleepers as it is for normal Zs). It's pretty easy to see what is calling that function, and what timeout parameter is being sent in.

I think he's talking about this (edited for clarity, obviously): SleeperVolume.Touch() { if ([this is an attack volume] and CanSleeperAttackDetect()) { ConditionalTriggerSleeperWakeUp(); -- wake up SetAttackTarget([player], 1200); -- set player as attack target for 1200 ticks } else entity.SetSleeperActive(); -- either not an attack volume or player is stealthy enough to not be 'seen' so just go active } Gonna change that 1200 to 400 is my guess. Absolutely. If you are crouched, the Z's get that 'freebie' check on you like I described a page or two ago. This is seriously edited for clarity: public bool CanSleeperAttackDetect() { if (player.IsCrouching) { [do some math using player's stealth-adjusted light level] if ([distance from Z to player ignoring line of sight] > [the math result above]) return false; -- nope, sleeper can't detect you (but it's gonna go active anyhow) } return true; -- either player is not crouching, or the math above didn't work out in player's favor: ATTACK! } The thing about the [math] above is that it does use some hard-coded values for the zombies alongside the player's stealth numbers, meaning it's a kinda attack-sleeper-specific calculation. And, I guess, idential 'senses' for any type of attack sleeper zombie? So your 3-10x more accurate senses might be right. The standard day-to-day stealth checks for vision use variables from the zombie's stats (in XML) and the player's stealth to calc. Not hard-coded.

I glossed over something in an earlier comment and I'll go back and correct it. There IS an auto-agro mechanism in "attack" volumes, if you are not crouched. That is, the CanSleeperAttackDetect() function always returns 'true' (meaning the Z can attack you) if you aren't crouched. So for players who aren't trying to sneak, every zombie in the volume absolutely will set you as their target and chase you for 60s, soon to be 20s. No matter where they are hiding, line-of-sight or not, etc. If you go in all "come at me bro", they will come at you. Where did 3-10 more accurate senses come from? Not disagreeing, just interested how you calculated that. I can see that it's hard-coded, but I dunno how to get from there to 3-10 times more accurate. I'm looking at CanSleeperAttackDetect (used for sleeper volumes) and CanSeeStealth (used I think for normal day-to-day stealth). Should I look elsewhere?

Another option which I use in my co-op server where I'm on all the time, but my friend only plays once a week or so, is to use settime to push the day back a few days. So maybe I play from day 29 to day 34 and I'm going to get into the Day 35 blood moon before we play together. I'll use settime to go back a day so I can keep playing without hitting horde day. Of course this has the effect of us getting quite a bit more done in the "7 days" between hordes than we would otherwise. We might get 8 or 10 in-game days of work done because I keep pushing the day back until he can play. Also other folks have reported issues with settime and trader resets. We've never experienced any problems with that, but we might just be lucky.

Preach it, brother! Weekly map-wide trader circuits require the gyro. Takes a fraction of the time to fly between 7 traders vs. driving roads or taking your chances off-road.

This seems like a really important point. I will try it out, sure, but why would you expect to be very successful at stealth whatsoever with zero points spent in it? They will hear you easily! "Legit" with their "normal" senses even. There is, actually, a "super sense" for zombies - but it's not for sleepers. Sleepers have two thresholds (entityclasses.xml): <property name="SleeperNoiseSenseThreshold" value="3,8"/> <!-- Indiv.Random. hearing capability - "I hear something" noise value --> <property name="SleeperNoiseWakeThreshold" value="9,12"/> So each zombie is given (at spawn) a random "sense" threshold between 3 and 8, and a random "wake up" threshold between 9 and 12. If the noise you make goes above the wake threshold, they wake up. This does not correlate exactly to the stealth meter, by the way. The meter combines sound and light. Awake zombies, though, have "super sense" for hearing: <property name="NoiseAlertThreshold" value="30"/> <!-- DEPRECATED; an awake zombie triggers instantly if touched by the sound range/volume --> I guess, we sort of agree. If you have zero skill in stealth, then zombies are going to hear you easily (wake up and move towards you) and see you shortly thereafter (target and attack). If you want to call this "auto-aggro", alright. I think of it as being not-very-stealthy and paying the price. The mechanisms are working exactly as faatal (and the XML, and the code) described.

We are talking past each other. Yes, there is a chase timer. No it is not the 90s constant defined in the ApproachAndAttackTarget code. I guess we define the word "automatically" differently. The Zs have a chance to hear and see you. That chance is based on strict mathematics of sounds, illumination, modifiers, and the Zs own senses. It's all available for any of us to review, and it matches exactly with faatal's description of course. If a zombie targets you, then you were visible to that zombie. And there is no special "sleeper vision" where sleeper zombies have extra-special sensory powers either. In any case, I tested warehouse_06 with my previous setup - padded armor, no books, 3 levels in Hidden Strike and From the Shadows, working at night. I did not use the shoot-out-lights modlet. Okay, so on the ground floor, this stack of closets seems suspicious. So I shot out all of the fronts. What do you know, it's 3/4 of a zombie barbershop quartet. All sleeping peacefully. Now they're even more peaceful. Crept around the shelving and saw these suspiciously zombie-sized containers. Already shot the top half of one, was empty, about to take out the next one. WHAT THE HELL! This warehouse is SHIPPING ZOMBIES! (He did not hear/see me; stayed snoozing in his crate) Now he can fit in a 1/2-size crate, saving shipping costs! My experience in warehouse_06 is identical to the house_modern I did before. Stealth works exactly as I expect. For what it is worth, when crouching perfectly still, the stealth meter (which is an amalgamation of illumination and noise, as described in stealth.txt) was 1 or even 0 in the very darkest places, but when moving at a walk it would be 10-20 depending on illumination. Apparently not enough noise to wake up at least these zombies.

I'm going to go poke around warehouse_06 ingame and also in the POI editor to see if I can offer any insight. I'd like to again encourage anyone interested in this topic to read stealth.txt before trying to draw any conclusions. It describes behaviors that map onto what theFlu is noticing (and what faatal said) and does not mention any 90-second timer. I looked into the code which handles stealth and there is a single constant declared: private const float cSleeperChaseTime = 90; So "AHA!" you say, there's the 90-second chase time! Except it's not. That variable is not used anywhere in the code. It's declared and then abandoned. I think it's an old value from an older stealth implementation. The current code has a small function which calculates a different value - MaxChaseTime - based the attributes of the target being chased (could be you, could be a bear the Z is fighting). One other point to emphasize - there is no "auto-aggro". Enemies have a chance to hear and see you (and some are better than others at this), that's it. They may get chances to do that at very inconvenient times - even situations where it is essentially impossible to avoid being seen! But there is no BMH-like GPS-to-player automatically upon falling from the ceiling or busting out of a closet. We really ought to trust that faatal knows WTH he's talking about. To the extent I can understand the bits of code I've read, it lines up perfectly with what he said. Edit: again, more nuance here than I originally posted. After looking into it more, what wasn't clear from faatal's note is that the 'attack' volume sleepers get a special can-I-see-you check that is not the same as a regular zombie's hearing or vision check. It ignores line of sight, but does take into account player stealth. If they succeed in 'seeing' you, they will set you as their attack target. This is similar to BMH zombies. If you have some stealth skill, the zombies may fail the check and just wake up without targeting you. There's more details later in this thread.

Aaand I'm back. New modlet, "Boid's Lights Out", available here: https://www.nexusmods.com/7daystodie/mods/1819?tab=files It allows you to shoot out lights once you reach level 2 in From the Shadows. Localization of the new perk benefit for English and Korean. What I mean by "allows you" is that your arrows/bullets get massive damage bonus towards POI lights. One-shot kill with any projectile. Works on lanterns and flashlights and all that as well.

I like the idea of them not going back to their original locations to sleep. So maybe you get chased out and hide for a while, but when you come back they're not all just out in the open (which as Roland points out would not be all that interesting), but maybe the bathroom which was empty before now has a sleeper in it. And the one on the living room floor is now behind the counter in the kitchen. The sleeper volumes already allow for multiple (randomized) spawn points so that a POI won't be identical on each playthrough. Would be neat if the sleepers could just pick one of the spots and go to sleep there. Oh, and have them rebuild the closet doors too so they're hidden again.

I think maybe they do? I recall, I think, browsing around POIs but not killing anything and then exiting the area and coming back later to find the sleepers re-sleeping (and not due to a quest POI reset). When I was poking around in the code, I noticed this method on the EntityAlive class: public void ResumeSleeperPose() { this.TriggerSleeperPose(this.lastSleeperPose); -- puts the zombie back into its sleeping 'pose'. <...irrelevant stuff about syncing client/server...> } And the only place that is called is in the "ApproachAndAttackTarget" AI code. Very abbreviated: public override void Update() { if (this.hasHome && !this.isTargetToEat) -- if the zombie has a 'home' and doesn't have a target to eat { <...some stuff about finding the path to 'home'...> if (!this.theEntity.IsSleeper) -- not a sleeper? then do nothing more return; this.theEntity.ResumeSleeperPose(); -- is a sleeper? resume the sleeping pose

To be clear, nothing in the sleeper volume check is RNG-based (with the possible exception of how the zombie might ragdoll out of its hiding spot), right? Also some sleepers will remain sleeping/passive (or there's a bug maybe). Is your description specifically for the sleepers set to 'attack' in the volume config? 'Cause in testing several sleepers remained happily sleeping in their closets even after shooting the door off when the player is well within the volume. I interpreted that to mean only the Trigger Type=2 (attack) sleepers would definitely wake up and be at least in 'active' mode, if they couldn't see the player.

My (mis-)conception: the following is what determines if a sleeper can detect the player, and there is no RNG-based skill check going on when entering a volume. [class PlayerStealth] public bool CanSleeperAttackDetect(EntityAlive _e) { if (this.player.IsCrouching) { float num = Mathf.Lerp(3f, 15f, (float) (((double) this.lightAttackPercent - 0.349999994039536) * 1.53846156597137)); if ((double) _e.GetDistance((Entity) this.player) > (double) num) return false; } return true; }