Project Zomboid
Тема закрыта
Zombies disappearing
Noticed in MP zombies tend to disappear in droves, hundreds at a time (sometimes even just zombies on ground). MP obv and no mods, no bad ping or anything. Seems to happen when we turn our backs on zombies, but happens more often when two of us are near eachother.

EDIT:
here is a workshop link for the fix as well:
https://steamcommunity.com/sharedfiles/filedetails/?id=2896255721

Thank you to Nippytime for creating it.

NOTE: Please read the workshop description carefully and do what Nippytime says. It seems the workshop code is not automagically replacing the vanilla code so you need to sub to the mod and manually replace. Just a heads up
Отредактировано Sooner535{UFIP}; 9 дек. 2022 г. в 19:01
Автор сообщения: Modinstaller:
Alright, so here's the file:

https://me
ga.nz/file/B2gCVKxL#NgmssYXY89XijKrVqKWEcYElQBMyqUsu9wbOfy6dPWo

This is modified so the upper limit is 32 767. Couldn't make it higher because the value is 2 bytes signed. Not sure if it'll keep preventing culling in x16 louisville for instance, but it worked perfectly in my tests: no culling. Runnable with steam, not sure how updates will interact. It's just a difference of 2 bytes.

The clients need to have it. Everything is handled client-side. Meaning it's possible to cheat this way too. I made the limit 0 and logged into a random server: the zombies all kept disappearing until none were left. You could probably also even remove the distance limit (which is "20" by default) to make it even more op. I won't share the file for this but I'm just putting the info out there for the devs and server admins.

Thanks Sooner535 you helped me a ton with this. By the way, you were changing the declared variable's value, but when I decompiled the .class I noticed that the "500" used in the algorithm was its own "on the fly" value instead of referencing the variable. So instead of touching the variable, I touched that value, and that's what did the trick.

Edit: err link removed... so I put some spaces in there...
< >
Сообщения 106120 из 249
You guys might find this interesting. Check the file C:\Program Files (x86)\Steam\steamapps\common\ProjectZomboid\zombie\popman\NetworkZombiePacker.class with a decompiler. It will mention a particular line where it breaks at "if (++n >= 300" which implies that it will delete any zombies after 300, instead of the 500, unless I am reading the code wrong.
Отредактировано Asdfer; 5 июн. 2022 г. в 8:47
Автор сообщения: Asdfer
You guys might find this interesting. Check the file C:\Program Files (x86)\Steam\steamapps\common\ProjectZomboid\zombie\popman\NetworkZombiePacker.class with a decompiler. It will mention a particular line where it breaks at "if (++n >= 300" which implies that it will delete any zombies after 300, instead of the 500 implied by Enimga, unless I am reading the code wrong.
interesting, what line is this code on? I decompiled it and see no such line in that file.
Ok I found the counter I believe. Its in the Zombie Count Optimizer, and it reads:
public static final int maxZombieCount = 500;

If I had to guess, this is the offending line of code. But I have little knowledge of Java (I used to do a lot when I was a teenager but have mostly worked with C++, C#, Python, Ruby, and Linux). I am not sure if there is any calls to this particular number, but I will try and get me and a friend to test before and afers of changing this value, if it is successful, then I will post it on the Steam workshop (I want to make sure that there is no tie ins for code, and importantly that using a higher value does something AND is relatively stable.)

I believe this is the code for how it counts zombies, so hopefully changing the count to higher will fix it (fingers crossed) once I am able to test it I will let everyone know :) good work Asdfer, you narrowed it down a ton :D thank you very much!
That does seem a bit more conclusive than what I found lol, thanks for looking at it
Ok so first off we (my friend and I) found out why I do not have that exact code, its just different decompilers, so there is that at least lol.

Next, I have for sure found the code for the zombie culling, but I am not exactly sure what is causing the issue with it culling down to 0. Since this tool I use to decompile is most likely different than the ones PZ devs use, I have no way to see what in the world is happening. My only guess is somewhere in the counting code it is being told to cull to 0 instead of 500, which is most likely in that previous file I mentioned.

Enigma, would you have any idea what compiler and decompiler is used for PZ? And if it is open source? I would like to poke around further >.<

