This mod fixes two separate instances of zombie disappearances in MP:

- A limit put in place by the devs to prevent performance issues, dubbed "zombie culling"
- A bug caused by an oversight in the serverside memorization of zombie position, dubbed "stale zombies"

Note that this does absolutely nothing in singleplayer. If you only play singleplayer, you don't need this. If you play both MP and SP, having the mod will not change anything to your singleplayer experience.


Project Zomboid is a game plagued with performance issues. Framerate is often very low in singleplayer. Multiplayer does not escape from this problem and it is made even worse: servers have to worry about multiplicative performance issues as players pile up in numbers, and the effects are not only felt as FPS drops but also network lag.

For this reason, Zomboid devs have opted to implement a purposeful limit of 500 zombies around any player. This is a hardcoded limit and there is no way to change it from inside - or outside - the game without hacking the code. If more than 500 zombies are present around a player, they will slowly be permanently removed until only 500 are left.

The main issue we players have with this hidden limitation is that for many, Project Zomboid's entire point is to face overwhelming adversity, fight against hopeless odds and be slowly driven to the edge. For many, this means the world needs to be filled with the constant threat of masses of zombies.

While 500 zombies may seem like a lot when starting out, as a player becomes familiar with the game's mechanics and quirks, it becomes easy to deal with. Not only that, but zombie culling is coded in such a manner that several other issues arise, the first of which is that a player running around a crowded town will cull 99% of its population.

It would appear zombie culling deletes older zombies first. This means while running in a crowded area, the new zombies that appear at the edge of the screen will be the last to be deleted. Running straight through a crowded city will constantly cull every zombie in sight until the very last 500 at the end of your run.

Because the edge of the "render area" where new zombies appear is much farther than the edge of the area visible to the player, with a higher population setting and once zombie culling has taken effect, the player is often left with no zombies in sight - the remaining 500 ones being mostly out of sight at the edge of the render area.

Players are left with no option but to lower population settings in multiplayer until zombie culling does not take effect anymore. Unfortunately, even on the default, x1 population settings, culling will still take effect in some denser areas of the world, such as the mall, or when events trigger exoduses of zombies, such as car or house alarms.

When asking developers to provide us a way to explore the performance impact of higher population settings, we the players were met with distrust and refusal. The only hope was for the change to maybe be bundled in an upcoming update. Because the release schedule of this game is so slow (once every 2 years!), we took it upon ourselves to fix the issue any way we could.

Upon fixing it, we discovered that the performance impact of higher population settings were, in fact, similar to singleplayer in terms of FPS, and perfectly viable in terms of network lag. It would appear the 500 zombie limit is not needed to enjoy a lag-free multiplayer experience, even with dozens of players on a high population server.


The java fix exists both as a clientside version, and as a serverside version. Because the clients do the zombie counting themselves and request deletion from the server, there are two different places where culling can be stopped.

The clients can be stopped in their counting so that they never request anything from the server. And the server can be stopped in its deleting the zombies, although the clients will still count zombies up eternally (and calculate whether they are out of sight of players), and this will come at an as of yet unmeasured performance cost for clients.

Both fixes are available here as a solution both for server owners who want to fix the issue for everyone, and players who want to fix the issue for themselves should a server be unpatched, and also make sure they don't suffer from the extra useless load of constantly counting zombies up.

Do note that if playing on an unpatched server as a patched client, all other non-patched clients will still send culling requests to the server and if such an unpatched client (player) were to come close to the player, some zombies would get culled anyway, albeit at a slower rate.


On an unpatched server, kiting zombies over a sufficiently long distance (for about one and a half minutes, usually) causes the zombies to stop in their tracks and disappear. This is unrelated to zombie culling and was in fact only widely recognized as a separate issue once culling was out of the way.

The disappearances are accompanied by clientside logs stating "Removing stale zombie 5000", indicating that it's been 5 seconds since the zombie was acknowledged by the server, therefore the client removed it as a last-resort type measure. But why does the server stop acknowledging the zombie?

It turns out that it's not directly kiting the zombies that causes them to disappear, it is rather moving away from their point of origin. In fact, the zombies disappear exactly when the "chunk" (area of 10x10 squares) containing their point of origin unloads.

