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

×
avatar
Timboli: Totally agree, and I am only interested in a full size Galaxy variant if the worst happens ... GOG get rid of offline installers. I guess we cross that bridge if it happens, but your program and gogrepo.py variants become redundant instantly if GOG do that, and no other offline option exists.

Many of us would tolerate Galaxy features in a full size installer file, but not tolerate a lack of a local offline installer file to backup.

I cannot see GOG doing that, but don't believe in having all my eggs in one basket, just in case. Certainly GOG would be stretching the meaning of DRM-Free, if the only way to do a backup is to backup the entire game folder ... which would be a right pain in the ass, and no good for updates ... which would require keeping the game installed or a fresh install of it, to then freshly backup.
That's an interesting viewpoint, I didn't look at it from that perspective.

My interest in the gog galaxy installers is to try reverse-engineer the gog galaxy protocol and possibly implement a mock "galaxy server" to setup multiplayer matchmaking on my local LAN. Admittedly, my networking knowledge might be just a tad lacking to pull it off (though not by much and I have a 80 hours course on Udemy that should fill that gap... the main thing I'm lacking currently is knowledge in the tooling to setup a "man in the middle" on my client machine to infer the specifics of the protocol).

Also, if I undertook such an endeavor, I probably could not publish it (its a big motivator for me, I like to share) as I suspect it would be illegal, but once GOG goes under and sufficient time has passed, maybe then.

Anyways, its very speculative at this point.
Post edited February 19, 2021 by Magnitus
Released version 0.2.0. See first post for details.
Sounds good and I am especially looking forward to the following update(s). :)

Keep up the good work and thanks for doing so.
avatar
Timboli: Sounds good and I am especially looking forward to the following update(s). :)

Keep up the good work and thanks for doing so.
Glad its appreciated.

The checksum in the generated manifest is already in the master branch ;).

I'm waiting until I've integrated checksum/size validation to storage upload to release it.

Maybe I'll release that first and then do zip validation as a separate release.
Excellent .... I'm trying not to hold my breath waiting. ha ha ha
Released version v0.3.0. See first post for details.
Excellent, will check it out.
avatar
Timboli: Excellent, will check it out.
Awesome, I QAed many expected scenarios manually (including failure situations, for example if you change the hash in the manifest prior to copying between two storages to deliberately cause a failure, fix the hash and then resume... copying between two storages use many of the same pathways in the code as the initial upload from the gog api which is awesome for testing as it is so much quicker and also, gog won't be left wondering why you are downloading the same installer 100+ times), but obviously, nothing quite replaces comprehensive automated tests (which I'll get around to once the main functionality is fully fleshed out).

If you find any issues, let me know and I'll look at it tonight.
Post edited February 22, 2021 by Magnitus
Will do.
Could you explain what features you hope to have in gogcli that are currently missing from gogrepo(c)?
Post edited February 22, 2021 by mrkgnao
avatar
mrkgnao: Could you explain what features you hope to have in gogcli that are currently missing from gogrepo(c)?
In all modesty, an observation that is made by looking at gogrepo's doc but not having managed to run it, I don't expect gogcli to include absolutely revolutionary features that will make gogrepo users say "omg, the tool I'm using is so passe, why didn't I think of doing my backups like that? Its imperative that I migrate now!". If you're already a happy gogrepo user, I encourage you to keep using the battle-tested tool that works well for you. Maybe I'm doing a lousy job of promoting my work here, but I'm a software engineer, not a salesman.

A couple features that are important for me (but probably won't matter for 95%+ of users):
- Support for redundant backups as a first class citizen (you can make one storage up to date with GOG.com and then propagate this to other storages in a robust minimalistic way without having to communicate with GOG.com again)
- Support for multiple storage solutions: I've taken a lot of interest in s3-compatible stores lately, especially Minio (https://min.io/) for on-premise s3 storage... I'm also mongodb certified so its probable that I'll add a mongodb/gridfs store later one
- A modular design, its easy to QA various parts of the tool by running different commands sometimes by targeting only the gog api, but not the storage and at other times, but targetting only the storage, but not the gog api

In terms of codebase (which is important to me as I have the skills required to add features that I want), I won't say that my codebase is simpler (while over-engineering is a thing, its often a lazy argument to make, my codebase is probably more complex overall actually), but the complexity is distributed in a more modular way (the sdk part only worries about communication with the gog api, the cmd part mostly worries about executing commands on the prompt, the storage part mostly worries about storage, the manifest part only worries about the modelisation of the data, etc).

I won't claim that my modularisation is perfect (there are creeping business-logic concerns in the storage and cmd parts that irks at me, I'll see what I can do about refactoring that), but a reasonable effort has been made in this regard and this makes increasing code complexity as I'm adding features a lot more manageable for someone like me.

