Just a small update; it seems that MangoHud was causing my stuttering issues, so running the game without MangoHud has resolved that. The crash issues on the latest version of Proton still remains, however.

As described in the OP, if using Proton >= 8 the game crashes when it shows you the EULA/Terms after starting the game but before connecting to a server. Changing to Proton Experimental afterwards, fixes the stuttering described in the OP. @alligatorshoes after you accept the dialog, change to experimental in a clean prefix, that should fix your stutters.

spikes happen in storage read causes stuttering , spikes in pings happens in the same exact moment
i have AMD rx580 GPU and the game installed on a sata ssd.

tried different proton versions with and without manghud always the same issue .

Apparently they said the netease launcher was better, i tried lutris installed the launcher and the game and its basically the same in steam.

@acco2oo2 we have the same gpu, if im facing away from player bases and structures i get fps around 80 fps but when facing structured it stutters and goes down to 20 fps in 1% lows. Hoping to find a fix.

@hijearim same here but always having stutters as low as 12 fps when spinning the mouse or driving.

GPU usage drops a lot.

something about this issue is slimier to borderland 3 with the texture streaming issue can be fixed using -NOTEXTURESTREAMING, BUT this game wont respond to any launch options

I came back after a while an did nothing different and was able to get in the game with 7.0.6.

@alligatorshoes I play with Mangohud and the stuttering issues were solved by disabling Vsync and limiting FPS myself. I had 100% CPU usage with Vsync enabled. From now on, my game is smooth.

This is not my experience. Vsync was already disabled and CPU usage was only at around 50%. Running the game without MangoHud is the only thing that fixed stuttering for me. Possible it's a specific MangoHud configuration variable that's causing it but honestly I don't have the patience to debug it at this point and will just run with MangoHud disabled.

@alligatorshoes after you accept the dialog, change to experimental in a clean prefix, that should fix your stutters.

As I already mentioned, it did not. Only disabling/running without MangoHud fixed my stutters. Again, could be a possible MangoHud configuration variable that's causing it but I'm tired of debugging at this point :) But indeed, doesn't seem to be a proton/DXVK issue causing the stuttering.

I came back after a while an did nothing different and was able to get in the game with 7.0.6.

Servers were down earlier which likely explains why you couldn't get in game.

the game has spiking max storage read speed 30MB/s on a 500MB/s sata ssd with constant read and I/O activity .
while this happening the stuttering gets worse + ping gets higher too somehow .

tested on two PCs one with high end plus nvidia hardware and one with around the recommended specs with AMD hardware, both has opensuse tumbleweed with latest updates.

Seems silly to ask but has anybody tried capping their frame rate. To 60,90, or 120. Does the stuttering still occur?

Can confirm 7.0-6 plays a lot smoother when you play for a while. It'll appear to have more severe 1000ms+ stutters when you first launch compared to 9.0-2 or experimental but it eventually gets better as you wander around the game. The other versions do not get better over time. I have played up to the Iron River region.

Am on kubuntu 22.04 6.5.0-41-generic, X11, nvidia 535.183 Ada, PROTON_ENABLE_NVAPI=1 gamemoderun mangohud

I have set the game to 120fps cap, and use mangohud to restrict to 60fps to test, so far it has been running a lot better than default which would stutter all the time moving or panning camera.

Seems silly to ask but has anybody tried capping their frame rate. To 60,90, or 120. Does the stuttering still occur?

Yup already tried this.

Also tried running game on Windows and I use a low end pc so my framerates are very average like around 50-60fps capped with 30fps on 1% lows but no stutters just fps lows. But in Arch im getting high framerates using Proton but high stutters. On my wits end tbh really liked the game.

So im thinking its a proton issue.

Spec:

R3 2200g
A320M
2x8 2666mhz
RX 580 8GB 2048sp

Arch Linux on KDE/Wayland
(also tried xorg and turned it off, still stutters)

Using Garuda Linux with Nvidia 4070 and 555 drivers on wayland.

Latest proton have unplayable stutters that don't go away.

Using proton 7 get rid of the constant stutter, day and night changer.

Tried to play as of the 07/22 experimental update, I was able to accept the EULA and start playing with no issues.

I had to turn the graphic settings to low to fix the black out effect, but even after turning them back up to max manually the blackout effect was gone!

Unfortunately, on my 7900xtx and 7800x3d combo, The game was a stuttery mess; The game will consistently jump in between 240 to 60ish fps, regardless of graphic settings! I do use shader pre-caching and play a lot of demanding games with zero issues, so this game is definitely an outlier in bad performance!

so this game is definitely an outlier in bad performance!

No, it's not. My nvidia 4070 and 7800x3d run the game at max graphics like a charm using proton 7. So it's definitely a proton issue.

Running with proton 9 is a stutter mess.

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2232981252

@ULilBagel @gargoyle

Try going in to settings and change "Graphics" to Very Low.
this seemed to fix that void bug for me :D i'm able to change the individual settings to higher values after with no problems, as long as i dont tuch the "Grapics" setting

7-50-GE on Vega64 and Arch works flawlessly.

only GE-proton 7-50 is working perfectly for me with zero issues.

opensuse tumbleweed
Kernel Version: 6.10.3-1-default
Steam Runtime Version: steam-runtime_0.20240610.91380
Driver: AMD AMD Radeon RX 580 Series (radeonsi, polaris10, LLVM 18.1.8, DRM 3.57, 6.10.3-1-default)
Driver Version: 4.6 (Compatibility Profile) Mesa 24.1.3

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2282849106

tiny note when stutter is happening my storage lights wont stop and the read speed around like 5MB on a sata ssd after using GE7-50 storage lights is so calm and not busy like before

Seems to run decently with GE-proton 7-55.

I noticed vulkan shader compilation for this game is pretty slow, something like 10-15 minutes. It normally takes about 5 or 10 seconds with every other game I've tried. Is it needed since the game compiles shaders after launching it?

Arch Linux
RTX 3080
560.35.03 nvidia-open drivers

Are you using any launch options?

Nothing important. Just personal things for sharper images, shader compilation messages and mangohud.
MANGOHUD=1 DXVK_HUD=compiler __GL_SHARPEN_ENABLE=1 __GL_SHARPEN_VALUE=40 %command%

Starting today, proton GE 7-50/7-55 no longer works. Newer proton versions work, but there's stuttering (I've noticed that when the game stutters, the GPU usage drops down to like 10% for a second, then back up to 65-70% when the stutter is over)

GE 7-50/7-55 give me an error when trying to launch the game now "WinLicense - An error occurred while loading imports. Wrong DLL present."
Happens for me on any Proton version below 9-0

Thusfar I've found Proton Experimental to be the smoothest of all the proton/GE versions I've tried, but there's still noticeable hitching/stuttering, particularly around/in water, while gliding and if you travel too fast in a vehicle. Stuttering can be as minor as dropping from 80-90 FPS to 30 for a second, and as severe as dropping from 90fps to 10 for 5 seconds straight.

Personally I've found Proton Experimental with DXVK_ASYNC=1 to be the smoothest, and have the most issues near water or when traveling very quickly (60-80km/h in the car/ATV seems fine, but 120+ on the bike gets really stuttery, especially when making quick turns or if you go flying off a mountain (let's be honest, who doesn't use their bike as a glider)

DXVK_ASYNC doesnt even do anything with official protons with official DXVK builds. Unless you replaced the files with the hacky async ones.

Ah, I did not, but I was using it on GE and didn't remove it when switching to official proton so I figured I should include that it's there. Idk if it even does anything on GE proton builds tbh, always figured it couldn't hurt by having it there though whether I notice any difference with it on or not.

