Dowlphwin Apr 14, 2016 @ 7:02am
Centralized redist repository
I should have written this in Suggestions in the first place, because it got moved into the monster complain/inquiry thread that will have extremely short-lived communication and won't allow talk about the actual feature I suggested let alone make it likely that Valve takes notice.
So...

Valve could have actually used the special nature of Steam game versions here, long ago, but no, still we have a giant waste of local storage space and internet bandwidth.
Whatever amount of total data you need to download for the recently security-updated redists, that is close to the amount of storage space wasted on your computer.

Just imagine: Not only are those redists the same for all games anyway, but you don't even have to install them. Most games contain ~100 MB (often more) of stuff they merely need to check and see that you already have that stuff installed either from other games or because it's pretty much omnipresent in any actively used Windows installation.

Wouldn't it be great if a Steam version of a game would simply access those redists from a shared local storage and not download it if it finds it already present there or if it's already installed in the system?

So a Steam release game would be designed to tell Steam: "I need DirectX 10". Steam then goes: "This way please, I already got it". And the game won't download it again and when finished downloading itself runs the installer and (naturally) realized DirectX 10 is already installed. Or more elegantly that could be communicated right-away before the game even tries to run the DirectX installer.
Last edited by Dowlphwin; Apr 14, 2016 @ 7:03am
< >
Showing 1-15 of 21 comments
Satoru Apr 14, 2016 @ 7:06am 
Note that many older games require a very specific version of directx depending on how they were compiled. Which mean a central repo is going t have a ton of redudant versions of directx because some game somewhere needs it.

The only approved way to distribute directx is to distribute the entire installer too.
Dowlphwin Apr 14, 2016 @ 7:11am 
No, I'm pretty sure especially DirectX is backwards-compatible. There's only the latest version being installed. Other redists that require special versions (Visual C, DotNet) are available in all those anyway. There's a handful of them.
The space saving would (evidently) be worth it. My suggestion is about avoiding redundancy, so if one game has older ones, you'd have those anyway. It's always an advantage.

As a side note, for some reason, now that I ran the updates, I only had the 0-bytes updates and nothing else, but that's for the other thread to discuss there. If necessary I will mention any updates on that here. This suggestion of mine was made based on reports from other people. I also still have all the excess redists in my game data.
Last edited by Dowlphwin; Apr 14, 2016 @ 7:24am
cinedine Apr 14, 2016 @ 8:00am 
You can delete them after install. The only problem I encoured so far is when I verified the local data which will download it again.

And never assume everything you need is installed anyway. I had quite a few software installations which required a certain DLL which of course was not installed anywhere.
Dowlphwin Apr 14, 2016 @ 9:30am 
Yeah, you have to run every game you get once and then avoid file verification, and then something like this security update occurs and you curse because you probably have to run every game again, after it has downloaded the redists again.
So not a proper solution, not even a good workaround.
There's generally a lot of sloppiness with wasting IT resources in online software distribution.
Last edited by Dowlphwin; Apr 14, 2016 @ 9:31am
aiusepsi Apr 15, 2016 @ 7:27am 
Originally posted by Satoru:
Note that many older games require a very specific version of directx depending on how they were compiled. Which mean a central repo is going t have a ton of redudant versions of directx because some game somewhere needs it.
OK, but then the worse case scenario is the central repo has as much in it as the individual games would have had. That's a very benign worst-case! Best case, you save a bunch of space because the installers that really are the same get deduplicated.

As it is, Steam already supports the inclusion of common redistributables (which is probably what happened with the 0kb update incident; a configuration on one of the common redistributables got changed) so deduplicating those would be a clear benefit.
Start_Running Apr 15, 2016 @ 8:07am 
That was tried at one point. It didn't work. Developers for the sake of assurance prefer to install the stuff they know their game needs with the install. It's better than having clients complaining that they get missing DLL file messages like they did in the old days with the vbrun libraries.

COnsidering how cheap storage space is ... it's the better of two choices
aiusepsi Apr 15, 2016 @ 8:15am 
Originally posted by Start_Running:
That was tried at one point. It didn't work. Developers for the sake of assurance prefer to install the stuff they know their game needs with the install. It's better than having clients complaining that they get missing DLL file messages like they did in the old days with the vbrun libraries.

COnsidering how cheap storage space is ... it's the better of two choices
You're conflating unrelated things.

