The many faces of a life after death.

Player Death Alternative allows you to keep playing in the event you finally succumb to death. The mode respawns you at a settlement and creates a zombie with all your gear in the spot where you died. Now this mode has received some love to make it better (and more stable).

Player Appearance

One of the things I really wanted to do was have the player take on the appearance of the settler they were replacing (if there was one to replace). Unfortunately the Papyrus functions to get HeadParts are all not available without F4SE (Fallout 4 Script Extender, which won't work on XB1). What I've decided to do instead is at least try to randomize the player appearance as much as I could. This also works when the player spawns in a random location due to having no settlers left to replace.

While there are no function to get HeadParts there is a function to change them. Gotta love the consistency from Bethesda on that one, huh? The ChangeHeadPart function in particular allows you to change parts of the head by passing in a HeadPart object representing the part you want to change. HeadParts are available for eyes (color), hair, and beard (for males) so I've included all of them. When you re-spawn a random eye/hair/beard is assigned to your character.

Unfortunately this does not include hair/skin color or other facial parts like nose/ears/eyebrows/etc. I have yet to figure out how to change these parts via scripting. It'd be nice to at least choose a random preset and then randomize the facial parts mentioned earlier, but I'm not sure if that is possible via scripting either.

Random Equipment

Another change to Player Death Alternative is when the player is re-spawned they now are assigned the following:

1) random blunt melee weapon (eg. board, cane, pool cue)
2) random under-armor clothing (eg. fatigues, road leathers, tattered rags)
3) stimpak, sweet roll, dirty water, and a single lockpick

This helps further randomize the character and in the case of the aid items add a bit of survivability. In the future I may consider adding a gun with limited rounds and possibly armor based on level.

Spawn Location

New spawn location at Covenant that doesn't automatically aggro the entire community.

Re-spawns with Player Death Alternative enabled will first check for existing non-unique settlers to replace and spawn you in there place. If not settlers are available, then a random settlement is chosen regardless of whether the player has ever visited it before.

The exact location of that spawn point used to be right on top of the workshop. It is now the linked ref of the map marker associated with the location of the workshop. I believe this to be the fast travel marker which is meant as a spawn point and tends to be outside the center. It gives you the options to assess the situation and decide to go in or turn around and head a different direction before getting knee deep in combat.

Bug Fixes

Recent updates also included bug fixes related to Player Death Alternative. The biggest being a script error related to an off-by-one error randomly accessing an array. The script error was infrequent as most random values fell within the range, but when it occurred it caused the re-spawn to never complete and black screen to get stuck. I've ran into this and know others have as well and I'm hoping these help resolve the issue and make the re-spawn work more reliably. 

Future Thoughts

Outside of continuing to improve the random appearance and equipment assigned there are other ideas I'm flirting with. One involves creating a random quest for the newly spawned player to give them a purpose. This idea was actually spurred when I watched YouTube video where the player created a fake mission for himself with a custom map marker: "The apocalypse just started and I need to find my daughter at the library."

Raider zombie taking out a former teammate while the sole survivor looks on.

There's no denying the popularity of The Walking Dead series. One of the features of that series that fans of this mod have been asking for is an option to have all NPCs start off infected instead of needing to be hit by a zombie first. With the latest update to Zombie Walkers, this is now an option.

NPC Resurrection options

The NPC Resurrection option has been a part of the Zombie Walkers holotape since almost the beginning of the mod. It used to be a simple feature toggle but has now been expanded as follow:

• DISABLED: turn the feature off.

• IF INFECTED: works like the old ENABLED option in that NPCs can resurrected from the dead as a zombie but only if they were previously hit by a zombie before dying.

• ALWAYS: this is the new feature that enabled all NPCs to resurrected as a zombie when they die regardless of whether they were previously hit by a zombie.

Note that the ALWAYS option will apply when the mod first processes each NPC. If using this on an existing save, there may be several NPCs already marked that won't have this affect applied to them. If those NPCs are hit by a zombie, they will still have the condition applied to them as normal. This does not apply to new games.

Expanding eligible races

In the past NPC Resurrection applied only to actors with the Human race. It has now been expanded to include the Ghoul race as well (not to be confused with Feral Ghoul obviously). This was done in part because Spawn Replacements lumps those two races together as one logical unit already. Also, why not? Ghouls are being used as the 'Zombie' that replaces the actor anyway and are identical to humans outside their skin in game terms. This makes it easy to transfer items over and provide more zombies in the game.

Future thought

Players have the concept of infection and resurrection (Player Alternative Death). NPCs only have the concept of resurrection. I am considering applying the infection state to NPCs such that if they are hit by a zombie they will slowly die and visibly show that to the player. This will handle cases where NPCs survive an attack.

You can imagine a scenario like a settlement attack where there are no settler deaths but a settler or two may have been infected. The player would need to keep an eye on their settlers to avoid their settler turning later on and spreading the infection from within the settlement. Maybe the settler could move a little slower and show the infection through skin color (if possible) or a periodic emotion/sound?

Finding out you are infected the hard way: coughing up blood.

Player infection has been a part of the mod for a long time now. A holotape option allows you to specify the Player Infection type, but when enabled there is 100% chance you will be infected when hit even one time.

Player Infection Chance

A new holotape configuration option has been added under Infection Settings -> Player Infection Chance. This setting only appears if the Player Infection setting is NOT disabled (for hopefully obvious reasons). The initial options for this new setting are as follows:

Based on Health (default)
25%
50%
75%
100%

Why Not Based on Armor?

I spent some time thinking about how to make infection more/less likely for players. Early thoughts centered around the armor the player is wearing. I was even going so far as to take into account the size of the armor (amount of flesh covered) instead of armor rating. However, armor is problematic for the following reasons:

1) inconsistent keywords on armor that seems only solvable by depending on a mod like AWKCR
2) mod-specific armors may fall through the cracks
3) it is difficult to query for currently equipped armor without F4SE which isn't available on Xbox

The above can be worked around but would add significant effort and code to maintain just to create variable infection chance. I then came to a realization that a reasonable approximation of armor can be achieved by instead looking at the amount of health lost during an attack. Health also simulates multiple attacks in short duration making the player more vulnerable which makes sense.

Based on Health

This is the default value for the new Player Infection Chance setting. The percentage chance of infection is calculate each time the OnHit is triggered by a zombie attack on the player. Inside the callback the GetValuePercentage convenience function makes it easy to calculate the percentage of health remaining for the player. The formula is pretty simple:

