PC V2.3 Experimental

To dumb it down, and this is not because I think you are dumb, it is just as matter of speach.
The main reasons I can think of, of the top of my head, when you mention "the more people, the more the lag", is because you are either using standard settings, or you increased some settings. Specifically the zombie amounts. The more zombies you allow at any given time, the heavier the toll on the server. 8 zombies normally, and 12 on horde night, with 10 players online, will tank any server. even the ones you can rent with a capacity of 100 players. Players doesnt really affect server load that much (directly), but the amount of zombies? That will affect it. meaning, if you have 10 players online, you can potentially have 80/120 zombies non stop. And when a server has to keep track of that many? well, how good are you at multitasking 80/120 jobs? ;-)

Then there is the amount of "unnatural blocks". And by that, i mean the blocks placed by players. when you have 200k+ blocks that players made and placed, they also need to be rendered from time to time. and the more blocks people put down, the heavier the toll.

Finally, there is the map. The more that gets explored AND changed, the more lag you will experience, when the chunks are loaded. Not much in the start, but you will notice it eventually.


You can check for yourself. Alert your playerbase, that you want to test something during primetime. Current game versus a full wipe. You will notice how smooth everything is, when there has been a wipe, and after 200 ingame days, everything gets more sluggish.



If you have a local machine as host, you can always check server FPS when ther is a high load (many players/zombies). it should always be 25+, so when it drops below that, the server is experiencing problems.


So while the game has been optimized several times, there is only so much you can do. Turn down amount of roaming zombies and horde zombies. You cant do much about mission zombies, though.


I hope this helps clarifying a few things for you :-)
Absolutely nothing you said justifies the poor performance, while there are claims that it's highly optimized there is quite a lot of evidence that there is plenty more to be done, also a server also does not render the terrain or user placed blocks so it can't be a rendering issue on servers. There appears to be performance issues with the physics system, the entity updates aren't multithreaded, some of the functions cause GC pressure where it shouldn't, just to name a few areas that aren't "highly optimized". As far as I can tell its just not their priority to address any of those things and to be fair it's not that simple to just update all entities in parallel when the code was never designed for this, to achieve this it also means you can't have multiple threads update the same data at once and if you add locking then you will basically not gain much, this however does not mean its impossible to do, if there is a will there is a way.
 
Absolutely nothing you said justifies the poor performance, while there are claims that it's highly optimized there is quite a lot of evidence that there is plenty more to be done, also a server also does not render the terrain or user placed blocks so it can't be a rendering issue on servers. There appears to be performance issues with the physics system, the entity updates aren't multithreaded, some of the functions cause GC pressure where it shouldn't, just to name a few areas that aren't "highly optimized". As far as I can tell its just not their priority to address any of those things and to be fair it's not that simple to just update all entities in parallel when the code was never designed for this, to achieve this it also means you can't have multiple threads update the same data at once and if you add locking then you will basically not gain much, this however does not mean its impossible to do, if there is a will there is a way.
I'm not a programmer or a geek, but what I understood from what @faatal said is that they will do more optimizations.
But he also said that the process gives diminishing returns. So the more you optimize an area of the game, the less gain you get.

Because of that I can understand why they always try to optimize when they see the opportunity, but on the other side they don't plan, currently, to do a full optimization pass on the entire game (e.g.: an update exclusively dedicated to that). It would probably be just a huge waste of time.
 
To dumb it down, and this is not because I think you are dumb, it is just as matter of speach.
The main reasons I can think of, of the top of my head, when you mention "the more people, the more the lag", is because you are either using standard settings, or you increased some settings. Specifically the zombie amounts. The more zombies you allow at any given time, the heavier the toll on the server. 8 zombies normally, and 12 on horde night, with 10 players online, will tank any server. even the ones you can rent with a capacity of 100 players. Players doesnt really affect server load that much (directly), but the amount of zombies? That will affect it. meaning, if you have 10 players online, you can potentially have 80/120 zombies non stop. And when a server has to keep track of that many? well, how good are you at multitasking 80/120 jobs? ;-)

Then there is the amount of "unnatural blocks". And by that, i mean the blocks placed by players. when you have 200k+ blocks that players made and placed, they also need to be rendered from time to time. and the more blocks people put down, the heavier the toll.

