EnigmaGrey

FPS does seem to affect this to some extent. Try matching FPS between yourself and your friend by going into Options, turning off Vsync, and locking the FPS to something like 60 FPS. Both of you should do his. No guarantees it'll help, but Beard noticed a connection between FPS and how vehicles behave in coop, so there's a chance it could be relevant.

Since the game pulls the username from the Steam name, the only way to handle this is for the player in question to change their Steamname back to the original name or for the server admin to free / clear the safehouse.

Note that we don’t support 32-bit and haven’t in many years, as said in the Steam min. specs. If 64-bit works, I recommend using it. We unfortunately can’t reproduce this on our end.

That'll depend entirely on what GTX has configured at the OS and game script level. For 3 players and no mods, you should only need 2-3 GB. If they did not set the Xmx value to a value that matches the plan you purchased, then it could exceed it, but it's fairly unlikely. ZGC does a good job of keeping memory usage low or at a fixed rate rather than growing significantly. If they host on Windows and disabled the paging file, then it'd use considerably more RAM due to the way the ZGC garbage collector works (it uses the page file to store pointers). If they host on Linux or Mac OSX, the OS will read it as using 3x the amount of RAM it actually uses because the ZGC garbage collector uses 3 separate lists of pointers to the same places in RAM to be pauseless. In short, you'll have to ask their tech support.

Guess it makes sense: 16262 is the direct connection port; 16261 is the Steam port. So by forcing Steam relay only, it’d act like the direct port isn’t there. So the bug is the message showing up when steam relay is selected.

It’s fine. You’ll never be that close or at that specific angle to see anymore roughness then present on most models in the game, anyway.

Those are corpses.

It also has to be the Steam username (or username you logged in with if not coop), not the character’s ingame name.

Unfortunately, people now use a Java mod to disable culling, sacrificing FPS for more zombies on the screen. So my best guess is that when one person has the "fix" and another person doesn't, it'll cause the zombies to be de synced between clients. They didn't seem to get that the deletion list is synced between the server and clients. Otherwise I can't explain why they seemed to be in full walk mode when they popped in. It's a bit hard to tell without names on, but that was another player crossing the screen, wasn't it? "Normally" when zombies spawn in they're in their idle state, albeit briefly, before the pressure of other nearby zombies or sounds causes them to move. These aren't. So I don't really get it ... We've seen zombies, ofc, walking in place when a server runs out of RAM, but this also doesn't seem like that.

B41 is done. There won’t be any fixes until 42 is released.

Would defeat the purpose of removing the corpses for performance reasons if they then spawned 5 - 10 3D items on the ground. Either way, you shouldn't feel compelled to raid every zombie in the ground and collect their items. I mean you can play it that way if you want, but it's a sort of self-created tedium. As is, it takes something like 2 weeks for them to be removed. You can probably create a new save with whatever settings you want then move the map_sand.bin to your existing save to disable it, however.

tl;dr: No, I agree. I think it'd be best for us to add signal handling in the future and one of the devs we've just hired is heavily involved with Linux. He'll be looking into it. It'll not be something that we can do until Build 42, though. Until then the PZ server needs to be treated the way it's designed: as a console application instead of a service. Long version: It's really not that I disagree or that I don't think we should do it. It's that I didn't know this was a "thing" with Java until this conversation. It's just something at least I, personally, have never encountered before (outside of a bit of C++). It's in our interest to support this however, as it explains a few issues we've encountered over the years when supporting users (that is, some likely tried exactly this -- some that offer paid hosting -- without realizing that not all applications are able to handle this without expressly being designed for it). So as the program is now, it has to be shut down with the console commands. From looking at the Wiki, I believe this is also what you discovered, hence the addition of zombie.command? If you can work it out so that you first send save, wait 10-15 seconds, then send quit, you should not risk data loss until we can sort this.

Okay, I think I get what you mean: the pz server isn’t designed to be a background service. It instead depends on console input to function and will not operate gracefully without it. You need to enter the save and then quit commands in the console to ensure it shuts down correctly. This is something we could look at changing in the future now that we’re aware of it, but I really must caution against running the server this way. I feel the wiki may be giving troublesome advice in this case.

I'm not well versed in Linux, so could you explain this a little more? Just from looking at the manual, I'm not sure what the practical difference would be for the game? The JVM will already create its own core dump if its exited abnormally, so having it sent to console output doesn't seen necessary. We also don't use any additional shutdown hooks (which seems to be what'd cause SIGTERM in java) and instead use System.exit().

A post from April that op states fixed itself? That doesn’t seem relevant. I can only reproduce this when I treat the Steamdeck like a $4k desktop or purposefully underpower it. You told me you were playing on insane zombies, right? So turn down the settings. We don’t reasonably have any control over how the OS handles task scheduling and power management regardless of your thoughts on it. I don’t think there’s anything else to say here. Another dev may look into it at some point, but beyond the above I can’t help further.

So … not a bug. Please don’t post mod related issues or requests in the bug report section.

I’m a bit confused here. Isn’t this all caused by mods?

Just to be clear: Steam's verify function will miss things (small changes to files, filename capitalization, deleted files .etc). Same with Steam's uninstall/install functions. Best practice is to delete the install directory yourself and then reverify the game to download a completely new copy. This can apply to the server as well.

If your install is out of date or corrupt, then the files might not match and therefore fail the checksums without mods. Steam’s update feature doesn’t always update properly; Steam’s uninstall feature leaves trash behind.

Turn on the performance overlay and set it to 5. See what the CPU does when the pauses happen. For me it's really consistent that the drops happen when 2 cores hit 100% or the steamdeck is over 75C.

PZ doesn't handle switching between controller and mouse/kb well. It should be treated as one or the other for now.

The highlighted line is just an example comment? It doesn’t affect anything ingame and ensures no one has the same value. This isn’t a bug with the game. You could just do a commit if there’s greater than 1 change instead of any change to avoid this?

Apologies, I assumed this was your account? https://steamcommunity.com/app/108600/discussions/0/6039921111956595692/?ctp=2#c3722819643268042028

And then you find out the library that provides all windowing features doesn't support that, so you can't do it. Like duh. Wasn't previously possible. Is now but it'll have to wait for sometime in build 42.

If you mean uploading a patcher to the workshop, then no. You can't upload programs to the workshop. If you want to just make a patcher that installs it and distribute it outside of the workshop, then I guess that's fine, assuming it doesn't violate the ToS. But, just in case: you should know that we do plan to implement an anticheat solution like BattleEye at some point. The work done to streamline this for MP might not be usable in the future (or might be further set apart from the main audience of the game than even now).