That's exactly the point. How is it going to use the API if it's not documented yet? Did they reverse engineer it? lgogdownloader is using the legacy APi which is going to be deprecated.

*nod* I ran across Lutris a few years ago and that's what prompted me to start my own experimental project instead of trying to extend Lutris.

It's temporarily on hold while I work on a more urgently needed PIM tool, but I've attached a screenshot of the current state of the redesigned GUI I'm just short of being ready to push to the GitHub repo.

(Everything you see there is auto-detected on startup. I've been holding off on implementing any kind of persistent state in order to motivate myself to make the autodetection as smart as possible. I do, however, plan to add a superior competitor to Steam's categories sidebar with the sidebar in that screenshot relegated to just an automatically-managed category within the larger user-defined set.)

That said, I have already shared a couple of blog posts based on what I realized while working on it:

* A Compromise Between Substring And Prefix Matching
* A More Formal Way To Think About The Validity of Input Data

nor really, you can use it without an "account" for steam for linux games it'll recognize the games you already installed and set them as installed, for wined steam if pointed at the right directory it'll also set it as installed. I use the account more as a reminder of what I normally have set as installed, in case I decide to distro hop again

Uhmmm..... it has been, what, about twelve years since 64bit processors first came out. I think maybe the day when all 32bit CPUs but the weakest are 12 years old or older, such a move will be alright. So I think that move would be alright if you wait a little bit more (next autumn, winter?)

I think several distros are about to drop the 32bit versions in their new releases too.

I, for one, would be one of the players affected by such a move as one of my computers is 32bit only but it is so weak by today's standards that I am okay with it but please do remember to WARN BEFOREHAND, thank you.

Personally I prefer them as they are since I can extract them without running the installer. However If binary mode would still allow me to do that then it's ok for me. :-)

(May seem off topic): What I would really like to see from the Linux side is the Linux versions of games that are otherwise available on Humble/Steam. A few examples: Dust, Limbo, Dying Light, Master of Orion....etc. Most of these games have came without a Linux version on GOG and there's was no given reason as to why. Does GOG even ask for these versions when they're about to release a game they know it has a Linux version?

Thanks.

I have to say, personally I like the flexibility offered by the current system. I can still use games on my older 32-bit system or extract particular files if I wish.

The reason given (removing the risk of being opened in a text editor) I feel doesn't seem to warrant changing the installers yet again.

Having 64-bit only installer is fine with me, as long as it would be still possible to extract it without running if anything goes wrong (now it kind of works). If you will still use MojoSetup it should be good. But rather than worry about bitness, may be you can clean up MojoSetup a bit. A few things in it which are starting to bit rot:

1. It creates $HOME/.gnome every time. I don't think anything uses this directory these days, so it shouldn't be created.
2. May be it should be using GTK3 instead of GTK2 already. Things are moving to Wayland, and GTK2 shouldn't be used anymore.
3. May be use a somewhat better compression (preferably with ability for parallelized decompression to shorten installation time)? Windows installers for same games are quite noticeably smaller than Linux GOG packages.

Since Mojo is really open source, may be you can make a Gitlab / Github repo for your whole bundle (combination of Mojo and other things), then community can help contributing various fixes and improvements by submitting merge requests. Same applies to any other installer solution you might prefer. Just an idea.

Thanks!

Not till Gnome switches to GTK4. They should burn in HELL for their stupid habit of breaking compatibility with every minor release! At least GTK2 is stable and proven.

That would be great! The sh1tty "bzip2" algorythm should be sent into the trash bin long time ago. LZMA (xz utility) is better in every way. (and "gzip" is absolutely pathetic as a compressor)

looks interesting, need to take some closer look at it sometime.
though tbh, i'm more interested in the backend than the GUI at the moment, as I'm still looking for a better way
to automate setting up a game in wine (and i'm not a fan of PlayOnLinux).

so basically it is just a laucher for steam games that I already have installed locally ?
Can I use the offered wine install scripts to install a game from CD or GOG without having to register online?

Didn't they sell these low-cost laptops/netbooks with 32bit cpus until a few years back?
//edit:
basically stuff like this:

Not sure how widespread the use of 32bit cpus still is, and I doubt a forum survey will get reliable numbers.

The question for me would be rather what are the benefits of a 64bit installer ?
No distro will be dropping basic 32bit multiarch in the near future, so as long as the 32bit installer doesn't have a huge/weird dependency list it will work fine on a 64bit distro. And you'll make those (probably very few) 32bit users happy.
Switching away from that to a 64bit installer offers what advantages ?
Of course if the game is 64bit only then there is no point in providing a 32bit installer.

Not exactly. http://www.networkworld.com/article/3091818/linux/linux-distros-look-to-drop-32-bit-support.html

I wonder though, what it would mean for games in Wine which require 32-bit multiarch. It sounds like a looming problem. If distros are to drop that, 32-bit Wine games will become unusable. Same goes for a bunch of native Linux games which are unfortunately only available in 32-bit and aren't likely to get any updates.

read the linked mailing list post.
That mostly talks about getting rid of i386 installation media/kernel support. Multiarch support is going to be available for quite a bit longer. that is still a long way to go ...

//edit:
and that is just ubuntu
I doubt debian is going to drop i386 support this century :p