Yea that's probably a valid option but when you start talking about the size of a game in relation to the size of the patch...I'm pretty sure it could take a while to go through that and find the changes in some larger situations. Not to mention you increase the risk of something being messed up when the patch is released.

Honestly, if someone has a crappy connection or a limited connection, just do yourself a favor a use Galaxy. Yes it's beta, and yes it's not perfect... but at some point it will slowly become better and with delta patching, etc, your life becomes easier. This is already being built into Galaxy, trying to make a comparable system for standalone installers would be redundant work for a most likely much smaller user base. Otherwise you will just have to deal with however the installer is delivered.

I was meaning purely a 'is this file identical to this file, if so delete' type of check. diff and cmp can both do the job, and checking shouldn't take any more time than it takes to raw read the files. Source code and diff/patch is much more complex. But this has the same flaw where if a belt buckle texture is changed in a zip file, and the zip file is 300Mb (think Torchlight) then the entire 300Mb is likely to need re-downloading vs the individual inner file and patching the files. Very much a bulk replacement on top of the current model.

Deleting/renaming files isn't considered, although another pass could find deleted files, or md5 checks could match moved files much like how Git works (using SHA-1 to identify unique files).

Yea I get what your saying but as I said your still very much increasing the risk over just packaging the full build and calling it a day. Not to mention, increasing the workload of a team I imagine already has enough to do. :P

It also probably gets harder to keep track of since GOG tends to roll up changes into a large cumulative patch (when they do release patches)...

EDIT:

Actually thinking about that, they probably already kind of do this for the cumulative patches...

Don't see why... A lot of it can be heavily automated.

I have a script called rezipit, which takes a zip file, extracts the images, optimizes them, then repackages them into the zip for use. It optimizes the files in the zip before re-packaging the zip and leaves the images uncompressed. There's a reason for this, and it's for the game ToME (Tales of Maj Eyal), which seems to work better that way when playing the game. unpacking images twice takes time, leaving PNG's uncompressed but compressed by zips is bad so that doesn't work. And leaving it all uncompressed simply leaves for huge & slow files.

Once the script is well written it works. Also you don't HAVE to make a patch exe file, it could just be a zip file you impose on top of a previous version.

But having them do cumulative patches in bulk or as a full release update is better, mostly. I'd say having up to 5 patches before a main release update would be fine. It doesn't take long go extract or install each in turn.

I mainly use Galaxy to get the installer files and handle updates when I decide its the right time to do them. The first rule for any game "More -> Settings -> Install Updates: Manually".

THANKFULLY! that is an upcoming feature in the overall settings because I generally hate auto-updating and specifically hate Galaxys update by redownload the whole damn thing again approach.

I'll have to vouch 100%, especially with ToME involved and games with mods where support for a mod can break between updates and versions. Completely changes the experience when a mod you love stops working, one that adds functionality or fixes features that aren't in the base game (like telling your companion to STAND STILL) while you fight off three bears coming close and they decide 'I'LL JUST RUN RIGHT PAST YOU INTO THE BEARS' and then 'AHHH I GOT HIT BY A BEAR!'...

Damn escort missions...

I wouldn't exactly say that. It works (like in your instance) when you know what your getting and exactly what it needs to do. There is a lot to consider here, for instance as you said deleting/renaming of files. If a file is completely moved to a different hierarchy in the folder structure. If the file type is changed... and more that I'm probably not considering here. Not to mention being able to detect those changes would probably require the original md5 hash from the dev for each file right? Something were not sure GOG even get's... this is based on my limited knowledge of how md5 hashing works. :P

Not saying I know everything about it or anything, but I would assume it can become complicated based on my own experience with creating batch files and stuff (which granted has been a long time) as well as coding.

As you said, version control is it's own level of fascinating. :)

The MD5 hash can be calculated at any time, so you wouldn't to request need a specific hash from the devs.

