La Couronne de Cuivre

OK je comprends tout à fait, le temps nécessaire à maintenir ces listes spécifiques devait effectivement être monstrueux !

Quand tu parles d'installation de play.it et de ses collections, c'est via apt, je présume ? C'est plutôt cette méthode que tu préconises, c'est ça ?

Mornagest a écrit : mer. 21 mai 2025, 09:10 Quand tu parles d'installation de play.it et de ses collections, c'est via apt, je présume ? C'est plutôt cette méthode que tu préconises, c'est ça ?

Exact. Doublement.

Avec l’inconvénient que sur Debian 12 (Bookworm) on se retrouve avec une version qui date pas mal. Je pense que je vais ajouter des instructions pour installer, toujours via apt, les dernières versions de ./play.it sur Debian stable.

C'est pas urgentissime de mon côté je suis en train de réfléchir à refaire mon installation sur notre PC fixe car on a un vieux dual boot avec Windows 7, et j'aimerais m'assurer que les quelques jeux que nous avons sur Windows sont gérés soit par play.it, soit par Wine (même si c'est moins propre).

Tu as peut-être la réponse à cette question d'ailleurs : sais-tu si Divinity Original Sin 2 est pris en charge ? J'ai vu que le premier l'est, mais je n'ai pas fouillé toutes les listes proposées...

Mornagest a écrit : mer. 21 mai 2025, 15:34 sais-tu si Divinity Original Sin 2 est pris en charge ?

Il ne l’est pas encore, mais je crois que j’ai accès à un compte GOG sur lequel il a été acheté. Tu peux me donner le nom de l’installateur actuel (le fichier .exe, pas la peine de lister tous les .bin) ?

Si je ne me trompe pas, le voici :
À voir s'il s'agit de la même édition que celle à laquelle tu as accès, par contre...

Mornagest a écrit : mer. 21 mai 2025, 19:03 À voir s'il s'agit de la même édition que celle à laquelle tu as accès, par contre...

Mince, non seulement ce n’est pas la même mais en plus je n’y ai pas accès, contrairement à ce que je pensais.
La mienne semble dater de 2019 au plus tard : setup_divinity_original_sin_2_3.6.37.7694_(27830).exe

Tout spécialement pour @Althéa, ./play.it vient de recevoir la prise en charge de Divinity: Original Sin 2 !

Yeeeeeeeeeeees !!!! Merci beaucoup !!!!

C’est tout neuf, ./play.it prend maintenant en charge Diablo II et son extension Lord of Destruction !

Si ça intéresse du monde, je peux rédiger un guide d’installation comme pour les autres jeux dont on discute sur La Couronne de Cuivre.

vv221 a écrit : sam. 28 juin 2025, 20:38 Diablo II et son extension Lord of Destruction !

Diablo 2 resurrected ?

loupgris92 a écrit : dim. 29 juin 2025, 08:43 Diablo 2 resurrected ?

Non, Diablo 2 1.14b, la dernière version (à ma connaissance) à ne pas être lié au malware client de Blizzard.

./play.it ne prend en charge que des jeux sans DRM, c’est un choix éthique fait au tout début du projet.