Though I will stand corrected, since the patch this morning, proton experimental randomly freezes, typically when hovering over items in my inventory. Game sound continues, but graphics freeze completely, GPU usage goes to 0% and CPU usage for the game drops by half and just sits there forever.

Back to re-testing each proton version I suppose.

Do not recommend GE Proton 9-13... xD

Will report back if I find one that's useful and stable for me.

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2376561083

I don't have once human installed anymore, but could you do me a favor?

Try the GE 9.x and set the graphics preset settings to low, you can bump all the individual settings to high after, as long as the preset general setting is set to low :-)

That's how I solved some "black texture" weirdness I had

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2376586495

I have tried this, even on the "Very Low" setting (I tried "Low" first), the black textures remain on Proton GE 9.x versions, and Proton official versions except for Experimental.

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2376599420

That sucks 😞 I was planning to play some once human again some day, guess this will end up in the "to be continued" pile

Well as noted, someone on ProtonDB said forcing the use_d3d12 option in the game config file fixed the stuttering for them on 9-13, and didn't report any texture issues, so the texture issue may not affect everyone, might still be worth trying it out.

I'm not sure what to do for myself at this point, I've reinstalled the game, deleted the prefix, disabled shader pre-caching, etc but issue persists.

I also did try everything, I am on steamdeck. I use proton hotfix, experimental, proton 9.0.3, ge-proton 9x nothing seems to work. I even tried the d3d12 option in the game config but no use.

I may have made a breakthrough - You need to manually install dxvk via protontricks.

After doing this, Proton 9-14 no longer had the black texture issue.
You need to make sure <setting_enable_d3d12> is set to 0 in the GraphicsConfig.xml file (this is the default value if you didn't change it) and append -dx11 to the end of the launch options

%command% -dx11 for example.

It's running buttery smooth with no stuttering, no texture issues.

The black void issue was fixed in mesa, it's not related to proton.

The black void issue was fixed in mesa, it's not related to proton.

The black void was occurring on mesa 24.3.0 until I installed DXVK and forced dx11 launch option, then it went away. There was no mesa update to fix the issue, so you are incorrect. It also immediately comes back if I remove the prefix and let it re-create it without dxvk. It also only occurred on certain proton versions.

I may have made a breakthrough - You need to manually install dxvk via protontricks.

After doing this, Proton 9-14 no longer had the black texture issue. You need to make sure <setting_enable_d3d12> is set to 0 in the GraphicsConfig.xml file (this is the default value if you didn't change it) and append -dx11 to the end of the launch options

%command% -dx11 for example.

It's running buttery smooth with no stuttering, no texture issues.

dxvk doesnt seem to show in protontricks for me. Still somewhat of a noob with linux. Am i missing something?

The black void issue was fixed in mesa, it's not related to proton.

The black void was occurring on mesa 24.3.0 until I installed DXVK and forced dx11 launch option, then it went away. There was no mesa update to fix the issue, so you are incorrect. It also immediately comes back if I remove the prefix and let it re-create it without dxvk. It also only occurred on certain proton versions.

Maybe it's a regression, as it definitely got fixed in Mesa 24.2.1:
Once human black artifacts consume the screen

Until this release I've experienced the black void on anything but low settings. After the release of 24.2.1, I finally could bump it up to the max. Have not played for a while now, so can't say if it's back.

It's also a bit odd that you explicitly would have need to install dxvk - I'd assume that comes with GE/Proton by default. But if that works for you, I might be wrong. :)

Ah, and I'm on a XT 7900XTX GPU, if that matters.

I may have made a breakthrough - You need to manually install dxvk via protontricks.

After doing this, Proton 9-14 no longer had the black texture issue. You need to make sure <setting_enable_d3d12> is set to 0 in the GraphicsConfig.xml file (this is the default value if you didn't change it) and append -dx11 to the end of the launch options

%command% -dx11 for example.

It's running buttery smooth with no stuttering, no texture issues.

I still had to use Experimental after manually installing the latest dxvk in the prefix. But that seems to have helped.

I had to use flatpack steam/mesa as the latest mesa on Fedora is 24.1 not 24.2+.

To answer @PompousG7

dxvk doesnt seem to show in protontricks for me. Still somewhat of a noob with linux. Am i missing something?

I don't know if grabbing the latest dxvk (2.4.1) is stricly required. I think we're just throwing stuff at the wall to see what helps at this point.

To manaully install it you need to extract/overwrite the various dxvk dll files into your wine prefix eg

..../steamapps/compatdata/2139460/pfx/drive_c/windows/syswow64
..../steamapps/compatdata/2139460/pfx/drive_c/windows/system32

Unless I am missing something obvious in the protontricks too!! :laughing:

I missed the obvious, it's in the menu you just have to scroll down farther...

latest mesa on fedora is 24.3

protontricks (like winetricks) handles moving the files there for you when you install dxvk through the tool.

I know that I tried the game with proton 9-14 with the -dx11 launch argument and had the black textures.
I closed the game, used protontricks to install dxvk (it installed 2.4.1), and started the game up again.

With no other alterations, the black textures were gone.

I then deleted the entire prefix, and repeated the same test again, first without dxvk, and again with dxvk, and the results were the same. no dxvk = black textures, dxvk = playable with minor stuttering

The stuttering is less on 9-14 (for me) than experimental, and it doesn't crash everytime I open my inventory, but it does get laggy when I open it.

latest mesa on fedora is 24.3

On Fedora 41 (Beta) :smile:

I've fired up the game again, using Experimental and GE-Proton9-14.
With Experimental things looked good, but I've experienced severe freezes when editing the body of my character for the new season.
With GE, there are no freezes, but I can confirm black textures.

Note that this is not the "black void" issue where suddenly the whole screen gets painted with black, but texture errors.

That is a newer issue, which might have been fixed already in the latest dxvk, which would explain why installing / overwriting it from the latest master might fix it. shrugs

latest mesa on fedora is 24.3

On Fedora 41 (Beta) 😄

You sure about that there, bud?

I've fired up the game again, using Experimental and GE-Proton9-14. With Experimental things looked good, but I've experienced severe freezes when editing the body of my character for the new season. With GE, there are no freezes, but I can confirm black textures.

Note that this is not the "black void" issue where suddenly the whole screen gets painted with black, but texture errors.

That is a newer issue, which might have been fixed already in the latest dxvk, which would explain why installing / overwriting it from the latest master might fix it. shrugs

Give it time, it will still stutter a LOT, especially when opening your inventory or flying. But it is otherwise 'playable' at least.

System specs:

CPU: 5900x
GPU: 3080ti
OS: CachyOS
Kernel: Linux 6.11.0-5-cachyos-lto
DE: KDE Plasma 6.1.5
WM: KWin (Wayland)
Proton: Experimental (not bleeding edge)
Launch options: DXVK_HUD=fps,frametimes,memory,gpuload,api PROTON_LOG=1 PROTON_HIDE_NVIDIA_GPU=0 PROTON_ENABLE_NVAPI=1 %command%

Game intermittently spikes in frametime causing stutter and fps drops. More noticeable while in combat or when effects are taking place. UI elements (inventory, looting, storage, etc) lag while loading or hovering over item icons. From what I can tell, and correct me if I'm wrong, but the game doesn't run in DX12 even if you set it explicitly in the Graphics-config.xml file. It will still run with DXVK which reports D3D11 FL11_1 from the HUD.

From the 1gb proton log produced in the 7 minutes the game was running before crashing, nothing seems to stick out, just a ton of:

1670.583:0368:0488:fixme:d3dcompiler:skip_u32_unknown Skipping 3 unknown u32s:
1670.583:0368:0488:fixme:d3dcompiler:skip_u32_unknown 0x00000000
1670.583:0368:0488:fixme:d3dcompiler:skip_u32_unknown 0x00000000
1670.583:0368:0488:fixme:d3dcompiler:skip_u32_unknown 0x00000000

This gets spammed for a bit:

1324.612:0368:03a4:fixme:bcrypt:BCryptGenRandom ignoring selected algorithm

and this is what hung and inevitably crashed the process:
https://pastebin.com/5hGpCGmL

Proton Hotfix runs better than experimental but it's still pretty unplayable imo, with frametimes spiking to 80ms once a minute. Have over 150 hours in the game as it worked fine with GE7.55 before the latest patch. Hoping a talented individual could come along and help out :+1:

I may have made a breakthrough - You need to manually install dxvk via protontricks.

After doing this, Proton 9-14 no longer had the black texture issue. You need to make sure <setting_enable_d3d12> is set to 0 in the GraphicsConfig.xml file (this is the default value if you didn't change it) and append -dx11 to the end of the launch options

%command% -dx11 for example.

It's running buttery smooth with no stuttering, no texture issues.

This fixed the black texture on steamdeck running GE-proton9-14 still have some random spike and when you get to town, can't move anymore. So I set my anti aliasing to low instead of Mid and works fine now 60 fps on meyers without npc but goes bad again when there are npcs and monsters specially when fighting. So I tried 9.0.3 everything goes smooth again but when I teleported back to my home base the stutter goes bad again.

Unfortunately I'm fairly certain the reason proton prior to 9.0 doesn't run is due to an anticheat update in the game.

I don't know how feesible it is to fix that in an older proton version, and the graphics issues were experiencing seems to be a regression of some sort, but at this point it's anyone's guess as to what was added between 7-55 and now that causes it. Since proton older than 9.0 can't launch the game, and 9.0-2 has the issue, it likely started somewhere in the 8.x versions but no way to really pin down exactly where anymore.

Time for everyone to dig through mountains of logs, ig

Verified what @joker-119 said, -dx11 and dxvk works great :) running protonGE 9.14

Verified what @joker-119 said, -dx11 and dxvk works great :) running protonGE 9.14

no stuttering? no lag issues?

I installed dxvk via protontricks and added -dx11 at the end of the command line but I still get black textures with Proton 9+. Hotfix worked prior to the update but now doesn't even boot. And experimental lags the game to a stop when I open Memetics, though I can still hear my radio. So, for me at least the game is completely unplayable under Linux. I'm now looking at getting KVM/VFIO working in order to play it...

Verified what @joker-119 said, -dx11 and dxvk works great :) running protonGE 9.14