As the system is handled in .class files it is not a simple matter of just decompile and compile since JVMs create .class files, if anyone knows a lot more about java I would greatly appreciate the input as all of my knowledge is both old and rusty, and I am simply learning as I go here. If anyone can reccommend an easy way to create .class files I can simply copy the code and hope it sinks up well (though there are a lot of weird issues with the code, like int and strings not being actually used, though I think it is also a specific compiler issue). I am going to try at some point tricking a JVM argument to create the .class file and hoping it calls and works, but this won't be today as I just finished a 8 hour shift and would like to relax.

Enigma would you please ask the devs to at least look at the culling code? I have, as I said, not a ton of experience with Java but it looks like the code culls it to 0, but then again I may be missing something in the decompile OR reading it wrong.

Hopefully stay tuned fellas and we can get this resolved and finally play PZ again :)
Good find, now we just need to overwrite this variable or the function(s) that use it (is that possible in a mod?).

There's probably a bug somewhere in the code so that it culls zombies down to 0. Maybe the zombie count never goes down and only goes up and when too many zombies are around it hits 500 and starts culling literally everything even if the 500 zombies that were counted are killed/culled.

Maybe it's poorly implemented and the area where zombies are counted is so big that it easily hits 500 and then anything but those 500 (which might be very far from you) is culled so that it looks like all the zombies are culled, when in fact some 500 are lost in a corner somewhere far off.

That area might be fixed or might move with you, but I'm assuming it's fixed, since I've had zombies getting culled like crazy somewhere specific, and then not getting culled at all 200 meters farther south, also somewhere specific. That was probably because I crossed a cell boundary and the count was reset.

Maybe this count parses zombies from north to south and west to east, for example, meaning there would be 500 zombies clumped northwest and then a ghost town for the rest of the cell.

However, from my testing (not extensive, so I encourage you to try it), the "peekaboo" effect really only works with vehicles. Somehow the algorithm that checks whether a zombie is "in sight" and thus "not cullable" must consider a zombie still in sight when it's in your back and you're on foot, but not when it's in your back and you're in a vehicle. I don't know what the conditions are when you're on foot, maybe it only depends on range, maybe solid objects have to come into play to block line of sight. This might or might not be intentional.

I'm personally more interested in removing this mechanic altogether rather than fixing the bugs it introduces. Even if it were implemented better: the zombiest farthest to you are culled first so that you barely ever notice anything disappearing, it would still hurt difficulty and in-game coherence too much.

Having absurdly low amounts of zombies regardless of your settings (500 per cell instead of the regular 10k) removes that sense of constant danger, fear and vulnerability that we love about Zomboid. Spreading these 500 over the cell makes them trivial. Clumping them in a corner, or even around the player and removing every other one in the cell still makes it trivial once you understand what's going on and know you can just lose them and run around in a ghost town.

Keeping the mechanic but ramping up the numbers still makes it effectively counter the custom settings chosen by the host. It's effectively saying "anything more than 'X' zombie pop is useless, it all gets balanced back down". At this point, it's more interesting to simply implement an upper cap for that zombie pop setting in the first place - it's more transparent and makes more sense. No more zombies popping out of existence magically, whether seen or unseen - more consistency.

The only solution for me given the current performance problems is keep the mechanic as it is for everyone oblivious to it (apparently lots of people) and implement an option somewhere to disable it so that any host interested in doing so can play around with zombie pop settings themselves and figure out what works or doesn't work for their expected server/client hardware and amount of players.

My guess is that the threshold at which performance becomes a problem varies wildly depending on these factors: a low-spec mega-server with 50 low-spec players on will have different results than a high-spec server with 2 high-spec buddies on at most. I think it's a reasonable guess. Unless I'm gravely mistaken, I think it makes sense for the devs to make their system more flexible to account for these differences.
Отредактировано Modinstaller; 8 июн. 2022 г. в 19:23
Something might be wrong with your PC then..... I have an Intel i9-9700k and RTX 2070S and when I was at the prison I saw 0 drop in FPS, neither did my friend who has a worse rig then mine (matter of fact, the only one who lost any frames was my friend who was playing on a laptop, though at that point I would hope you would lol)