% infection chance = 1 - % player health remaining

eg) if % player health remaining = 0.8 (80%), then % infection change = 0.2 (20%)

Improvement to Lethal Infections

When any setting other that 100% infection chance is used the player is now uncertain about whether or not they are infected when struck by a zombie. If the Lethal Infection mode is enabled there will also be an incubation period before applying the infection to the player. Combine these two together and now when a player is hit by a zombie they aren't sure if they are infected or not and won't find out until incubation is over (~45 seconds). The hope is that this will add some tense moments while the player waits to see if the "You are infected" message appears.

Future

I'm considering another config option that would allow configuration of the curability of an infection all the way from incurable to cured 100% of the time with antibiotics. This isn't a big priority though as you can pretty easily roleplay an incurable infection by simply not using antibiotics, but sometimes it is easier to have a setting in case you forget. Having a percentage effective configuration might be interesting though and make the game tougher for those that find they have a surplus of antibiotics.

Another though is to make a cure specific to zombie infection which isn't the game's standard antibiotics at all. That would allow me to control the rarity of the cure and maybe even spawn a quest to retrieve it when you get infected.

Zombie, meet Shotgun.

After taking a break from modding over the summer I'm starting to get back into it again. My wife and I caught up on seven seasons of Game of Thrones and after watching the White Walkers I have to say that I'm glad to be back to real zombies again.

Version 2.4 Released

I figured the best way to get back into this is to go over my laundry list of to-do items and pick a few items off. There are outstanding bugs still out there too, but the prospect of bug fixing is not very motivating sometimes. The items included in the version released yesterday include:

- Updated Extra Spawns config to be daily % based
- Increased range of Spawn Limit check
- Added 10% zombie health option
- Added 1% legendary zombie spawn chance
- Added switchblade to death alternative spawn
- Increased shotgun damage and added stagger to zombies

Fixing Shotguns

I can't believe it has taken this long to address shotguns in Zombie Walkers. They have been laughably weak since practically the beginning and as a traditional zombie slaying device that just doesn't seem right.

The difficulty with shotguns seems to lie in the spread of the shot and connecting with the head. Only a percentage of the shot actually hits the head in game terms and the damage doesn't seem to be very high even though the weapon has a higher base damage that other single shot weapons. I can only theorize that the damage is spread out and only a small portion actually hits the head unless precisely ranged and at very close range.

Version 2.4 increases limb damage received by zombies from shotguns by 4x. This should be enough to make even partially connecting head shots take them down and in my testing seemed to be. Admittedly, I was testing at level 1 with a base double barrel and I'll be interested to hear feedback from shotgun wielding players when they try it out.

Another tweak to shotguns included was an automatic stagger affect to zombies when they are hit. This helps in cases where the shot doesn't connect direct enough with the head and makes sense. Shotguns have stopping power and will now cause zombies to stop and stagger as if they were just hit by a sledgehammer.

Extra Spawns Adjustment

There have been reports in the past of too many zombies spawning, especially in downtown Boston. One possible culprit is the "Extra Spawns" feature. Up until now, the config for extra spawns was based on a time range (eg. 2 - 5 days). That meant if you visited an area and initialized the extra spawn points there and the left and came back a week later, 100% of the spawn points would trigger on your return. Given that the spawn points could be as little as 2000 units apart there could be an awful lot of them in certain areas.

As such I have decided to move away from a date based config to a percentage based config. When you enable extra spawns now you will be able to choose a percentage chance each spawn point will trigger each day. This flat percentage means that it doesn't matter how long you were gone before returning to an area and should help avoid spawn spikes.

Another spawn related adjustment I made was to increase the range of the spawn limit check from 4500 to 8000 units. This means it will now check a wider area for existing zombies before spawning more if you have reached the configurable limit (default 50).

Moving Forward

There's no shortage of ideas out there and plenty of previous posts on this blog outlining future ideas that I could pursue. In the short term I may play around with some kind of noise-based attraction so that zombies will investigate activity from a further range. Another related idea would be looking into attracting zombies to dead bodies to feed which could make for some interesting moments and give players a chance to use the bodies as bait. Maybe making resurrection time configurable would help?

I'm always interested in feedback so if you happen to be reading this and have any thoughts feel free to let me know.

Piper, is that you? I guess she wasn't protected by the wall after all.

Is being the sole survivor of vault 111 not enough? Ever dreamt of being the sole survivor of the entire commonwealth? If so, then the Zombie Walkers 2.3.3 update is for you.

New Spawn Replacement Options

People have asked for the ability to replace all NPCs with zombies almost from the beginning of this mod. Now you can (almost) as I have added a couple more replacement options to the Zombie Walkers holotape:

- Humans/Ghouls
- Turrets

Note that the Humans/Ghouls option affects all Humans and Ghouls in the game regardless of faction. It also includes children with special handling to ensure that the children are only ever disabled by never issued a "kill" to avoid violating Bethesda terms and conditions (other actors are issued a kill when the zombie that replaced them is killed).

Also note that the existing options for Gunners and Raiders are overwritten if the general Humans/Ghouls option is enabled. As a result, I have decided to hide the Gunners and Raiders options when you enable Humans/Ghouls since that one takes precedence.

Spawn Replacement General Settings

Back when I overhauled spawn replacements with a new replacement approach, I described some base criteria that I used to prevent unwanted replacements. These protections kept things like companions like Strong (super mutant) and other friendlies like brahmin from being replaced.

I have added a new sub-menu under Spawn Replacements called General Settings that now allows you to override this behavior if you want to. By default the settings match what they always have and will avoid friendly replacement.

- Replace Essential
- Replace Nearby Visible
- Replace Non-Hostile
- Replace Protected
- Replace Teammate
- Replace Unique

Note that some NPCs may classify for several of the categories above and ALL all checked before replacement. This means if you really want to replace everything you'll need to Enable all of these overrides.

A special note on "Nearby Visible": this was added to avoid actors disappearing in your view (for immersion). The best example of this is the Museum of Freedom. When you enter through the load screen, the raider on the balcony will likely not be replaced even if you enable raider replacements. If it doesn't bother you seeing a raider disappear before your eyes and zombies spawn out of thin air, then you can safely enable this override even without the others and continue to play as you have while ensuring all replacements happen.

Humans/Ghouls replaced by Zombie Ghouls

