Hey team,
I run Eroded Networks, an Australian gaming community hosting Plutonium servers in Sydney. I’d really appreciate some guidance with server-browser visibility and stability across my BO1/T5 and BO2/T6 servers.
This affects multiple Official and Modded instances, not just Reimagined or one particular server.
We have already addressed the specific issues identified in our previous investigations. I’m leaving those resolved errors out of this report so they don’t distract from the remaining investigation. Some recently deployed corrections still need validation after their next normal load, so I’m not claiming every possible cause has been ruled out.
SERVERS TAKING TOO LONG TO APPEAR IN THE BROWSER
Some servers take an extremely long time to appear in the server browser, and occasionally some do not appear at all.
During these periods:
Players can still connect directly using the server’s IP and port.
Players generally have good ping once connected.
The heartbeat checks I monitor continue without corresponding missed check-ins.
What I can’t establish is whether those check-ins are being accepted by the master server and whether the server is then successfully passing whatever discovery/query checks are required.
I understand direct-IP connectivity and good ping don’t prove that the master-listing path is working correctly. Likewise, a local heartbeat message does not necessarily prove successful registration.
I’d appreciate help with:
How to verify that the master actually receives and accepts a server’s heartbeat.
Whether there are listing limits or rate limits when several T5/T6 instances share one public IP.
Whether the browser performs additional queries or validation that could fail even while direct connections work.
Any particular game/query port, advertised-address or Docker networking requirements I should double-check.
How to distinguish a master-listing problem from client-side browser caching, filtering or query timeouts.
What logs or packet captures staff would need to trace this properly.
I don’t have enough evidence to say whether this is on my side, in the route to the master, or in browser discovery. That is what I’m trying to establish.
HITCHES AND SERVER STABILITY ACROSS BO1 AND BO2
The broader stability investigation covers both BO1 and BO2, including Official and Modded instances.
The symptoms we have been investigating include:
Short in-game stalls/hitches.
Occasional periods where a server process remains running but the game stops responding normally.
I’m treating brief hitches and a completely unresponsive game as potentially separate issues. I also don’t want to assume the server-browser problem and the in-game stalls share a cause.
The specific faults we have already found have been addressed. What I need now is guidance on validating those changes and collecting useful evidence for any remaining or recurring problems, rather than repeating fixes for old errors.
HOSTING SETUP
AU dedicated host:
Faded Servers, Sydney.
Intel i7-10700K, 8 cores / 16 threads.
64 GB RAM.
Ubuntu 24.04.4 LTS.
Kernel 6.8.0-142.
Docker 29.7.1.
Pterodactyl Panel 1.15.1.
Wings 1.13.1.
Game runtime:
Windows dedicated-server processes running through Wine in Pterodactyl-managed containers.
Wine 9.0 via /usr/bin/wine.
WINEARCH=win64.
Wine prefix /home/container/.wine.
Launching with xvfb-run and Wine.
Multiple instances on the dedicated host, using separate port allocations.
AU BO2 Reimagined was verified as Plutonium r5354; I’m not assuming that one check verifies every instance’s build.
CUSTOM SCRIPTS AND INTEGRATIONS
The servers use EN custom GSC scripts and native utility/API integrations for community features, account/progression systems and diagnostics.
“Official” is our server label. Those instances still contain EN integrations, so they should not be treated as completely unmodified vanilla controls.
Some integrations communicate with our AU backend. I’m aware that network latency alone is different from blocking a game thread, and that the important questions are how requests are handled, whether callbacks or queues stall, and what happens during a timeout.
WHAT HAS ALREADY BEEN CHECKED
The investigation has included:
Overall CPU load and individual game-thread activity.
Memory usage and available OOM/process-lifecycle evidence.
Disk capacity, I/O latency and logging/checkpoint activity.
MariaDB/backend load and possible contention.
UDP/query responses alongside actual game-script progress.
GSC compilation, script behaviour and resource usage.
Native/API request behaviour under delayed responses.
Corrections have been made where specific problems were identified. I’m deliberately not presenting those old errors as unresolved problems here.
However, passing compilation, seeing spare RAM or observing a running container does not prove that the live game is healthy. We are checking actual server responsiveness and script progress as well.
Delayed API/native-request testing did not reproduce a main-thread freeze in the tested conditions. That narrows one scenario, but does not completely rule out the integrations.
I also haven’t conclusively ruled out Wine behaviour, contention between instances, remaining script behaviour or interactions with native plugins.
CONTROLLED COMPARISON
A native-Windows comparison is being prepared using an Official T6 setup with matching scripts and plugins.
The intention is to change the hosting/runtime first while keeping the server setup consistent. An integration-free baseline would be a separate comparison, so we aren’t changing everything at once and then guessing which change mattered.
That comparison has not been completed yet.
WHAT HELP WOULD BE MOST USEFUL?
Are there known T5/T6 dedicated-server issues with Wine, or recommended Wine versions/settings for this setup?
What is the most useful supported way to capture the state of a server that is still running but no longer responding properly?
Which engine/GSC diagnostics should be collected to distinguish a script stall, native-plugin stall and hosting/runtime problem?
What logging or sampling frequency would give useful evidence without adding enough overhead to create more hitches?
Is there a particular native stack/dump capture method under Wine that Plutonium staff can meaningfully analyse?
Would you prioritise native Windows, an unmodified server baseline, disabling native integrations, or reducing the number of hosted instances as the next controlled test?
For the browser issue, what exact information would let staff check whether an instance is registering and remaining eligible for discovery?
I actively manage these AU servers and would really appreciate some guidance on the next useful steps. I’m trying to isolate the cause properly rather than assume it is Plutonium, Wine or the hosting provider without evidence.
Also, could I get the Server Hoster role? Please let me know what verification is required.
Thanks,
Soda_toucher03
Eroded Networks
