Palschema- DatHost-Wine-Linux- Functionality?

[demtha11]

Hey Brother,

I have tried just about everything to get the latest 0.6.0 Palschema working on a DatHost dedicated server. They use WINE with Linux to run Palworld. Latest Version of UE4SS works and loads fine. I also tried installing multiple different palschema versions, but all of them hang the server during boot.

The UE4SS log file shows palschema loading and making the config file and thats the last line before the server hangs and never finishes boot. See below:

[2026-07-12 17:21:22.7051631] Console created
[2026-07-12 17:21:22.7051631] UE4SS - v3.0.1 Beta #0 - Git SHA #c2ac246
[2026-07-12 17:21:22.7051631] Timezone: UTC (local disabled due to wine)
[2026-07-12 17:21:22.7051631] UE4SS Build Configuration: Game__Shipping__Win64 (MSVC)
[2026-07-12 17:21:22.7071630] Setting up mods...
[2026-07-12 17:21:22.7071630] Loading mods from: Z:\home\dathost\palworld_windows\Pal\Binaries\Win64\ue4ss\Mods
[2026-07-12 17:21:22.7101629] Starting mods (from mods.txt (Z:\home\dathost\palworld_windows\Pal\Binaries\Win64\ue4ss\Mods\mods.txt) load order)...
[2026-07-12 17:21:22.7111629] Starting mods (from enabled.txt (Z:\home\dathost\palworld_windows\Pal\Binaries\Win64\ue4ss\Mods), no defined load order)...
[2026-07-12 17:21:22.7111629] Mod 'PalSchema' has enabled.txt, starting mod.
[2026-07-12 17:21:22.7121629] [PalSchema] [warning] Config file not found, a new one was generated. Default values will be used.

I sent a request in to DatHost to let them know, but figured I would post this here in case you have an idea... mainly to help others with the same problem because I spent hours with GROK and CHATGPT trying to troubleshoot and there is not much online that explains the root cause.

Notes:
bUseUObjectArrayCache is set to false and GraphicsAPI is set to dx11 in UE4SS settings file.
I went through the instructions about 10 times and made sure I followed them exactly.
I have also tried a full server wipe/reset and installed everything fresh- same problem

Thanks for the help.

[SvanT]

We traced this to UE4SS proxy startup rather than PalSchema's scanner or a general Wine threading failure.

UE4SS's get_main_thread_id() currently calls Thread32First() in the initializer of a for loop and calls Thread32Next() in the condition. The first snapshot entry is never processed. Under Wine on Palworld 1.0, the main thread can be that first entry, so UE4SS misclassifies normal proxy loading as manual injection and runs process_initialized() synchronously from DllMain.

PalSchema then starts and waits for scanner worker threads while the main thread owns the loader lock. The workers need the same lock for DLL thread attachment, producing the deadlock.

We confirmed the branch selection directly in the hung process: UE4SS's s_wait_for_ue4ss was 0. Selecting the queued-APC path changed it to 1; the official PalSchema 0.6.0 multithreaded scan completed and the dedicated server booted normally under Wine 11.7 Staging.

The generic source fix is now proposed upstream:

• fix: process first thread snapshot entry during proxy startup UE4SS-RE/RE-UE4SS#1338

Okaetsu/RE-UE4SS and canonical upstream main are currently both at c2ac246, so the fix belongs in canonical UE4SS. Once it is merged (or cherry-picked earlier), the remaining Palworld packaging steps are to sync the Okaetsu fork, rebuild UE4SS-Palworld.zip / UE4SS-Palworld_zDev.zip, and advance PalSchema's deps/RE-UE4SS submodule from c2ac246.

Separately, PalSchema starts after this fix but reports four missing Palworld 1.0 signatures. Those appear to be ordinary 1.0 signature compatibility work and are independent of this startup deadlock.

[Okaetsu]

Not sure if this was ever an actual issue, but I've updated ue4ss regardless.

[xorkerh]

Wanted to add a data point here in case it's useful — still reproducing this after the UE4SS update, with a fairly clean isolated repro.

Setup: ripps818/docker-palworld-dedicated-server-wine. UE4SS confirmed via checksum to be the current
experimental-palworld release build. PalSchema 0.6.1, bare framework only — empty mods/, empty enabled.txt,
zero sub-mods.

Result: hangs at the same point every time:

  Starting mods (from mods.txt (...) load order)...
  Starting mods (from enabled.txt (...), no defined load order)...
  Mod 'PalSchema' has enabled.txt, starting mod.

Then nothing — no crash, no error.

Two plain Lua mods (no DLL-level init work) load fine in the same environment when PalSchema isn't in the list to load, for what it's worth — seems specific to PalSchema's own init path.

@SvanT's analysis above lines up with what we're seeing. Happy to test anything or provide full logs if it'd help.

[xorkerh]

Quick follow-up with what we found after the last comment — figured it was worth sharing even with the issue closed.

We tried to replicate @SvanT's exact fix as closely as we could: forced the same queued-APC branch (built a small
patched UE4SS to force it unconditionally, bypassing get_main_thread_id() entirely) and ran it on Wine Staging.
Still hangs at the same point for us, every time — no scan progress, no error, nothing.

Digging into why PalSchema hangs specifically: SignatureManager::Initialize() calls into UE4SS's shared
SinglePassSigScanner, which spawns 8 worker threads via std::async and blocks on .wait() for all of them. That looks
like the actual deadlock-prone step, and it's shared UE4SS SDK code (not PalSchema's own), so any C++ mod doing a
signature scan on Wine could hit it.

That said — we could easily be missing something on our end rather than this being unresolved. A few real
possibilities: we're on Wine Staging 11.10 vs the 11.7 @SvanT mentioned, and we don't know if WINEESYNC/WINEFSYNC
were set in that working environment (Staging supports these but they're not on by default, and they change how
thread sync actually behaves under the hood). It's also possible this is a genuine race and we're just not winning
it as often. So this isn't "still broken, case closed" from us — more "we tried to reproduce the exact known-working
setup and couldn't, and would genuinely like to know what we're doing differently if anyone has ideas."

Happy to share our repro steps, test any theories, or provide full logs if useful.