Team Cherry have now officially released the second patch for Hollow Knight: Silksong, read on to find out everything that's changed and fixed.
With such a big release, there was bound to be numerous issues that need solving. We're likely to see patches come in for a while following the released on September 4th.
All the changes for Patch 2 are:
- Added Dithering effect option in Advanced video settings. Reduces colour banding but can slightly soften the appearance of foreground assets. Defaults to 'Off'.
- Updated Herald's Wish achievement description to clarify that players must both complete the wish and finish the game.
- Fixed Savage Beastfly in Far Fields sometimes remaining below the lava.
- Fixed rare cases of Shrine Guardian Seth getting out of bounds during battle.
- Fixed rare case of Second Sentinel knocking the player out of bounds during battle.
- Added catch to prevent Lugoli sometimes flying off screen and not returning during battle.
- Further reduced chance of Silk Snippers getting stuck out of bounds in Chapel of the Reaper battle.
- Fixed various instances of dying to bosses while killing them causing death sequences to play messily or out of sync.
- Fixed Shaman Binding into a bottom transition causing a softlock.
- Cocoon positions in some locations updated to prevent it spawning in inaccessible areas.
- Fixed Liquid Lacquer courier delivery not being accessible in Steel Soul mode.
- Fixed some NPCs not correctly playing cursed hint dialogues in certain instances.
- Fixed Pondcatcher Reed not being able to fly away after singing.
- Fixed Verdania memory orbs sometimes replaying layered screen-edge burst effects.
- Fixed the break counter not working for certain multihitter tools eg Conchcutter.
- Fixed Volt Filament damage multiplier not applying for certain Silk Skills.
- Fixed Cogflies and Wisps inappropriately targeting Skullwings.
- Fixed Cogflies incorrectly resetting their HP to full on scene change.
- Fixed Curveclaw always breaking on the first hit after being deflected.
- Fixed Plasmium Phial and Flea Brew sometimes not restoring as intended at benches.
- Various other smaller tweaks and fixes.
Also, fancy doing some modding? Want to make Hollow Knight: Silksong easier or need a few minor tweaks? We have a Hollow Knight: Silksong modding guide for Linux, SteamOS and Steam Deck!

