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

×
I could finish a status download for my collection today. Perhaps it's a function of the server load.

The changes in the patches are definitely good ideas, so they should be committed.

I still have the problem with moebius. I tried going to the gog refresh URL but that gave me an internal application error today :)
I have a feature request for an option:
For DLCs, can you please use 'gamename' as the directory name?
avatar
Loenas: I have a feature request for an option:
For DLCs, can you please use 'gamename' as the directory name?
Here's an untested patch I put together in few minutes.
https://sites.google.com/site/gogdownloader/dlc_gamename_subdirs.diff
Does this work?
It should make the downloader save dlcs to "gamename/dlc/dlcgamename"
Git version now has the previous patches applied with some changes
- Added retry support to Downloader::getResponse
- Make subdirectory for dlc based on the dlc gamename
- Added --wait option to set delay for http requests

Arch Linux users:
If you have installed the newest rhash from AUR and build fails due to linking error then you'll need to create a symlink for librhash
ln -s /usr/lib/librhash.so.0 /usr/lib/librhash.so


If there aren't any major problems with the current git version then this will become version 2.13
From now on I probably won't be adding any new features and only do bug fixes. However patches and pull requests are welcome.


I had planned on doing a rewrite of some classes and even started working on the rewrite but abandoned it after we got the news about GOG Galaxy.
GOG Galaxy most likely means that the current API is going to be deprecated when Galaxy is released and therefore the time used for rewriting the classes would be wasted.

Perhaps I'll create a new downloader for the Galaxy API.
But that depends on how much time I have available and how difficult it is to reverse engineer the Galaxy API (unless GOG documents the API).
avatar
Sude: I had planned on doing a rewrite of some classes and even started working on the rewrite but abandoned it after we got the news about GOG Galaxy.
GOG Galaxy most likely means that the current API is going to be deprecated when Galaxy is released and therefore the time used for rewriting the classes would be wasted.

Perhaps I'll create a new downloader for the Galaxy API.
But that depends on how much time I have available and how difficult it is to reverse engineer the Galaxy API (unless GOG documents the API).
Let me know if you'll need any help with it. I'll be interested in it too. Not sure if GOG will accept the request to open the protocol. So far they didn't care about their current one at least.

Also, Galaxy client is going to be a more complex project than just the downloader, but making an open alternative is a worthwhile effort.
Post edited June 10, 2014 by shmerl
I think they have to open the Galaxy API in order to facilitate their open gaming across (downloader) platforms, perhaps in a fashion similar to the steam api.

At worst, they won't document the downloader API.
avatar
coffeecup: I think they have to open the Galaxy API in order to facilitate their open gaming across (downloader) platforms, perhaps in a fashion similar to the steam api.

At worst, they won't document the downloader API.
Don't forget to vote if you didn't yet (and feel free to spread the word):

* Documenting Galaxy protocol and API
* Open sourcing the official Galaxy client
Post edited June 15, 2014 by shmerl
LGOGDownloader 2.13
- Fixed some characters in extra filenames by url decoding the links
- Patches now use duplicate handler
- Added support for DLCs
- Fixed segfault when downloading non-dlc patches (patch by: Geoffrey Biggs)
- Fixed a login issue
- Downloader::getResponse now prints more verbose error messages
- Use secure.gog.com to get "buk" value for login form
- Check orphans regex matches the file path instead of filename
- Fixed using local xml for hashes in Downloader::downloadFile
- Use remote XML for languagepacks (patch by: Ismo Toijala)
- Only hash file if remote XML is available (patch by: Ismo Toijala)
- Added retry support to Downloader::getResponse
- Subdirectories for DLCs are created based on the DLC gamename
* gamename/dlc/dlc_gamename
- Added --wait option to set delay for http requests
- Removed language id/code from urls because GOG no longer requires it

https://sites.google.com/site/gogdownloader/lgogdownloader-2.13.tar.gz

sha256: ad4e6749f2bc17c064e5778c591450b17d960e029d11696de13def862f542655
md5: 66b71b263e29f78067854426aa03ba72
Hello All,

i've built new Debian-Packages for lgogdownloader 2.13:


Debian Wheezy 7 64bit:
mash-systeme.de/sites/default/files/downloads/lgogdownloader_2.13-1_amd64.deb

Debian Wheezy 7 32bit:
mash-systeme.de/sites/default/files/downloads/lgogdownloader_2.13-1_i386.deb

These Packages may work on other Debian-based Distributions (e. g. Ubuntu) too, but i only tested them on Debian 7.

Hopefully someone will find these useful.
avatar
mashppps: Hello All,

i've built new Debian-Packages for lgogdownloader 2.13:
May be you'd be interested in uploading them to official Debian repos? In light of upcoming Galaxy though, I'm not sure how long the current downloader protocol will still work,
Hello shmerl,

since i'm not an "official" debian-developer, i've no possibility to push the packages to the official debian-repos.

Even worse, since i'm using and compiling on the stable-tree (wheezy), there would be no way to include the packacges to the official wheezy-repos, since new packages won't be accepted for this tree.

I'm thinking about setting up my own repo for these wheezy-packages, if you agree.

So everyone interested could put this repo into his "sources.list" and would get the newest packages automatically as soon as i push them to my repo.

Once Galaxy is finalized and available, we'll see what happens to the existing API. :-\
avatar
mashppps: since i'm using and compiling on the stable-tree (wheezy), there would be no way to include the packacges to the official wheezy-repos, since new packages won't be accepted for this tree.

I'm thinking about setting up my own repo for these wheezy-packages, if you agree.
I see. I'm using Debian testing. I'd guess most desktop Debian users aren't using stable, but using testing or Sid.

As for pushing to Debian, I don't think you need to be a Debian developer to propose and prepare a package (but you need to be one to actually accept it in the repo). But I might be wrong about it.
Post edited June 29, 2014 by shmerl
Git version now has support for blacklisting files: https://github.com/Sude-/lgogdownloader/pull/17

But perhaps more important is that git version now supports the new login form

Current git will become version 2.14 if there aren't any major issues
This question surely was already asked, but is there a way to integrate lgogdownloader into Firefox similar to the original downloader?
I mean that when I choose the "Download with GoG Downloader" option in the games list a new terminal is opening and starts downloading the choosen game with given parameters e.g. language, extras etc.
Sorry if this was already answered, but Google didn't show up anything useful apart from some Wine tricks for the old original downloader :/
avatar
TheMechanist: This question surely was already asked, but is there a way to integrate lgogdownloader into Firefox similar to the original downloader?
I mean that when I choose the "Download with GoG Downloader" option in the games list a new terminal is opening and starts downloading the choosen game with given parameters e.g. language, extras etc.
Sorry if this was already answered, but Google didn't show up anything useful apart from some Wine tricks for the old original downloader :/
This will require creating a parser for gogdownloader:// url scheme
It could be possible by adding a check for it in --game option. I'll see what I can do.