A Zombie Horde approaches!

In almost every tradition zombie film the zombies tend to horde together in groups and wander around. This is something I've always wanted to bring to my mod and I've finally gotten around to implementing it.

AI Packages

Packages are sets of instructions that influence the behavior of actors in the game. You can think of them as configurable AI that gives actors (like zombies) a list of possible actions to perform.

Many actors in the game, including Feral Ghouls, have default packages assigned. One in particular has a lot of useful functionality already called the Default Master Package which I'll talk about below.

Linked References

Step one is figuring out how to make them move. It really isn't a horde if the zombies just stand around. What I wanted to accomplish was zombies that walk around aimlessly if they are idle (not in combat).

This is where the aforementioned packages come in. The Default Master Package has procedures for Follow and Patrol. Both of these procedures work by making the actor path to a linked reference. A linked reference can be just about anything and there are methods in Papyrus to GetLinkedRef and SetLinkedRef.

Patrol (aka. make them wander)

The patrol package is triggered if a zombie has a linked ref set to something like an Idle_Marker. Idle Markers are hidden objects that mark a particular location or object. They can be explicitly assigned as a linked reference to an actor or idle actors can "discover" them on their own if they happen to be in the area (like settlement workshops).

In my case, I spawn an Idle Marker in a random direction away from a zombie I want to make walk and then assign the marker as the zombie's linked reference. This is enough to make the zombie slowly walk (regardless of the Speed setting on the holotape).

Once they get to the marker, they stand around. Of course I want them to continue wandering aimlessly until they bump into something (ie. enter combat). To do this, I use the RegisterForDistanceLessThanEvent between the zombie and the Idle Marker. This event triggers when the zombie gets within a certain radius I define of the marker. When it triggers, I simply move the marker. This pattern repeats and the zombie continues to follow the continuously moving marker.

The direction they move is random at first and then they generally stay in the same general direction afterward. I assigned a number to the basic cardinal directions and used an Actor Value assigned to the marker to keep track of the direction. The first move is completely random, then the subsequent moves can be straight ahead (no change) or 1 value deviation from the last direction.

7 (NW)	0 (N)	1 (NE)
6 (W)		2 (E)
5 (SW)	4 (S)	3 (SE)

Dealing With Patrol Problems

Unfortunately, there are times when a zombie is unable to reach the Idle Marker or at least get close enough to trigger the DistanceLessThan event. In those cases, the zombie will just stand around and stop moving so we need to do something about it.

I created another Actor Value for timestamp and assigned it to the marker to keep track of the last modified time. This timestamp is set when the marker is created and any time it is moved.

I already have a hidden quest with a trigger to do some processing every 10 seconds or so. I updated this function to add a check for all markers (of a type that I spawned). If a marker's timestamp is older than some threshold I define then the marker is deleted and I send a Custom Event.

All zombies that are spawned listen for my custom ZombieMarkerDeleted event that is generated by my quest's script and respond to it. In the case of a zombie that is wandering, it begins the wandering process all over again by spawning a brand new marker in a random direction.

From Wandering Zombies to a Horde

OK, so at this point we have every zombie wandering in it's own direction randomly. To make it a horde they really need to band together some how and move in groups.

To accomplish this, I took advantage of the Follow procedure which works similar to the Patrol above. If you set a linked reference for a zombie to another zombie then it will follow it. It's really that simple.

But wait, who should follow who? I came up with a simple solution to allow the zombies to determine whether to follow or start patrolling themselves. The zombie effect script that gets attached to them (see Dynamic Script Attachment) now sets their FeralGhoulFaction rank randomly from 0 to 100 and that rank is used to determine who follows who.

• Check for nearby zombies and follow the first one you come across with a higher rank than my own.
• If no zombies are nearby with a higher rank, then start to patrol (wander by spawning an Idle Marker to path to). 
• Note that any zombies that have decided to follow me will therefor also start to patrol behind me.

Dealing With Follow Problems

The only real problem you run into when following another zombie is what to do if that zombie dies. The easy solution for this is to register for the OnDying event and follow someone else (or start to patrol ourselves).

Issues With Quests

After release, a bug was reported where a player was sent to clear zombies from an area but when they got there the zombies were nowhere to be found. As you might have guessed, the horde behavior caused them to wander out of the area before the player got there.

To address this and avoid interrupting quests, I decided to disable the horde behavior for certain zombies so that they would be there when expected. To determine which zombies to not move, I ended up discovering by some research that many of the quest related actors in the game are linked to their location with a Location Ref Type. There types allow quests to quickly determine if all actors in a group are still alive (eg. functions like GetRefTypeAliveCount). You can check if any actor is used as a Location Ref Type pretty easily using GetLocRefTypes.

Another exclusion I ended up adding is for zombies that spawn in a Clearable or Dungeon location. These locations often rely on the actors being present to be "cleared" and can easily be checked by GetCurrentLocation and HasKeyword.

• do NOT follow or patrol if:
• Actor (or replacement) has a least one linked Location Ref Type
• Actor (or replacement) spawned in a Clearable or Dungeon location.

The "or replacement" refers to the optional Spawn Replacements holotape settings. If used, the replacement is taken into account in determining mobility. Note that if replacement levels larger than one for one (eg. two for one) are used, then the "extra" zombies are not tied to the original actor in any way and can and will wander freely.

Wrap Up

The combination of patrolling and following described in this article gives zombies an initial wandering horde behavior that is much preferred over just standing around. It adds a dynamic unpredictability to every play-through as well in that you'll never know where zombies might appear even if you've memorized all the spawn points.

I'll likely continue tweaking this behavior as bugs are reported and ideas come to me. I already have thoughts about adding additional marker types for noise and possible dead bodies. Noise markers could serve to attract zombies from farther away than the game's default detection range (but not make them hostile, just make them lumber toward the sounds in the distance). Dead bodies could attract nearby zombies for a feast as Idle Markers can have Idle Animations associated with them (eg. the Feral Ghoul crouching and eating animations).

Infinite zombies spawning to replace molerats at the Rotten Landfill location.

