Thanks. Saved me a hassle.

Out of curiosity, what games did you install with ./play.it?

I'm sure you're aware, but the RSS feed seems to be working now. Thank you!

It has been updated in Debian thanks to your request, I had not noticed the update had already been installed on my instance (I automated system upgrades).

I will check that the snac2 dev is aware that their fix works as expected.

Cool. FWIW, the individual posts are missing "pubDate" (datetime of publication) fields.

Is it still about the RSS feed?

Yes

Some GOG game installers for Linux do not include some old versions of libraries that I need to hunt for. It has been more and more difficult to find those when I realise I need them.
Can you tell me if ./play.it handle those cases?
For example, I think I never got Risk of Rain to run.

Support for Risk of Rain is included in ./play.it. Running "play.it gog_risk_of_rain_2.1.0.6.sh" will give you the download URL for the archives providing the required obsolete libraries.

Great! Thank you for the reply. I should try one day. I have been away from ./play.it for quite a bit.

While I have your attention, I tried to modify the original code a few years ago to add the option of producing a file tree with just the game files instead of a package.The idea was that other outputs could be built from there. My intention was to create a squashfs from it -- FUSE supports squashfs and overlayfs, and I made it work fine for some games. Later it came to me that that could, perhaps, enable other back-ends like Flatpack, Snap or Appimage -- you provide the raw directory structure and someone else could work from there.

The code was widely documented and well structured, but not very noob friendly. As a non-shellscript expert, I spent quite some time trying to figure out the flow of the code and why things were not working out as I expected them to. That is my feedback: I wish there was a high-level overview of how things work (and some times, why) to welcome new contributors.Also, a link to some place with tips on how to debug bash code would have saved me some time. I am not complaining, just suggesting.

By now I expect my half-amator code to be very out-of-synch. And my 20-something hours of so of work would take someone like you 20 minutes to accomplish.

Should you have the time and the inclination, these are my suggestions (TLDR version):
- have some welcoming documentation (I would happily help with that, reviewing it and discussing it and making suggestions/questions)
- creating the "final" tree and exiting, before generating any package-specific files, and without generating the package archive

In any case, thanks again for your work and dedication all these years.

This is something I would love to have, but never found the good combination of time+motivation to work on it. Some contributors worked on drafts, but they probably ended up lagging far behind the current codebase state because of a lack of review and updates.

This sounds like a relatively easy first task to get used to our codebase, if you would like to work on it feel free to ask for help on the #play.it IRC channel (OFTC network) or on forge.dotslashplay.it.

Another way to get familiar with our codebase would be to pick up tasks marked as "first contribution".