Finally, there is the map. The more that gets explored AND changed, the more lag you will experience, when the chunks are loaded. Not much in the start, but you will notice it eventually.


You can check for yourself. Alert your playerbase, that you want to test something during primetime. Current game versus a full wipe. You will notice how smooth everything is, when there has been a wipe, and after 200 ingame days, everything gets more sluggish.



If you have a local machine as host, you can always check server FPS when ther is a high load (many players/zombies). it should always be 25+, so when it drops below that, the server is experiencing problems.


So while the game has been optimized several times, there is only so much you can do. Turn down amount of roaming zombies and horde zombies. You cant do much about mission zombies, though.


I hope this helps clarifying a few things for you :-)
It was tested on a 2K map with no prefabs and 25 zombies, with 5 players killing zombies. I'm talking about client performance.
 
I'm not a programmer or a geek, but what I understood from what @faatal said is that they will do more optimizations.
But he also said that the process gives diminishing returns. So the more you optimize an area of the game, the less gain you get.

Because of that I can understand why they always try to optimize when they see the opportunity, but on the other side they don't plan, currently, to do a full optimization pass on the entire game (e.g.: an update exclusively dedicated to that). It would probably be just a huge waste of time.
Not neccessarily. You could just add the option to turn off certain rendering and processing options. So say turn everything down on horde nights so you can go balls to the wall so to speak and not take a huge performance hit. So you miss some nice animations, but you don't have massive lag.
 
It was tested on a 2K map with no prefabs and 25 zombies, with 5 players killing zombies. I'm talking about client performance.
sounds like several problems at the same time. I will list a few things you can check out.

Graphics. While the game says "recommended hardware" on steam, you have to laugh at those recommendations. double everything that even says "RAM". Both pure memory AND graphics. My machine has a 3060 with 12 GB VRAM installed and 64 GB RAM installed. while impressive, my 64GB RAM is "only" DDR4, meaning they are slower than most today. I also have a 5700G processor. I still use certain settings on a much lower setting than what is recommended by GeForce experience.

the HDD. Both on the server and the client machines. if they are mechanical in nature, there is only one way to put it. Out of its misery. It is preferred to use a SSD or even M.2 disc today.
The best way to descreibe it is, back when the i7 came out, people were always saying "what CPU does the server have", and would be "ok" when they heard i7... Regardless if it was 1st gen or 7th gen. They just assumed it was awesome, because it was an i7.

Does the hardware actually work together? Meaning, are all the hardware able to talk to eachother in a civilized manner? Something in the matter of cramming a square block into a round hole.
Also check if the server has enabled the XPM thingie in BIOS. That enables RAM to run as they should. Not sure if XPM is the correct thing to enable or not, I just "do it" without thinking about it.

lastly, there is the client game settings. While you may run the game on a GTX 9999 with 200 gb VRAM, but in the end, there are certain setting that are just garbage.
SSAO - Disable it.
Grass distance - Set it to near
Rendering distance (this one totally sucks up memory and GPU power) Set it to medium.
Particles. - 80% or medium. w/e that doesnt turn it into crap.
reflections - one step down from recommended.
V-Sync - Kill it.

Anything that you can tweak in regards to "looking nice", should be lowered, untill it becomes ugly. if possible, put it 1 step above ugly, so you can also enjoy the visual effects, the game has to offer.


On a sidenote, if your machine is a few years old, I also strongly recommend that you factory reset it, so you get rid of a serious amount of irrelevant software. I just checked my screen shots folder. in a span of 30 months, I have accumulated 5GB of junk. Not to mention all the crap I have from other games (Aslain mod pack for world of warships and other mods for other games, that I just redownload, once there is a new version out).
Doing the factory reset, also means you need to DL an ISO file onto a flashdrive. When you reset it, there is an option that doesnt require a flashdrive, ignore that one. The one with the flashdrove, is the better option (also takes much longer to finish). Dont forget to have your drivers ready for the motherboard etc etc..


Finally, I am sorry for this long ■■■ post, but my brain went into overdrive:)
 
Just a suggestion that may help...

Try setting the framerate in options to half. I do this and it makes a huge difference for me. Without it, I can hit my monitor max framerate of 60, but it fluctuates a lot, and that fluctuation is very noticeable. At half, it mostly stays steady, so looks much better than higher FPS that fluctuates.