The residents of Diamond City look a little different these days.

I have decided to replace humans and ghouls in a way that is consistent with how NPC Resurrection works. Instead of spawning a standard Feral Ghoul, I spawn a Zombie Ghoul instead and transfer and equip items over. Note that this does not apply to the child versions of those races and those will be replaced by standard ferals.

I felt this would make trips to places like Diamond City more interesting in that you'll see zombie guards, zombies in suits, etc. Also, there are already plenty of standard ferals in the game anyway. I considered making this configurable and may depending on what feedback I get.

When choosing the replacement options for humans/ghouls you still have the ability to replace them with 1 -3 zombies. The first replacement will be the Zombie Ghoul with item transfer and then any remaining zombies will be standard Feral Ghouls spawned next to them (which is why you can see a feral ghoul in the screenshot above).

Issue with Enable State Parents

I noticed some errors in the log file and saw an occasional non-replaced actor (usually children) during testing. I'm still researching this but wanted to describe it here for awareness.

cannot disable an object with an enable state parent

From what I can tell so far, this appears to result from me trying to disable the actor as part of replacement. The call to disable is what throws the above error and apparently is the result of this actor having a special link to an "enable state parent".

"Note that references with an Enable Parent cannot be enabled or disabled independently of their parent, even through script. Their disable/enable state is always determined by their enable parent." (source: Reference#Enable_Parent)

This is more problematic in that I have yet to find out a way through scripting to determine whether an actor has one of these enable state parents or how to get them if they do. Googling other modder comments on the topic in various forums makes it sound like there is no way and that these relationships are setup in the world view user interface which makes me sad.

As a result, some replacements may error out and not work. I didn't notice this error until working on adding the replace humans/ghouls option and mostly around Diamond City where I was testing. If you have all replacement options and the overrides in general settings enabled and see an occasional child or something still running around that is why.

Future: Zombie Ghoul Animation

The fact that Zombie Ghouls still walk like boxers with their fists up bothers me and you'll see it even more if you enable the new options. Also their punching is troublesome, but especially the lunging power attack they usually make first as it is not in line with the lumbering Romero-style I am going for with this mod. Needless to say this has been on my list for awhile and is increasing in priority.

Future: Zombie Animals?

If you've been following this mod, you've likely heard other asking for zombified creatures. I'm still not ruling this out in a future update. Many of the creatures already in the game have feral/ghoul versions of the actor already so it wouldn't require texture work for those (which I'm not good at). I could make a configuration option allowing you to decide what to replace animals/creatures with (eg. Feral Ghouls or Zombie Animals/Creatures). There are a couple challenges though:

1) Zombie creature behavior would need to be defined and different people may have different answers to these questions: 

Do they require headshots? walk/limp? form groups? infect on hit? etc.

2) Some creatures only exist only in DLC 

I'd like to avoid making Zombie Walkers depend on any DLC but I'm also hesitant to spawn another plugin mod from a maintenance perspective. Depending on the answers above, one of the other may need to happen as not all the changes needed may be possible with scripting alone.

A vault-dweller zombie? Say it ain't so!

Death is a normal part of every zombie apocalypse, but it doesn't have to be the end. Wouldn't it be fun to spawn as a new character and hunt down your now-zombified former self? If you answered 'yes', then read on.

Changing player death

When the player dies in the base game a load screen appears where you are forced to load a previous save or start a new game. To avoid this from happening you actually have to avoid the player actually dying. They way I did this is setting the player to 'essential' when Player Death Alt is enabled in the holotape. When the feature is disabled, the player is set back to normal and can die again for those that miss the lovely load screen.

When a character is marked essential and they enter a bleedout state instead of dying. Companions in the base game do this by sitting down on the ground for awhile until they eventually recover. Papyrus provides an event callback function called OnEnterBleedout that you can register for to perform any special actions when the actor enters this bleedout state. This is how I tied in the functionality to change player death that I'll describe below.

The player is bleeding out, now what?

First, we pause the script for a few seconds to allow the player to realize they have "died" and then fade out the screen to black. Then a series of things happens while the view is hidden from the player:

1. Companions are dismissed

If the player is accompanied by a companion, that companion is dismissed and will return to their home. This part of the script was modeled after the Survival mode script to return companions home if they are downed and the player abandons them and should function in the same way.

Note that Dogmeat is handled separately in the special Followers quest from other companions so this process may actually issue two separate dismiss calls (one for Dogmeat and one for the other companion). This has not been tested with multiple companion mods, but I'd be interested in hearing feedback from players using them.

2. A zombie is spawned to replace the player

A Zombie ghoul is spawned at the players bleedout location. All items the player is carrying or has equipped are transferred to this new zombie (including bottlecaps). Items currently equipped by the player will be equipped by the zombie with the exception of weapons. 

The zombie is then added to a special "Zombie Walkers" quest to track their location to aid the player in recovering their items. Note that these zombies will wander just like others if Horde Behavior is enabled. If fast travel is used by the player, they may actually travel quite some distance.

3. The player is moved

The script first tried to determine the closest settler in a player-owned settlement to the bleedout location. If a settler is found, then the player is moved to that settlers location while the settler is killed and disabled (made invisible). Then items are transferred from the settler to the player in much the same way the players items were transferred to the zombie replacement. When this process completes, the screen is then faded in from black and the player can then resume play.

Note that there is currently a couple conditions on what settlers are considered for replacement:

• only Human or Ghoul races (eg. no robots)
• only non-unique settlers (eg. generally this means only recruited settlers, no specials or companions)

In the event no suitable settler can be found for replacement, then a random settlement in the current world area is chosen. The player is then moved to this settlement and not given much in the way of items (eg. tattered rags). Note that the settlement moved to may or may not be owned by the player and may not even have been discovered by the player yet, so be prepared to fight or run. 

I did impose a restriction that it be within 1000000 units from the bleedout location which eliminates DLC areas if you are in the base game. Within a DLC area this restriction should keep you there.

Future

There will likely be feedback from play testing that I will as always take into consideration. This first version should be considered beta and I highly recommend saving before you try it out just to be safe.

There's a bug where sometimes the screen doesn't fade back in from black that I'm still investigating. It may have something to do with dying during VATS mode, but I'm not 100% sure yet. If this happens you can simply manually reload a previous save.

Another thing that bothers me is the endless messages that appear notifying the player that they have dropped each item in their inventory. I'm not yet sure how (or if) this can be prevented.

