Spillvert.no

Palworld uses much more memory but less CPU in my experience. Probably leaking like hell tho.

We have 10x test servers running at the moment. The CPU usage when there are 4+ players on a server is just absurd. If you try to limit the CPU usage with TCA CPU Limit or affinity , the server may notify the players of "High Server Load". Let's hope they can sort this. At this point a server for this game will need to be priced really high to cover the costs.

Any known settings to optimize the CPU utilization? As it is absolutely scorching our 5950x's at this moment.

Absolutely this can be fixed for the pre-built packs and versions you provide in TCA. However, in real life it is not that easy to enforce this fix when users are able to upload and run any version of MC and older pre-built modpacks. And the Updates does not allow for custom commandlines so it needs to be scripted for every update. The panel needs to know what version the server is on and apply the correct startup variable. If the wrong command is used (ex: -Dlog4j2.formatMsgNoLookups=true on a 1.16 server) it will fail to start.

Mojang is indeed urging Java server owners to take steps: https://www.minecraft.net/nb-no/article/important-message--security-vulnerability-java-edition

Has anyone had any luck overriding this with a commandline parameter? The official dedi wiki does not contain any info on this atm.

Yes it will, but all values has reverted to defaults. And even if you try to save one of the default values, the saved settings are also reverted. I did not try this outside MVC as there was no time to debug this on the production platform.

After updating to 160.18, all our games lost their default variables https://gyazo.com/ca6396328d8a7777348e868b2d355813 Re-adding the default variables reverts to disabled after settings are saved. And all settings done to them reverts to zero. So yeah, the update basically broke most games' commandline parameters on our platform. Trying to revert back to 160.0 now. Update: Rolling the master back to 160.0 solved the issue for us. All default command line parameters (and their default values, descriptions, regex etc.) was fortunately not lost.

Both fresh and "old" servers with worlds created several days ago, where the worlds will get wiped with the nightly scheduled server-restart. These worlds and the uptime of the game server are well north of the 30 min mark. We do have automated scripts that create a compressed copy of the worlds folder on a regular basis. However, some clients complain that if they restore this working backup, the same thing (wipe) happens on the next restart. And then we go full circle. We all know that this is a early access indie game in it's second week. Let's just hope they prioritize to patch this soon as all we do now is putting out fires 24/7.

Still getting massive amounts of tickets regarding world wipes on stop/restart. Running a few hundred Valheim-servers across a mix of Xeon and Ryzen nodes. Plenty of free memory and disk space on our machines. However, this game is still badly optimized and hogs our CPUs real bad, even when its supposed to be paused (when empty). Been racking new machines since friday to keep up. Our commandline looks like this: -nographics -batchmode -name "$[HostName]" -port $[Service.GamePort] -world "![World]" -password "$[PrivatePassword]" -savedir $[Service.RootDirectory] We do allow our customers to name their worlds whatever they like. We have however not seen the problem more often with worlds that have custom names compared to worlds named "world" or "dedicated" We have set the Stop Delay for this game to 15s to give it plenty of time for a gracefull shutdown. However, this has not eliminated the problem. All our nodes are Windows-based. A typical telltale sign when this bug occurs is that a world .db-file drops in size, from e.g. 17 MB to 1 MB. When this happens, the only solution is to restore from a previous backup.

Anyone else seeing a issue where changes to the commandline parameters on a server is not read by the server? The initial settings will be used, but if trying to change worldname / servername on a server that has gone full cycle, the server will still start with the old name and worldname. E.g You are staring a brand new server with parameters: -name "MyServer1" -world "MyServer1" Then stop the server and change the startup parameters to: -name "MyServer2" -world "MyServer2" After the server has started, it still runs the world MyServer1 (no MyServer2 world file is even created) and the name is still MyServer1 ? If running the server from a bat file, however, and make the same changes to that bat file - the changes are read every time. I fail to see the logic here.

We won't be taking this route as we will be waiting for the commandline parameter to set the world path, but please share your results after testing

I guess this only applies to Linux environments?

Got the same response. Will update this thread as soon as I know more. Hope you will do the same