Sometimes, too many zombies is a bad thing. Like when said zombie horde crashes your game. This is unfortunately what was happening at the Rotten Landfill thanks to how the quest there worked in conjunction with animal spawn replacements.

The Issue

There is a quest used at the Rotten Landfill to stage a fight between a settler and some molerats. The idea is to have this fight continue until the player is close enough to witness it and potentially intervene.

The quest marks the settler as immortal and spawns a few molerats that are marked to re-spawn when killed. When the player gets within 6000 units the fight is triggered and will continue forever with the molerats continuously re-spawning as the immortal settler eventually kills them. When the player gets within 3000 units the fight becomes real in that the settler is mortal and the infinite re-spawns are stopped (and instead become X waves as described on the wiki).

When using the animal spawn replacement option via the Zombie Walkers holotape, these molerats are replaced by zombies. During that replacement, the molerat being replaced isn't just disabled (disappearing from view) but also killed. Since the molerat is killed, it triggers the quest to re-spawn the molerat which in turn gets killed and replaced with a zombie. This triggers the molerat to re-spawn again... well, you probably see where this infinite loop is going.

Why kill the replacement?

Good question. I knew some quests involve creatures that might be replaced by my mod. To avoid those quests getting stuck, I wanted to make sure they didn't end up waiting for a death event that would never arrive. The first example of this I can think of is the Sanctuary bloatfly quest with Codsworth.

So how do we fix Rotten Landfill?

The easy solution would have been to simply exclude the location from spawn replacements, but I'm too masochistic for that. Instead what I ended up doing is delaying the kill until the zombie that replaced the molerat was killed.

This was actually fairly straightforward to implement. At time of replacement, the creature being replaced is still disabled and I added a linked reference to the creature being replaced to the zombie that was replacing it with a new keyword. When that zombie died, I added code to check for that type of child linked ref and kill it also if present. Note that this only applies to the first zombie replacing that actor, so if you are using 2 for 1 replacements, the second zombie's death will do nothing to the replaced actor.

This approach not only solves the Rotten Landfill issue but also keeps quests from getting stuck. It should also be universally applicable for other re-spawns that might be used in other areas. Finally, it makes sense and flows better while you are playing the game. Now when you meet Codsworth in Sanctuary, you will search the neighborhood killing zombies instead of bloatflies instead of the quest starting out in a "I already searched the neighborhood" state.

Immortal Zombie (reaver armor) with the gunshot wounds to the head to prove it.

Zombies That Magically Heal

Sometimes zombies just don't want to die, even when you shoot them in the head numerous times. In the case of the Reaver style zombies (encFeralGhoul04), they get knocked down and then get back up with full health restored. This is the zombie type I've personally noticed this bug with and it is 100% repeatable with them. All other zombie variants die as expected with a headshot.

Tracking Down the Issue

Tracking this down involved a lot of trial and error, but eventually it came down to what I believe to be a bug in the game with Deferred Kill and this particular Feral Ghoul actor type. Deferred Kill basically makes it so an actor does not die until you tell it to. If headshots only mode is enabled, then deferred kill is started when the zombie is initialized.

To end the deferred kill, I registerd for the OnCripple event. This event is triggered when any limb (including the head) is crippled by damage. I noticed for the Reaver style armored zombies that this event was triggering twice and that the deferred kill seemed to not be honored.

Event OnCripple(ActorValue akActorValue, bool abCrippled) 

[ZombieEffectScript] HandleCrippleEvent([Actor < (FF00134A)>],[ActorValue <PerceptionCondition (0000036C)>],True) -> 0.000000

[ZombieEffectScript] HandleCrippleEvent([Actor < (FF00134A)>],[ActorValue <PerceptionCondition (0000036C)>],False) -> 100.000000

 As you can see above, the first call has 'True' for the crippled bool flag for the PerceptionCondition (head) which is good. In that handler I EndDeferredKill and then call Kill if the actor is still alive. This apparently isn't good enough for the Reaver zombies as they regenerated their health and limbs, did NOT end deferred kill and got back up off the ground. This regeneration is what I think triggers the second onCripple event which notifies the code that the head is now un-crippled (abCripple is 'False').

After some experimenting in game, I noticed that you could in fact kill these zombies if you shot it multiple times in the head in succession (while it was dropping to the ground). I then experimented with shooting them in the torso a bit first and then the head which revealed a pretty consistent way to dispatch them as they died almost always with a single head shot if their health was down a bit first.

Fixing the Problem

As an experiment, I updated my onCripple handler to remove any remaining health before ending the deferred kill state and that fixed the issue. Apparently triggering EndDeferredKill when their remaining health was 0 always worked for the Reavers, even though the other types didn't care how much health was remaining. I think it wasn't the EndDeferredKill call itself so much as the subsequent call to Kill that seemed to behave differently.

Here's what I ended up with:

; helper function to handle both onCripple and onPartialCripple
Function HandleCrippleEvent(Actor akSender, ActorValue akActorValue, bool abCrippled)
Debug.OpenUserLog("joefor")
Debug.TraceUser("joefor", "[ZombieEffectScript] HandleCrippleEvent(" + akSender + "," + akActorValue+ "," + abCrippled + ") -> " + akSender.GetValue(akActorValue))
If( abCrippled )
If( akActorValue == HeadConditionAV )
; head is crippled - make sure zombie dies
KillZombie()
Else
; other body part crippled - apply knockdown
ZombieActor.PushActorAway(ZombieActor, 1)
NPCFeralGhoulInjuredDownNotOutEnter.Play(ZombieActor)
EndIf
EndIf
EndFunction

Function KillZombie()
float healthAmount = ZombieActor.GetValue(HealthAV)
Debug.OpenUserLog("joefor")
Debug.TraceUser("joefor", "[ZombieEffectScript] KillZombie(" + ZombieActor + ", health=" + healthAmount)
; there's a bug with Feral Ghoul 04 not dying if health remains before deferred kill ends
; make sure remaining health is zero to trigger deferred kill
ZombieActor.DamageValue( HealthAV, healthAmount )
; end deferred kill to allow zombie to die
ZombieActor.EndDeferredKill()
; now, make sure zombie dies
If( !ZombieActor.IsDead() )
ZombieActor.Kill()
EndIf
EndFunction 

