Originally posted by bidulless:

if i partially remind me , we have access to our cloud save trought our client ( top menu/help/steam support/somewhere inside ) and if the cloud is applying zstd on save , i guess we will be able to use 7zip with the addition of "codecs"

https://github.com/mcmilk/7-Zip-zstd/releases/tag/v24.09-v1.5.7-R1

It's here: https://steamhost.cn/account/remotestorage
These files download as expected - the file is decompressed before Valve serves it to your PC as a download. This could be used as workaround later, if needed.

Also, for anyone who is worried about losing access to their cloud saves, you can use a tool like this:
github dot com/pyscsd/steamCloudSaveDownloaderGUI
to batch download the cloud save files for all your Steam games. This tool's platform and interface sucks but it will automatically download all your cloud saves, which is better than manually downloading 3000 files from the steam website by hand.

Originally posted by bidulless:

what i hope in our issue, it that it won't be apply to cloud save and dl ...
because, it will be a bit more annoying ...

This concerns me a lot. If Valve starts converting all our cloud saves into zstd-compressed payloads, then our clients won't be able to download them back after uploading them to Valve. That would be another extreme problem.

Originally posted by bidulless:

glad i've helped you a bit on analyzing our issue xd

Yeah, thanks adding what you know. Maybe there will be a proper solution to all this somewhere down the road.

Yeah... when a game is already installed, steam only downloads and applies a delta patch, instead of full versions of each affected file, and that really complicates things. That's where the decryption & decompression (zstd) in one whole go as a stream is likely how it works and makes external manipulation of the process almost impossible.

In this case, forcing a full redownload of all files (or at least the affected ones), could be a way to still make use of a potential tool like the one I talked about yesterday.

It is censored. The information is not available as intended and most of the time it stays like that permanently. One of your own comments from a week ago on page 2 is censored right now. You really shouldn't make excuses for Valve while they're raping you... I certainly don't.

I didn't know about the quote trick, though, that is pretty useful, thanks. I will have to remember that and I hope it stays working.

We all really would benefit from a better place to talk about these things that is less hostile and censored.

Oh wow my second-to-last comment was censored too?

Here it is as an image: https://i.postimg.cc/MZ0S4FQv/censored-2.png


Here is what the last 4 comments of the thread look like: https://i.postimg.cc/RFrkp7C7/censored-3.png
(Noting this for posterity that they have been censored by Valve)

My last comment, which simply noted that my second-to-last comment was censored, is also censored. Fuck Valve.

Steam censored your last comment
postimg dot cc/G9tPcRfR

SteamPipe initially splits each file into roughly one megabyte (MB) chunks. Each chunk is then compressed and encrypted before being upload to the Steam content-delivery system. They remain compressed and encrypted until downloaded by each client, where they are decrypted and expanded and placed in the necessary file location(s).
From: partner dot steamgames dot com/doc/sdk/uploading

This is a huge problem. Decryption and decompression probably(?) happen in tandem while the client is downloading the chunks, in a stream, as opposed to being atomic with files on-disk. If that's true, then the entire "do zstd decompression ourselves" concept I put forth in my message last night won't work. Damn.

Originally posted by bidulless:

what i still do not understand is why some current updates does not use it when , in fact , they should because dev does not have any control on which compression scheme to use
on my side nearly all games update are sadly affected now ( on the 20+ games i have allready setup ) and it was progressiv

Have you tried downloading a beta branch of any of your games? Try it with gmod if you have that, or any other game that has 1) a beta branch, and 2) the beta was updated recently. More data points are always useful.

Originally posted by bidulless:

not really sur if all this efforts are necessary imo because we allready have 2 working and easy solutions for old steam client :
using steamcmd or depotdownloader

If I understand the process right (correct me if I'm wrong), these ^ are not easy, and they are not solutions. They are slow workarounds.

- Option A: Steam downloads game update like normal. Done.
- Option B: Steam starts to download game update, update fails, you have to manually move all existing game files so Steam wont find them, then uninstall game (or leave it and just validate files later), then interrupt whatever you were doing to 1) exit Steam, 2) launch other steam or steamcmd, 3) type commands to download game, 4) wait for download, 5) close other steam/steamcmd, then manually move all downloaded + updated/patched-over files back to original location, then relaunch older steam client, then install game (or validate files), then wait for file discovery (long time for big game), then you can finally play game. Multiply all this pain by how large the game's files are (twice).

I like Option A a lot more than Option B.

I don't have time to keep throwing away needless hours of my life to Valve for absolutely nothing in return, and especially doing that by manually updating all my of games every day is insane. That amount of time slavery is beyond unacceptable.

A somewhat better version of Option B, which I'm going to try setting up for myself, is to install a post March 2025 Steam client side-by-side, add my library folders to it, and use it to update games as needed, like I previously did with the Oct 2 2019 client and the first year of the half-vgui half-cancer clients. This should reduce the number of manual steps and absurd wasted time by half, maybe, I hope.

Originally posted by bidulless:

it seems valve does not recompress the whole game but only the new files ( and it's anought to failed ...) and the good point is that valve does not seems to recompress old games without update

I've noticed this in my experience as well. If I download games that have not been updated in years, they download fine. However, if the game has any Steamworks Common Redistributables dependencies in its depots, then the game download initially fails because the Steamworks Common Redistributables download fails (because zstd is being used on the entire(?) Steamworks Common Redistributables depot now). Clearing download cache and resuming the game download after the client restarts fixes the issue and allows the game to finish downloading properly. (Noting this here for anyone who has yet to discover this trick.)

However, not all new game updates are using zstd depot chunks.
Example: the x86-64 beta branch of Garry's Mod just had two updates today (2025-07-31). This update successfully downloaded and installed using my May 2023 Steam client. The previous x86-64 branch update on 2025-07-25 also succeeded under my May 2023 client. So have all other x86-64 branch game updates succeeded since the zstd introduction in March when installing using my May 2023 client.
This must mean either: 1) game publishers can choose to opt-in to using zstd on their games, which I think is unlikely, or 2) Valve is only forcing zstd depot chunk compression on updates for select depot chunks - maybe only the main game branch gets zstd? (beta branches still get lzma)
This is worth noting and potentially useful, especially for games like gmod where the beta branches are the best way to play the game.