Of course, my computer is about 6 or 7 years old. But with that one change, I can play this game on mostly high settings without any problems, even with horde night and multiple people playing.
 
Can anyone else confirm that legendary parts are dropping exceedingly slowly in 2.3? It's possible my RNG sprites are being arsehats again, but I think maybe their availability has been lowered. I've not dug around in the xml files to see (lazy bum) but it could just be my imagination or I'm not yet high enough gamestage and that's been adjusted a bit?
 
Can anyone else confirm that legendary parts are dropping exceedingly slowly in 2.3? It's possible my RNG sprites are being arsehats again, but I think maybe their availability has been lowered. I've not dug around in the xml files to see (lazy bum) but it could just be my imagination or I'm not yet high enough gamestage and that's been adjusted a bit?
Yeah, I've noticed that too, I don't get as much legendary parts either. But I couldn't tell you if that is just my dumb luck or if that's part of 2.3 or not.
 
Absolutely nothing you said justifies the poor performance, while there are claims that it's highly optimized there is quite a lot of evidence that there is plenty more to be done, also a server also does not render the terrain or user placed blocks so it can't be a rendering issue on servers. There appears to be performance issues with the physics system, the entity updates aren't multithreaded, some of the functions cause GC pressure where it shouldn't, just to name a few areas that aren't "highly optimized". As far as I can tell its just not their priority to address any of those things and to be fair it's not that simple to just update all entities in parallel when the code was never designed for this, to achieve this it also means you can't have multiple threads update the same data at once and if you add locking then you will basically not gain much, this however does not mean its impossible to do, if there is a will there is a way.
Let me ask you a question...
Would it take a lot of work to shut off all limb and head colliders at a distance, and only have the single full body collider active? And what about relying on bone proximity to determine a headshot vs a body shot? So say you're using a sniper rifle on a zombie 60 meters away. Only his full body collider would be active and if you shoot the zombie, the game checks to see which bone the bullet was closest to determine a headshot or a body shot.
 
Let me ask you a question...
Would it take a lot of work to shut off all limb and head colliders at a distance, and only have the single full body collider active? And what about relying on bone proximity to determine a headshot vs a body shot? So say you're using a sniper rifle on a zombie 60 meters away. Only his full body collider would be active and if you shoot the zombie, the game checks to see which bone the bullet was closest to determine a headshot or a body shot.
I'm not sure what you are asking, games typically have hitboxes setup and it should be already efficient enough in most of the cases, their collision collider has nothing to do with hitboxes, even if you shoot off their head it will probably keep the capsule collider as is or might resize it, I haven't looked at how exactly this is done so I can't give you an exact answer.
 
I'm not sure what you are asking, games typically have hitboxes setup and it should be already efficient enough in most of the cases, their collision collider has nothing to do with hitboxes, even if you shoot off their head it will probably keep the capsule collider as is or might resize it, I haven't looked at how exactly this is done so I can't give you an exact answer.
The game is using all the colliders at all times. There's no reduction in the number of active colliders at distance. What I'm asking is if the collision collider could be used as a hit detection collider at distance, while all the other colliders are deactivated. I want to know if a mod can be made to use what's already there to reduce the amount of calculations needed so more zombies can be spawned at once without a big impact on performance.
 
The game is using all the colliders at all times. There's no reduction in the number of active colliders at distance. What I'm asking is if the collision collider could be used as a hit detection collider at distance, while all the other colliders are deactivated. I want to know if a mod can be made to use what's already there to reduce the amount of calculations needed so more zombies can be spawned at once without a big impact on performance.
Plus st least the high tier consoles like the Xbox X.. they can handle a nice number of zombies
 
Yeah, I've noticed that too, I don't get as much legendary parts either. But I couldn't tell you if that is just my dumb luck or if that's part of 2.3 or not.
When you grow up, and become an adult wannabe gamer like the rest of us, you will realize something extremely important. Namely, What you want you aint getting, and what you are getting, you dont want ;-)

Which is mor a core rule of any sandbox/progression game, than anything else.

So when you get the ones you need, you end up stockpililng them. Fast. In 2.1, I ended up making 4 armor sets, 14 tools and 22 weapons, that I crafted as tier 6, while still having 200+ leg parts when we wiped for 2.2 :cool:
 
Back
Top