Version 1.15 Coming Soon

I'm wrapping up some testing and will be deploying in the next day or so. Here's what will be included:

• The fix described above for immortal zombies
• fix for Suffolk County Charter School (humans in underwear spawning instead of zombies)
• NEW optional horde behavior - zombies follow each other and wander around instead of standing still where they spawned (I may blog separately about this)

Update 1/1/2017: more immortal zombies

More immortal zombies, one of which is missing half its skull.

Another immortal zombie bug was reported and has been fixed. This one has to do with situations where the OnCripple event is not received by the script and therefore the zombie never leaves the deferred kill state. Subsequent OnCripple events are not received for the head if you continue to shoot the head.

To reproduce this, I used a missile launcher and aimed for the chest in a group of zombies. The immense amount of damage seems to sometimes cause this. I'm still not 100% sure why the OnCripple for the head (PerceptionCondition) is not received by the script. I noticed that every time it happens, the script does receive OnCripple for the body (EnduranceCondition). Maybe the game assumes if the torso is crippled (which is rare) then the creature will die anyway so it doesn't bother sending a separate one for the head?

In either case, to fix the problem I added one more event registration to the script. This one is for the OnDeferredKill event. This event gets triggered when an actor is in the deferred kill state and receives damage that would kill it if it weren't in that state. It also happens to fire over and over again as damage is received, even if the health goes into the negatives. Basically, I use this function to check the state of the head and end deferred kill if it is destroyed.

Let's hope this is the last of the stubborn zombies that refuse to die.

Update 1/27/2017: crippled vs dismembered

Even after my last update, still some immortal zombies were reported albeit rarely and usually when using certain explosive weapons like Spray N' Pray. Upon further research I noticed that in VATS only their torso was target-able as in the screenshot below.

Immortal zombie with only the torso target-able in VATS.

I began doing research into what would cause the head to not be there and quickly realized that it is actually dismembered (like the legs/arms in the screenshot above). After adding some debug logging I then saw that sometimes the head health would be above zero even though the head was dismembered!

OnDeferredKill([Actor < (FF000F36)>],[Actor < (00000014)>]),  PerceptionCondition = 20.053139, HeadDismembered = True

I then updated my function to check if the head is destroyed by checking EITHER:

• Head health is 0 (PerceptionCondition)  ... OR ...
• Head is dismembered (Head1 for feral ghouls and humans)

I then tested by spawning groups of 20-30 zombies at a time, waiting a bit for my scripts to attach and initialize on all of them, and then mowing them down with Spray N' Pray. Before the changes I was seeing 1 or 2 in every group in the immortal state in the screenshot above. After the change I could not produce a single occurrence even after spawning several waves.

I have published Zombie Walkers to the Nexus mods site to hopefully expand the PC user audience as many players on PC use the Nexus Mod Manager instead of Bethesda's built-in mods menu.

http://www.nexusmods.com/fallout4/mods/20485

Why?

The current approach used on Zombie Walkers involved modifying Leveled Lists by jamming Feral Ghouls (Zombies) into them so they spawn instead of the intended Actor type. This works most of the time, but has a couple of drawbacks:

• It doesn't work for all actors. Super Mutants for example seam to have all sorts of problems sometimes spawning naked without heads, or spawning as a zombie naked without heads, or spawning as a Super Mutant called Zombie.
• It doesn't work in all situations. Leveled spawns that have scripts associated with them, like ambushes, often spawn headless zombies. To get around this for ambushes, I ended up not updating the leveled list and doing a literal search/replace in the game cells. This modifies the cells of course and causes issues when users install/uninstall the mod until they manage to get their cells to reset.

New Approach

Instead of modifying leveled lists or replacing them in cells I am moving toward a scripted solution. I already have a quest that runs every 10 seconds to assign special attributes to Zombies, so I am adding more aliases to it to check for Non-Zombies and replace them if a set of criteria matches.

Current base criteria:

1. Actor does NOT have the SkipZombieReplacement keyword.
2. Actor is NOT essential.
3. Actor is NOT protected.
4. Actor is NOT unique.
5. Actor is NOT player teammate.
6. Actor is NOT currently visible by the player.

If it meets these criteria, then we check if it a type we want to replace. The SkipZombieReplacement keyword is added when the actor fails replacement for any reason so that it is not checked again in the future to improve performance. For the first version, I am porting over just the 5 existing replacement categories already configurable in the mod:

1. Large Creature replacements enabled and has "heavyKnocker" keyword (eg. Deathclaw, Mirelurk Queen, Sentry Bot)
2. Super Mutant replacements enabled and has "SuperMutantRace" race
3. Robot replacements enabled and has "ActorTypeRobot" keyword
4. Animals replacements enabled and has "ActorTypeAnimal" keyword
5. Creature replacements enabled and has "ActorTypeCreature" or "ActorTypeBug" keywords