no stuttering? no lag issues?

Not really no, I'd have to test different areas out before I can say for sure but so far so good

Verified what @joker-119 said, -dx11 and dxvk works great :) running protonGE 9.14

no stuttering? no lag issues?

Not really no, I'd have to test different areas out before I can say for sure but so far so good

Thats great. Can you share how? So i can test it on my end bro?

I installed dxvk via protontricks and added -dx11 at the end of the command line but I still get black textures with Proton 9+. Hotfix worked prior to the update but now doesn't even boot. And experimental lags the game to a stop when I open Memetics, though I can still hear my radio. So, for me at least the game is completely unplayable under Linux. I'm now looking at getting KVM/VFIO working in order to play it...

@Godless-Heathen that's from your mesa version. Use vulkaninfo | grep driverInfo to know the version of mesa you are using. If it's less than 24.1.7 (for 24.1) or 24.2.1 (for 24.2) then check with your distribution if there's a newer release.

@Huszyl @kieeps I'd appreciate if you guys removed the @joker-119 from your replies in the future, it causes me to get pinged each time 🤣

Or better yet, don't create reply chains of consecutive comments in the first place.

I don't really see an issue with reply chains when they are direct replies to what's said, it actually helps keep things in context for others.

But removing unnecessary @'s to other people from them should be a courtesy :)

The frame drops get worse the longer you play, until you restart the game. Could it be some kind of resource leak?

@Godless-Heathen that's from your mesa version. Use vulkaninfo | grep driverInfo to know the version of mesa you are using. If it's less than 24.1.7 (for 24.1) or 24.2.1 (for 24.2) then check with your distribution if there's a newer release.

@braiam yes, I figured that was the issue since my system is on 23.2.1, but I'm having an issue upgrading to 24 on Linux Mint 21.1 which I think is because my OS is a few versions behind. So I'm moving over to LM 22 on my new 4TB NVMe and setting up dynamic bind/unbind for my GPU so I can run Win 11 via KVM/VFIO (VM) for those games that don't play nice with Proton. And I'll still be able to run games with prime-run when my GPU is rebound, much like how a gaming laptop works with an iGPU and dedicated card.

The frame drops get worse the longer you play, until you restart the game. Could it be some kind of resource leak?

@StelardActek Yes, there are memory leaks in the game. I'd have System Monitor up on my second monitor as I was playing, and the game would eventually eat up 20+GB and at some point it would just close to desktop. I don't know if it does that under Windows, but I'll be finding out soon.

Using Mesa 24.2.3 and Proton Experimental, I'm having an issue where the game runs fine for as long as I keep it open, but as soon as I try to make a new character on a server the game freezes. I cannot make a character, so I can't actually get into the game.

Using Mesa 24.2.3 and Proton Experimental, I'm having an issue where the game runs fine for as long as I keep it open, but as soon as I try to make a new character on a server the game freezes. I cannot make a character, so I can't actually get into the game.

Try using proton GE 9-14, it seems much more stable than experimental is, experimental kept soft locking for me when opening my inventory or memetics

A friend on windows sent me this:

looks likle a mem leak

Over the course of playing for 6hrs, the game's only using 8-10gb of ram for me. Not really all that impactful of a leak, whatever one there is.

And that certainly wouldn't affect things 5-10mins into the game when it's sitting under 6gb of ram used.

he just showed me a screenshot of his task manager, showing 24gb of ram used with not many apps opened and once human running for a few hours

Correct me if I'm wrong, but that screenshot shows once_human consuming just over 5gb of memory, and the windows desktop manager consuming almost 8gb.

I'm not sure if you know this, but Linux (incl. proton) do not have a Windows desktop manager taking more memory than our games.

The game has been running for approx. 2 hours, and the game is consuming 5.2gb of memory.
And I just closed the game, and my system memory usage dropped by about 5.8gb (this accounts for the game and proton stuff combined).

Hardly an issue for a game to be consuming 5gb of ram, memory leak or not, it's memory usage is not relevant to our issues here, as any leak there may be, is obviously not bad enough to cause an issue so quickly into playing the game.

On a side-note - I found some threads related to stuttering issues on windows, and noticed that the netease launcher version of the game ships with several vcrun 2017 dll's, while the steam version does not.

I installed vcrun2017 via protontricks, and noticed a significant improvement.
By no means is the stuttering gone (especially when opening your inventory/navigating menus), however my 1% lows went up from 18-20fps to 39-45fps, with the average remaining about the same at 81fps.

Results may vary on this, I haven't tested it super thoroughly, but anecdotal evidence suggests it may at least improve the issue somewhat, or at the very least, doesn't make it any worse.

Try using proton GE 9-14, it seems much more stable than experimental is, experimental kept soft locking for me when opening my inventory or memetics

