For those of you who would like to help our constant work to expand and improve ./play.it, we now have some basic contribution guidelines to ease you into it: https://git.dotslashplay.it/scripts/about/#contributing

./play.it 2.32.0 feature update is under preparation, I plan to share ~daily news about what is going into it through our Fediverse account: https://fediverse.dotslashplay.it/snac/playit/p/1734044054.402702

The set of updates to be included in the incoming 2.32.0 feature release has just been frozen, so we have a first release candidate (library version 20241225.1): https://git.dotslashplay.it/scripts/log/?h=release/2.32.0

Here is a summary of the improvements and new features that are going to be part of this release:
* Improvements to MD5 hashes caching
* Predictable ordering for archives list
* New default paths for game scripts collections
* Graphical terminal spawning from launchers
* Improved support for Debian-provided DXVK
* Improvements to winetricks handling
* Expanded context support for GAME_ID
* Ren'Py write access to the game directory
* Case-insensitive archives content

A more detailed changelog can be found on our releases tracker: https://forge.dotslashplay.it/play.it/play.it/-/issues/555

As usual you can expect this update to be thoroughly tested on Debian Sid, but for other supported systems (Debian stable, Ubuntu, Arch Linux, Gentoo, etc.) we rely on feedback by users and contributors. So if you want to ensure nothing is going to break on your system, especially if you do not use Debian Sid, please consider testing this release candidate with your favourite games.

There is not deadline for the release, it will mostly depend on the free time of the people testing it and doing the actual release. Unless bugs are reported it might happen in a couple days, maybe very early January. If bugs are spotted (there are bugs, no doubt about that, but we rely on feedback to spot them) the release will be delayed for as long as required to fix all of them.

---

Original message on the Fediverse

I briefly crawled from under my rock to check what is new with ./play.it.
Only now did I noticed the (not recent) "collection of game scripts", and I was a little puzzled by it.

This "split" does not seem to address any technical problem, so I can only hypothesize it tries to appease some conflict between contributors. Would you mind talking a little bit about the game script collections?

Thank you for your work.

There has been two splits:

The first one at the time of ./play.it 2.16 (June 2022) was to dissociate the development of the library, based on feature releases and bugfix releases, and of the game scripts collection, with no releases. Since they had very dissimilar release models, it made no real sense to tie their development together.

It gave the ability to start third-party collections, the hope at that time was that contributors would start personal collections including their favourite games, thus reducing the maintenance load for the community-maintained collection. Sadly I was for a long time the only one who started my own collection, so the maintenance load did not change significantly.

The second one is much more recent, and is about splitting the huge community collection into small thematic ones (adventure, puzzle, etc.), to help with the discoverability of supported games. This one is still a work in progress, we only have two thematic collections out of 8~10 planned.

Once again I have hope it can help the maintenance, this time mostly by finding new co-maintainers who might be motivated by specific genres of games (like if you only play puzzle games, it could make sense joining in the maintenance of the puzzle games collection).

As surprising as it might sound for a free software that has been more than ten years under development, we never had any kind of conflict between contributors ;)

Great to hear you never had any conflicts. And I hope it continues that way.
I hope it won't make it hard for new contributions to be merged in.

It should actually make that easier, because now contributors have two choices:
- Ask for their contribution to be included into one of our team-maintained collections;
- Start their own collection, so they don’t have to rely on us reviewing anything.

I wanted to do that for a long time, this is finally ongoing: I’m getting rid of the GitLab instance hosted on forge.dotslashplay.it!

I had already removed the git repositories from this forge, in favour of tools much lighter and pleasing to both maintain and use. So they can be found at git.dotslashplay.it, that is relying on cgit and gitolite. But I was still missing something to handle the tracking of bugs and requests…

Then the obvious hit me (ouch!): I already have the perfect system for that. Email. That’s it.

I’m talking a bit more about this on the Fediverse: https://fediverse.dotslashplay.it/snac/playit/p/1746833536.923345

A first release candidate for the upcoming ./play.it 2.33.0 feature release is ready: https://git.dotslashplay.it/play.it/log/?h=release/2.33.0

The full changelog is available from the above link, a couple highlights follow.

---

Improved support for Adventure Game Studio games:
By setting a single variable "AGS_NAME" from game scripts, some other variables can be omitted, leading to much shorter game scripts when adding support for an Adventure Game Studio Game running through ScummVM.

New system for LD_PRELOAD hacks:
Including the source code of a C shim that should be loaded through LD_PRELOAD, usually to work around bugs in the game we can not fix without access to their source code, can now be done through a single variable: LD_PRELOAD_SOURCE.
Prior to this update, it required setting a bunch of variables:
- PRELOAD_HACKS_LIST
- HACK_xxx_NAME
- HACK_xxx_DESCRIPTION
- HACK_xxx_PACKAGE
- HACK_xxx_SOURCE

Package properties fallback values:
When a property for a given package is unset, it can fall back on the property set for another package. This reduces the amount of boilerplate needed in game scripts adding support for games coming with binaries for several architectures, and for games with multiple localisations.

Improvements specific to WINE games:
A new function "wineprefix_init_custom" is exposed to game scripts, allowing to run any arbitrary actions on the WINE prefix initialisation.
A new variable "WINE_REGISTRY_INIT" is exposed to game scripts, allowing to set Windows registry keys that should be set prior to the game first launch.

---

Test reports would be welcome, especially as due to lack of access to hardware able to run games in correct conditions this first release candidate has seen unusually few tests. When reporting problems please make sure to include the library revision number, that can be fetched with:
grep library_revision ~/.local/share/play.it/libplayit2.sh

---

source: https://fediverse.dotslashplay.it/snac/playit/p/1753361398.037304

The first bugfix release candidate for ./play.it 2.33 is ready: https://git.dotslashplay.it/play.it/log/?h=release/2.33.1

Here is its changelog: ---

source: https://fediverse.dotslashplay.it/snac/playit/p/1756034534.145410

./play.it release candidate for a second 2.33 bugfix update is ready: https://git.dotslashplay.it/play.it/log/?h=release/2.33.2

Here is a list of included fixes: Please report any problem you get with this release candidate, or any bug that is affecting you but is not listed here.

---

source: https://fediverse.dotslashplay.it/snac/playit/p/1757255831.842006

Hello. Let us imagine I could get access to a time-travelling machine and I got free time that I could allocate to ./play.it (after getting rich from all that stock and crypto trading).

Either from a list of game names or a local backup of GOG installers, would it be possible to easily produce a list of games that
a) I could transform using ./play.it; and/or
b) That I could try to add initial support for ./play.it?

Yes, and it would actually be quite easy to build these two lists.

First you need to install ./play.it (obviously) and all collections. Then run the following command on each of your game installers: If the installer is already supported, the path to a script is displayed: If it is not supported yet, you get an error instead: In the first situation, a success return code is sent, and in the second one a failure return code instead. You could use that to write the installer names in either of two lists (supported installers vs. not supported installers).

A new release candidate is available, still at the same URL: https://git.dotslashplay.it/play.it/log/?h=release/2.33.2

Thanks to Jinini feedback on GOG forums, it includes extra fixes: ---

source: https://fediverse.dotslashplay.it/snac/playit/p/1757691552.365389