Note that you can still set a percentage replacement which is checked each time. I've updated the percentage options to be 50%, 75%, and 100%. You can think of these percentages as "percentage chance to replace if base criteria is matched". For example, there's a 100% chance that a super mutant will be replaced if they are not essential or protected or unique or a player teammate and not currently visible to the player. (Strong is safe since he's essential)

Another thing I am adding is the option to replace a creature with more than one zombie. This was not possible with leveled lists as I had no control there, but now I can let players replace each Super Mutant with 2 Zombies and each Deathclaw with 10 Zombies if they want to. These options will be configurable alongside the current replacement percentage config.

Progress and Testing

I've finished implementation and have been testing the past few days in between publishing updates for the new PS4 version of the mod.

Testing has been going well overall but there are still bugs to work out before I publish the update. If anything, the replacements are working a bit too well and replacing things they probably shouldn't. I'm trying to test edge cases and make sure I don't break people's games (unless they want me to).

There are still some edge cases I haven't tested yet, like DLC robots and captured animals. Unfortunately, I don't have DLC outside of Far Harbor on PC so I may need to fire up my XBox to test those eventually.

For my initial testing I enabled all replacement options at 100% with a 2 to 1 replacement ratio (2 zombies per creature replaced). The only exception is the Large Creatures category which I set to a ratio of 10 to 1 for fun.

Here's some screenshots with captions that explain a few of the things I've run into:

Zombies replaced the 2 Gorillas in the Institute. Funny thing is, they were hostile in color but displayed idle behavior and the Institute scientists didn't seem to care (no combat triggered). This kinda gives the impression that the Institute is involved in starting the zombie apocalypse. Maybe I leave it?

Several zombies spawned in Diamond City and a couple of them killed poor Abbot before I even got to him. It seems they replaced the cats, eyebot, and brahmins. Cats and Brahmin are not always replaced as they are usually marked protected. Abernathy's animals were fine, but the crazy cat trader was overrun when I got there.

Several zombies spawned aboard the Prydwen. They replaced the cat, Mr. Handy, and molerats.

Update (11/25):

I added to the base criteria to address non hostiles being converted in settlements/cities:

7. Actor is hostile to player OR Actor is in ambush mode (will be hostile)

Initially I added just the Actor is hostile part, but I noticed certain ambush types like Molerats and Radroaches would not be replaced. When I researched it I noticed ambush actor types use the same scripts to trigger the ambush. The two main types are:

• DelayedAmbushScript - start off disabled (but still hostile) and appear upon some trigger like the death of another actor
• MasterAmbushActorScript - start off enabled but not hostile and become hostile when triggered by player proximity.

The MasterAmbushActorScript types were the issue as the others were being replaced since they were hostile from the beginning. After further research, I figured out you can check if an actor has this script type using the CastAs function. You can use it directly in a conditional statement since it will safely return NONE if the actor isn't of that type.

; returns the target casted to the specified type or NONE
If( target.CastAs( "MasterAmbushActorScript" ) )

After making this change, testing is looking much better. Ambush types are being replaced as expected and no zombies are spawning in Diamond City or the Prydwen anymore. I'm almost ready to deploy and test on my XBox for final verification.

I noticed Zombie Walkers (PS4) is getting some press lately. It was featured in an article from iDigitalTimes as #4 of "5 Of The Absolute Best Mods To Try On Sony's Console". Click the image below to see what the other 4 are.

5 Of The Absolute Best Mods To Try On Sony's Console

Splitting the PS4 Zombie Walkers Mod

There seems to be two types of users of the PS4 version of the mod. Some want more zombies and some want less. To accommodate the latter, I have moved spawn replacements into a separate optional mod and made the main mod much smaller in scope in that it just transforms Feral Ghouls to Zombies (to the extent possible without scripting).

Zombie Walkers: Replace Creatures

Zombie Walkers:Replace Super Mutants

Future

In the event Bethesda and Sony ever agree to allow external assets (specifically custom scripts), I will migrate the main version of the mod to PS4 and deprecate the PS4 version and the replacements spin-off.

I've received a lot of requests for more zombies and more replacements on PS4. I can accommodate those requests through addition plugin mods for replacements, but the extra spawns is very tedious without a generic scripted approach.

I have 8 version of this mod across 3 platforms now. The user comment threads are difficult to keep up with at this point and I've even being tagged in social media comments on YouTube. It is satisfying to create something that so many people seem to enjoy, but it is at the same time a bit overwhelming trying to keep up with it all.

In the short term, I'm going to focus my efforts on mod consolidation starting with the deprecation of the XBox/PC Ambush Replacements mods. The next blog post may be a recap of the new approach to replacements that I'm hoping will make this possible.

Zombie Walkers: Replacements (PS4)

Zombies are attacking Red Rocket Truck Stop! Can you find them in this screenshot?

Settlement Attacks vs Sleep Interruption

Zombie Walkers has had the Zombie Attacks mode for awhile but it was buggy and didn't always work. Also, this mode only worked by interrupting your sleep for an attack. It didn't trigger settlement attacks when characters were awake (usually daytime).

I re-organized the holotape settings to better describe the mode by calling it Sleep Interruption and added a new one called Settlement Attacks. Both modes can spawn attacks at different times and can be configured with different percentage chances (per hour).

Triggering Settlement Attacks

To cut right to the chase, to trigger a settlement attack using the built-in mechanism you must get a reference to the appropriate WorkshopScript and then call the CheckForAttack method with an argument of true for forced. 

I found looking at the games built-in settlement scripts like WorkshopParent to be helpful For example, to get a collection of workshops in the game you add the following property to your script:

In my script, I chose to only trigger attacks when you are present at a settlement. There's nothing worse in Fallout 4 than being notified of attacks on the other side of the map. Also, with how I modified my attack it will begin immediately so you wouldn't get there to help anyhow.

There's a timer that runs to check for an attack every 30 minutes in game. The percentage chance is based on your holotape configuration setting (halved since the holotape setting is per hour).

Sleep Interrupted With No Attack?

The Sleep Interruption mode didn't always trigger an attack when CheckForAttack was called. To debug the issue, I eventually realized you can enable Story Manager debugging with the following ini setting:

bEnableStoryManagerLogging=1

I then saw the following line in StoryManager.0.log:

----Quest 'WorkshopZombieAttack' failed to fill aliases

Eventually I realized that I wasn't giving the game world enough time to load before trying to trigger the attack. Quest alias, like the workshop itself, won't fill if the objects are not yet loaded.

To "wake up" the Player I copied the approach used in the game's built-in survival script which is to call playerRef.MoveTo(playerRef). Moving the player to their current location causes the screen to fade out and back in and the game world to reload, I guess to simulate waking up? To fix, I added a short wait after waking up the player but before triggering the attack with Utility.Wait.

Only Zombie Attacks

The other thing I wanted to do was make sure that when settlement attacks are triggered only zombie attacks would result. To do this I updated the settlement attack quest properties in Character -> SM Event Node -> Script Event. I added a property to each settlement attack quest that basically says only allow this if Settlement Attacks mode is disabled. For my custom zombie attack quest if says only allow this if Settlement Attacks mode is enabled.

Add property to WorkshopAttack quest scripts to disable all but zombie attacks.

Zombie Attack Quest Tweaks

One final thing I did was modify the Zombie Attack Quest itself to add notifications when the attack is beginning and over at the appropriate Quest Stages (see the screenshot at the beginning of this post). The game has similar notifications already, but only for settlement attacks that you are not already present for. Since these attacks are limited to when you are at a settlement, I had to add my own.

The built-in settlement quests also delay the start and end of these quests. The start delay is to accommodate the player making their way to the settlement and the end for them to chat with settlers about helping them. I removed both of these delays by updating the appropriate Quest Stages so that the attack starts right away and the quest is completed once the 'all attackers dead' stage triggers. This allows another attack to immediately happen at any time without delay.

Update 1/23/2017

The settlement attack implementation has been updated to move away from the game's built-in quests. Please see Better Settlement Attacks for details.

Zombie Walkers (PS4)

I'm happy to announce the release of a PS4 version of the Zombie Walkers mod. This has been a long time coming and even a stripped down version is better than nothing.

This version includes most of the Feral Ghoul Overhaul features (no running/sprinting, body part data updates to encourage headshots, more damage, etc.) but has no custom scripting since it is not allowed for PS4 unfortunately. This means no holotape configuration options, headshots only mode, NPC resurrection, etc.

I may add global (non-configurable) spawn replacements if there is enough demand for it.

One Major Restriction

It appears Bethesda and Sony have reached an agreement that will bring mods to the PS4 after all. However, there is one MAJOR restriction:

"Note - PS4 Mods are Plugins only. No archives are permitted." - source

Before realizing this restriction, I gleefully went to deploy Zombie Walkers to PS4 and received the following message from the Creation Kit:

PS4 does not support archives :(

What it means for Zombie Walkers

Basically this means you are not allowed to add custom scripts and can only modify assets already in the game. Therefore a direct port of Zombie Walkers is not possible. At best I could create a separate very stripped down version that resembles the first version I pushed out in July which basically made Feral Ghouls walk, not dive around, and take less damage to all but the head.

I'm not ruling out this possibility, but this is certainly a setback and makes me sad.

Out with the old, In with the new

Top: GeForce GTX 1050ti 4gb
Bottom: GeForce 9400 GT 512mb

Up until now I have been modding Fallout 4 on my Macbook Pro laptop. I used Bootcamp to install a copy of Windows 10 in a separate partition and then tweaked the daylights out of the game and discovered a workaround for a startup issue. At best I can get 40-50 fps in the special QA Smoke room on ultra-low settings (eg. vsync/grass/godrays/fog/etc. turned off).

The trouble is when I enter the real game world the frame rates plummet. In Sanctuary I'm lucky to get in the teens but can't see where I'm going. Needless to say when users report issues with one of my mods in specific areas of the game, it becomes difficult for me to test. Some issues, like game crashes, are impossible to debug on XBox.

Luckily my wife loves me and decided to let me upgrade my graphics card for my birthday (I know you are all jealous). Here's a screenshot comparing old vs new. Note that the old 9400 card pictured below is actually from my PC and performs on par or worse than the integrated Intel HD 4000 in my Macbook Pro.

Screenshot Comparison

The screenshots below show a stark contrast in both quality and performance. The one thing you don't see is that everything about the game is slower on the integrated card (including scripts). Some areas of the game get as low as 1fps depending on how many objects are around.

Fallout 4 on low settings 640x320 @15fps on Intel HD 4000 graphics

Fallout 4 on ultra high settings 1280x1024 @60fps on GeForce GTX 1050ti graphics

Happy days for me as a modder and I guarantee Zombie Walkers will benefit.

I am very happy to announce the release of Zombie Walkers - Far Harbor. This initial version includes spawn replacements for Far Harbor animals and creatures and brings the For Ghouls (renamed Zombie of course) to the Commonwealth.

Look for more updates to follow.

Update 1/29/2017

Please note that this plugin mod was deprecated recently and is no longer available for download. The Far Harbor changes have been rolled into the base mod for PC and Xbox One and include spawn replacements and the spawning of Fog Ghouls in the commonwealth (renamed zombie of course).

Zombies approach Far Harbor as part of opening sequence.

Progress

The new mod is progressing now that I've figured out inter-mod communication. The main Zombie Walkers mod is now dynamically checking for the Far Harbor plugin and adding fog zombies to the core leveled lists as part of the initialization script.

Outside of that I am now adding and testing spawn replacements starting with Gulpers and Anglers. Once all the core replacements are set for Far Harbor animals/creatures, I'll post the first version of the mod. Right now the mod will automatically replace all Far Harbor creatures and I haven't decided yet if I want to put the work into a holotape config option. The replacements are kind of the main point of this mod.

Wolf bugs?

When I was doing a search and replace for the DLC03_LvlWolf leveled actor and replacing with the zombie equivalent, I noticed the below error message when I next loaded the Creation Kit.

Warning when opening the Creation Kit about how I'm changing a wolf from cell 'NONE'.

The bit about changing ref from base to base makes sense because that is what I'm doing. However, I did not change the cell so I'm not sure why it is saying from NONE to Wilderness. In the render window it is in a wilderness cell (it appears anyway), so I'm wondering if a couple specific instances of LvlWolf are not configured correctly?

Game Crashes (resolved)

At first I tried using the render window to do all replacements. The problem is the game would crash on cell load. Different combinations of replacements would crash in different cells (where the specific creature was used I'm guessing?).

Initially I suspected wolves are what was causing the crash given the error above. It turns out the game crashed even if I didn't touch the wolves. I ended up rolling back all the way to no render-view replacements and updating leveled lists directly before I could walk across half of "The Island" without a crash.

Now that I'm more familiar with modding, I recognize the brief hiccup that sometimes occurs on my XBox is the game loading a new cell. It is during that hiccup that I was experiencing the crashing, so now I cringe slightly each time and then relief comes over me as I realize the game is still running.

I haven't experienced anymore crashing after sticking with leveled list updates, but at some point I'd like to figure out what is going on in case I need to use the Render window for this mod in the future.

Recently I received a generous donation on this very site from a fan of this mod. I decided to invest some of that money back into the mod by purchasing Far Harbor for PC. I own the season pass for XBox, but that does not transfer over to PC where I have to do the modding from (unfortunately). I have plans for replacements and bringing the Fog Ghouls to the commonwealth in a plugin to this mod.

During the process of creating this new child plugin, which is still a work in progress, I am running into all sorts of errors. Basically learning by doing things wrong and quickly learning about limitations. I'm going to document some of those errors below in case others happen upon this page in a future google search.

TL;DR when dealing with mods that depend on others, read the Inter-mod Communication wiki page for options.

Error 1: const type zombiewalkerutil may not be used to define script variables or properties

I have a ZombieWalkersUtil script in my main mod that has some global utility methods I'd like to use in the new mod. I tried to declare a property with the type being the script name, which apparently isn't allowed.

I then changed the property type to "Script Object" which is allowed. The problem is, when you go to assign a value, the list is empty for me so I can't chose any script let alone the one I want.

Solution: I'm not sure this is allowed

Error 2: type mismatch while assigning to a var (cast missing or types unrelated)

Since this is declaring Global functions, I figured I'd try out the special utility method made to call them: Utility.CallGlobalFunction.

In my case, this looked like it was going to work until Papyrus got grumpy with one of my script parameters in the Var array. Either it doesn't like int[] params, or I am doing something wrong. I tried explicitly casting as an int[] but that didn't help. The other parameters (eg. FormList, int) didn't seem to throw any errors.

Eventually I ended up giving up and rewriting a portion of the script inline where I needed to use it (for now). Maybe someone stumbling upon this post can provide some guidance on what parameter types are allowed.

Solution: maybe int[] parameter types aren't allowed?

Error 3: Cannot open store for class "ZombieWalkerFH_QuestPlayerScript", missing file?

The errors above came from a Quest initialization script where the scripts associated with the quest could not be read/bound. This resulted in an abrupt game crash. I eventually realized the error resulted from me violating the undocumented naming conventions for ba2 files.

Solution:

1. File -> Create Archive
2. for each filename, you must follow this convention (including spaces): {modname} - {type}.ba2

Example expected naming convention for main archive. Note mod filename is "walkers-farharbor.esp"

Error 4: Property ZombieListOfLists on script ZombieWalkersFH_QuestScript attached to ZombieWalkersFH_Quest (0800D291) cannot be bound because <nullptr form> (08016D3B) is not the right type

This error occurred after I fixed Error 3 above. I'm a Java programmer professionally and like others in my field, NullPointerExceptions sometimes haunt me. Now I guess they officially haunt me in Fallout too.

The ZombieListOfLists property above was setup to point to a FormList in my base Zombie Walkers mod. You can see the id value (08016D3B) is present but it isn't happy because apparently the game knows the file is not provided directly by my Far Harbor plugin.

Solutions?: It was at this point that I realized I am probably doing this wrong. After some reading, it seems there are a couple options:

• you can use Inter-mod Communication which seems like the correct way to go
• HACK: you can"esmify" a plugin to a master temporarily in order to link a plugin to it to override/depend on files from that master. See Using FO4Edit or How Do I Esmify An ESP File? for a hackish approach.

Zombie Walkers + D.E.C.A.Y = terrifying looking walkers

Mod Conflict

The D.E.C.A.Y - Better Ghouls mod started out as just texture and sound replacements for Fallout 4's Feral Ghouls. This initial first version didn't conflict with Zombie Walkers (or probably most mods out there). Then they released an update (v2.1) that introduced additional changes to drop lists, new Feral Ghoul types, and most importantly a modified leveled list.

The custom leveled list included brand new Feral Ghoul types, some of which were customized and didn't inherit everything from the base template. Specifically, it was reported on several occasions that some Zombies were performing leap attacks when my mod was used with this one even though I explicitly disabled those.

Fixing the Conflict

I ended up "fixing" the conflict accidentally while working on a totally different change. I modified the Feral Ghoul default leveled list which meant if my mod is later in the load order, only zombies in my leveled list will spawn and the new ones introduced by D.E.C.A.Y will not.

The reason I finally modified the leveled list for Feral Ghouls was that I wanted to introduce spawn variety. Basically, I created a whole slew of new Feral Ghouls so that each of the base types in the game were represented at each "level" of Feral Ghoul. I also made the leveled list spawn each zombie independently so each would be a random type even when they spawn in groups.

It is nice when you kill two birds with one stone like this.

If only software bugs were this easy to kill.

I've been away from modding for a few weeks. Work has been very busy as I was away at a conference, representing my company at a job fair, and then giving presentations on new technology. :)

I finally got back to looking at this mod and figured attempting to tackle a couple bugs would be a good way to start. After perusing the comment threads and reviewing my notes I decided to look into the immoral zombies and issues starting a new game.

I liken the below "fixes" to spraying a can of raid on some bugs. You think you hit them but they scurry away into a hole. Hopefully they are going to find a comfortable place to curl up and die and the best you can do is hope they don't surface again.

Bug 1: Immortal Zombies?

Apparently some zombies just won't die when "Headshots Only" is enabled. I have to assume this is because deferred kill is being set but never unset. I think the video in this link speaks for itself ...

 XBox game clip - courtesy of Dxrk Element

That poor, poor zombie. I've actually encountered this bug myself and I'm not 100% certain how I did it. I wish I saved the game actually because I had a zombie that simply wouldn't die no matter how much I shot him in the head. Maybe it is just a game engine bug?

Anyway, one thing I did with the latest 1.06 bug fix release was add an additional check for a zombie's head condition in the onInit script. I figure this way every time the script attaches to nearby zombies (every 5-10 seconds or so) it will double check if the head is destroyed, end deferred kill, and actually kill the zombie.

I'm not 100% sure this will fix the issue and it is difficult to test it so I'm just pushing it and relying on the community to report back on this one.

Bug 2: New Game Infinite Loading Screen

I'm a little more confident in this fix as I am easily able to test a new game. It didn't work before and worked the first time quickly after my changes.

Basically, I got fancy in a prior release and added a popup that describes the changes in the current version of the mod the first time you load your game after updating. Trying to create this message right away when a new game starts is a bad idea and apparently causes the game to hang.

I moved the message to the code block where I add the holotape (after you acquire the pipboy) for now and that seemed to do the trick. I need to verify the message still appears as my PC save game appears corrupt based on the errors I'm seeing in the log. I have a feeling that message not appearing won't upset too many people though as you can see the changes in the mod description anyway.

Update 10/17/2016: I received reports of the game hanging on loading screens during fast travel.One in particular was very detailed and thought they could hit 'A' and hear a menu closing. As a result, I have completed removed the popup since it isn't important and the changes are listed in the mod description anyway.

I have published this mod for the PC through the Creation Kit. It should appear under the mods menu when you launch the game (same as Xbox). I'm in the process of adding links to the PC version of the mod and will keep both updated as changes are made.

Zombie Walkers (PC)

I guess news of PS4 mod support being dropped by Bethesda got me thinking about platforms for this mod. If PlayStation 4 support ever returns, I'll publish to that platform as well.

Working on PS4 Mod Support

Bethesda has been working to bring mods to PS4 for months now. During that process, I was deploying and updating my Zombie Walkers mod so it would be ready and had a fair amount of favorites with comments from users waiting to try it out.

Sometime later I published my Ambush Replacements extension and noticed a 24-hour waiting period was in effect for PS4 mods before I could publish the mod. Apparently Sony wanted to institute a review process and Bethesda was trying to accommodate them (Xbox doesn't have any review and you can publish anytime).

Announcement from Bethesda

On September 9th, Bethesda released a post stating that mod support for PS4 was being put on hold.

"Sony has informed us they will not approve user mods the way they should work: where users can do anything they want for either Fallout 4 or Skyrim Special Edition."

 PS4 Mod Update - [bethesda.net]

PS4 Mods Deleted

On September 13th, I received a couple email notifications that my PS4 mods have been deleted by users Famo and Dinasaur. I checked the website around lunch time (EST) and the number of PS4 mods had dropped to around 400. After checking this evening, the option for PS4 has been completely removed from the platform dropdown.

9/13/16 - no option for "Playstation 4" anymore on Platform dropdown.

Future?

My impression is that Sony is worried about modders significantly hurting the user experience because I'm not sure how much further you can go from corrupting save files or crashing the game? Hopefully Bethesda and Sony can work this out and bring mods to the PS4, but it certainly doesn't look good right now. 

Zombie with zero health still alive and well because the head has full health.

Aim for the head!

When you find yourself fighting zombies, the first rule you learn is aim for the head. Ever since the beginning of creating the Zombie Walkers mod I've wanted to create a headshots only mode. It just seems like the right way to play any zombies game. Finally, I've found an implementation I'm happy with.

Deferred Kill

Fallout 4 has built in functions for creating a deferred kill situation where an actor still takes damage but does not actually die until "allowed" to:

• StartDeferredKill - Puts the actor into a Deferred Kill state. In this state, the actor can take damage but will not die.
• EndDeferredKill - Removes the actor from a Deferred Kill state. If the actor's health went below zero or the actor was killed for any other reason while in the Deferred Kill state, the actor will die when this is called.
• Kill(Actor akKiller = None) - Kills this actor with the passed-in actor being the culprit.

The above is tailor made for keeping zombies alive until their head is destroyed. Basically, you call StartDeferredKill on init and then wait to call EndDeferredKill until the head health is zero. To be extra sure I actually check if they are dead after calling EndDeferredKill and if not actually kill them.

Checking Head Health

Checking head health is actually pretty straightforward. Actors have several properties called actor values that you can check with a simple function:

• GetValue(ActorValue akAV) - Gets the specified Actor Value from the Object Reference.

Since the function takes an ActorValue object, you need to know what object corresponds to the condition of the head. In my script I created a property called HeadCondition and then used the property view to browse available options. After some experimentation I could see that PerceptionCondition was the right actor value to check and ranged from 100 (perfect health) to 0 (crippled/dismembered).

Putting it all together

Here's a sample of what the script might look like (note that I haven't tested this one as I pulled the relevant pieces out of a larger script):

  ActorValue Property HeadCondition Auto Const Mandatory
  GlobalVariable Property HeadshotsOnly Auto Const Mandatory

  Event OnInit()
    ZombieActor = self.GetActorReference()

    ; Headshots Only mode - start deferred kill
    If( HeadshotsOnly.GetValue() == 1 )
      ZombieActor.StartDeferredKill()
    EndIf
  EndEvent  

  Event OnHit(ObjectReference akTarget, ObjectReference akAggressor, Form akSource, \
            Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, \
            bool abBashAttack, bool abHitBlocked, string apMaterial)
    ; check condition of head
    If( ZombieActor.GetValue(HeadCondition) <= 0 )
      ; zombie's head is destroyed, end deferred kill
      ZombieActor.EndDeferredKill()

      ; now, make sure zombie dies
      If( !ZombieActor.IsDead() )
        ZombieActor.Kill()
      EndIf
    EndIf
  EndEvent

Why are you so excited about this?

First, this implements a feature I've been wanting from the beginning. More importantly, it does it in a way that is totally independent of Body Part Data configuration. Torso and Limb damage values/health can be set to whatever (and maybe eventually made configurable) and the zombies will still only die when their heads are destroyed.

I may revisit Body Part Data now that this mode exists to make crippling a little easier. I had changed damage on limbs to 25% and set the health very low but the crippling rate still never seemed to match the default settings. The only downside of changing the limb damage values is it'll make zombies a lot easier to kill if anyone turns off headshots only mode. Then again, who would do that?

What's the problem?

While melee vs zombies isn't always a good idea, it is sometimes necessary. Some masochistic players (myself included) play with extra hardcore mods that reduce ammo and increase ammo weight among other detriments. Therefore, being able to pick up a baseball bat to bludgeon zombies make survival easier with ammo at a premium.

The big issue with melee in Fallout 4 as it relates to Zombie Walkers is that it is difficult to target the head. If you are using VATS then it is impossible as you can only target the enemy generally and the hits location is seemingly random. Outside of VATS, where I usually play, it is still difficult to target the head as the swing trajectory often clips something else instead like one of the arms or upper torso.

Attempting to make melee feasible

The first thing I wanted to do was increase damage and stagger zombies take. Zombies stagger others when they strike with melee, so it only seemed fair it should work both ways.

Looking at the game files it became apparent that these are achievable via perks. I already have a hidden quest with aliases to "nearby zombies", so I updated the script attached to said zombies to add a hidden perk called ZombiePerk to them. Once added, I could then configure the perk as needed to apply various effects.

Hidden ZombiePerk added to "nearby zombies" via hidden quest alias

Perks can be selectable and usable by the player or given to any other Actor in the game. The sections at the top of the screen above area largely for player perks. The Perk Entries section is where the effects of the perk are defined.

Perk Entry for ZombiePerk to modify incoming limb damage (melee only)

Perk Entries are built in and selectable via the drop downs on the right. Each allows to change the values of things like damage in different ways (multiple/add/etc.). The Conditions section on the left appears to be slightly different for different entry points. For example, Mod Incoming Limb Damage allows you to specify Attacker Weapon conditions but this section is absent for Mod Incoming Stagger.

Adding Knockdown

Ok, so I've increased melee damage and stagger but is that enough? If I hit a zombie with a power attack shouldn't the clumsy shamblers fall down once in awhile from the force? I thought so too.

I tried looking for entry points in perks to apply knockdown, but was unable to find one that allowed me to specify Attacker Weapon. I didn't want to suddenly add knockdown chances to guns, so I opted to script it instead using the script attached to the hidden quest alias (same one that adds the ZombiePerk).

The magical function for knockdown in the Creation Kit is called PushActorAway. If you are playing on PC, then this is also available via the console and can result in lots of fun and frivolity. Try "pushactoraway  -id- 100" for example. I think this function is how the world series baseball bat works.

In my case, I used values much lower at apply the knockdown. A normal attack produces a knockdown with force equal to 1 which basically means the zombie falls where they are standing. If the attack is a power or sneak attack, then I increase the force by adding 1 to add a bit of kick.

The knockdown applies the ragdoll effect similar to an explosion going off. Once the zombie hits the ground, it resets slightly and then starts the get up animation. The entire time you can continue to beat them senseless while they are on the ground.

Using onHit event handler attached via quest alias to display player damage.

Much of what I want to do with the Zombie Walkers mod involves scripting. Some of the scripting needs to happen when things are hit or killed which involves attaching scripts to Actors. Unfortunately, this isn't feasible or possible to directly attach scripts for the following reasons:

• attaching scripts to ALL humans would involve modifying a whole bunch of Actors in the CK (very very time consuming)
• attaching scripts to leveled list actors (like the Feral Ghouls) is NOT possible. The section is literally grayed out in the tool and a known limitation of the Creation Kit
• each Actor updated in the CK adds to the risk that a mod will conflict with others (and increases the mod size)

Fortunately, there are ways to dynamically attach scripts to Actors. :)

Magic Effects

The first involves applying a magic effect to an Actor. A magic effect is essentially a script that runs to do something to an actor and you can create your own custom types.

For example, early on in the mod I figured out that you can attach a spell to the unarmed feral ghoul attack. Spells can apply a custom magic effect to register for events like hit or death and respond. In my case, I used this approach to monitor an NPC for hit events and then when they died resurrect them as a zombie.

Unfortunately, you need to apply the magic effect in some fashion for this to work. There's no easy way to just apply a magic effect to all actor types. For my NPC resurrection, the effect is applied when an NPC is hit by a zombie (which makes sense for my mod), but what if we wanted to resurrect NPCs Walking Dead style where a previous scratch/bite is not required?

Hidden Quest Aliases

Another, more flexible approach to dynamically attaching scripts to actors is via a hidden quest. Quests can be created that are never visible to the player and have pretty advanced functionality associated with them.

One such piece of functionality has to do with quest aliases. Aliases are basically references to objects in the game world that dynamically "bind" to a quest through a set of rules. When the quest begins, the first thing it does is bind all it's quest aliases. If any quest aliases are marked as required and cannot be bound for some reason, then the quest will fail to start.

ReferenceAlias for Zombie closest to the Payer that binds ZombieScript to the Zombie

Quest aliases are defined in the Creation Kit using the UI above and have different options like specifying a Unique Actor (like the Player) or Find Matching Reference which searches the area for a match closest to some reference point. Once an alias is bound/filled, any scripts you have defined in the Papyrus Scripts section are bound to that reference and can be used to register for events on the Actor.

You can define multiple aliases "Closest To" Player and each will bind to a different Zombie as long as the "Allow Reuse in Quest" checkbox is NOT checked. Each alias is unique, so once the closest Zombie is bound, the next alias searching for closest will select the next closest, and so on.

Current uses in Zombie Walkers

NPC Resurrection is using the Magic Effect to resurrect NPCs when they die by monitoring the onHit event.

Sleep Interruption is using the Quest Alias on the Player to register for sleep events to randomly trigger a settlement attack or spawn zombies nearby and wake up the player early.

The Zombie Walkers Holotape is automatically added via the hidden quest initialization script. It uses a timer to check if the player has received the pipboy (from the vault 111 quest) before assigning since the Player inventory may reset before then.

Possible Future uses in Zombie Walkers

• update NPC Resurrection by adding a Walking Dead style mode that resurrects NPCs regardless of how they died by registering for onDeath.
• enhance melee using on onHit event handler to possible do more damage and stagger/knockdown?
• add optional headshots only mode where zombies respawn if they die and their head was not crippled/dismembered.
• add configuration options for various things like zombie damage resistance

I'm sure plenty more options will reveal themselves in the future, but I wanted to give a flavor of the types of things that these approaches enable for the Zombie Walkers mod.

References

For the quest alias magic, I found some excellent resources that basically steered me in this direction so I wanted to list a couple of them here.

• http://www.creationkit.com/index.php?title=Dynamically_Attaching_Scripts
• http://forums.bethsoft.com/topic/1349649-dynamically-attaching-scripts-to-actors-near-the-player

Note: some functions references in the articles above like RegisterForUpdate and RegisterForSingleUpdate are not present anymore in the CK and have been replaced in with Timers.