Ok
(dommage que resurrected soit lié au client blizzard en effet, pour une fois qu'un remaster est fantastique )

loupgris92 a écrit : dim. 29 juin 2025, 14:48 dommage que resurrected soit lié au client blizzard en effet, pour une fois qu'un remaster est fantastique

C’est clairement frustrant, ce remaster et celui du premier StarCraft m’auraient bien tenté si Blizzard n’avait pas décidé de traiter les joueurs comme des criminels en puissance.

Je viens de re-travailler la documentation de ./play.it, qui utilise maintenant un style particulièrement épuré : https://doc.dotslashplay.it/index.fr.xhtml

N’hésitez pas à suggérer des ajouts, en particulier dans la section "Problèmes courants".

C'est un peu bling-bling, ta page

Je pense que tu peux raisonnablement indiquer qu'un gros jeu du genre BG3 nécessite une construction de paquets d'environ deux heures. Ça permet de donner un ordre d'idée, pour éviter que les joueurs ne se demandent si le processus n'est pas bloqué.

Mornagest a écrit : mar. 08 juil. 2025, 17:38 C'est un peu bling-bling, ta page

J’ai tout donné

---

Mornagest a écrit : mar. 08 juil. 2025, 17:38 Je pense que tu peux raisonnablement indiquer qu'un gros jeu du genre BG3 nécessite une construction de paquets d'environ deux heures.

Bien vu, j’ai ajouté un avertissement à ce sujet.

Une première version candidate pour la version 2.33.0 de ./play.it qui est en approche est disponible : https://git.dotslashplay.it/play.it/log ... ase/2.33.0

La liste complète des ajouts et modifications est disponible derrière le lien partagé au-dessus, et quelques uns des changements les plus intéressants sont mis en avant juste en-dessous.

---

Une meilleure prise en charge des jeux Adventure Game Studio :
En définissant la variable "AGS_NAME" depuis les scripts de prise en charge de jeux, plusieurs autres variables peuvent être omises, ce qui aboutit à des scripts beaucoup plus courts pour la prise en charge de jeux Adventure Game Studio via ScummVM.

Nouveau système pour les hacks basés sur LD_PRELOAD :
Inclure le code source en C d’un shim qui doit être chargé via LD_PRELOAD, en général pour contourner des bugs dans le jeu qu’on ne peut pas corriger sans accès à son code source, peut maintenant être fait via une variable unique : LD_PRELOAD_SOURCE.
Avant cet ajout, il fallait définir une poignée de variables différentes :
- PRELOAD_HACKS_LIST
- HACK_xxx_NAME
- HACK_xxx_DESCRIPTION
- HACK_xxx_PACKAGE
- HACK_xxx_SOURCE

Propriétés implicites pour les paquets :
Quand une propriété pour un paquet n’est pas définie, une propriété d’un autre paquet peut être utilisée automatiquement à la place. Ça réduit la quantité de déclarations de variables nécessaires pour certains jeux fournissant des binaires pour plusieurs architectures, et pour les jeux proposés avec plusieurs traductions.

Améliorations spécifiques aux jeux tournant via WINE :
Une nouvelle fonction "wineprefix_init_custom" peut être définie depuis les scripts de prise en charge de jeux, permettant de lancer des actions arbitraires lors de l’initialisation du préfixe WINE.
Une nouvelle variable "WINE_REGISTRY_INIT" peut être définie depuis les scripts de prise en charge de jeux, listant des clés de registre Windows qui doivent être définies avant le premier lancement du jeu.

---

Des rapports de test seraient les bienvenus, d’autant plus que nous n’avons pas accès actuellement à du matériel permettant de faire tourner des jeux de manière confortable et donc que cette première version a été bien moins testée que ce que nous faisons d’habitude. Au moment de signaler des problèmes, pensez bien à inclure le numéro de révision de la bibliothèque que vous avez utilisé, qui est retourné par la commande suivante :
grep library_revision ~/.local/share/play.it/libplayit2.sh

---

source : https://fediverse.dotslashplay.it/snac/ ... 398.037304

Une version candidate à la première mise-à-jour corrective de ./play.it 2.33 est prête : https://git.dotslashplay.it/play.it/log/?h=release/2.33.1

Voici les correctifs qu’elle inclut :

• Correction de la détection des binaires MS-DOS via file/libmagic.
• Amélioration du message d’erreur lorsqu’aucun binaire n’est trouvé pour un jeu Unity3D.
• Prévention du remplacement d’une valeur définie explicitement pour LD_PRELOAD_SOURCE par une valeur par défaut.
• Ajout de la prise en charge de l’auto-complétion pour certains shells interactifs :
  • - fish
  • - zsh
• Jeux WINE : Correction de l’inclusion du wrapper pour winetricks quand un moteur de rendu Direct3D autre que celui par défaut est utilisé.
• Jeux WINE : Prévention de la création d’un répertoire registry-scripts vide.

---

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

Pour les utilisateurs de ./play.it qui le font tourner sur une Debian stable, est-ce qu’il y en a parmi vous qui seriez intéressés par des backports de ./play.it ?

Je cherche à savoir s’il y a des personnes qui utiliseraient vraiment ces backports, pas juste des personnes qui pensent que ça pourrait être une bonne idée

En terme de prise en charge, qu'est-ce que ça changerait du côté utilisateur ?

Je suis sur Debian Trixie (actuellement stable, donc) et je n'ai pas installé play.it via les dépôts, Baldur's Gate 3 n'étant pas inclus dans les listes proposées dans les paquets de Debian stable. Donc je suis passé par ton script que tu fournis dans le sujet idoine. (je sais que tu es au courant, c'est surtout pour les autres utilisateurs que je le précise ).

Mais ça rend les éventuelles futures installations / mises à jour du jeu dépendantes de toi pour avoir un script opérationnel spécifique. Est-ce que ça change quelque chose pour toi si c'est proposé dans les backports plutôt qu'ici ?

Je pose sûrement des questions naïves, mais comme je ne connais pas les détails liés à la maintenance de paquets selon les divers dépôts... je ne me rends pas compte du travail nécessaire (ou non)

Les liens donnés sur le forum pointent sur les versions que je développe directement, donc des versions qui existent dans tous les cas. Elles ne me donnent pas de boulot supplémentaire, vu qu’elles sont le résultat de mon travail original, avant empaquetage pour Debian.

À savoir que contrairement à ce que tu écris, la prise en charge de Baldur’s Gate 3 est bien incluse dans les paquets proposés par Debian stable (Trixie). Pas au-delà par contre de la version 4.1.1.6072089 (patch 7, hotfix 3), dernière version prise en charge au moment de la préparation du passage de Debian Trixie en stable.