I played around a little bit with trying to spawn an exact clone of the player so that the zombie would look like them. This involved experimenting with spawning the player itself (id 14) and the hidden spouse version of the player actor but both cases have a lot of issues. In one case, the zombie shares an actor base with the player so things like race and essential status would be shared. Play testing the spouse version of the player was initially promising, but quickly became very buggy including invisible heads. It'd be nice to find a solution for this to apply here and for NPC Resurrection but it doesn't look good outside of using F4SE (which won't work on Xbox).

I was thinking about bringing up the character menu and allowing you to change the looks of your new character and maybe even other things like stats and name (if possible). This would really help in making your new character feel new (and the old one truly gone). I could add an option to simply randomize appearance also. On PC you can do these things via console, but these would really be value-adds on the Xbox side I think.

A settler before and after zombification.

NPC Resurrection was one of the first advanced features added to Zombie Walkers way back in the beta days during version 0.4. The idea is simple, any human NPC hit by a zombie will become a zombie when they die. This is consistent with zombie lore in that the infection spreads from victim to victim. Some compromises in the implementation had to be made, which I'll discuss below, but overall I think it accomplished the goal and is actually a unique feature to this mod.

Implementation

The feral ghoul unarmed weapon was updated to cast a hidden spell on a victim that is hit. If the victim is human, it adds a RaiseAsZombiePerk to the actor. This perk registers for the onDying event of the Actor it is attached to and when that event is triggered does the work of converting the Actor to a zombie.

I did some research and experimentation to determine the best approach to zombify the Actor. Ideally I wanted the new zombie to resemble the Actor but behave like a feral ghoul. This became difficult however due to some limitations I ran into very quickly.

Race is tied to the Actor Base type and if changed affects ALL actors spawned from that base

This is a big one. Many NPCs, like Raiders, are spawned from Leveled Lists. Leveled List actors share a common base type which is tied to a race. This means changing the race on any one of these will change it for ALL of them. In the context of this mod, changing a Raider that was killed by a zombie into a zombie by setting the race would mean all Raiders spawned from that base type would become zombies (not what we want).

Due to this, the only actor types that you can safely change the race for are unique actors since they do not share their type with others. Unique actors are few and far between and many are marked protected/essential. However, these flags can be cleared by the Zombie Walkers holotape (or other mods) so I decided to handle unique actors differently so that at least unique actors would look like they did. For non-unique actors however, I would have to spawn a brand new actor and transfer inventory.

Why is race important? It controls many behaviors of an actor to make them more zombie like including their body part damage distribution, default voice, unarmed weapon, etc.

Functions to get facial features (hair, eyes, etc.) do not exist without F4SE

The problem with spawning a brand new actor is that they now look nothing like their old self (especially their face). This problem is compounded when methods to get facial features are absent from the CK. For example, I have not yet found a way to get their hairstyle and apply it to the new zombie actor replacing them.

Now I had to decide what to spawn. Do I spawn a bald, generic human or something else? I ended up spawning a Ghoul to replace them since they sort of look zombified anyway. I created both a male and female Ghoul NPC as a base that is assigned to the new ZombieGhoul race.

Humans/Ghouls use a different skeleton than Feral Ghouls and therefore can't use their animations

This one is unfortunately and is why the NPC zombies walk like boxers and punch like them too instead of clawing and biting. I experimented with trying to force the animations and while you can do that they just don't work. The NPC becomes a strange ball of flesh with parts where they shouldn't be.

Longer term, I'd like to revisit the animations at least to see what can be done in replacing and removing ones that do not look right. For example, it'd be nice to replace the walking with fists up combat movement with simple walking. It'd also be nice to eliminate some of the punching attacks, like the one they seem to do first that has them charging forward with a power punch.

At one point I considered trying to "fake" it and give NPC zombies a hidden knife to fight with so that it would look like they are slashing at least. Of course, this would require kill animations be disabled and I'm not even sure if it would work or exactly how it would look.

Transferring Items

For the non-unique Ghoul zombies, they spawn naked with no items. Therefore, I had to transfer all the items from the old actor over to them using RemoveAllItems. This puts the items in the inventory so they are available for loot, but it does not equip items the old actor was wearing. 

To equip items, I used OnItemAdded in a script attached to the Ghoul NPC. Each item added was checked to see if it was one of a predefined list of keywords and if so it was equipped. This has problems though in that keywords are not consistently applied and many users have reported the occasional naked zombie as a result.

A better approach that I am going to explore is to use OnItemUnequipped. This should be triggered by the old dead actor when items are unequipped as part of being transferred to the new actor. When triggered, I can then equip the item on the new actor (in theory).

A note regarding weapons

In the base game, weapons like guns are dropped when an actor is killed. These weapons are still associated with the actor and are cleaned up by the game when the actor is eventually disabled or the cell resets. However, there appears to be a bug with RemoveAllItems in that these weapons are NOT included in the inventory list that is transferred to the new actor. Therefore, that loot is lost when an actor is zombified.

To address this, I set the global property iDeathDropWeaponChance to 0 to avoid weapons actually being dropped. This results in actors with weapons still in their hands (sometimes at weird angles) and includes them in the inventory list for the item transfer.

Future

NPC Resurrection was one of the first advanced features implemented as I was initially learning to mod. I've been meaning to revisit it for some time but have been busy adding other features that I felt were missing. The biggest thing is I'd really like to venture into the realm of animations and figure out how to make them behave a little more like the Feral Ghouls in the game.

I'm working on a new feature for player permadeath which will feature the player's old character being turned into a zombie similar to how NPCs are. I'm already running into many of the same limitations, but this may finally force the revisit that I've been planning on so stay tuned as this feature may finally get some long overdue love.

Death is the eventual fate of all infected that do not find a cure.

Everyone who has watched a zombie film knows that getting bit is bad news. You become infected and eventually die only to rise again to join the undead. Up until recently, Zombie Walkers featured infection in the form the built-in survival infection disease which simply gives periodic damage. I wanted to add a new Lethal Infection option for those wanting a more hard core experience.

Implementation

When the player is struck by a zombie attack, they are given a special Zombie Infection Perk. This perk adds a persistent magic effect on the player that stays until the perk is removed. Currently, the perk can be removed using survival mode's standard antibiotics.

The magic effect uses a game timer to advance the infection every 15 in-game minutes which translates to about 45 seconds for the default time scale. The number of times the effect has triggered is tracked as Zombie Infection Ticks. As time goes by the infection gets worse.

Incubation

When the player is hit there is a brief incubation period before any of the affects are applied to the player. This incubation period is currently a single tick (~45 seconds).

Stage 1: Periodic damage/rads

- periodic damage begins (every 30 in-game minutes from Infection disease)
- periodic radiation begins (every 15 in-game minutes, starts at 10 and grows over time)
- sleep is limited to 4 hrs at a time (even in a regular bed)
- Well Rested & Lover's Embrace perks removed if present
- camera/controller shakes and blood splatter appears on screen

Stage 2: Dehydration (12 hrs)

- all effects from previous stage applies
- dehydrate player every 90 in-game minutes (similar to taking a stimpack)

Stage 3: Dark Craving (24 hrs)

- all effects from previous stages apply
- dehydration increases to every 60 in-game minutes
- Dark Craving effect is added (same as survival cannibal perk - normal food no longer satisfies hunger)

Stage 4: No Sleeping (36 hrs)

- all effects from previous stages apply
- periodic radiation damage now grows twice as fast
- dehydration increases to every 30 in-game minutes
- sleep is no longer possible

Death by Rads

The idea with the above stages is to start off slow but eventually become lethal if not cured. Death is eventually guaranteed thanks to how radiation damage works. The player will die regardless of their health if they reach 1,000 rads. Given the fact that the radiation damage slowly increases over time, it will eventually reach 1,000 even if the player stands next to a doctor all game and heals after every infection tick.

The rads given each tick equal the number of ticks that have passed. This means the rate is linear and the rate only increases when it is doubled at stage 4. To give you an idea of the numbers, here are the ranges of rads given at each infection stage:

Stage 1 = 40 - 182 rads/hr
Stage 2 = 186 - 374 rads/hr
Stage 3 = 378 - 566 rads/hr
Stage 4 = 570+ rads/hr

Note that Stage 4 continues to increase the rad rate given until the player dies. This theoretically means it could award 1,000 rads at a single tick instantly killing the player. My original target for death was about 48 hours at which point the rate is around 948 rads/hr.

Banking on Survival Needs

To put extra pressure on the player and re-enforce the unofficial 48 hour window, I decided to attack each of the player's survival needs. This takes advantage of the already built-in penalties and effects that survival mode contains and adds some immersion.

Pressure is applied to water starting at 12 hrs, to food starting at 24 hrs, and to sleep starting at 36 hrs. Assuming the player can survive all the radiation damage, they may be left with some serious stat penalties and more periodic damage if they do not have a large water supply and the cannibal perk.

Severely Dehydrated: -10 INT, -7 PER, -3 LCK + continuously take bleed damage.

Starving: -10 END, -5 CHR, -3 LCK + continuously take bleed damage.

Incapacitated: -75% AP regeneration, -6 STR, -4 AGL, -3 LCK + no run [walk only]

Keep in mind that the continuous bleed damage above is in addition to the periodic damage they are already receiving form the Infection survival disease. Also note that while an infected player can work to avoid dehydration (with lots of water) and starvation (with cannibal perk), incapacitated status is unavoidable.

Future Thoughts

I'd like to explore the idea of armor providing protection against getting infected. The protection level could be based on armor coverage (Heavy variants cover more flesh than Sturdy and Standard) and/or type (leather vs metal etc.). The protection would basically be a % chance of not being infected when hit that could be increased to some max with each armor part being worn. This could get tricky when you consider under-armor and special outfits, which is probably why mods like AWKCR exist.

Another idea which is more ambitious is exploring the concept of handling player death differently. Instead of reloading a previous save, maybe that version of the player is dead forever and the player is instead re-spawned as a new character at a different location. Maybe they spawn at one of their settlements or randomly on the map. They can adjust their name, looks, etc. to basically create a new character. The former dead player will rise as a zombie and must be tracked down and killed if the player wants to get any items back. Maybe this would be a quest with a marker?

Have any thoughts of your own? Feel free to share them in the comments.

Update: 2/4/2018 (as of version 2.5.3)

Dark Craving and Inability to sleep are now applied at Stage 1. Dehydration also now begins at Stage 1 but continues to progress in frequency. The incubation period is now 1 in-game hour (4 ticks). No changes have been made to radiation damage.

The above changes were made due to reports that lethal infection was a minor annoyance in the early stages. Also, it takes time for the in-game survival needs to start impacting the player so I wanted to get those timers started right away.

Does this zombie want peace or is he about to claw at me?

I spent some time recently playing my Zombie Walkers mod on survival and really enjoyed it. One thing that bothered me though was how often I died whenever I attempted to use melee. I guess I didn't realize that even though the zombie move slow, they still swing their arms and bite at ninja speed and it is difficult to get the very important first hit in.

Attack Animations

Attacks, like other actions, are tied to animations associated with an actor. Animation is one area I hadn't delved into yet in the Creation Kit other than disabling a few. Bethesda used an SDK called Havok to create them and the tooling to customize them is not made available to modders.

As a result, the options are limited. I tried experimenting with various settings on the Unarmed Feral Ghoul weapon used by the zombies to lower attack speed, but none of the settings seemed to have any effect. It appeared the attack speed was linked to the actual animations.

Bethesda Forum to the Rescue

I eventually came upon this forum post where others had observed the same things I did:

https://community.bethesda.net/thread/13123?start=15&tstart=0

The 19th post on this thread states the following:

The best solution so far is to:

1. Make a magic effect with Peak Value Modifier and AnimationMult (set other parameters to your liking)

2. Give a melee weapon or some armor piece that magic effect via an enchantment

3. On the enchantment, add a condition to trigger the effect only if IsAttacking = 1 and some keyword that links back to that weapon

That should essentially give what you're looking for, except the very first swing of the weapon.

AnimationMult is the key. This is a multiplier that controls the speed of ALL animations on the target actor. 100 is the default and lowering it will slow down animations.

I applied this to a "bloody hands" piece of armor and gave that to all the zombies and verified that it does indeed work after the first attack. It's a good start, but I wanted it to work even with their first attack since that was really the important one (especially if you play with infection enabled).

Slowing Down the First Attack

I expanded on the IsAttacking condition by adding a condition on proximity to the player. If the zombie is attacking OR the zombie is within a certain radius nearby the player, then slow down ALL of the zombies animations. I tried to optimize the radius by trial and error to be close enough to trigger before the zombie is close enough to attack but not much further away so that it slows them down while moving toward the player. It mostly works, though once in awhile they still manage to get a ninja-like swing in.

The solution above seems like a hack. It accomplishes what I wanted it to, but it gives me that feeling like I'd really like to revisit this and do it the "right" way at some point, assuming there is one. The issue is that AnimationMult slows down ALL animations, so it includes zombies reacting to getting hit, getting up off the ground, etc. Ideally, just the attack animations would be slower and they would still fall to the ground or stagger at normal speed.

Behavior Graphs

Through researching animations, I became more familiar with the behavior graph that governs when they play. I didn't end up needing them to implement the solution for slower attack speed described above, but the knowledge has helped in disabling animations that don't fit.

The behavior graph is basically a tree structure of conditional branches with leaf nodes that are animations to be played. You can view them in the Creation Kit by going to Gameplay -> Animations... menu. The nodes in the tree are animation events and can have conditions added to them. To disable animations, you simply need to add a condition that will return false. In my case I added a constant global property called ZombieWalkers_Disable_Animations that is set to 1 and add a condition to check the value is not 1 to disable an animation.

The Feral Ghoul (Zombie) jumping neck bite finishing animation disabled by adding a new condition.

The behavior graph may come into play when I revisit NPC Resurrection. I have a custom race for NPCs that are zombified but still look like a human/ghoul. Right now they use the standard human/ghoul behavior graph which is why they behave like them. 

I'm hoping to be able to set the customs races up as "additive" to override things or even assign them their own unique behavior graph. Doing so may allow me to disable animations that don't fit with them being a zombie.

Replacing Animations

Another thing I learned that didn't come into play for the solution but may be useful is how to replace animations with others that already exist.

Basically, you can use the Archive2.exe program in the Tools menu of your Fallout 4 directory to extract archives including "Fallout4 - Animations.ba2". Once extracted you can manually add them to your Fallout 4 Data directory. From there you can simply copy/paste to overwrite and then when building the archive for your own mod, add the animations you modified to it.

This may also come in handy with NPC Resurrection. It may be possible to change the walking animation for example to one where they don't hold their fists up in the air like a boxer. I'm not sure what options there are for the actual attacks themselves but it is something I hope to experiment with.

I'm continuing to learn more and more as I work on this mod and I'm optimistic the mod will continue to improve as a result. Also, it is still a lot of fun to work on and that's important.

Piles of zombie bodies at Cambridge Police Station during Fire Support quest.

When the new extra spawns mode was released, there were no limits to how many zombies would spawn. This also applies to other spawn settings like spawn replacements. In areas like Cambridge, where there are a lot of Feral Ghouls in the base game, a spawn replacement setting of 1 to 3 zombies combined with extra spawns and re-spawns from the Fire Support quest can lead to hundreds of zombies in a single area.

Performance Impact

I have a GTX 1050ti and normally get a solid 60fps when playing with the default Ultra graphics setting. To test the limit of zombie spawns I started the Fire Support quests and monitored the zombie count which went over 100 in short order (within a 10000 unit radius of the player). I was getting around 30fps at this point and then manually spawned 200 more zombies right next to Paladin Danse and watched my frames per second plummet to around 8-10fps.

I was able to play through it with Spray 'N Pray but it was quite laggy and I probably would've died if it weren't for using God Mode during my testing.

Area Spawn Limits

To help avoid performance problems, I had added a new spawn limit to the Zombie Walkers holotape. This limits zombies from spawning by checking how many zombies already exist (alive or dead) in the area around the spawn point.

This spawn limit applies to all spawning options including extra spawns, spawn replacements, settlement attacks, etc. and it checked each time. It is possible for an extra spawn point to respawn if the zombies eventually wander out of the area but those zombies would then be counted against the limit in the area they wander into.

This limit is really more of a soft cap in that I did make an exception for spawn replacements. If a spawn replacement is processed, at least one zombie will spawn regardless. Note that the replacement may only spawn one zombie even if the holotape is set to three if the zombie count is at or over the limit in that area.

Dead Zombies Count?

Dead zombies count against the spawn limit as they also chew up resources until they are cleaned up. Sometimes the game is good about doing this automatically as more continue to spawn but sometimes it can take some time.

To address this, I added a new Utility Menu on the holotape to "Remove Dead Zombies" which will disable and mark all dead zombies for delete. Additionally, I add a cleanup timestamp to each zombie at the time they are killed and a quest alias binds them for manual cleanup when the time comes. Currently, the cleanup time is set for roughly 48 in-game hours.

Extra Spawns - Initial Spawn Delay

I made a small change to the extra spawns feature to not spawn when the spawn point is first established. The logic here is that this is the first time the player has ventured into the area where the spawn point resides and there is likely already other creatures nearby anyway.

Now the spawn point will spawn for the first time after waiting the configurable amount of time (eg. 2-5 days).

Increased Spawn Density

Now that I have a spawn limit in place, I felt more comfortable expanding the number of extra spawn points. As such, I added X Markers to the list of potential spawn points since there are a lot of them and they include some random event locations not otherwise covered by Patrol Markers or COC Markers.

Also, I decreased the minimum distance between spawn points from 3000 to 2000. To get this to take effect for save games that have already skipped a bunch of potential spawn points, I migrated to a different keyword. Basically this means previously skipped spawn points are re-checked.

New Featured Mods menu that includes Zombie Walkers

Bethesda has released the 1.9 update to Fallout 4 this week that includes a new Feature mods menu at the top of the screen when viewing mods in game. It is currently out for PC and is expected to roll out to PS4 and Xbox One soon.

The exciting thing for me is that my Zombie Walkers mod was chosen as one of the 12 in the list. There are a lot of mods out there for Fallout 4 and I was a bit late to the game. I'm honored and happy to see that it will get exposure to some potential new players that may not even have known it existed.

This mod continues to be a hobby of mine and I've still got plenty of ideas I'd like to work on. I created a forum on Bethesda's site looking for feedback on some ideas I had for the future. Check it out if you are interested and any feedback is appreciated:

https://bethesda.net/community/topic/24479/relz-zombie-walkers

Zombies spawned from a new spawn point at one of the entrances to Concord.

Why add extra spawns?

There are many mods out there that spawn actors in the game and some of them spawn extra Feral Ghouls that work with Zombie Walkers. The trouble is they tend to spawn creatures only in certain areas as is the case with the Zombie Apocalypse mod or spawn so frequently that they create an arcade-like experience.

I wanted a dynamic approach that would spawn not just in cities but also the country-side. Also, I wanted respawns to happen in a way that would flow with playing the game as if zombies wandered into the area in your absence.

Many players have asked for more zombies and while the spawn replacement changes have largely answered this, it still leaves areas of the game world empty once cleared when playing on survival. I wanted the outdoors to continually re-populate over time and keep players looking over their shoulders.

Where to spawn?

The first challenge is determining where to spawn zombies. Here are a few thoughts I had while working on this:

My first thought was to pick a location at a random distance from the player, but this would quickly lead to zombies spawning in places they shouldn't like inside buildings or water. 

I then started thinking about spawning them where creatures have already spawned. The trouble is I was unable to get a reference to the leveled creature markers via script. For a bit I considered spawning my own hidden spawn marker whenever a creature replacement was processed. The trouble with this is that it relied on replacements being enabled and would add extra markers to keep track of (not to mention slightly increasing save game size).

Then I started researching markers that already existed in the game and which ones I could dynamically query for via script. During testing, I spawned vertibird grenades or pre-war shiny cars at these markers so that I can see where they were. There are several types available, but two in particular stood out and were chosen for the first version: 

1. Patrol Markers - 8,972 in base game
2. Center on Cell (COC) Markers - 622 in base game

Center on Cell Marker at one of the entrances to Concord.

How to spawn?

In my experiments with spawn locations, I noticed that Patrol markers in particular are sometimes clustered in groups as many as 10-15. I didn't want to have 10-15 separate spawn points for what is essentially one area, so I needed a way to tag just one of them as a spawn point but the others as not. To do this I created two keywords: ZombieSpawn and SkipZombieSpawn.

I already have a script attached to a hidden quest that I use for replacements, so I was able to use that and simply add more aliases to it. The first alias was for "potential zombie spawn points" and the second was for checking if existing "zombie spawn points" should spawn.

The potential spawn markers are filled by any Patrol or COC markers in the load area around the player that have not been processed (has neither of the keywords). For each potential spawn point, I check the area around it for an already existing spawn point (within a certain distance). If there is already a spawn point nearby, then I add the SkipZombieSpawn keyword, otherwise I add the ZombieSpawn keyword which effectively turns that marker into a new zombie spawn point. Note that markers located in settlements, cities, or interior cells are excluded from becoming spawn points.

The existing zombie spawn points are filled by anything in the load area around the player that has the ZombieSpawn keyword. For each spawn point, some processing is done to check if this spawn point should spawn and if so zombies are spawned at that marker's location.

When to spawn?

Determining when to spawn was a little more tricky and may be an area that I revisit with some tweaks as this new feature is play tested. 

The first thing I added was a time constraint. The game has the concept of game days passed which you can get by calling Utility.GetCurrentGameTime(). Each spawn marker has an actor value added to store a timestamp in the future that signifies when this spawn marker is eligible to spawn. Basically I take the current value of game days passed and add to it.

• Get current game days passed 

• Add 2 - 10 days to it (configurable via holotape)

• Make sure time is midnight so zombies spawn at night 

I made the time midnight to avoid mid-day spawns as I'm assuming most players sleep at night. If you happen to be out and about at midnight, you might be in for a few surprises as you wander around. "I thought I just cleared this area?"

Once a spawn point is eligible to spawn, it will start to fill in the zombie spawns quest alias where the timestamp is checked:

Zombie Spawn Point quest alias match conditions.

 The next step is to do a couple extra checks to impose limits on the spawning and hopefully avoid problems:

• Zombies may not spawn within 3000 units of the player

• A configurable max zombies threshold is checked before spawning to avoid too many zombies spawning within a given area (currently 10,000 units radius of spawn point)

• Also, note earlier that spawn points are not allowed to be created in settlements, cities, or interior cells.

Future Plans

In the short term, I'll be interested to hear player feedback on the feature to see if I need to make any changes. There are configuration items for max spawns in an area and the maximum number of days between spawns for a given spawn point. I may expand on these configuration fields moving forward.

Another thought I had has to do with an escalating zombie epidemic. Maybe I could add an optional mode where spawns slowly increase in size and frequency as time passes in the game?

Zombies are attacking Sanctuary!

Refactoring is an ongoing effort with Zombie Walkers and this time I have revisited settlement attacks once again. Settlements are a cool addition to Fallout 4 and lend themselves to the zombie apocalypse play-through as survival havens. As such, I want to make defending them actually matter.

What was wrong?

The first implementation used the game's built-in settlement attack quests. These are unfortunately a bit buggy due to the nature of all the code involved. Also, I feel a bit out of control in that I fire it off and sort of hope it works. I've had more than one user report being notified that an attack was happening and then not seeing any zombies. Others have reported setting settlement attacks to 100% and then never having their settlement attacked. Neither of these are acceptable.

A new approach

The settlement attack quests have a lot of logic involved in determining whether an attack should occur and where. In my mod, I just want to add extra attacks against the settlement you are currently at and the how often is a simple percentage checked hourly. Zombies now attack even if you have 0 food, water, and settlers.

To execute the attack, I use a quest alias to get a settlements LocationEdgeMarkers just like the game's built-in settlement attack quests. For the zombie attacks, I randomly choose one side to attack from only as zombies aren't smart enough to coordinate multiple attack vectors. The number of zombies that spawn is now controllable via a holotape option (from 10 to 30). Note that I've chosen to always spawn a minimum of 10 and the default max is 20.

Once spawned, the zombies are given a reference alias to the settlement's workshop (also bound via quest alias) so they path toward it. This workshop alias is a much simpler way to get a reference to the currently location's workshop than what I was doing which I'm not going to go into here.

I have chosen to retain the "Zombies are attacking ..." message to notify you of the attack but no longer have a message indicating the attack is over. This is due to not keeping track of the attacking zombies which the game built-in quest was doing. I didn't think it was necessary anyway. 

Another side effect of this new approach is what happens if you run away from the attack. In the games built-in quest your settlement structures can become damaged and possibly settlers killed. In this new approach, the zombies will eventually congregate around the workshop if you have no settlers. Having settlers may result in a long battle that the settlers will eventually win unless you have 'Kill Protected' enabled.

More than just zombies

The old implementation actually disabled settlement attacks from anything other than zombies since I was tying into the game's built-in quests and it was the only way to be sure a zombie attack happened when I wanted it to.

Now that I am executing the attack myself, I was able to restore the game's built-in settlement attack functionality so you can be attacked by raiders/super mutants/etc. again. I guess in theory you could be attacked by raiders and zombies at the same time, though it would probably be pretty rare.

A couple things to note though:

1. the settlement attack holotape options only affects zombie attacks (frequency/max size)
2. the replacement holotape options may still replace certain settlement attackers

Sanctuary Hills bug

One of the spawn points in Sanctuary was not working properly. It is the one near the main bridge that is actually located up in a tree off the ground (don't ask me why). Whenever this spawn point was chosen either zombies didn't spawn at all or they spawned in the nearby house near the bridge (the one not completely destroyed). To fix this, I moved the spawn point (via script) to the other end of the main Sanctuary bridge where I thought it belonged anyway.

Sanctuary Hills LocationEdgeMarker up in a tree that was moved to the other end of the bridge.

Future ideas

I'm already thinking about possible future enhancements. One thought revolves around putting a real negative consequence to abandoning your settlement during an attack. Maybe all your settlers die, the zombies stick around, and you lose control of the settlement until you clear the zombies and re-activate the workshop?

Level 8 Zombies approach the player in the woods.

I initially set out to do some refactoring and re-introduce Fog Ghouls to the commonwealth after deprecating the Far Harbor plugin to Zombie Walkers. I ended up reworking the entire zombie leveling scheme hopefully for the better.

The Old Way

The old zombie leveling scheme basically matched the game's built in approach for Feral Ghouls. There are eight (8) main base types of Feral Ghouls each at a different level with different stats. These 8 types are combined in leveled list and the version that spawns is highest level Feral Ghoul that is at or under the player's current level. Below is a table of the main stats I'll be focusing on:

Level	XP	Damage Resist	Energy Resist	Base Damage*	Health
1 - 8	7	10	20	30	35
9 - 14	13	15	30	45	70
15 - 21	22	30	45	60	80
22 - 31	32	40	60	70	140
32 - 41	47	50	75	80	170
42 - 51	61	60	90	95	200
52 - 61	76	70	110	105	385
62+	90	85	140	120	505+

*note: Base Damage was increased by 15 over base game and extra radiation damage removed. The value listed is damage done on Normal difficulty (2x = very hard, 4x = survival).

A couple things to note from the above:

• Health increases greatly at level 52 and again at level 62. After 62, the zombie health can and does continue to grow as the level 62 variant of Feral Ghoul is the only one that levels with the player.
• Base Damage on survival is lethal. At level 1, zombies do 30 * 4 = 120 damage which is enough to one shot many characters. Survival is the difficulty this mod is meant to be played at, but zombies one shotting players isn't what I am going for either.
• Between level jumps, the zombie stats remain static. This means a level 8 zombie is identical to a level 3.

The New Way

I used the Google Chart API to graph the progression of these statistic changes for Feral Ghouls and noticed that most fit a linear trend. The API allows charts to render trend-lines that provide the formulas which I extracted and used in the OnInit method of the zombie's script to set there stats after they spawn. Here are screenshots of the charts (just in case the API changes, I don't want to have to maintain them here):

XP = 1.432 * Level + 1.063

Damage Resist = 1.24 * Level + 8.276
Energy Resist = 1.933 * Level + 13.988

Damage =  1.433 * Level + 33.175

Health = 5 * Level + 20

A quick note about the Health chart. Notice the two red dots above the trend line toward the right. Feral Ghouls gain more health at levels 52 and 62 than they normally do prior to that. It seems like an attempt by the game creators to just make them a lot tougher for high level characters to face. To create this trendline, I basically used the 35 health at level 3 as a base and extrapolated it out using the game's known health leveling formula. Coincidentally, all of the other Health totals fell in line with this trend.

Survival Damage Adjustment

The new way actually increases damage dealt at level 1 to about 35. On survival this becomes 140! To address this, I added a new holotape option that allows players to adjust the amount of damage done on survival and set the default to match very hard (2x) so that level 1 damage is 70 which should be survivable (at least 1 hit anyway).

To implement this so that it only affects zombies, I actually divide the damage they do by an amount to where when it is multiplied by 4 (survival's damage mult) it comes out to the value I want. For example: diving 35 by 2 gives 17.5, which when multiplied by 4 becomes 70.

Refactoring Spawn Variety

To initially implement spawn variety, I created copies of the 8 actor types for each level increment and manually adjusted their stats at each level. Tedious, painful, and a maintenance nightmare. Not to mention having 8 * 8 = 64 zombie actors increased the size of the mod.

To refactor, I deleted all the extras and stuck with the base 8 types. All of their stats are set via a script attached to them when they spawn now, so I no longer have to worry about manually setting their stats via the GUI. 

I also went through and added all available skin tones for Feral Ghouls in the base game to all variations (Traits -> Object Template on the Actor in CK) and added the special Pink zombies from Suffolk County Charter School for fun.

  4 different base outfits (default, bloody, withered, armored)
* 7 different base skins (Carrion, Charr, Dark, Green, Grey, Pale, Pink)
= 28 base combinations
+ 1 special Suffolk Country Charter School skin/outfit
+ 1 Fog Ghoul skin/outfit (if Far Harbor installed, see below)
= 30 total combinations

Fog Ghouls Zombies

Finally, I added the necessary code to add the Fog Zombies to the commonwealth if you have Far Harbor installed. Originally, I was just going to add the outfit to the list above, but I thought it would be funner and maybe more appropriate to use these zombies to replace marine creatures (if spawn replacements are used). In this way, when you enter an area that would spawn things like Mirelurks, which are normally near water, you would start to see the fishing net covered Fog Zombies.

Here's the list of creature types replaced by Fog Zombies (if replacements are enabled):

• Creatures
• Anglers
• Gulpers
• Mirelurks
• Heavy Knockers
• Fog Crawlers
• Hermit Crabs

Zombie Walkers 2.0

The above was released as part of the Zombie Walkers 2.0 release. Since the leveling changes and refactoring was quite large and affected the core of the mod, I decided to finally up the major version number. I'm hoping to stick with a more canonical versioning scheme moving forward.

Other changes included in this release was a fix for immortal zombies caused by explosive damage and a reset of the Far Harbor leveled lists to help those migrating away from that deprecated mod.