Additionally, because zombies move around by themselves (notably from noise events), kiting zombies is not the only way to receive "Removing stale zombie 5000" messages. In fact, even on a default server, logs are often spammed by these messages, indicating that a lot of zombies are being removed improperly by the server.

Fortunately, the removals are not permanent as the zombies are technically unloaded as if they were very far from the player. Also, if a second player stands near the origin chunk of a zombie, that zombie will not "go stale" (disappear because of this issue) since the chunk will not be unloaded when it is kited away.

This bug only affects multiplayer because it is only present in serverside code. The reason clients "time out" the zombies (the 5000 message) is because the clients do not remove them when the origin chunk unloads, only the server does.

The reason the server deletes a zombie when its origin chunk unloads is because the server never properly updates the zombie's position on the world squares. As such, only the originating square ever keeps the zombie in its "list of things that are standing on me right now". No other squares that the zombie passes through update their lists.

When the servers unloads a chunk (because no player is close enough, to save on memory), it will therefore remove all the zombies originating from this chunk, believing that they are still there.


The fix involves adding instructions to serverside code to properly update squares with zombies passing over them. Thanksfully, as the groundswork has already been laid out, this is done by just adding the right function call in the right place (only one line added).

Because the source of the issue is serverside code, this can only be fixed for servers, unlike zombie culling which can be fixed for both.

As a final note, the fix allows servers to properly update position for zombies that are simulated by players. The zombies that are simulated by the server will still not properly update the squares they walk over. This, however, is a rare occurence and should not negatively affect the players' experience.


The game is coded both in java and lua. Most mods use lua, as the devs intended, and therefore work right out of the box as they integrate seamlessly with the game.

But lua is very limited and doesn't allow us to modify just anything in the game. It doesn't allow us to modify the code responsible for zombie culling, or fix the bug that causes stale zombies.

For that we need to quite literally hack the game. We're transforming its code back into a readable form (.java) with the help of decompilers, analyzing it to figure out what to change, editing the code, and then recompiling it with a simple java compiler back into its machine language form (.class).

Shoutout to beautiful-java[github.com] for its decompiling automation, and to Fed_Cap for his expertise in recompiling zomboid code!

The very first version of this mod was made without decompiling/recompiling but rather directly editing the .class file by looking at its "bytecode" and detecting where in the bytecode were the hexadecimal values we wanted to change - for example, the 500 zombie limit which we changed to a maximal 32767 limit. The file you'll find over at Zombie Fix was made this way.

Shoutout to Sooner535 for showing us the exact location of the zombie culling code back then, and Nippytime who had the original idea to make this into a workshop mod!


The older, outdated mod by Nippytime has interesting claims in its description. We don't have anymore contact with Nippytime so we can't say why he has made such claims, but we will address each point nonetheless:

- "Claims to have created a server sided version they claim work"

We don't only "claim" it works, it works. We know it does because we've tested it extensively ourselves, because we've hunted the logic in the code, and because everyone says it works, including youtubers known in the community.

- "Also server-sided is not thoroughly tested"

It's, again, been thoroughly tested by us, youtubers, and the community at large by now as it's been more than a month since the serverside fix has been released with at least a thousand of players having tested it, including on a server with more than 100 concurrent players. It is absolutely working and stable.

- "No one involved is an expert in modding nor making these changes so when using any "server-sided" option, any issues fall completely on you to resolve outside of their comments"

We are definitely not experts in modding or programming! However we've spent literally dozens of hours by now scouring the code, testing in-game and hunting the stales bug. We would definitely say we are experts when it comes to the issues fixed by this mod. If we're not, at this point, we don't know who'd be. Additionally, we see no reason that anyone would be facing any issues, and we will of course help our users to the best of our ability.

- "Neither version will fix stale zombies completely, but will handle the majority of them."

Nippytime is confused about the meaning of "stale zombies". To be precise, the old version does not fix stales at all. It does fix zombie culling, clientside (like our new version, of course). Our version fixes stales completely. We can 100% guarantee that you will not have any problems with stale disappearances in-game.