Avoir des paquets pour ./play.it dans les backports de Debian Trixie permettrait justement d’avoir, pour ceux qui installent ./play.it via les dépôts de leur distribution, accès à la prise en charge d’installateurs plus récents. Sans ceux-ci, ils ne peuvent bénéficier de la prise en charge que de ce qui était déjà publié quelques mois avant la sortie de Debian Trixie en stable.

Par contre préparer ces backports me demanderait du boulot supplémentaire. Pas seulement de manière ponctuelle, mais à chaque fois que je mets à jour ./play.it ou une de ses collections dans Debian unstable, je devrais y revenir 5 jours plus tard pour préparer en plus les backports pour Debian stable.

C’est pour ça qu’avant de potentiellement me mettre à fournir ces paquets supplémentaires à travers Debian, je cherche à m’assurer que cet effort (effort raisonnable, on parle probablement d’une heure de boulot chaque mois, pas plus que ça) sera vraiment utile à quelqu’un.

---

À titre personnel je préférerais qu’un maximum de personnes passent par les dépôts des distributions pour installer ./play.it, et activent le partage de statistiques anonymes sur les installations de paquets via poularity-contest, pour avoir une meilleure idée de la popularité de ./play.it mais surtout pour que ce soit plus facile quand je dépanne quelqu’un de savoir quelle version de ./play.it ils ont utilisé.

D’autant que ça simplifie aussi l’installation des dépendances, et des différentes collections de prise en charge des jeux, donc il y a moins de risque d’avoir des problèmes parce que seuls certains morceaux de ./play.it sont installés.

Merci pour toutes ces précisions

vv221 a écrit : ven. 29 août 2025, 20:12 À titre personnel je préférerais qu’un maximum de personnes passent par les dépôts des distributions pour installer ./play.it

Les dépôts classiques, ou les backports inclus ?

Pour ma part, j'ai installé popularity-contest (dès l'installation du système), mais comme je ne passe pas (pour l'instant) par le paquet play.it, ça ne va pas vraiment t'aider... enfin, j'imagine que je ne représente pas la majorité des joueurs.

Quand je parle des dépôts, c’est dans leur globalité, peu importe la branche : stable (avec ou sans backports), unstable, ou même Ubuntu.

Dans ce cas, tout à fait personnellement, j'aime autant utiliser une version des dépôts, backport dans mon cas... mais bon, ça implique du boulot en plus pour toi, donc c'est pas non plus l'idéal...

Ce n’est pas un boulot qui me rebute, bien au contraire, mais je veux être sûr de ne pas le faire pour rien, d’où ce sondage avant de me lancer

Une version candidate pour la seconde mise-à-jour corrective de la branche 2.33 est prête : https://git.dotslashplay.it/play.it/log ... ase/2.33.2

Voici la liste des correctifs inclus :

• Inclusion des fichiers nécessaires à l’autocomplétion dans les archives publiées.
• Jeux Visionaire : Ajout d’une dépendance explicite à SDL2.
• Archive AppImage : Vérification des outils requis.
• Arch Linux : Correction de la génération des préfixes WINE.
• Debian : Meilleure prise en charge de la compression gzip forcée pour les paquets allant au-delà de la taille limite pour le format .deb.

Merci de nous signaler tous les problèmes que vous rencontrez avec cette version candidate, ainsi que les bugs qui vous dérangent mais ne sont pas inclus dans cette liste.

---

source : https://fediverse.dotslashplay.it/snac/ ... 831.842006

S’il y a des germanophones parmi vous, je viens de publier une mise-à-jour groupée de la prise en charge de tous les jeux Infinity Engine, version classique et Enhanced Edition, pour ajouter la possibilité de jouer à la version allemande.

A quand Redfall ? Nan j'deconne, je sors...

Barbach a écrit : ven. 12 sept. 2025, 15:03 A quand Redfall ?

Je vois qu’il a un mode solo, et est développé sur le moteur Unreal Engine 4 pour lequel nous avons une particulièrement bonne prise en charge.

Donc blague ou pas, il ne manque en fait qu’une distribution sans DRM. À partir de là sa prise en charge ne serait l’affaire que d’une dizaine de minutes de travail

Une nouvelle version candidate est disponible, toujours à la même adresse : https://git.dotslashplay.it/play.it/log ... ase/2.33.2

Grâce aux retours de Jinini sur les forums de GOG, elle inclut des correctifs supplémentaires :

• Amélioration de l’identification automatique du système en cours d’utilisation.
• L’identification du système en cours n’est effectuée que si aucun format de paquet par défaut n’est déjà défini.
• Debian : Affichage d’une erreur explicite si la version de dpkg-deb n’a pas pu être identifiée.

---

source : https://fediverse.dotslashplay.it/snac/ ... 552.365389