unless performance somehow got worse after I posted this (which I suppose is always possible lol) I have had no impact from the improved animations, with maxed out everything..... I am even the one hosting or playing SP most the time (though again haven't played in months as this single bug has all but removed my want to play).

Now of course I have no way to test a pop settings anywhere near the old days, thanks to this system or bug or whatever we are calling it, but I imagine that getting to those numbers might eventually drop the FPS worse then in old builds, but again even on my old PC (which was awful) playing with 4.0 pop only dropped my FPS when we literally created the biggest horde possible and threw a grenade at it (from a mod, goodbye FPS).

The thing that I think irks me the most, is this one update has made me go from considering PZ as the single best indie and zombie game period, to me not even recommending it anymore to people.... I really hope one day this gets resolved.
Отредактировано Sooner535{UFIP}; 9 июн. 2022 г. в 8:12
Автор сообщения: Modinstaller
Good find, now we just need to overwrite this variable or the function(s) that use it (is that possible in a mod?).

There's probably a bug somewhere in the code so that it culls zombies down to 0. Maybe the zombie count never goes down and only goes up and when too many zombies are around it hits 500 and starts culling literally everything even if the 500 zombies that were counted are killed/culled.

Maybe it's poorly implemented and the area where zombies are counted is so big that it easily hits 500 and then anything but those 500 (which might be very far from you) is culled so that it looks like all the zombies are culled, when in fact some 500 are lost in a corner somewhere far off.

That area might be fixed or might move with you, but I'm assuming it's fixed, since I've had zombies getting culled like crazy somewhere specific, and then not getting culled at all 200 meters farther south, also somewhere specific. That was probably because I crossed a cell boundary and the count was reset.

Maybe this count parses zombies from north to south and west to east, for example, meaning there would be 500 zombies clumped northwest and then a ghost town for the rest of the cell.

However, from my testing (not extensive, so I encourage you to try it), the "peekaboo" effect really only works with vehicles. Somehow the algorithm that checks whether a zombie is "in sight" and thus "not cullable" must consider a zombie still in sight when it's in your back and you're on foot, but not when it's in your back and you're in a vehicle. I don't know what the conditions are when you're on foot, maybe it only depends on range, maybe solid objects have to come into play to block line of sight. This might or might not be intentional.

I'm personally more interested in removing this mechanic altogether rather than fixing the bugs it introduces. Even if it were implemented better: the zombiest farthest to you are culled first so that you barely ever notice anything disappearing, it would still hurt difficulty and in-game coherence too much.

Having absurdly low amounts of zombies regardless of your settings (500 per cell instead of the regular 10k) removes that sense of constant danger, fear and vulnerability that we love about Zomboid. Spreading these 500 over the cell makes them trivial. Clumping them in a corner, or even around the player and removing every other one in the cell still makes it trivial once you understand what's going on and know you can just lose them and run around in a ghost town.

Keeping the mechanic but ramping up the numbers still makes it effectively counter the custom settings chosen by the host. It's effectively saying "anything more than 'X' zombie pop is useless, it all gets balanced back down". At this point, it's more interesting to simply implement an upper cap for that zombie pop setting in the first place - it's more transparent and makes more sense. No more zombies popping out of existence magically, whether seen or unseen - more consistency.

The only solution for me given the current performance problems is keep the mechanic as it is for everyone oblivious to it (apparently lots of people) and implement an option somewhere to disable it so that any host interested in doing so can play around with zombie pop settings themselves and figure out what works or doesn't work for their expected server/client hardware and amount of players.

My guess is that the threshold at which performance becomes a problem varies wildly depending on these factors: a low-spec mega-server with 50 low-spec players on will have different results than a high-spec server with 2 high-spec buddies on at most. I think it's a reasonable guess. Unless I'm gravely mistaken, I think it makes sense for the devs to make their system more flexible to account for these differences.

I am.... unsure if a mod will be able to. The problem is how Java handles its code and files, a .class file is not really in my knowledge window of how to create.

Fingers crossed either I can figure it out, or someone with the knowledge can come by and give us the info. Either way it is literally as simple as changing 1 line of code to increase the limit, or adding a toggle into it. It could be fixed in an evening -.- but now I have to spend my hours figuring out how to fix it :/.

If/when I do I will post the file here, it will be as simple as copy and paste over the previous file and poof its done. Only thing that will be bad is you may have to reapply after steam updates. But yet again this is all depending on if the code takes too when I finally figure it out, as if my theory about the decompiler is right, it may not work at all >.<.
People really dont understand that syncing many many entities (zombies in this case) between many players with many pings and not having FPS / desync is very hard. Its why no other Zombie survival game in multiplayer has this many zombies active at once. Look at 7 days to die when a blood moon starts . FPS tanks massively in order to get maybe 20-30 zombies on screen at once.

I do fear that NPCs in multiplayer is going to be a MASSIVE hurdle though if there's this much trouble with just the zombies.
Well I figured just about the most janky solution I can think of:

Simply delete the file: ZombieCountOptimiser

I ran SP and nothing happened as opposed to last time.

I did finally get some FPS drop once I had about 700+ zombies on screen, though the thing that bugs out more quickly is the sound, the game is not a huge fan of it at all.

If anyone would like to play PZ with high settings I would recommend deleting that file until the devs figure out something to either fix this issue, or remove it entirely.... Which will hopefully happen at some point.

I will try and get my friend to test on MP later on to see if it will work on a server as well (both as a host and as a client)

about 3.0 zombie settings seems to be a good sweet spot, enjoy! Fingers crossed nothing breaks :) (I started to notice sound cut outs at about 600+ zombies, a bit before I saw my first frame drop, so keep that in mind. I figure turning off ingame music might help as I assume it's a resource issue with java and the coding for PZ). I am going to attempt to test a few more things performance wise and see how everything lines up, and see if I can get the music and sound stable, I will respond here if I do :)
Ok I fixed it.

Go to:
ProjectZomboid64.json and change Xmx to 5120. 5GB of RAM and the music no longer cuts out, and it was able to handle a few more zombies before losing FPS.

I will note, I am testing peak day 1 4.0 max at 4.0 pop, so the highest possible zombie count you can possibly go, in muldraugh on maintown, and it is working. On to the MP test!

EDIT: Ok hosting crashes the game. Because the culling mechanic is supposed to only be called in MP I assume, unsure why SP culls sometimes who knows. So back to creating a custom .class file!
Отредактировано Sooner535{UFIP}; 9 июн. 2022 г. в 10:37
Alrighty looks like I may have fixed it. Testing on MP now, if testing goes well I will post the file and everyone can use it :) (just not 100% sure its actually working)
Автор сообщения: EnigmaGrey
Автор сообщения: Modinstaller
My guess is that the threshold at which performance becomes a problem varies wildly depending on these factors: a low-spec mega-server with 50 low-spec players on will have different results than a high-spec server with 2 high-spec buddies on at most. I think it's a reasonable guess. Unless I'm gravely mistaken, I think it makes sense for the devs to make their system more flexible to account for these differences.
I'm going off of memory here and won't be able to check until sometime next week, but:

Even my 3080 / 11700KF system drops to around 30 FPS with 500 zombies spawned (from an average 115 FPS). Most people aren't going to have a $3000 system, so having 500 as the upper bound already pushes it, frankly. (The SP game replaces zombies after 1k with black silhouettes, iirc, but by then you're already in slide-show territory.) Hence why I'd really recommend just playing with 0.8 pop or something vs. pushing it higher.

You can just try it yourself. It's the same thing in SP, just without culling, as zombies are now client-side. Go into debug, right click and find the Spawn Horde option. (In the old days, before animations, zombies were server-side and had comparatively simple animations via sprites, meaning you could have thousands of them without impacting the client, but it'd do a number on the server, necessitating spending hundreds of dollars a month to support a large number of players. The situation is now reversed, where it's the client that takes the load and the server can be run cheaply).

The main flaw with it is just that it counts interior zombies in the max of 500 and it's possible that moving fast means the 500 that are preserved are well past you before it runs. That said, yes, I fully agree that a vehicle's field of view seems very sketchy with it. And sure, I'd like a smarter algorithm.

It's basically 8 lines of code. There's not much to it as is.

I find the game very playable on my setup (6900 + 12700kf). It does stutter when I spawn 500 zombies right in front of me, but then it also stutters when there are 0 zombies and I just zoom out a bit, lol. The game's performance is all over the place, that's no secret, whatever.