Are they going to fix the native version? Quite an impressive number of gamebreaking bugs discussed in our Discord, and using Proton fixes them all. A lose-win... emoji
Really? It's been rock-solid for me. I think I have had one crash in about 40 hours of gameplay. No gamebeakin g bugs but maybe I'm just lucky? Or maybe it's because I have been playing on the Steam Deck?
Last edited by Brokatt on 22 Sep 2025 at 11:40 am UTC
Switching to Photon 10-4 fixed it and the game has been a lot easier when I'm not constantly sprinting into spikes.
Some thoughts and a question:
A "native Linux" label doesn't automatically mean fewer layers or better longevity. Unity's Linux export targets Vulkan/OpenGL and uses SDL2, but the core engine is proprietary. Proton is open source end-to-end, fixes classes of issues for many games at once, and can also be used independently of Steam (e.g. via Lutris). In practice, Proton's centrally maintained stack often delivers faster, broader fixes than a one-off proprietary Linux port.
Many of us still equate "native Linux" with fewer dependencies and better long-term stability. In reality, both paths are layered. The difference is who maintains those layers and how quickly fixes propagate when things break.
A one-off proprietary Linux port needs continuous care as distros, drivers, Wayland/X11, and ABIs evolve. Most studios cannot budget that care indefinitely. Proton's model is centralized, ongoing maintenance by design, with broad QA across titles and hardware. That is why long-standing issues in a "native" build can persist, while Proton get fixed within weeks or even days.
We assume native equals independence. But a proprietary engine plus changing system layers is not independence; it is just a different dependency set, with fewer possibilities for the community.
Unity’s open-source dependencies are compiled and linked together with Unity’s proprietary engine code. Many issues can’t be fixed by the community. You'd need changes inside the closed Unity runtime or the game project itself. Proton, by contrast, is OSS across the compatibility stack (Wine, DXVK, vkd3d-proton, FAudio, SDL2, etc.) and doesn't require modifying the game's Windows binary. In practice, the developer provide a working Windows build - they do almost always for commercial reasons.
So here’s the question: For closed-source commercial titles (not community-maintained OSS like 0 A.D.), what concrete benefits does a (proprietary) "native Linux" build deliver that outweigh Proton's faster fixes, wider hardware coverage, and transparent maintenance? If there are strong cases where a native Unity Linux export proves more robust over the long term, I'd genuinely like to see them.
Last edited by 1xok on 22 Sep 2025 at 6:10 pm UTC
A "native Linux" label doesn't automatically mean fewer layers or better longevity. Unity's Linux export targets Vulkan/OpenGL and uses SDL2, but the core engine is proprietary.
Something seems to be missing here...
Unity's Windows support targets DirectX (I guess), which by Proton is translated to Vulkan/OpenGL. So yes, for Unity exports, which you seem to be talking about, native Linux does mean fewer layers.
Many of us still equate "native Linux" with fewer dependencies and better long-term stability. In reality, both paths are layered. The difference is who maintains those layers and how quickly fixes propagate when things break.
Who maintains the .exe format or the DirectX Interface? Ah...
We assume native equals independence.
Never heard that. I assume native support means native support.
Unity’s open-source dependencies are compiled and linked together with Unity’s proprietary engine code. Many issues can’t be fixed by the community. You'd need changes inside the closed Unity runtime or the game project itself.
It was possible for the Unity problem I'm actually aware of though, a strange interaction between a 10 year old Unity weakness and Steam using CEF in a certain way 10 years later.
(Good luck btw for getting a bug fixed for a Windows version of a ten years old game...)
https://ein-eike.de/2025/06/05/fix-for-old-unity-games-for-linux-not-starting-anymore/ [External Link]
So here’s the question: For closed-source commercial titles (not community-maintained OSS like 0 A.D.), what concrete benefits does a (proprietary) "native Linux" build deliver that outweigh Proton's faster fixes, wider hardware coverage, and transparent maintenance?
For the vast majority of my Linux native games, I don't need fixes, have never had a problem with hardware coverage and have the most transparent OS-to-OS translation layer possible: none. So, I don't see all the greatness you want to have outweighed in the first place.
What do you get by having a native version: Your system is supported, which seems to mean nothing for you, but much for me. And you are entitled to support by the developers. We lately had a case in the Steam forums again where somebody was told that the devs don't care that their game stopped working with Proton, they only care about Windows.
https://steamcommunity.com/app/221410/discussions/0/601915789280286287/ [External Link]
(Yes, there's bad support for Linux version as well sometimes. And for Windows versions used on Windows.)
Last edited by Eike on 22 Sep 2025 at 7:15 pm UTC
These sentences feel strangely disconnected. Unity's Windows support targets DirectX (I guess), which by Proton is translated to Vulkan/OpenGL. So yes, for Unity exports, which you seem to be talking about, native Linux does mean fewer layers.
Yes, I actually didn't want to say that. I should have used the word better instead of fewer.
The Unity Vulkan code is simply broken and leads to something like this on my and other systems. This is my system, I made the screenshot myself:
https://steamcommunity.com/sharedfiles/filedetails/?id=3547585264 [External Link]
The error has existed for years now.
https://www.reddit.com/r/HollowKnight/comments/wg2f8r/graphics_issue_on_steam_deck [External Link]
I have very little hope that it will be fixed. Hollow Knight is my favorite game, and I've been playing it for a long time. Until around 2021, I had hardly any problems with the Linux build. But now I'm having a lot. It all started when they switched the game to Vulkan. Maybe Unity would be better off using DXVK for its Vulkan path and basing the Linux build on the Windows version.
What do you get by having a native version: Your system is supported, which seems to mean nothing for you, but much for me.
That definitely means something to me. Even so: We don't need to view our system through rose-tinted glasses. Linux has strengths and weaknesses. Backward compatibility isn't one of its strengths. Even glibc likes to break userland. The typical scenarios in the OSS space are covered. If something breaks, it's quickly repaired. But when it comes to closed sources games, nobody cares.
We can do that though:Thanks for the tip. I'll keep your page in mind.
But: You can see for yourself that you fix it yourself.
As a technically inclined person, I think that's great. But as a gamer, I'd probably sit in front of my PS4 at some point. Hollow Knight is, for me, an artistic experience. So when I notice reflections in the Linux build of Silksong where there shouldn’t be any, the enjoyment is gone.
I simply don't trust native Linux builds from Team Cherry anymore because this developer obviously don't really test them. But I'm still a big Team Cherry fan. Am I crazy? Maybe. These people earn millions but apparently it's not enough for a proper Linux build.
With a native Linux build, I'm dependent on the game's developer. With Proton, I'm usually dependent on Valve and the community. Many game developers are simply terrible at their Linux builds. They just click the Linux button in their engine without adequately testing the resulting output. That's my personal impression.
Proton is the solution for me in this and other cases. Especially since I simply couldn't play some of my favorite games without Proton. Elite: Dangerous.
I hope you can understand me. I think I do the same in reverse.
Last edited by 1xok on 22 Sep 2025 at 8:56 pm UTC