Instale o Steam
iniciar sessão
|
idioma
简体中文 (Chinês simplificado)
繁體中文 (Chinês tradicional)
日本語 (Japonês)
한국어 (Coreano)
ไทย (Tailandês)
Български (Búlgaro)
Čeština (Tcheco)
Dansk (Dinamarquês)
Deutsch (Alemão)
English (Inglês)
Español-España (Espanhol — Espanha)
Español-Latinoamérica (Espanhol — América Latina)
Ελληνικά (Grego)
Français (Francês)
Italiano (Italiano)
Bahasa Indonesia (Indonésio)
Magyar (Húngaro)
Nederlands (Holandês)
Norsk (Norueguês)
Polski (Polonês)
Português (Portugal)
Română (Romeno)
Русский (Russo)
Suomi (Finlandês)
Svenska (Sueco)
Türkçe (Turco)
Tiếng Việt (Vietnamita)
Українська (Ucraniano)
Relatar um problema com a tradução
Regras e diretrizes para discussões
Denunciar esta mensagem
A USB drive works fine for games as long as it is USB 2 or 3. Just expand, the bonus being you have a removable drive with all your games when you upgrade etc. On top of better performance on the OS.
On 446gig OS drive I have 277 free gigs.
On my game drive I have 3.63TBs with 1.5TB free.
https://steamcommunity.com/sharedfiles/filedetails/?id=2903570893
What Steam does:
In the more pessimistic cases where the patch itself is almost as big as the file it is patching - which is not unthinkable given encrypted or compressed packed assets are very popular - that means you have three or four copies of the whole thing on disk:
the original file; the patch itself; the temporary copy; and - depending on whether Valve update the temporary copy in place or not - the output of the patching operation.
What they could instead do:
(Atomic move operation: takes no time. No file data written to disk; only updating the lookup tables.)
(Filesystem can pre-allocate without zero-writes, costing effectively no time to perform, and can then perform a streamed contiguous write for max throughput.)
And look: suddenly you only need enough disk space for the patch; the original installation; and the biggest file that is being patched. This is still a deterministic metric the patch process can pre-compute and thus it can still warn the user if they are low on disk-space.
Yes; this process doesn't keep a full safety copy for when the patch process fails.
But you know what? Why does Steam do that when it doesn't allow you to start an unpatched copy anyway ??
Once the local client has become aware of an update, it demands that it is applied. So even if you could roll back to the unpatched situation, you'd still not be allowed to start the game.
And also: in the edge case that the patch fails, the patcher could automatically use the implementation of the "verify files" procedure under the hood and reacquire the broken files in full instead.
As is the case with many features in Steam, the developers didn't think it through properly; rushed out something semi-working; and then called it a day to never look back on actually fixing it, instead only being interested in the new-and-shiny.
This is also literally why the client is adopting heavy-weight Chromium web views everywhere: the Steam client developers were fed up maintaining the existing UI framework.
So instead, they deliver something half-broken that e.g. causes people to no longer be able to log in and use Steam at all.
Wonderful, ain't it?
It's how the game is built's fault. Using large Packed archives the "patcher" have to unpack to get to the file(s) needing the patch, and then pack it back up again meaning you need the free HDD space of the Game +the copy of the game +temp space for the action.
Lets take a new game, High on Life. To patch that you need at least 50GB of free HDD (size of game) OR you need ~40 -50GB free for the PAK file alone, depending on what is needing the patch. (and if it is patched from Steam or "manually).
How steam patches: Copying the game to ..\Downloads\<some number>, apply the patch to the needed files, Moves the game back to install folder.
"Manual": Applies the patch directly to files in install folder for the "loos files", unpack the packed files and apply patch, packs it back up, done. (VERY simplified)
Both methods needs approx. the games install size free.
If you're wondering, I was referring to:
This isn't really what Steam does. Or, at least, it's a very incomplete picture of what Steam does. One issue is there's at least two methods Steam uses to do patches, using both at once in many cases; for lack of better names, the 'original Steampipe' method, and a more-recent 'delta' method. Unfortunately, I don't have an awesome grasp on what the 'delta' method does, so I might get things a bit wrong with the description of it.
The 'original Steampipe' method looks like this:
That is *really* similar to your suggested operations, just in a slightly different order. At most, this only occupies extra temporary storage of the size of the changed files. As an example, I just observed an update for "Cult of the Lamb" and it created about 184 MB in temporary files, with the game itself being about 1 GB.
I think Steam also has a single file mode, which I've seen mentioned in the Steam/logs/content_log.txt file, but I didn't observe what it was doing as it happened so I don't know exactly what it does, but, if I had to guess based on the name: it does the same process as above but operates file-by-file so it can work with a lower temporary file overhead, and only kicks in when there's limited space for temporary storage.
The significant unknown (to me, anyway) is how exactly the 'delta' method works. You can tell when an update is using 'delta' because in Steam/logs/content_log.txt, the update will say something like "AppID 250900 update started : download 0/6371904, store 0/0, reuse 0/523979975, delta 0/20960454, stage 0/535946143" with 'delta' having actual numbers rather than just having "delta 0/0". (Sidebar: 'reuse' means amount copied from old install, 'store' is from a backup or retail disc, and 'stage' is amount written to the temporary folder)
I know that 'delta' is based on creating very optimal patches between specific pairs of game versions, and they built it to deal with the issue where some games didn't patch very optimally with the basic Steampipe system because of their on-disk data layout and so downloaded more than they really needed to. I think it only kicks in where the 'basic Steampipe' system leads to overly-large download sizes.
If I was going to reconcile our observations about the systems, I would guess that what you're describing might be the 'delta' system, if it works by downloading a single large patch file and then applying it.
I guess the irony here is that the system that (might) be badly-behaved, the 'delta' system, is the result of them looking back at the patching system to try to fix a perceived problem with it.
Yeah. It does irritate me a bit that people rush to blame developers. There *are* things which developers can do which inhibit the ability of Steam to patch efficiently, and Steam's documentation does advise against these things. Developers really should avoid:
The last two in particular basically make patching impossible; you have to just download from scratch. No patching algorithm can ever make updating encrypted data a patch rather than a full redownload. That's just something the developer just has to stop doing to get a sensible patch. But what Steam can do is design the algorithm, that's entirely within their control, to not behave pathologically in those circumstances.
Steam puts this in the UI it tells you both how much it’s downloading as well as how much local files need patching. I mean how much more do you want?
And yes; I may have oversimplified a bit when trying to keep things terse and understandable for lay men. You're right about that.
Like you said: the actual patching algorithm is under Valve's control. They should have the power to avoid pathological cases with compressed or encrypted files. A trivial approach: if the patch data for a file is 90+% the size of the original file, just do a full download of the file itself and don't patch client side.
There is also no reason for them to have designed it around a rigid always-in-use safety copy, when that could've been easily conditionalized on the actual '@AllowSkipGameUpdate' flag value. Something that never even made it to public release, but Valve just didn't care to clean up and optimize the updater afterwards.
Because who doesn't have a spare additional 40+ GB lying around on their SSD, right?
That other consumers blame the consumers makes me laugh how about getting actual full releases that you dont have to patch day one or every damn week. Nowadays it seems like every title is a early access game at this point,
I don't think it shows any temp file sizes just install progress download and write to disk
Uh no it shows the actual download size and file size......
https://steamcommunity.com/sharedfiles/filedetails/?id=2780434332
The numbers are there. yes there is the overall % indicator, but the actual download size and local disk usage numbers in actual numbers also exists.