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.