GE runs the game, but all of the textures in the game are black and/or not loaded. I used GE to get past the initial bit, and have used Experimental since. The performance is awful, and the game hitches a lot. The game tends to crash when trying to enter my "Gear" inventory screen.

Try using proton GE 9-14, it seems much more stable than experimental is, experimental kept soft locking for me when opening my inventory or memetics

GE runs the game, but all of the textures in the game are black and/or not loaded. I used GE to get past the initial bit, and have used Experimental since. The performance is awful, and the game hitches a lot. The game tends to crash when trying to enter my "Gear" inventory screen.

Read the rest of the thread, brother.

You need to manually install dxvk latest via proton tricks, and if you have an amdgpu you need the latest version of mesa.

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2389708671

@joker-119 you dont experience any lag or stuttering issues now bro?

Replying to https://github.com/ValveSoftware/Proton/issues/7888#issuecomment-2389708671

@joker-119 you dont experience any lag or stuttering issues now bro?

Still lag and stuttering issues, but they seem to have gotten less severe after what I did in my last post about tinkering with stuff. It Playable, but only barely.

I can confirm that the game seems to run decent with GE.Proton9.15. There are still stutters but not as bad as they used to be.

I d'ont know if you have this too, but, after some playtime (5 min) i start to feel a huge input lag that increase over time.
I use proton ge 9.15 i am using sunshine + moonlight for streaming over local network.
The input lag only appear in game-play, in the game menu (settings) the cursor is very smooth and responsive.
The machine is in a vm too with pcie gpu pass-through, but, it doesn't explain why the performance and input lag get worse over time.
No components are overheating and cpu usage is low, my vm has 14 gb dedicated ram.

@MARTINrichard05 only limiting the fps to 60 ingame fixes high input lag for me, setting it via DXVK_FRAME_RATE still gives high input lag

I did that, but i will try other settings

I can confirm that the game seems to run decent with GE.Proton9.15. There are still stutters but not as bad as they used to be.

This.

FWIW I can clearly see the game aggressively unloading assets. A cutscene switching the camera angle by about 180° makes it obvious that even if I skip through the dialogue it still unloads parts of the background immediately when looking away. This of course – to absolutely nobody's surprise – causes significant churn even when running on SSD (presumably assets have to be decompressed or something, I dunno, at the very least there's some latency to it) during which framerate drops to and below the absolute minimum.

Considering that the game runs smooth on Windows I would wildly guess that its internal metrics for loading or unloading assets may get wonky results on Linux (e.g. the good old "considering fscache memory to be unavailable thus dropping allocations wildly due to perceived memory pressure"). On the other hand I don't know squat about video game (or proton/dxvk) internals plus I have not seen the game run on Windows first hand so the behaviour I suspect to be the culprit may also be present on Windows, so take this with a grain of salt.

I saw someone on protondb suggest just running it with %command% -force-vulkan, and decided to give gamemoderun mangohud %command% -force-vulkan a try. I'm new to mangohud, but I was hoping it would tell me if the game was actually in vulkan or not; it seems to suggest it's not, since it still says DXVK below CPU.

Despite that, however, I can't help but feel that performance is improved. It's still really bad in some places, particularly the Blackfell town area near the municipal building. But there was also a patch, so who knows if that was the cause of my possibly-imagined improvement or not.

Edit: Oh right, I upgraded Mesa to 24.2.4, so that might have had an impact too.
Edit2: Subsequent playing suggests not much difference after all.

since it still says DXVK below CPU.

Yeah, it saying DXVK and not VULKAN is a dead give away that it's not using vulkan and that the
-force-vulkan flag isn't doing anything. Sucks because that would have been interesting. @StelardActek

I have not seen the game run on Windows first hand so the behaviour I suspect to be the culprit may also be present on Windows, so take this with a grain of salt. @benaryorg

I got a chance to observe it on Windows and can confirm the same thing is happening on there. It's more exaggerated on proton though. Turning off FSYNC/ESYNC - PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 - seems to offer some very minor improvements, could just be wishful thinking / confirmation bias on my end though; would need more people to verify.

Interestingly enough I've found that the lag/stuttering from things being aggressively loaded/unloaded does not happen in Eternaland at all. I suspect perhaps there's something going with anti-cheat.. but that's a WAG at best.