A Hash is literally a one->way function that converts a stream of data into a digital signature that you can then use for a lot of things, including Associative arrays (for fast lookup) checking if a file has changed or downloaded correctly and other security measures. MD5 is fairly weak, but at no point is the dev needed to give you the MD5 hashes. You'll already be able to calculate them from v1.1 and v1.2 when you put them side by side. Or ignore the hashes and just do a simple compare to see if the files are identical (cmp can probably do the job).

Even if moving a file is done, it could be seen as deleting a file and adding a new file, which would be easy enough to manage, you'll still end up with the file in the patch, but likely most patches are going to be major game files, executables or quests or stuff, and less likely to be the 300Mb container that holds meshes, textures, and static images that are unlikely to change from such a patch.

I see. Generating a hash yourself for each file based on the old build and comparing it to the new build and detecting which files hashes have changed. Got you.

As I've said I believe that it could easily be done like you described, but one would just have to make sure any such script accounts for any possible change that can happen, that's all I'm saying... I imagine GOG might already do this honestly. Sometimes their handing of standalone patches is just weird though, and might just be more of GOG does what GOG wants to do.

This use to happen every so often for me, but it's rare for me to see that message now. That's not to say it won't happen or anything just my experience.

Galaxy has been out in beta for about a year and a half (give or take). The issue is they rushed Galaxy to beta when it was really still an alpha (and kinda still is) because of the Witcher 3. Can't say I blame them, but it doesn't make it any less true.

It's not uncommon for software to spend a few years in a alpha/ beta state. Having said that, I expect at the very least another good year or two before release. Unless the upcoming 1.2 update adds a lot of features, which they say is coming soon but who really knows. GOG's soon is very different from our soon.

I find that hard to believe, since I have the "preview updates" thing turned off, and the "beta channel" thing (which I think is for the games themselves) turned off, and yet the version number on the title bar of hte program still says beta?

1.1.24(beta) to be precise.
The only galaxy updating that ti did to itself was on first run it downloaded some files, so if this is some kind of test build beta it never gave me any options, it just installed it.

Also, I've more questions.

First, back to the DLC. Now that Van Helsin is installed I can't find any mention of the texture pack DLC other than in the "backup and goodies" section. No way to uninstall it to save that little bit of HD space that I can find, not even in the Uninstall Programs windows menu.

Second, I went ahead and told galaxy to scan my install folder to find other games that I installed, so that it would at least list all the GOG games I installed, not just the few it automatically found.
During that whole "its just updating to make gog compatable" it tried to run the installers all over again. That actually happened with the ones it auto detected before I asked orginally as well. It tried to run the directX installer for some game all over again.

Not all the instllers mind you, but the one for NWN2 and i think NWN. It happily jumped right past most of them, just triggered for those two.

Annnddd its clearly trying to re-download the entirety of Wasteland 2.

Edit: It also doesnt' like my modded Baldur's Gate 2. Any way to force it to show up outsie of reinstalling it, and then re-modding it?

I was not aware, other devs said they needed to send in patch files. Thank you for that.

I'm sorry for spreading miss information then.

i should have worded that better, I said out IN beta for about a year and a half, not out of beta. Galaxy is still in beta yes.

EDIT: See Gurlok's comment below please.

---

All DLC should be under MORE -> Settings. I don't own that game so I can't check how Galaxy is handling the DLC.
Might take a few sec/min to show. This is sometimes really slow for me.

You should also see INSTALLED ver# and number of DLC installed listed next to the MORE button.

Yea they still haven't gotten all the kinks out yet with this.

Probably not... if it's not automatically showing then it must have been using an older version of the standalone installer... not the Galaxy compatible version (which not all games do yet). So it probably will need an imported, then updated first.

Van Helsing FC is some kind of exception when it comes to dlc, a gog user asked on the game's thread the very same question:

https://www.gog.com/forum/van_helsing_series/gog_galaxy_is_the_texture_dlc_automatically_installed

Also, I can confirm this myself, as I have installed it through galaxy, and the hd textures were NOT installed (and to be honest they aren't even that great, considering the nearly 19~ gb they require, but that's just my opinion).