) do provide far too many results using the search function to check them all manually.TL;DR
Streamline the automatic update process by providing diff archives to skip several patches at once.What ?
I just updated Factorio (linux release, direct download from factorio.com) from 1.1.3 to 1.1.19. While being absolutely amazed about the amount of work the devs put into optimizing every little aspect of the game the updater is still quite unfinished. Updating from patch .3 to .19 took 16 archive files to be downloaded, extracted, and written to disk (named e.g. core-linux64-1.1.3-1.1.4-update.zip). Each of the archive files contains all the files which got changed since the last patch.Method A: Current situtation
- now.png (38.96 KiB) Viewed 1038 times
The updater does the following:
1) Download the diff archive (each around 25-32 MB for 1.1.x)
2) Extract all the files and overwrite the old ones (each time around 80-100 MB)
3) Go back to 1) until we reach the current patch level.
So not playing the game for a few weeks (or "skipping" some updates) took me downloading around 460 MB and writing 2.1 GB of files to disk.
Method B: Diff files for every combination
- fast_crop.png (150.45 KiB) Viewed 1038 times
The fastest solution from the user perspective would be to provide diff files to specifically upgrade from version x to version y. Providing diff archive files for every possible combination would explode in terms of storage space needed. Since we don't need to be able to downgrade to older versions of the game it's sufficient to provide diffs for all older version to the current version.
Method C: "Feeder flights"
- balanced_crop.png (51.96 KiB) Viewed 1038 times
As a tradeoff between traffic and storage space we can mix method A and B: Do up to n single hops (worst case) to the n-th patch (next "intermediate patch") and continue doing much bigger hops to the current patch version.
Example:
Using every 5th patch as an intermediate patch would have made me update from patch .3 to .4, .5, .10, .15 and then directly to .19 (or via .16, .17, .18 to .19).
It's possible to use variable density of these intermediate patches the more we go back in time - e.g. skipping directly to the next minor release for every version before 1.0.0.
Method D: Best of Everything
Combine methods B and C - offer the fast-forward approach from method B for users who are coming from a very old version while providing direct diffs for all versions released in the past month.
Why ?
The improvements I suggested would save a lot of- server bandwidth (for the devs)
- download time (for the user)
- extraction time (for the user)
- SSD life time
- time for defragmentating conventional HDDs
The improvements I suggested would cost
- some developement time for the updater function
- more storage space on the server
