Closed mirh closed 1 year ago
On the games that do need a first time setup, there's a installscript_sdk.vdf
file in their install directory. That details what should be installed, but I don't see any flag to determine it has already been ran.
Maybe it works by scanning the registry? Deleting a game's prefix for instance (which is effectively deleting its "Windows installation") makes the script re-run again. It must be stored somewhere in there.
Nope, I'm not talking about steam knowing whatever redists were already installed (which yes, it is recorded in the registry).
If you follow my first link above, you see there must be some internal variable tracking whether the game was launched (or at least whether it has gone past the "runasadmin.vdf
" phase) at least once.
I'll grant this has actually more of a theoretical utility than practical, but still.. even after two years I'm still pretty salty about the absolute lack of documentation on the matter.
Ok I'm actually pretty stupid. Yes, steam does remember "having already run once". But it's nothing permanent eventually, if you restart the client you'll be back to square one.
installscript.vdf
will run with all modifications of the world up to that, and then it will start to be rejected if it's not restored at least temporarily.
And for the inattentive eye, lack of issues in the long run (since the thing is effectively dead) is interpreted as "continuing to work".
Well, I don't really know what you're talking about, but glad you figured it out.
If you have just downloaded a game, installscript modifications won't work right off the bat because you need to run the vanilla thing at least once for the edited file not to be rejected.
I presumed this was related to some "first installation done, don't care about signature anymore" flag that gets toggled somewhere (because I was in a haste and pissed back then, and what else could make sense?) but there's no such a thing actually.
The moment you restart Steam, it will stop again to read the modded installscript (until the next "clean run" at least).
The difference doesn't really matter if your intent was just "neutralizing" harmful commands that you didn't want to have execute on every launch, but on the other hand if your aim was to positively always run something that wouldn't fly (thankfully your tool is exactly one of the possible workarounds in this case).
EDIT: ok I think I did eventually found the logics behind.. the steam service (presumably) keeps cached a whitelist of the first level of HKLM\Software
keys that signed installscripts have written to
Anyway on top of that I just further discovered another implementation quirk (documented nowhere else that I know).
If appinfo contains the installscriptoverride
config property, the game won't even be shipping the installscript as a file!
Or better yet, you do eventually get one where expected at install time, but this gets delivered straight out of the "install" section of appinfo (and any attempt of touching it on disk will be nullified, since it gets overridden every time).
For the moment I'm just throwing this out for the records, but perhaps in some future it might be of interest for the editor.
Hmm, so how does the override works? Do you need to put the contents of the override in the appinfo file itself? Or can you set a path and have it load that file? That could be interesting.
I imagine it'd be useful to have Steam install certain dependencies, like dotnet and whatnot, on games that do not install them by default, since that way you could then run modded installations or launchers that usually depend on these things. It'd be much easier.
Uh.. I didn't actually think this much through it. My use case was just 1. EA fucking up cdkeys init (but hopefully #28 is the better fix here) 2. experimenting with games settings.
I don't really know how the override works then (nor how many unholy signatures you'd have to adjust in order to edit it).
I can just (barely) tell you this is how Dishonored behaves (note how the install configuration could be parsed).
Instead of steamservice.exe running whatever pre-existing long-lasting file is specified in the extended_installscript
property, Steam.exe writes the thing to disk unconditionally on every single launch (well, at least those initiated from within the steam client/api, running directly the exe doesn't seem to trigger this) and then you have the usual functioning.
Proceeding even deeper down the rabbit hold from #28, Steam (or its affiliated service) must be storing a flag for whether they already run the first time setup or not.. somewhere I still haven't figured out the location.
@FatRodzianko or @aluigi may presumably have some extra insight.