doesnt sym link the folder to target ssd work?
or just change tmp folder to the target ssd if it is possible

Whilst I've not gotten it that far I have managed to reduce the installer size for Deus Ex Mankind Divided yesterday.

The size for the base game unmodified GOG installers is 34.7GB, the Season Pass unmodified GOG installer is 10.4GB, so in total for both its about 45.1GB.

I extracted the game from the original installers using innoextract, removed the language packs (which saved about 10GB) then added the Season Pass files to the base game then created my own Inno Installer for the whole lot which in total sits around 31.5GB.

I could most likely get it smaller if I knew more about compression.

And also creating it myself means I know what its doing, and it doesn't have a lot of the bloat that GOG installers have.

I think you cannot symlink folders with locked files (and usually you have some locked in use files in temp).
You can move temp to some other disk sure, but changing this requires Windows restart.
Sure, let them be in small galaxy parts inside or whatever, just let us select temp dir for where files are merged.
Not everyone has 70GB+ free C:\ space

Just some food for thought, as I have not actually looked into the situation.

1. Does the GOG installer extract to the TEMP folder and then MOVE or COPY files to the final destination?
2. If it does a MOVE rather than COPY, then where the TEMP folder is on the same drive as the final destination, there is no wasted extra file writing (abuse), just indexing changes for the new location, as the data remains exactly where it was. It also would mean that any extra time taken should be minimal.
3. Of course, if it is COPY rather than MOVE or different drives, then that is bad, as files are being written to two different drive locations ... which wastes time and abuses one drive.

There could be one or more reasons for writing to a TEMP folder first. Maybe some kind of extract and build happens. Maybe not all files end up in the final destination (i.e. language ones). Maybe some files are run from the TEMP folder to determine what is needed on a system or OS etc (DirectX etc). Makes it easier for cleanup afterward.

Unless there's special registry entries and things that need to be done, i'd rather just have a zip file that extracts and you run the game within the folder you extract. Problem over, simple, done, recompress to 7z if you want better compression, the whole nine yards.

I agree, I'd prefer such simplicity as well. As long as the game does not have some very obscure dependencies that you need to figure out and install yourself... I guess with many current GOG games it could be done by first installing the game, and then 7-zipping the installation folder? Those games that are portable that way...

At the moment I don't see point in trying to repack my GOG game installers, as so many of them still get updates so I'd have to redo it every time.

GOG installers create a .tmp file in the TEMP folder and then run that to create the game data in your chosen destination folder. Then installers are run for any dependencies (e.g. Visual C++ libraries, .NET Framework). Finally a GOG script is run which creates the Start Menu and Windows Registry entries for the game.
Multiple installers are usually involved, which do not need to be present after installation. So having an initial extraction to the TEMP folder makes cleanup simpler. It also allows users to control where temporary files go (so anyone concerned about SSD wear and tear can set their TEMP variable to point to an HDD and add to its wear and tear instead - or a ramdisk).
As an aside, Primo Ramdisk allows you to create a hybrid ramdisk where RAM is used initially, while data exceeding the allocated RAM gets written to a file. So you could have a 20GB ramdisk using 4GB RAM and a 16GB file - giving you the speed of a ramdisk (at least initially) while having less chance of running out of capacity (downside: Primo Ramdisk requires online activation).

You quoted me, but appear to have missed the point of what I was asking.

How does content get to its final destination - COPY or MOVE?
Or are you saying some kind of create (Build) occurs at the final destination folder, that doesn't involve a straight COPY or MOVE from the TEMP folder?

This is important to know, because COPY and MOVE are not the same processes. MOVE can be instant if on the same drive, while COPY never is. COPY will always involve more wear & tear of your drives.

The following happens when you run an "old" GOG installer (either without a suffix or a short version suffix):
* a randomly named subfolder is created in the TEMP folder (call this TEMP1);
* an identically-named .tmp file is placed in that folder and executed - this creates another random subfolder in TEMP (TEMP2), and extracts its files (mainly graphics and support DLLs) into it;
* the setup window is displayed where you choose options like your preferred installation folder;
* when you press "Start Installation", extra files are copied into (TEMP2) for the graphics to be displayed during install;
* game files are placed in your installation folder. They are not held in TEMP/TEMP1/TEMP2 so must have been extracted from the original installer .exe/.bin files;
* installers for needed system components (VC++ libraries, .NET Framwork) are extracted to a __redist folder in the install folder as part of the previous step - these are now run;
* TEMP1/TEMP2 folders and their contents are deleted.

The following happens when you run a "new" GOG installer (with a long version suffix):
* a randomly named subfolder is created in the TEMP folder (call this TEMP1);
* an identically-named .tmp file is placed in that folder and executed - this creates another random subfolder in TEMP (TEMP2), and extracts its files into it - including the graphics displayed during install;
* you are asked for your preferred language;
* the setup window is displayed where you choose options like your preferred installation folder;
* dozens of subfolders are created under TEMP2 - these were empty when I viewed them but I'd guess these would contain individual game files prior to them being moved/copied to the install folder;
* installers for needed system components (VC++ libraries, .NET Framwork) are extracted to a __redist folder in the install folder as part of the previous step - these are now run;
* scriptinterpreter.exe in the redist folder is now run, which adds entries to the Windows Registry and Start Menu;
* TEMP1/TEMP2 folders and their contents are deleted.

There may have been other changes between "old" and "new" installers, but the above should still generally apply.
If you want a definitive answer to that, then I would suggest you fire up Process Monitor and use that to examine a few installs. Since installs are (or should be) an infrequent event, I see no point in considering the wear-and-tear they might create.

I wonder how hard it would be to make a proper installer which could patch itself ,so no more need to redownload the whole game everytime.
It could even have optional features separated like languages.

Thanks for the info.

By all that you appear to be implying that most of the content of an EXE or BIN file are extracted straight to the final destination folder, and so never reside in a TEMP folder? That would be great if so, as it means less wear and tear.

It's not so clear now with these newer ones.

You are right, I could. But as I made clear in my recent post about all this, I was just pondering the possibilities, and was leaving it up to someone in the know to answer.

While installing a game might be somewhat infrequent, it is more about how many files are involved, rather than the frequency ... though regular frequency would of course impact.

Many games have a huge number of files, and if a COPY is occurring or a MOVE to another drive, then that constitutes drive abuse to my mind. Not so if a MOVE occurs to the final destination folder, if the same drive as TEMP folder is on. Lots of really small files really heat up a drive when its being written to with them. So unnecessary writes are good to be avoided.

So anyway, potentially there could be some benefit to having the TEMP folder be on the same drive as the final game folder destination ... but only if MOVE proves to be the case.

P.S. If no-one else who knows answers my query, then I will eventually get around to checking things myself. Been up to my neck in projects lately ... even my reading has suffered.

Because it's a standard going back to the DOS era. And because people should re-learn computer basics again like environment variables and all that jazz :-D

It may be standard to a degree. But using a tmp directory is pointless if you have enough ram to do the job. If you were unpacking an 8Gb game and had 2Gb ram, sure. But if you are unpacking an 8Gb game and have 32Gb, unpacking to a temp directory may mean nothing. Worse is if the installation is to a different drive than the temp is located, then it unpacks, then has to copy. An awful lot of extra work.

On the other hand if more memory becomes common, people will start using ramdrives for temp directories and the problem goes away.... mostly...

This is done during the extracting process of larger games. It's part of how inno works. you can change the temp directory in your Windows settings.

sounds like a garbage outdated installer if that is the case
hah why do they use temp anyway when they have access to the final folder and could just do their job there?:O