It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Community
General discussion (archive)GOG Patcher lacks rollback/validity checks(14 posts)(14 posts)
(14 posts)
Pages:
1
This is my favourite topic
Posted February 05, 2013
I don't get how the GOG team haven't implemented this yet. If there are certain files files that can't be patched using an update patcher, the patcher will exit with error, but will not roll back the files. The next time you try again, it will spew a lot more errors because it does not check whether or not files are already patched, and tries to patch them anyway, and fail horribly.

What should be done is the following:
- Check whether or not a file has been patched already before trying to patch it. Embed CRC sums into the patcher. Ignore file if already patched. (This will help existing installations borked by the patcher to finish patching.)
- If the file to be patched is to be overwritten with a new copy, back up the original.
- If the file is to be diff patched, either test patch or compare to original checksum. If that fails, do not real patch any remaining files, but check only.
- If any files failed, roll back the changes, after checking remaining files. If the patch library you guys use can't roll back, it is junk.
- The game should be in the exact same state as before if patching failed.
- It'd be useful if there's a retry/ignore system for those of us who mod games.

This is elementary stuff. I know Inno doesn't support rollback and repair, but if you guys are going to add patching functions, at least implement them well. (I'm thinking Windows Installer, but light.)
Posted February 05, 2013
I can already see it...

Roman5: New jobs available at the GOG.COM office: QA, Programmers
Posted February 05, 2013
avatar
GMMan: This is elementary stuff. I know Inno doesn't support rollback and repair, but if you guys are going to add patching functions, at least implement them well. (I'm thinking Windows Installer, but light.)
Elementary stuff? I think I would have understood that better had it been in Latin.
Posted February 05, 2013
avatar
tinyE: Elementary stuff? I think I would have understood that better had it been in Latin.
Elementary stuff for anyone who understands the issue more than you :-P Yes, I am saying I am better than you. I am also way smarter, stronger and more humble.
Posted February 05, 2013
avatar
tinyE: Elementary stuff? I think I would have understood that better had it been in Latin.
avatar
Fenixp: Elementary stuff for anyone who understands the issue more than you :-P Yes, I am saying I am better than you. I am also way smarter, stronger and more humble.
Yeah, well the Jerk Store called; they're running out of you!
Posted February 05, 2013
avatar
tinyE: Elementary stuff? I think I would have understood that better had it been in Latin.
avatar
Fenixp: Elementary stuff for anyone who understands the issue more than you :-P Yes, I am saying I am better than you. I am also way smarter, stronger and more humble.
http://startswithabang.com/wp-content/uploads/2008/05/t0m537.jpg ;)

Elementary stuff in regards to businesses like this, presumably.
Posted February 05, 2013
Elementary, as in basic, for file management. I consider game patching similar to source code patching, except you're dealing with binary files more than text. GNU patch will retain original state and emit rejected files so you can check what went wrong. It also tells you where something went wrong. While the GOG Patcher isn't on the same scale, the very least it can do is to retain the older version.
Post edited February 05, 2013 by GMMan
Posted February 05, 2013
avatar
tinyE: Yeah, well the Jerk Store called; they're running out of you!
All right, petty insults it is. Your mom is so classy strangers bow when they meet her.
Post edited February 05, 2013 by Fenixp
Posted February 05, 2013
avatar
Fenixp: Elementary stuff for anyone who understands the issue more than you :-P Yes, I am saying I am better than you. I am also way smarter, stronger and more humble.
avatar
tinyE: Yeah, well the Jerk Store called; they're running out of you!
Ha i love seinfeld
Posted February 05, 2013
avatar
tinyE: Yeah, well the Jerk Store called; they're running out of you!
avatar
Fenixp: All right, petty insults it is. Your mom is so classy strangers bow when they meet her.
I got nothing. That was my best comeback. :D
Posted February 05, 2013
avatar
GMMan:
This "elementary stuff" is mostly already implemented :-) Including the version and checksum verification and file rollback. But the whole game is not rolled back, because in most cases the differences that cause the errors are small and don't really break the patching process.

Basically we provide patches for our versions of games, assuming they were more or less unmodified since the installation. We can't predict or handle any modifications someone can make to the game.

If you get the error log, then you know what changes weren't made, so you know how to proceed. Other changes are still done normally - the patcher doesn't just stop and exit. If the errors are minor (readme file wasn't changed), you can proceed and play the game. If not, or you don't know, you can always reinstall the game and try again - and the patch will work with a fresh install.

Patcher proceeds with the process even if there are some differences, because in most cases they are minor (like changed settings file) and it works. If the game is heavily modified, there is no good way to handle that, aside from not doing anything. And there is no way for the patcher to tell if the changes will be minor or critical.
Posted February 05, 2013
I'd actually be fine with that, but what I currently see is the patcher derps on already patched files, spewing errors. I can go back and pull the original files, put them in place, patch, then reimplement my changes, but it's difficult when fixing one thing causes the patcher to spew errors on other files just because they were already patched. I can't easily check what files I might have missed when manually restoring them so they can be patched.

Rollback could be an option. Ask at the end of the failed patching session whether or not the user wants to roll back.

(BTW, the game in question is Strike Suit Zero, which contains Zlib compressed text files. I subsequently decompress those files so I can poke at them. I'm not sure when you're building the patch kit if the choice to diff is based purely on file extensions. In any case Zlibbed files don't diff well.)
Posted February 05, 2013
avatar
GMMan: snip
I see your point, but what you described (multiple patching with manual file swapping) is not really what the patcher was optimized for. But thanks for the input, there's always room for improvement :-)
Posted February 05, 2013
avatar
GMMan: snip
avatar
Gowor: I see your point, but what you described (multiple patching with manual file swapping) is not really what the patcher was optimized for. But thanks for the input, there's always room for improvement :-)
Well, running the patcher another time to get those modified files up to date is the only way to update those files, isn't it?
Pages:
1
This is my favourite topic
Community
General discussion (archive)GOG Patcher lacks rollback/validity checks(14 posts)(14 posts)
(14 posts)