I've very rarely had 500 zombies in view. A realistic amount of zombies for me is something like this: https://i.imgur.com/CR867t4.jpeg maybe 300-400 zombies surrounding me, and that was with a chopper, not a 24/7 situation.

The problem with culling, btw, is not that it prevents this kind of situation. It doesn't just prevent having more than 500 zombies right in front of you. It prevents having more than 50. Hell, 30 or even 20 at times. It prevents entire streets from having any zombies in them. It goes from the screenshot I took, to a completely empty town in the span of 2 days of running around the city, going into the woods, and then coming back.

I'm gonna keep calling this gamebreaking. It's not a "can't have absolutely insane pop levels but can still have up to 500 zombies in front of you" situation, it's a "can't have more than 50 odd zombies at a time wandering around the streets" situation.
Автор сообщения: Sooner535{UFIP}
Well I figured just about the most janky solution I can think of:

Simply delete the file: ZombieCountOptimiser

I ran SP and nothing happened as opposed to last time.

I did finally get some FPS drop once I had about 700+ zombies on screen, though the thing that bugs out more quickly is the sound, the game is not a huge fan of it at all.

If anyone would like to play PZ with high settings I would recommend deleting that file until the devs figure out something to either fix this issue, or remove it entirely.... Which will hopefully happen at some point.

I will try and get my friend to test on MP later on to see if it will work on a server as well (both as a host and as a client)

about 3.0 zombie settings seems to be a good sweet spot, enjoy! Fingers crossed nothing breaks :) (I started to notice sound cut outs at about 600+ zombies, a bit before I saw my first frame drop, so keep that in mind. I figure turning off ingame music might help as I assume it's a resource issue with java and the coding for PZ). I am going to attempt to test a few more things performance wise and see how everything lines up, and see if I can get the music and sound stable, I will respond here if I do :)

I don't understand. Culling is MP-only, you can play SP however you like, have 1 billion zombies around you if it strikes your fancy. I've never seen any sort of culling anywhere in SP. Except for my own, lol.

Sound bugging out is something that the recent patch introduced, with the revamped music. The music keeps cutting out, even when the amount of zombies is "reasonable" like maybe 100-200 around you.

I will admit I did not test increasing ram, maybe this could work. I don't really play much anymore though.

You can add me as friend and give me the file and I'll test it for you :)
Автор сообщения: Modinstaller
Автор сообщения: Sooner535{UFIP}
Well I figured just about the most janky solution I can think of:

Simply delete the file: ZombieCountOptimiser

I ran SP and nothing happened as opposed to last time.

I did finally get some FPS drop once I had about 700+ zombies on screen, though the thing that bugs out more quickly is the sound, the game is not a huge fan of it at all.

If anyone would like to play PZ with high settings I would recommend deleting that file until the devs figure out something to either fix this issue, or remove it entirely.... Which will hopefully happen at some point.

I will try and get my friend to test on MP later on to see if it will work on a server as well (both as a host and as a client)

about 3.0 zombie settings seems to be a good sweet spot, enjoy! Fingers crossed nothing breaks :) (I started to notice sound cut outs at about 600+ zombies, a bit before I saw my first frame drop, so keep that in mind. I figure turning off ingame music might help as I assume it's a resource issue with java and the coding for PZ). I am going to attempt to test a few more things performance wise and see how everything lines up, and see if I can get the music and sound stable, I will respond here if I do :)

I don't understand. Culling is MP-only, you can play SP however you like, have 1 billion zombies around you if it strikes your fancy. I've never seen any sort of culling anywhere in SP. Except for my own, lol.

Sound bugging out is something that the recent patch introduced, with the revamped music. The music keeps cutting out, even when the amount of zombies is "reasonable" like maybe 100-200 around you.

I will admit I did not test increasing ram, maybe this could work. I don't really play much anymore though.

You can add me as friend and give me the file and I'll test it for you :)
Ya this is something different. I think and hope it is just java being java. So far we have tested and not a single zombie has been culled (though we set it to 1500 zombies so eventually it can be culled).

A lot better, and no noticeable performance issues.
< >
Сообщения 106120 из 249
Показывать на странице: 1530 50

Дата создания: 21 дек. 2021 г. в 23:19
Сообщений: 249