My suspicion is that zstd support can be added to older clients without touching CEF at all (which is good - because as you note, M86 in the half-vgui clients is far less cancerous than M126 in the pure cancer clients).

New idea: If we cannot get the necessary zstd interface into the client itself (into steamclient.dll or into process memory some other way), then maybe we can utilize the on-disk cache Steam uses when downloading game files. If Steam places the compressed (by zstd) files into the steamapps/downloading/... folder, we may be able to intercept those files, suspend Steam somehow, do the zstd decompression ourselves (with our own program), and then allow Steam access to the file again. Depending on how the Steam client may or may not be controllable during this download->decompress->relocate file procedure, this could be a way to decompress zstd chunks without ever needing to modify the Steam client itself.

Ideally, it'd go like this:
1. Steam writes a full zstd compressed chunk (header to footer) to steamapps/downloading/... and then begins its decompression process.
2. Our external program is waiting for this moment and blocks Steam's access to write to the chunk file.
2a. Ideally, this will stall the Steam client indefinitely, until we unblock its access to the file. The client probably has a timeout or similar failsafe, however (e.g. the "CONTENT FILE LOCKED" failure code, perhaps), which could make this difficult.
3. Our external program decompresses the chunk and places the decompressed output file wherever Steam is expecting it (is it in-place? it is to a new file? idk). The decompressed output file is locked from writing so that Steam won't clobber it with its garbage output from failing to decompress the zstd chunk itself.
4. Our external program unblocks Steam's access to the compressed chunk file.
5. Steam recognizes (how?) that the decompressed chunk is completed & available and moves it to the next stage of the install process (perhaps copying to final destination, perhaps applying patch to existing files in final destination, etc).

This ^ is all theory. I have no idea exactly how the client does the whole game download & install procedure, but perhaps something like the above is possible.

Other possible problems include:
1. Racing against Steam. We may have to decompress the zstd chunk before Steam finishes producing its garbage lzma decompress. Thankfully, zstd is supposed to be many times faster to decompress than lzma, so assuming equal CPU resources go to Steam and our external program, we should beat Steam in this race every time.
2. Complex zstd patches. I don't know how Steam stores and delivers updates exactly. Perhaps one of the ways is to supply a zstd-compressed patch that is decompressed & applied to existing game files simultaneously, through streams instead of atomic file operations, in which case the only way to make this succeed is to supply the older Steam clients with the zstd decompression interface.
3. And more probably.

---

On the VAC note, I've personally never heard of anyone getting VAC banned for enabling VxKex only on steamwebhelper.exe, and I know a couple people who have been using VxKex like that for a bit now and have not had problems so far. I'm testing this out myself now, so as time goes on I can contribute my experiences using it that way.

Also, there's Valve's public statement about how VAC operates:

NOTE: VAC only attempts to detect cheats reported by the developer. Valve does not actively seek out cheats either automatically or through manual digging.

From: partner dot steamgames dot com/doc/features/anticheat

This makes sense, is believable, and suggests maybe (but does not explicitly state) that Valve, at their own discretion, maybe does not consider certain forms of manipulation of the Steam client processes (e.g. appverifier DLLs) to be cheating and thus does not employ a detection for them. That's a complete assumption, however, and also because this is public information on a topic which is best controlled by censorship, it is foolish to trust Valve's statement about this without proof.

Adding some notes that may be useful later.

steamclient.dll appears to contain a zstd compression routine. Perhaps this dll is also where the decompression routine lies (not clear yet), given that Valve uses their own zstd payload data structure, and their own zstd library to compress/decompress, instead of solely using the bare compressed data and the standard zstd library. It seems that CEF is not being used to decompress Valve's custom zstd data. Or maybe the Valve payload format is a mere wrapper which is stripped away for CEF to chew on? (though that seems unlikely). Unless the Valve servers are sending data around with zstd markers in the headers and the client relies on those markers, it seems most likely that CEF is completely unrelated to the client's ability to decompress zstd-compressed data.

steamclient.dll contains strings "zstd_valve" and "zstd_dict_valve" that look like type names, again suggesting Valve has their own zstd implementation and/or a serious custom payload format, beyond normal zstd.

The steamclient.dll I was looking at is from steamcmd (release circa 2025-06-27), which ofc has no CEF and therefore has to be able to decompress zstd payloads without CEF. This further suggests the client's version of CEF has no bearing on the Steam client's actual ability to decompress zstd depot chunks.

The SteamKit project had to solve the zstd decompression problem themselves earlier in the year. Their work may contain useful clues, such as the "VSZa" magic header string constant, which is present in zstd-aware versions of steamclient.dll.
See:
github dot com/SteamRE/SteamKit/issues/1503
github dot com/SteamRE/SteamKit/pull/1504
github dot com/ppker/SteamKit/commit/2edc80b96e96dd231df3be996b269aec10144f01

All this reminds me of the "use a newer steamclient.dll in an older Steam client" concept from years ago, during the initial SteamAPI v21 turmoil. Perhaps revisiting this concept would be a good idea. Maybe we could shoehorn the steamclient.dll from steamcmd into the older clients, or redirect certain newer interfaces and features (like zstd) from the older client's native steamclient.dll version to a newer one.