Just to save other people the trouble, I decided to give NTsync a try. While it might have helped the overall FPS (it's hard to tell), it doesn't solve the awful lows from frequent loading.

I feel like the game behaves much better with VKD3D (DX12 in-game). It still lags and stutter a lot, but seems mostly to happen with initial loading of textures and shadders, but the aggresive unloading (when rotating the camera, for example) seems not to happen that much.

I still need to test a bit more but it's worth trying since with DVKX doesn't seem to work that well.

EDIT: Update VKD3D through protonfixes if not updated already.

@Fasgort How do you get it to run in DX12 mode? There's no setting for that in the steam version as far as I can see.

@Fasgort How do you get it to run in DX12 mode? There's no setting for that in the steam version as far as I can see.

@StelardActek Be sure you are not using some command line like -dx11 in steam.

I think you can also force the setting in /steamapps/common/Once Human/Documents/GraphicConfig.xml.
There should be a Graphic>Advanced><setting_enable_d3d12>1</setting_enable_d3d12> settings that should be equal to 1.

@Fasgort How do you get it to run in DX12 mode? There's no setting for that in the steam version as far as I can see.

@shelterx I don't have that option in my settings. Is that the steam version or the website launcher version?

@StelardActek steam version

@shelterx I wonder why I don't have it.

CMIIW, but even on Windows, only Nvidia cards show the menu to change between dx11 and dx12.

@shelterx try enabling DXVK Nvapi , if you have a NVIDIA Card

Ah, I have a Radeon. I guess that's why, then. Hopefully they let us use DX12 soon too.

@Fasgort How do you get it to run in DX12 mode? There's no setting for that in the steam version as far as I can see.

https://www.reddit.com/r/OnceHumanOfficial/comments/1evfr6r/they_added_dlss_and_dx12/

you can add 2 lines in the games xml file
for me it crashed since i tried :/

for those who don't have this option:
navigate to "SteamLibrary\steamapps\common\Once Human\Documents" and open the GraphicConfig.xml file.
There you just need to set

<setting_enable_d3d12>1</setting_enable_d3d12>
<setting_use_d3d12>2</setting_use_d3d12> 

@DSDV I'm not convinced that works. I have made those changes, but mangohud still says DXVK is in use, not VKD3D. Admittedly I don't have enough knowledge or experience with mangohud to know if it would say VKD3D in that case, but nothing else seems to have changed. I assume the game detects my radeon (or more likely, fails to detect an nvidia card) and goes to DX11 regardless of configuration files or command-line arguments.

@StelardActek the game is phishy as hell to me ^ ^
i tried those changes on my dual boot W11 and it looked like it was working but next time i boot into i can try to check (need to google how to do that on windows tho)

but (sadly as usual) code quality / performance of games is not the best :(
it even wants administrative privileges every! time it starts -.-'
(luckily my W11 is only for testing and a few games plus in a separate vlan)

//EDIT1: https://medium.com/@DarkRa/once-human-patch-leads-to-directx-12-crashes-players-advised-to-switch-to-directx-11-8298ed1da9c1 ... yep looks like DX12 crashing is another game dev thing -.-

Also the Devs though it might be a great idea to gate DX12 to nvidia users only.
Apparently they "only" added it for DLSS to work XD

@DSDV Yeah, when I was gaming on W10 I would mod the manifest so it wouldn't ask for admin rights. Seemed the only reason it needs them is so that the game proper can download and write updates to Program Files, so if you don't install there you don't need it.

If they had just put their self-patching code in a separate exe that self-escalates when an update is detected, there'd be no need to run the game as admin, but that requires 15 minutes of dev time to produce. So I'm not terribly surprised to hear their DX12 implementation is just for DLSS.

I've found recently that being in proximity to a chaosweaver world boss causes my game to crash. Has anyone else experienced this?

Edit: GE-Proton9-14 doesn't seem affected by this, while 9-18 is.
Edit2: Updating only DXVK to latest (2.5) inside GE-Proton9-14 has not caused the problem to resurface.

After nov-21, on a RTX 4070 the 3d part of the game started with almost all black textures and moving around makes all object borders to be dragged around looking like this https://drive.google.com/file/d/1HUD3Nfn5rWl55O8AhkrKrj54632yi4Y0/view

Proton log has a lot of these
88660.169:011c:018c:fixme:d3dcompiler:skip_u32_unknown Skipping 8 unknown u32s: 88660.169:011c:0188:fixme:d3dcompiler:skip_u32_unknown Skipping 8 unknown u32s: 88660.169:011c:018c:fixme:d3dcompiler:skip_u32_unknown 0x31314452 88660.169:011c:0174:fixme:d3dcompiler:skip_u32_unknown Skipping 8 unknown u32s: 88660.169:011c:017c:fixme:d3dcompiler:skip_u32_unknown Skipping 8 unknown u32s: 88660.169:011c:0188:fixme:d3dcompiler:skip_u32_unknown 0x31314452 88660.169:011c:018c:fixme:d3dcompiler:skip_u32_unknown 0x0000003c 88660.169:011c:0174:fixme:d3dcompiler:skip_u32_unknown 0x31314452 88660.169:011c:017c:fixme:d3dcompiler:skip_u32_unknown 0x31314452 88660.169:011c:0188:fixme:d3dcompiler:skip_u32_unknown 0x0000003c 88660.169:011c:018c:fixme:d3dcompiler:skip_u32_unknown 0x00000018 88660.169:011c:0174:fixme:d3dcompiler:skip_u32_unknown 0x0000003c

I'm getting the same thing on a Radeon 7900 XTX. Updating DXVK to 2.5.1 didn't help, trying various Proton versions (GE and official) doesn't help. I've tried both AMDVLK and RADV drivers, to the same effect.

Game is still playable by setting DX12 in-game and using VKD3D.

Game is still playable by setting DX12 in-game and using VKD3D.

Sadly that doesn't seem to be an option for radeon users.

Game is still playable by setting DX12 in-game and using VKD3D.

Sadly that doesn't seem to be an option for radeon users.

Yeah. Quick reminder for any newcomers to the thread: DX12 is feature gated for Nvidia cards only. It has nothing to do with the launcher.

After nov-21, on a RTX 4070 the 3d part of the game started with almost all black textures and moving around makes all object borders to be dragged around looking like this
I'm getting the same thing on a Radeon 7900 XTX. Updating DXVK to 2.5.1 didn't help, trying various Proton versions (GE and official) doesn't help. I've tried both AMDVLK and RADV drivers, to the same effect.

So this is a strict issue with the DX11 version regardless of graphics card vendor?
Did you clear out the game-internal shader cache (the game stores it in the game directory under Documents/baking_ppk if memory serves)?
When using DX11 and turning on the DXVK HUD does it list the known-good DXVK 2.5.1, or is this happening with a different DXVK version?

https://drive.google.com/file/d/1HUD3Nfn5rWl55O8AhkrKrj54632yi4Y0/view

It would be really cool if screenshots were added in the thread itself, both for persistence (I don't trust that link to still work in two years when someone reads through this to figure out whether there was a regression, meanwhile I trust GitHub to keep the image as long as the issue exists) and privacy.

Game is still playable by setting DX12 in-game and using VKD3D.

My experience with DX12 was that the performance was lower overall, but somewhat more stable.
Despite being more stable it was still a good chunk under 30 fps for me which made it borderline unplayable, despite lowest graphics settings.
I have yet to hear confirmation that it actually runs smooth with DX12.

-force-vulkan

I find it somewhat odd that at time of writing there are 7 PC reviews on ProtonDB that use that flag despite it not doing anything at all.
To anyone coming from ProtonDB, please turn on the DXVK HUD; if it still shows then you're still on DX11.
If it doesn't, you're probably on DX12 instead; switch to DX11 in the settings and try again with the flag, if DXVK shows then you were almost definitely just on DX12, not Vulkan.
Heck the developers did a bad job at getting DX12 to work (frequent crashes, etc.) just to get DLSS to work for Nvidia users, why would they go about and use Vulkan which effectively requires more code and planning, and puts more responsibility on the devs than DX11 (definitely) or DX12 (probably).?

It happens on both dx11 and dx12, I can select them on the game options. It also happens with whatever graphic quality settings (I've try everying as low quality and it still happens).

@benaryorg I tried renaming the baking_ppk dir, it didn't help. And yes, I'm definitely using DXVK v2.5.1.

Here's a screenshot of the issue I'm seeing

Game is still playable by setting DX12 in-game and using VKD3D.

My experience with DX12 was that the performance was lower overall, but somewhat more stable. Despite being more stable it was still a good chunk under 30 fps for me which made it borderline unplayable, despite lowest graphics settings. I have yet to hear confirmation that it actually runs smooth with DX12.

I haven't noticed lower performance, but it still has the same issues that plagues DX11 performance-wise. The loading and unloading of textures and the massive FPS drop when it is happening, still happens in DX12.

I suspect it's the anticheat not playing nicely with proton, since all problems started when they added the anticheat, as far as I know.

@benaryorg I tried renaming the baking_ppk dir, it didn't help. And yes, I'm definitely using DXVK v2.5.1.

Here's a screenshot of the issue I'm seeing

This is what I'm seeing too. Proton 9.0-3 and Proton Experimental, RX6800 GPU. The game played fine about a week ago, but between now and then I've had to reinstall it (for reasons unrelated).

I'm not sure what changed, but the game is currently playable again for me. Didn't try it for long, but I was able to get meaningful graphical output at least, low bar as that may be.

I'm thinking it was either an update to the game, or perhaps the fact that I'm on kernel 6.12.1 now. Using Proton Hotfix too, but I was getting garbage output from that before.

Edit: Still develops frame pacing issues after teleporting or messing with the inventory too long.

Yeah, same thing, started working again out of the blue. I didn't update anything linux related, so it was either a proton update or one of the million game updates that they do

Aside from the abundance of game bugs:

The last known good version of Proton was 7.55 (now incompatible), subsequent versions have suffered from the frame pacing mentioned elsewhere in this thread (especially when streaming in content - though not exclusively). Per the above PR, PROTON_SET_GAME_DRIVE=1 seems to almost entirely resolve the problem (closing the map and other UIs will still cause the game to hang for up to a minute) - I wonder if the lack of free space information is preventing the game from caching PG outputs?

The specific version of Proton doesn't seem to matter much.

setgamedrive

Per the above PR, PROTON_SET_GAME_DRIVE=1 seems to almost entirely resolve the problem (closing the map and other UIs will still cause the game to hang for up to a minute)

I currently have several issues with the game, which I'll go into detail below, however setting PROTON_SET_GAME_DRIVE=1 does indeed fix what I would've referred to as symptoms of caching issues indeed.
When opening the building menu it does no longer hang for a solid 5s on SSD to read the damn icons off disk, instead it just opens with the icons there.
I can hit Escape and actually see a menu which I can leave again without waiting ten seconds for each of those.

I'll be putting some time in now and if I have any relevant findings report back.

Update 1

Been playing for a while now and remembering my first experiences when starting it up yesterday were "damn this lags hard when loading initially, but then runs somewhat okay" I am seriously questioning whether I did inadvertently change something (which I don't believe I did).
No matter where I am in-game or how much stuff there is around for it to load in/out of memory/off disk, it lags so badly.
The classic "finally I'm back to base" followed by the game freezing up entirely on the very border of your territory, giving only audio but no visual output, the window being solid frozen, having to apply blunt force (read: killing the entire process namespace) to even stop the game.
Then we have the good old "just riding on a motorcycle through a town" accompanied by the oh so familiar slideshow (read: about 3 seconds per frame on an RTX 3080) and after the third frame finding yourself lying on the ground bleeding out.

Note that I double checked the cmdline of the wine process, which lists ONCE_HUMAN.exe (because Windows people love capslock since the DOS era) as running in S:\common which means that setgamedrive is in effect.

Looking at this box' PSI values indicates an IO issue (but only in the past hour or so, and I've been playing for more than that) which is really "funny" when looking at the storage metrics which show no significant throughput or IOPS in the same timespan with the IO pressure stalling. Do I take this to mean that the CPU ⇔ GPU HVV IO is bottlenecked? If so I have a different set of questions.

I guess I'll be poking at the game some more.

Update 2

I restarted the game, it ran super smooth for a while, even when entering a larger town (albeit a bit stuttery while loading the assets, despite still being at basically zero IO pressure and almost no throughput at the time, thanks memory caching), and then started getting stuttery again.…
I really don't know anymore.

Note that this happened while NVAPI was active (i.e. I can "quit" the game while hitting the graphics settings menu).

*very long and exasperated sigh*

I might check later, or I might drop the game for another few months, I dunno.
Y'all have fun tho!

Update 3

After shoving the entire game into squashfs so I can check both fscache status as well as flash it to a spare local NVMe partition I was able to dig further into the game's disk reads which I assumed to be a bottleneck.
They are very likely not.
Thanks to Linux being generally extremely damn good at caching, it barely ever reads from disk at all.
Basically I can fire up the game and have a very smooth experience.
Until I walked around a bit and the game has loaded/unloaded a few assets.

So FWIW the experience deteriorates over time as it did previously.

Yes, this game is playable for a few minutes and then requires a restart to be smooth again, which isn't too bad (it still sucks), but playing with friends and having to restart while in the middle of something doesn't sound too appealing tbh.
And this is just talking about open world exploration, I assume missions/dungeons/whatnot to have the same problems I ran into half a year ago, where a single.… uhh.… "vault"(?) was so big that by the time my friend and I arrived at the boss, it was lagging real bad, and restarting the game then isn't much of a choice in those situations.

Either way, with DX11 now actually working properly I'll try and run an overlay again to get more info.
I haven't tried DX12 too much at this point, because it generally runs worse AFAICT (though if nothing's changed then it'll at least stay that way and not dip further the longer you play).

DX11/DX12

Aside from the abundance of game bugs

Which leads me to further details; this only works with DX11 (little surprise here given that DX12 was – and probably still is – just there to allow DLSS). DX12 still sucks in all of the above respects.
Caveat; I cannot open the graphics settings on DX11. On DX12 it works fine (oh boi, am I happy to be an nvidia user blessed with the ability to switch to "low performance but slightly more stable" API /s), but when running on DX11 I can visit the basic graphics settings menu (brightness, resolution), but upon hitting the actual settings (y'know, AA, Detail, Shader Quality, the good stuff) it just hard crashes to desktop which is hilarious in its own right (or it would be if this was a prototype for a game presented at E3 slated for release in two years from now).

So.… DX11 with graphics settings via the XML file it is for me.

Update 1

Hmm.… I'm not happy about this (but nothing about the technical aspects about this game will make me happy any time soon), but setting PROTON_ENABLE_NVAPI=0 PROTON_DISABLE_NVAPI=1 (former for Proton 9, latter for Proton 10) actually allows me to open the graphics settings on DX11, implying that the game trying to figure out whether or not my system supports DLSS (or anything else in regards to figuring out whether or not to offer me DX12 at all, which – again – isn't available to AMD/Intel users at all AFAIK) leads to the game somehow crashing.

Proton Version

The specific version of Proton doesn't seem to matter much.

I'm currently running Proton-GE9-27, mostly because I need the gamefixes feature (to force games on ALSA, because the pulse library seems to be unable to do latency in my specific case, don't ask), but 9-25 is pretty much the same and my short encounter with the Steam Proton 10 Beta has renamed my compatdata prefix to "corrupt_pfx_$number" and upon downgrading required me to wipe the Documents directory (in the game directory, where the game blatantly stores per-user information, instead of per-user directories, but hey, I'm not a game dev for an F2P game, what do I know, I only write software that actually works 🤡) to have the account binding restored.

Bugs

This game is an abomination (even on Windows)

The above quoting from the linked issue holds true.
Half a year back (almost exactly) I reported via the in-game feedback form that the game's minimap, when set to "face in camera direction" (instead of having north at the top) faces neither in the camera direction, nor the cardinal directions, moving in sync with the camera direction at semi-random angle offset from the actual camera direction while still displaying the cardinal directions as if the minimap had North towards the top.
Of course this doesn't make any sense and renders the minimap absolutely useless.
This has not been fixed to this day.

This anecdote should get your expectations somewhat in line with what the game's going to give you *sigh*

TL;DR

What does this mean for anyone wanting to play the game?

Switch to DX11 (if you haven't already), use env PROTON_SET_GAME_DRIVE=1 %command% as launch options, and enjoy a somewhat(?) playable experience.

What does this mean for anyone subscribed to or reading this issue?

I'd like some feedback on whether or not anyone else has seen the game just crash to desktop upon opening the graphics settings.

Launch Options (re: ProtonDB)

I'll reiterate on the profileration of useless launch options suggested on ProtonDB for a moment.
Of course y'all here are on GitHub, participating in actual discourse so I'm probably preaching to the choir here, but:

• -vulkan, -force-vulkan, or even better -force-vulcan do not exist, the game does not do vulkan, it does bad DX11 and worse DX12. No vulkan. Period. (again you can verify that by providing -vulkan and turning on the dxvk/vkd3d overlay/debug options, proving that point)
• you cannot set environment variables by providing them as arguments, that's not how it works (unless Proton goes really out of its way to be weird); as long as your launch options do not include %command% you will not be able to set PROTON_* to anything, especially not if you provide -vulkan before that. You can make it blatantly obvious what you're doing (providing execve(2) args) by using env PROTON_SET_GAME_DRIVE=1 %command% --whatever
• I still haven't seen -dx11 or -dx12 work either, so I'm also questioning everyone setting those

I've pushed gamedrive override to Proton along with a couple of other fixes where we weren't reporting information related to disk sizes properly in the functions the game is using. That is available in Proton Experimental ([bleeding-edge] branch, see https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding-edge for how to select it).

But thing is, I could not reproduce persistent stuttering even without that. It is possible though that it only happens on specific configurations, or somehow further in game (although I built a garage), so some chance filesystem-size related changes will be actually helpful (I see the game querying those parts, certain point of failure without gamedrive, just not the actual effect of that so far here, the game seems to create its cache data in the installation directory regardless).

Also, I am absolutely not reproducing long delays going into map / inventory / garage and back mentioned above. I tried on AMD and NVidia. I could observe occasional short stutter going across own territory boundary near base and while surfing around, but I reproduced the same on Windows on the same machines as well. I am running with all default, no configuration options anywhere, no DirectX switching from default in options.

I suggest to try with official Proton Experimental ( bleeding-edge branch), remove any startup options (besides PROTON_LOG=1 %command% if collecting default log for issue reporting, but for actual gameplay and performance measurement it is best not to have that). Prior to that backup and delete Proton prefix (especially if it was previously created or used with unofficial Proton distributions), and maybe also reinstall the game (manually wiping game installation directory after uninstall) if it was installed long ago: the game creates various caches in the game install directory, what if those got screwed up somehow or just became huge filled in with unused data.

Then, if the severe stutter is still reproducible with official Proton and everything clean (apart from first run before various caches are populated), the following information might be helpful:

• exact reproduction instruction, where to go to see that and what exactly to do (preferably within the area(s) available for complete newbies);
• hardware info: CPU & GPU info, disks configuration, where the game is installed (default / external drive, which filesystems).

UPDATE: also worth including in reporting any slightest customness used in setup, including some overlay layers not enabled by default, kernel version (and trying with the stock kernel if it is not) etc.

The best way to reproduce in Manibus Scenario it's to use the teleport system and travel to different areas. After 2-3 areas, go to Blackfell you should start seeing it getting increasingly slow ( you may need to level up the character to unlock the areas). The inventory lag it's visible if you have more than a couple items, I can see it drawing rows on by one and take a lot of time to close it

Distro:NixOS 25.05 (Warbler) (Unstable)
Kernel:6.13.5 (cachy, also attempted vanilla)
RAM:63 GB
GPU Driver:4.6 Mesa 25.0.1 (Git, also attempted stable)
GPU:AMD Radeon RX 7900 XT (radeonsi, navi31, LLVM 19.1.7, DRM 3.61, 6.13.5)
CPU:AMD Ryzen 9 7950X 16-Core

NTSync seems to make no difference (verified with MangoHUD)

@gofman incredible improvement! Deleted the prefix as requested, the game is basically the same as Windows, plus a few minor stutters that clear up. I sadly have been able to get my character into an infinite loading screen - no luck with a prefix reset once it has happened.

As for repro steps, this is what you're looking at: join a Manibus server that's 2-3 weeks in, this might be a challenge because you'd need an invite code if it's full (which you want because that increases the odds of a massive hive base). Ask in world chat if any hives have cool bases, and you'll almost certainly get a party invite - followed by a free TP to the player, just hit 'Y' on both prompts. Failing that: https://steamcommunity.com/id/exciting-burp

I am a developer, so I'll also have a go at PROTON_LOG.

Something I have noticed is that what should be identical textures are getting streamed in individually. I don't know if this is happening on Windows as well (I can't see what they do individually, too quick). Maybe the developers are relying on something that is deterministic on Windows but not Proton?

@gofman definitely feels like an improvement to the current 10.0 but I also see the performance degradation over time, especially after visiting asset dense areas.

I followed your instructions and went with the bleeding-edge build and activated Proton logging. Log file is attached. Second file optionally contains only unique lines and number of occurrences (in case it helps).

steam-2139460.tar.gz
steam-2139460_unique_lines.tar.gz

@MementoMortes try LD_PRELOAD="" %command%, the steam recording feature seems to degrade performance over time for me.

@MementoMortes try LD_PRELOAD="" %command%, the steam recording feature seems to degrade performance over time for me.

Steam recording is turned off globally for me in the settings and I do not notice any difference when using the parameter but thanks for the suggestion!

@MementoMortes try LD_PRELOAD="" %command%, the steam recording feature seems to degrade performance over time for me.

Steam recording is turned off globally for me in the settings and I do not notice any difference when using the parameter but thanks for the suggestion!

worth noting that LD_PRELOAD="" resolves a similar "time-bomb" performance degradation issue, but it is instead related to a steaminput bug that can cause stuttering over time that only appears when the game is receiving inputs (like moving the mouse).

the ld preload fix works great for that particular bug, and we can also confirm that the set game drive fix absolutely relieves the majority of the odd caching/streaming lag that is described in this thread.

Like @MementoMortes said, game has severe performance degradation, while working almost flawlessly at the start, after 30+ minutes becomes almost unplayable in heavy locations. Stuttering happens when I rotate the camera or ride a bike (seems like assets loading, I'm sure it's not the famous steam record bug). Whats interesting - once I get heavy stutters anywhere - they will be almost everywhere near any POIs.

What I've tried (without any result):

• various ingame settings
• dx11 / dx12
• experimental/ge/cachy proton, including deleting the prefix and Documents folder
• PROTON_SET_GAME_DRIVE=1 and LD_PRELOAD="" (had them almost always)
• PROTON_ENABLE_WAYLAND=1
• disabling FSync/ESync
• moving the game from btrfs to xfs (both different NVMEs)
• living at the outskirts of the map (lol), helps a lot being at the base (almost zero stuttering because of low amout of meshes/textures I guess), but doesn't save from this 'time bomb' at other locations after

How to reproduce: load into Manibus, wait for ~10-15 minutes, TP/walk to the Deadsville and drive to any near town (you have a bike as a reward for visiting it via main questline iirc), then try to rotate the camera.
Also driving is incredible heavy on its own, maybe it's the fastest way to get these stutters. Tested several times with a jeep and my friend - guaranteed stuttering after driving from one POI to another as a passenger, cured only by restarting the game.

Context - 7950x, 3080ti, 64gb ram, arch with cachy kernel, mangohud with fps lock.

Some conspiracy:
Game spawns 110+ (saw 240 once) tasks, has 200k+ records in lsof (and keep leaking with time, highest i've seen is 500k), some game's .npk files has ~150-200 entries in it. Really cursed, but I'm not sure if it's related.
Also this game has RAM leaking even on windows (proton too).

steam-2139460.tar.gz

I realised I haven't actually reported back after my latest testing.

game has severe performance degradation, while working almost flawlessly at the start, after 30+ minutes becomes almost unplayable in heavy locations

Pretty much this regardless of settings (as the comment prior already elaborated on).

Also this game has RAM leaking even on windows (proton too).

At least system memory being leaked sounds unlikely to cause this to me.
I've recently gotten my hands on some extra RAM bars (since I can't just use the abundance of ECC sticks we have lying around because [insert tangent on consumer hardware and ECC being arch enemies]) and even with free (i.e. not just available) memory I've run into the same problems.
Doesn't mean that there isn't some subtle interplay between systems at work that causes slowdowns in conjunction with leaks of course.

Game […] has 200k+ records in lsof (and keep leaking with time, highest i've seen is 500k), some game's .npk files has ~150-200 entries in it. Really cursed, but I'm not sure if it's related.

While I can't speak on the impact of a large number of file descriptors themselves, at least at this point I can pretty much confirm that it is definitely not a disk or filesystem issue itself.
I've been running the game straight from tmpfs multiple times now and even there it has the same issues of running butter smooth on startup and then quickly degrading into an unplayable mess.
Switching between btrfs/ext/xfs (or in my case cephfs/squashfs/tmpfs) should not have any notable impact, in case that helps narrowing down the issue.

@benaryorg I agree it's not RAM problem in the root, usually I have 40+gb available memory, it's just an indicator of developers incompetence (at least) in resource management.

Also there is IO cache on linux, when I've checked it during the game it was ~37gb large at my system, so imo no point in using tmpfs (but good idea to check anyway). During first stutters IO usage jumped high, but later they appeared even with zero IO activity (that cache I guess).

Also, yesterday traveled to the city in ~45lvl region, god how awful is that, performance degrades almost instantly, <10 fps in some houses. Game needs to be restarted after visiting that immediately. On the other hand, I could clear many dungeons in row without any issues at all.

anyone else having terrible cpu performance, 5700x3d and can barely break 60fps with a 9070 XT, already tried both dx11 and 12 no difference

I've been running nvidia-smi dmon while running the game and I am consistently seeing mclk and pclk going down 50% or more when those stutters appear ingame. Power consumption and temperature are also dropping at that time. So either something is throttling GPU for some reason or some part of the game is waiting for another resource (e.g. CPU, disk or network) which causes the GPU to clock down as it is waiting and too underutilized to keep the clock high.

Helo, it's me again with some more testing.

ReBAR

So first of all, can y'all please throw in some solid confirmation of whether or not Resizable BAR is enabled on your systems?
Something like this should do:

sudo lspci -v | grep -i 'memory at' | grep -Eo '\[[^]]+\]'

Which lists the sizes of all BARs, so if any of them is significantly above 256M or 512M (such as my card at 16G) that would confirm it.

New Card (B580)

I use env PROTON_SET_GAME_DRIVE=1 PROTON_ENABLE_NVAPI=0 PROTON_DISABLE_NVAPI=1 DXVK_FRAME_RATE=144 DXVK_HUD=devinfo,fps,frametimes,memory,gpuload,version,api,compiler %command% btw.

I ran my first tests on HDD this time because 80GiB just don't need to be on my limited SSD storage given that I saw barely any improvement throwing it even in tmpfs, and things were actually fine for a while, but having hit what seems like a bottleneck in loading in stuff I've copied it back over to tmpfs for now. I know it's not necessary, but I just want to make 100% sure that disk isn't the bottleneck for my testing.

However while still on HDD I already saw the game actually using ~3G of VRAM with occasionally using up to ~4G and reasonable unloading of textures 'n stuff (meaning after walking away from a lot of assets it dropped back down to ~3G) which makes sense to me. Still odd that it's just 4G at most (pretty much 4008M) when I have 16G available but eh.

With that said, the B580 (running regular off the shelf Flatpak Steam with mesa 25.1.3 at time of writing), with ReBAR confirmed to be on (16G BAR as per above) running off tmpfs does perform a little worse, I guess because it gets more assets thrown at it in a shorter span of time, however I can actually run the game at ~100fps on near-potato settings with occasional drops to 40 and stutters that give me a very brief slideshow at worst. However, the stutters in my testing are temporary. Whenever I teleport out of an area the framerate recovers, or even just standing still for a bit recovers the framerate, so I guess that's either CPU-bound or got something to do with the asset loading process causing churn.
VRAM usage for HDD and tmpfs are pretty much the same.

I am not ready to chalk that up to "Intel gud, NVidia bad", since ReBAR could've played a big role in this, with my old mainboard being a hot piece of garbage, however I feel like the drops and stutters are at least somewhat more consistent in I guess frametime pacing than with the old card, so it's still annoying when it happens, but at least the frames are coming in at a roughly regular rate so you can still aim somewhat. Though to be fair the stutters mostly happen when loading in something, so most of the time when I was actually playing the game as a shooter it was running smooth enough to play.

TL;DR

I feel like my current setup with the B580 has lower overall fps, however it manages to recover from stutters after visiting busy regions, and the stutter is much more manageable. The game runs reasonably well off of HDD, although it does benefit from SSD. All I can say is please check your ReBAR settings as stated above and report back on that because it may be indicative of something.

Also, kudos to Intel for actually being a reasonable choice for graphics cards at a time when NVidia and AMD are trying their hardest to make low-end graphics cards more expensive than a kidney or something while also playing shady PR games.

First thing with this game, I have managed to get rid of the majority of stuttering as an NVIDIA user (outside of occasional stuttery-ness) with PROTON_HIDE_NVIDIA_GPU=1 and PROTON_SET_GAME_DRIVE=1 (I also at one point set LD_PRELOAD="" but it didn't seem to make a huge difference) it's at least playable for the most part now and doesn't degrade over time. With the most recent patch however I have missing textures throughout the world. I can see grass, but I can't see the ground at all, and I can see through scenery. I can see my house just fine though. Haven't done a lot of other exploring but yeah currently there's a big texture problem with the latest update for me. I am going to try to remove the set game drive setting and see if rebuilding the shader cache fixes it, but yeah so far nothing I've tried in terms of verifying game integrity and removing the Once Human/Documents/{patch_ppk| baking_ppk} folders made zero difference. I also cleaned up the shader cache and rebuilt it by changing the graphics preset (which appears to have only really cleaned up the files in Once Human/Documents/res/runtime_temp), but it hasn't rectified the situation with the missing textures

For me, ground textures are missing for some reason, here is a video: https://vimeo.com/1098713386

[System]
OS: Ubuntu 25.04 Plucky Puffin
Arch: x86_64
Kernel: 6.16.0-061600rc4-generic
Desktop: ubuntu:GNOME
Display Server: x11

[CPU]
Vendor: AuthenticAMD
Model: AMD Ryzen 7 5700X 8-Core Processor
Physical cores: 8
Logical cores: 16

[Memory]
RAM: 30.3 GB
Swap: 23.1 GB

[Graphics]
Vendor: AMD
OpenGL Renderer: AMD Radeon Graphics (radeonsi, gfx1200, ACO, DRM 3.64, 6.16.0-061600rc4-generic)
OpenGL Version: 4.6 (Compatibility Profile) Mesa 25.2.0~git2507021732.c733f07378e~p~mesaaco13
OpenGL Core: 4.6 (Core Profile) Mesa 25.2.0~git2507021732.c733f07378e~p~mesaaco13
OpenGL ES: OpenGL ES 3.2 Mesa 25.2.0~git2507021732.c733f07378e~p~mesaaco13
Vulkan Version: 1.4.304
Vulkan Drivers: AMD Radeon Graphics (RADV GFX1200) (1.4.318)

For me, ground textures are missing for some reason, here is a video:

I have honestly given up with this mess of a game. Last this happened to me, clearing the game's internal shader cache worked - though I forget where it was actually stored.

Can confirm the textures are missing for me too, so this at least seems to be independent of hardware. If someone with an Nvidia card with proprietary drivers could confirm their state that'd be good.
With the assumption that Windows users still see the ground (which I feel the need to explicitly state), that'd give a hint on where in the compatibility this could originate from (i.e. potentially rule out mesa if it also happens with Nvidia).

Driver: Intel Mesa Intel(R) Graphics (BMG G21)
Driver Version: 4.6 (Compatibility Profile) Mesa 25.1.3 (git-ba95e694fe)

Can confirm the textures are missing for me too, so this at least seems to be independent of hardware. If someone with an Nvidia card with proprietary drivers could confirm their state that'd be good.

4090 with propietary 570.153.02 drivers. I see through the ground.

A fix that is working for me, to solve missing ground textures is:

Navigate to Once human install directory, find GraphicConfig.xlm (Once Human / Documents) Open the file and find the line that says: setting_enable_d3d12 change the value from 0 to 1. For me, it works for Rx 9060 xt.

https://imgur.com/RK65DHI

A fix that is working for me, to solve missing ground textures is:

Navigate to Once human install directory, find GraphicConfig.xlm (Once Human / Documents) Open the file and find the line that says: setting_enable_d3d12 change the value from 0 to 1. For me, it works for Rx 9060 xt.

https://imgur.com/RK65DHI

this worked for me, but i noted the game client also patched itself prior to me loading in...could be that netease fixed something?