Some nice things for some users would be:
- The client is truly multi-platform (not Linux or Windows specific thing, you just need to get the binary for your platform and you are in business)
- The client is a self-contained binary (you don't need to have dependencies like Python or some library installed on your machine)
- The client has some low level commands to interact with the gog api (if you'd like to script something on top of the client for example)
- The client uses a battle-tested command-line library (Golang's Cobra) which makes it more user-friendly for running commands: You get detailed outputs for the commands, subcommands, arguments and the posix convention is respected (which will be familiar to a lot of people)

Beyond that,the mechanism to authenticate is more basic, which is a double-edged sword (and something I would like to eventually revisit). The client currently doesn't try to login for you, it just expects you to put two cookie values in a file.

If you don't know anything at all about http, cookies and how to access them in your browser dev console, that will probably be hell. However, if you know how to do that, then you won't have to content with a finicky login mechanic that will sometimes work, sometimes fail.
Post edited February 22, 2021 by Magnitus
avatar
mrkgnao: Could you explain what features you hope to have in gogcli that are currently missing from gogrepo(c)?
avatar
Magnitus: In all modesty, an observation that is made by looking at gogrepo's doc but not having managed to run it, I don't expect gogcli to include absolutely revolutionary features that will make gogrepo users say "omg, the tool I'm using is so passe, why didn't I think of doing my backups like that? Its imperative that I migrate now!". If you're already a happy gogrepo user, I encourage you to keep using the battle-tested tool that works well for you. Maybe I'm doing a lousy job of promoting my work here, but I'm a software engineer, not a salesman.

<snip>
Thanks. I'll continue lurking here.

I'm reasonably satisfied with gogrepoc, although there are a few features that I'd like to see (mostly related to the on-screen output, which is both too verbose and lacking in essential information). I could modify it myself (I have worked a few years in python), but I'm not that interested in diving into the code. It doesn't seem like that's your focus, though, at least at the moment.
avatar
mrkgnao: Thanks. I'll continue lurking here.

I'm reasonably satisfied with gogrepoc, although there are a few features that I'd like to see (mostly related to the on-screen output, which is both too verbose and lacking in essential information). I could modify it myself (I have worked a few years in python), but I'm not that interested in diving into the code. It doesn't seem like that's your focus, though, at least at the moment.
Atm, I'm trying to strike the right verbosity balance, though admittedly I need to work on that.

If you don't use the -d flag, you'll get almost total silence (except for errors) and if you use the -d flag, you'll get logs that would mostly qualify as "info" with a couple of logs that belong more in the "debug" category.

I need to integrate log levels (at least info, debug and error), though as this is my first golang project ever, I haven't looked into that part of the language yet. Its on my "todo" list though definitely after I have a viable mvp.
Post edited February 22, 2021 by Magnitus
avatar
Timboli: Good idea to relocate, as we certainly ended up hijacking that thread ... for good reasons of course, as this stuff is all related and several gogrepo.py users have good insight, as Geralt_of_Rivia, Kalanyr and others have demonstrated.

Hopefully they will follow you here from -
https://www.gog.com/forum/general/gogrepopy_python_script_for_regularly_backing_up_your_purchased_gog_collection_for_full_offline_e/post2693
Strictly speaking, I actually don't use gogrepo. ;-)

I was interested in it but scanning the files was way to slow for me. That's why I decided to write my own downloader. I had finished most of the data collection routines last summer and wanted to have a finished downloader around Christmas at latest but work as well as real life related problems kept keeping me from continuing on it.

I read threads about user-made downloaders because that's where you learn about the undocumented GOG internals from those who fought with them before you. ;-)

And of course to share my knowledge as well when someone asks for things I already know.
avatar
Geralt_of_Rivia: Strictly speaking, I actually don't use gogrepo. ;-)
Goodo, thanks for the heads up ... maybe I should have said gogrepo.py thread attendees. ;)