Steam already provides a set of common redistributables (see here: https://partner.steamgames.com/documentation/common_redist for the documentation on that) which developers can opt-in to in their Steamworks configuration, and Steam handles the details of installing those when you launch the game. Steam could be set up to deduplicate those installers by putting each one into a common place rather than duplicating them across each game. From the game's point of view it would be transparent. The game would still get the stuff it needs installed installed.

If a game needs something that isn't on Steam's list of common redistributables, then the game can still provide the installer file itself, and give Steam the script to install it, as is done with custom redistributables today.
Last edited by aiusepsi; Apr 15, 2016 @ 8:15am
Start_Running Apr 15, 2016 @ 9:28am 
Originally posted by aiusepsi:
Originally posted by Start_Running:
That was tried at one point. It didn't work. Developers for the sake of assurance prefer to install the stuff they know their game needs with the install. It's better than having clients complaining that they get missing DLL file messages like they did in the old days with the vbrun libraries.

COnsidering how cheap storage space is ... it's the better of two choices
You're conflating unrelated things.

Steam already provides a set of common redistributables (see here: https://partner.steamgames.com/documentation/common_redist for the documentation on that) which developers can opt-in to in their Steamworks configuration, and Steam handles the details of installing those when you launch the game. Steam could be set up to deduplicate those installers by putting each one into a common place rather than duplicating them across each game. From the game's point of view it would be transparent. The game would still get the stuff it needs installed installed.

If a game needs something that isn't on Steam's list of common redistributables, then the game can still provide the installer file itself, and give Steam the script to install it, as is done with custom redistributables today.

Far simpler for the developer to assume it isn't there and install it anyway.
aiusepsi Apr 15, 2016 @ 9:39am 
Originally posted by Start_Running:
Far simpler for the developer to assume it isn't there and install it anyway.
Yes. They can try to install it again from Steam's central repository of installers.

Sure, you could say, "what if Steam screws up and doesn't download the installer the game asked for?". Well, that's true. But what if Steam screws up and doesn't download the game's executable? I think we can take it as given that Steam will download the right files.

Also: I really can't overstate this enough: plenty of games already rely on Steam to provide the right installer files. Look at e.g. https://steamdb.info/app/296470/depots/

When the game launches for the first time, it triggers a Steam install script to install these things. If a game bundles a custom dependency / redist, the dev provides a Steam install script for those. These aren't new mechanisms: this is what happens today!
Last edited by aiusepsi; Apr 15, 2016 @ 9:45am
Start_Running Apr 15, 2016 @ 9:46am 
Originally posted by aiusepsi:
Originally posted by Start_Running:
Far simpler for the developer to assume it isn't there and install it anyway.
Yes. They can try to install it again from Steam's central repository of installers.

They won't. THey know what repositories there game was built around and like it or not they don't like to take chances on these things. Installing there own will always result in things being where they need to be. DOing otherwise.. inserts chance for failure.. Besides it's not like the old days when HD space was expensive.
aiusepsi Apr 15, 2016 @ 9:48am 
Originally posted by Start_Running:
They won't. THey know what repositories there game was built around and like it or not they don't like to take chances on these things. Installing there own will always result in things being where they need to be. DOing otherwise.. inserts chance for failure.. Besides it's not like the old days when HD space was expensive.
I'm gonna assume you didn't see my edit:

"Also: I really can't overstate this enough: plenty of games already rely on Steam to provide the right installer files. Look at e.g. https://steamdb.info/app/296470/depots/ "

Seriously, sign the agreement and read the Steamworks docs: https://partner.steamgames.com/documentation/common_redist
https://partner.steamgames.com/documentation/installscript
Last edited by aiusepsi; Apr 15, 2016 @ 9:50am
Dowlphwin Apr 15, 2016 @ 2:51pm 
So if I understand correctly, the reason why the redist duplicates issue exists is because the devs don't know about that central storage or refuse to comply with it?
In that case the recent oddity with the update flood would show the widespread refulsal of Steam game devs to make use of it.
So exactly what I suggested already exists? Or is it somewhat different?

I noticed in various other cases how some devs don't seem to use Steam right for the publishing, either because of pure ignorance or because communication of features is bad or because the features don't work properly. (One example would be game type flagging "Free" vs. "Free to Play" and what the choice entails, in part regarding trading cards.)
Last edited by Dowlphwin; Apr 15, 2016 @ 2:53pm
Start_Running Apr 15, 2016 @ 3:15pm 
Originally posted by Dandowlion:
So if I understand correctly, the reason why the redist duplicates issue exists is because the devs don't know about that central storage or refuse to comply with it?
Not a matter of refusal just a matter of required certainty. It's just simpler to distribute themselves than assume someone else did. Also remember for many of these games the isntallers aren't specifically steam. You'll find the same installers used for origin, gog etc.

In that case the recent oddity with the update flood would show the widespread refulsal of Steam game devs to make use of it.
So exactly what I suggested already exists? Or is it somewhat different?

Even if it existed.. most PC devs would not use it. Again... certainty. They know that the files they distribute it with, will properly run the game as intended.

Dowlphwin Apr 15, 2016 @ 3:27pm 
They'd know the same with Steam's own files, because they're identical and common.
As auisepsi pointed out, any error that could come from using Steam's redists could also come from distributing the game itself on Steam.
Start_Running Apr 15, 2016 @ 4:41pm 
Originally posted by Dandowlion:
They'd know the same with Steam's own files, because they're identical and common.
As auisepsi pointed out, any error that could come from using Steam's redists could also come from distributing the game itself on Steam.

Steams redists can change. And again, Steam isn't the only distribution point for the installers.
< >
Showing 1-15 of 21 comments
Per page: 1530 50

Date Posted: Apr 14, 2016 @ 7:02am
Posts: 21