La Couronne de Cuivre

Salut camarades Debianistes, Archers, Gentooistes et autres Linuxiens !

./play.it est un outil facilitant l’installation de toute une collection de jeux vidéo sur Linux, en générant des paquets natifs (.deb, .pkg.tar, etc.) à partir d’installateurs en tout genre. Ces paquets s’installent ensuite via le gestionnaire de paquets habituel de la distribution. Parmi ces installateurs gérés se trouvent ceux vendus sur gog.com pour Planescape: Torment, aussi bien ceux pour la version classique Planescape: Torment pour Windows que ceux pour la version Planescape: Torment Enhanced Edition pour Linux.

Les instructions d’utilisation se trouvent sur les pages suivantes :

• Planescape: Torment
• Planescape: Torment Enhanced Edition

Tout retour, que ce soit un rapport de bug, une suggestion, une requête, une demande de clarification, un insulte ou un simple « Merci » est le bienvenu dans cette discussion. Nous espérons que vous apprécierez le confort apporté par ce logiciel autant que nous nous amusons à l’écrire et l’améliorer !

Salut,

Beau boulot ! J'ai quelques petites remarques :

vv221 a écrit :Dans l'optique d'une intégration parfaite avec le système, nous allons installer le jeu sous /usr/local/games ce qui peut nécessiter des droits particulier pour votre utilisateur. La série de commandes suivantes donnera à votre utilisateur toto (à remplacer bien sûr par votre nom d'utilisateur) et par la suite à tous les utilisateurs du groupe "games" le droit d'écrire dans ce répertoire (ce qui servira non seulement à installer le jeu mais aussi à permettre la sauvegarde et d'autres fonctions nécessitant des écritures dans le répertoire du jeu). Ces commandes doivent être lancées en root, ou via sudo pour les systèmes configurées sans accès au compte root :

► Afficher le texte

addgroup games
chown :games /usr/local/games
chmod g+rwx /usr/local/games
adduser toto games

• Je t'invite à ajouter la commande "export WINEARCH=win32" lors de la création d'un préfixe Wine pour une application 32 bits, car sinon ça pourra poser des problèmes en fonction des distributions Linux ;
• D'un point de vue sécurité, ce n'est clairement pas une bonne idée de donner des droits d'écriture sur un dossier système pour un utilisateur, et encore moins à tout un groupe d'utilisateur. Je pense vraiment que tu devrais éviter ;
• Par convention, les programmes qui ne sont pas gérés par le système sont plutôt à placer dans /opt, je crois ;
• Ta méthode implique que les différents utilisateurs seront obligés de partager la même configuration de jeu, si toto la modifie elle sera changée pour titi également ;
• Au final, le jeu n'est pas disponible pour tous les utilisateurs, puisque tu mets le fichier .desktop dans le dossier .local/share/applications d'un seul utilisateur. Pour qu'il soit disponible à tous les utilisateurs du système, met-le plutôt dans /usr/share/applications.

La seule façon "propre" de régler ces problèmes et d'avoir le jeu disponible pour tous les utilisateurs est d'installer tous les fichiers du jeu qui n'ont pas besoin d'être modifiés dans /opt (ou dans /usr/local/games, peu importe), puis de créer un préfixe Wine pour chaque utilisateur dans lequel on va faire des liens symboliques qui pointent vers les fichiers du jeu. Les fichiers nécessitant d'être modifiés par l'utilisateur (ici, essentiellement torment.ini et les dossiers save et temp) seront eux directement copiés dans le préfixe Wine.

C'est certes beaucoup plus contraignant pour toi, mais en faisant comme ça

• les utilisateurs auront chacun leur config ;
• le jeu sera installé sur le système pour tous les utilisateurs sans avoir besoin de donner des droits d'écriture spécifiques.

Si tu veux, voici un exemple d'un script qui fait exactement ça (je l'ai réalisé pour un autre jeu, et pour une autre distribution Linux, mais le principe est le même) : https://aur.archlinux.org/packages/limbo/. Tu cliques sur "Télécharger l’archive", et tu regardes le script "launch_limbo".


N'hésite pas à me demander si tu veux des précisions !

Beau travail en effet. Ta procédure diffère assez bien de celle que j'utilise en général pour les jeux Infinity Engine... à savoir : double-cliquer sur l'installateur et suivre la procédure comme pour une installation sur Windows. Cela dit, je n'ai jamais essayé d'installer PsT sur Debian donc j'ignore si cela fonctionne aussi simplement.

Comme Mirandir, quid de l'installation dans /usr/share, plutôt réservée aux programmes issus des dépôts ?

Quelques commentaires sur la proposition de vv221, en rebondissant partiellement sur ceux de mirandir

mirandir a écrit :Ta méthode implique que les différents utilisateurs seront obligés de partager la même configuration de jeu, si toto la modifie elle sera changée pour titi également

Je suis d'accord sur ce point. À moins de manquer de place sur le disque dur, il me semblerait en fait plus adapté de faire une installation différente par utilisateur, dans $HOME (quitte à, pour gagner du temps, copier-coller l'installation fraîche dans les $HOME des autres utilisateurs à la fin plutôt que de leur réinstaller indépendamment à chacun. D'autant que, bien que le système soit multi-utilisateurs, tout le monde n'utilise pas un compte spécifique par personne ; la plupart des ordis que je croise sont encore en monosession.

La solution proposée par mirandir (liens symboliques) fonctionne évidemment aussi et est assez élégante, mais elle serait encore plus compliquée à gérer pour, par exemple, un Baldur's Gate II où chacun installe ses propres mods.

mirandir a écrit :D'un point de vue sécurité, ce n'est clairement pas une bonne idée de donner des droits d'écriture sur un dossier système pour un utilisateur, et encore moins à tout un groupe d'utilisateur. Je pense vraiment que tu devrais éviter

J'ajouterais que, si la machine ne comporte qu'un seul compte utilisateur (genre, un portable perso) ou qu'une seule personne compte jouer aux jeux, aller chercher les répertoires systèmes et modifier les groupes est assez overkill : inutile de modifier les permissions et droits d'accès si tout est faisable sur le même compte utilisateur.

mirandir a écrit :Par convention, les programmes qui ne sont pas gérés par le système sont plutôt à placer dans /opt, je crois

Je crois que /opt était utilisé historiquement, mais que la plupart des gens préfèrent maintenant utiliser /usr/local. Un peu comme il y a eu le changement /mnt → /media, ou bien l'apparition de /srv.


Une petite remarque supplémentaire : tout le monde ne joue pas en plein écran

Merci de vos retours !

Pour ce qui est de /usr/local, cette arborescence est réservée aux programmes installés depuis une autre source que les dépôts (par opposition avec /usr/share). Le choix de celle-ci ou de /opt est essentiellement cosmétique.

Pour l'installation globale des .desktop dans /usr/local plutôt que ~/.local, c'est en effet une meilleure idée. Ça m'était sorti de la tête a force de n'utiliser que des systèmes mono-utilisateurs.

Je vais regarder du côté de WINEARCH, je n'ai jamais eu besoin d'utiliser cette option (wine fonctionne-t-il vraiment en 64-bit ?) mais si elle est nécessaire sur certaines distributions je vais l'ajouter.

Un système de liens symboliques pour obtenir une configuration par utilisateur me paraît une excellente idée !
Je vais essayer de repérer la liste de tous les fichiers ayant besoin d'être modifiés par l'utilisateur pour implémenter ça.

Par contre, pour ce qui est de l'installation globale dans $HOME, pas besoin dans ce cas de ce tuto : la méthode de Mornagest "double-clic et ça marche" fonctionne dans ce cas tout aussi bien et surtout beaucoup plus simplement.
Si je me concentre sur l'installation dans /usr/local, c'est parce que je vise à terme un script permettant de créer un paquet .deb à partir de l'installeur GOG (et, qui sait, un .rpm ou autre joyeuseté quand je saurai m'en servir).

Si je conseille un changement de groupe de /usr/local/games, c'est essentiellement pour éviter d'avoir à lancer wine en root.
Ça pourrait simplement être remplacé par l'ajout de l'utilisteur au groupe staff (qui donne les droits d'écriture sur /usr/local).

Pour le plein écran, c'est bien sûr une généralisation abusive de ma part
Je vais rajouter un avertissement à ce niveau !

-----

Hé bé, je ne m'attendais pas à obtenir de réponses aussi vite, et surtout pas autant de critiques constructives !
Ça fait plaisir de voir que je ne suis pas le seul à faire tourner Torment sous Linux.

Je note tout ce que vous m'avez conseillé, et je me lance dans un deuxième jet.

Merci !

C'est l'avantage d'installer les jeux dans /home : tu évites toute manipulation en tant que root... par contre, tu ne peux utiliser le jeu que sur un seul compte d'utilisateur... pour ma part, je ne tourne qu'en simple utilisateur donc ça ne me pose pas de problèmes particuliers

Compiler en .deb, Billou du forum Ubuntu en parle ici mais je ne sais pas si son projet a abouti. Il y a un lien dans son premier message vers une page de doc, avec une marche à suivre. Comme je n'ai jamais testé, je ne sais pas si ça fonctionne, mais si tu as le temps, ça devrait t'intéresser

Bon courage !

vv221 a écrit :Pour ce qui est de /usr/local, cette arborescence est réservée aux programmes installés depuis une autre source que les dépôts (par opposition avec /usr/share)

Par opposition à /usr tout court /usr/local est censé avoir la même arborescence interne, avec notamment un répertoire bin pour les exécutables et un répertoire share pour les ressources.

vv221 a écrit :(wine fonctionne-t-il vraiment en 64-bit ?)

Oui ; mais la plupart des systèmes, à ma connaissance, sont plutôt en train de s'orienter vers la solution du multiarch (donc, l'installation de la version 32 bits de wine, quelle que soit la version du reste du système)

vv221 a écrit :Un système de liens symboliques pour obtenir une configuration par utilisateur me paraît une excellente idée !
Je vais essayer de repérer la liste de tous les fichiers ayant besoin d'être modifiés par l'utilisateur pour implémenter ça.

Hors cas de mods, il me semble que ce serait effectivement la solution la plus indiquée.

vv221 a écrit :Si je conseille un changement de groupe de /usr/local/games, c'est essentiellement pour éviter d'avoir à lancer wine en root.
Ça pourrait simplement être remplacé par l'ajout de l'utilisteur au groupe staff (qui donne les droits d'écriture sur /usr/local).

Avec un vrai paquet (à installer en tant que root, donc, mais qui ne concernerait que l'installation) et la solution des liens symboliques, ce genre de soucis disparaîtrait

Le paquet place toutes les ressources « fixes » du jeu dans /usr/local/share, et le script (ou plutôt les, cf juste en dessous) dans /usr/local/bin ; script qui va vérifier automatiquement la configuration des ressources utilisées (copie des fichiers de configuration + liens symboliques vers le restes) dans le ~/.local/share de l'utilisateur) avant de lancer le jeu.

vv221 a écrit :Pour le plein écran, c'est bien sûr une généralisation abusive de ma part
Je vais rajouter un avertissement à ce niveau !

Je suggérerais deux scripts d'exécution différents, l'un lançant en plein écran et l'autre en fenêtré (avec juste une modif (un coup de sed, par exemple) sur le fichier ini pour s'assurer d'avoir la bonne option ; et bien sûr, l'appel à xrandr dans le premier des deux seulement).
D'ailleurs, tu peux, pour mieux automatiser la chose, faire en sorte que le script de plein écran récupère lui-même la résolution actuelle (xrandr permet ça aussi, 'me semble) avant de la réduire, pour la remettre à la fin sans que l'utilisateur n'ait à modifier le fichier.

Elzen a écrit :Je suggérerais deux scripts d'exécution différents, l'un lançant en plein écran et l'autre en fenêtré (avec juste une modif (un coup de sed, par exemple) sur le fichier ini pour s'assurer d'avoir la bonne option ; et bien sûr, l'appel à xrandr dans le premier des deux seulement).
D'ailleurs, tu peux, pour mieux automatiser la chose, faire en sorte que le script de plein écran récupère lui-même la résolution actuelle (xrandr permet ça aussi, 'me semble) avant de la réduire, pour la remettre à la fin sans que l'utilisateur n'ait à modifier le fichier.

Ouaip, c'est ce que je cherchais à faire, mais je vais devoir apprendre à me servir un peu mieux de grep+awk pour obtenir la résolution actuelle depuis xrandr (il ne veut pas me la cracher dans un format direcetement exploitable "largeur x hauteur").
Et pour la modification de l'ini, c'est sed qui me fait défaut...

Bon, il n'y a pas 36 solutions : man awk, man sed et au boulot !

@ Mornagest : Merci pour le lien, je sens que ça va être un énorme coup de pouce !

Pour xrandr, à première vue : Pour sed, pour mettre en plein écran, (pour mettre en fenêtré, simplement inverser 0 et 1).

Je n'ai pas Planescape sous la main, mais ça doit être la même chose, il doit suffire de repérer la bonne option si ce n'est pas celle-là.

N'hésite pas à demander si tu as besoin

Ah, parfait !
Non seulement ta ligne xrandr fonctionne nickel, mais en plus j'ai compris comment elle fonctionne ! tr et cut viennent de s'ajouter à ma maigre boîte à outils.

Pour la gestion plein écran/fenêtré avec sed je vais tester ça dès que j'en aurai fini avec la compilation de wine 1.6 (sur un Sempron 3000+ faut pas être pressé).

-----

C'est bon, je m'en suis sorti avec sed.

Merci encore pour le coup de main !

Reste à installer les raccourcis et les icônes de façon globale, mais ce n'est l'affaire que de 2~3 mots à changer dans les lignes de commandes proposées, ce sera vite fait.

Après ça je me pencherai plus sérieusement sur la possibilité d'une installation globale du jeu avec une configuration par utilisateur.
D'ailleurs, connaissez-vous d'autres fichiers qui seraient concernés que "torment.ini" ? ("save" et "temp" ne sont pas créés à l'installation et seront donc beaucoup plus simples à gérer)
Je vais avant tout jeter un oeil sur le script de mirandir histoire de voir comment on peut gérer tout ça...

-----

OK, l'installation globale des icônes et raccourcis est assurée, je peux maintenant me plonger dans le boulot de mirandir pour tenter de concilier installation globale et configuration par utilisateur.

Voili voilou :
* plus besoin de modifier les droits des utilisateurs, c'est root qui installe
* l'installation est globale, la configuration et les sauvegardes locales

Ne me reste donc plus que deux points sur lesquels me concentrer :
* la possibilité pour chaque utilisateur du système de modder son jeu localement (j'ai déjà la méthode en tête, ça sera facile)
* la traduction en français des textes (et peut-être des voix si je trouve un PC avec une meilleure connexion au Net que celui-ci)

Un grand merci à mirandir qui m'a franchement mâché le boulot pour toute la partie install globale / config locale !

Au passage, si quelqu'un peut me passer un lien vers les fichiers .tlk de la version française patchée, je n'ai plus assez d'aspirine pour lancer une nouvelle recherche après ma journée passée sur ce tuto...

vv221 a écrit :* la possibilité pour chaque utilisateur du système de modder son jeu localement

À mon humble avis, le meilleur moyen, pour ça, c'est de faire carrément une autre copie du répertoire de données. Tu peux éventuellement faire en sorte que les liens symboliques vers les fichiers qui vont être modifiés par la plupart des mots (je suppose, le dialog.tlk et le répertoire override) soient remplacés par des copies physiques, mais je pense qu'on trouvera toujours un mod qui a besoin d'aller trifouiller des fichiers ailleurs.

vv221 a écrit :Au passage, si quelqu'un peut me passer un lien vers les fichiers .tlk de la version française patchée, je n'ai plus assez d'aspirine pour lancer une nouvelle recherche après ma journée passée sur ce tuto...

Juste au dessus de ton sujet, il y a ceci : http://www.baldursgateworld.fr/lacouronne/planescape-torment/26392-guide-section-planescape-torment.html, qui pointe vers un bon guide d'installation qui a tous les fichiers nécessaires

@ Elzen : Tu viens de me faire remarquer mon erreur : je croyais que les mods remplaçaient les fichiers par des versions modifiées (fournies par le mod lui-même) auquel cas la version modifiée aurait simplement écrasée le lien, m'évitant par là une nouvelle migraine...
Mais il est tout à fait possible que des fichiers soient modifiés directement et là je ne vois pas non plus d'autre solution que la copie complète des données.
Bah, j'y réfléchirai plus tard, je ne suis plus au top de ma concentration !

@ mirandir : Houla, il est vraiment temps que j'aille me coucher, je n'ai plus les yeux en face des trous...

vv221 a écrit : Mais il est tout à fait possible que des fichiers soient modifiés directement et là je ne vois pas non plus d'autre solution que la copie complète des données.

C'est même le cas dans 99% du temps. J'ai peur que rendre une installation de ce type compatible avec le moding soit très difficile !

La seule solution qui me vienne en tête est de créer un script "d'initialisation du modding" qui remplacera l'intégralité du système de liens symboliques par une copie du dossier en /usr/local/games.
Les avantages sur une installation standard dans /home :
* la possibilité de relancer ce script pour réinitialiser le dossier du jeu et s'épargner l'étape de réinstallation pour repartir sur une base clean (avec une conservation des sauvegardes ? est-ce vraiment utile si la base de mods change ?)
* la possibilité de revenir au système de liens symboliques et à un jeu non-moddé (même question au sujet des sauvegardes)
* l'automatisation (via le script d'initialisation) du téléchargement et de l'installation de WeiDU pour Linux
* des wrappers autour de WeiDU du type "pstorment-mod-add" & "pstorment-mod-rem" pour respecivement ajouter et enlever un mod

Sans-Nom parle maintenant français ! (les textes uniquement, pour les sons j'ai de sacrés doutes du côté de la légalité de la manoeuvre)

Ne reste vraiment plus que la partie modding, je n'ai plus d'autre choix que de me pencher dessus sérieusement pour trouver une solution efficace et élégante...

-----

La configuration manuelle des lecteurs de Wine a été remplacée par une configuration automatique pour simplifier le processus.

vv221 a écrit :* la possibilité de relancer ce script pour réinitialiser le dossier du jeu et s'épargner l'étape de réinstallation pour repartir sur une base clean (avec une conservation des sauvegardes ? est-ce vraiment utile si la base de mods change ?)
* la possibilité de revenir au système de liens symboliques et à un jeu non-moddé (même question au sujet des sauvegardes)

Non, ce n'est pas nécessaire, les sauvegardes ne seront pas compatibles.

vv221 a écrit :Sans-Nom parle maintenant français ! (les textes uniquement, pour les sons j'ai de sacrés doutes du côté de la légalité de la manoeuvre)

C'est le même niveau de légalité que pour les textes

mirandir a écrit :C'est le même niveau de légalité que pour les textes

Les fichiers .tlk français ne sont-ils pas distribués dans le patch officiel ?
Si c'est le cas je pourrais tenter d'écrire un script qui télécharge le patch puis en extrait les fichiers .tlk, on pourra difficilement dans ce cas m'accuser de mettre à disposition des ressources du jeu

Je me renseigne sur la légalité parce que je pense traduire ce tuto et le publier sur les forums de GOG, où je pense qu'ils doivent être plutôt stricts sur ce sujet.

-----

Aïe !
Si tout marche parfaitement sur ma première machine de test (Debian Sid 32-bit avec accès au compte root via sudo), sur une deuxième (Debian Sid 64-bit avec accès au compte root via su) je me retrouve au moment ou Wine tente de créer sa première fenêtre avec l'erreur très classique :
"No protocol specified
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly."

Un echo $DISPLAY en utilisateur comme en root renvoie la même valeur.
Je vais me renseigner sur les forums Debian à ce sujet, mais si vous avez une suggestion pour me débarrasser de cette erreur je suis preneur !

-----

Un simple fichier à copier (.Xauthority) et le tour est joué, ce problème aura été vite réglé !

Par contre, j'en profite pour découvrir que KDE semble ignorer royalement /usr/local/share/applications pour remplir son menu…

Ah, les joies des différences de fonctionnement entre les environnements de bureau !

-----

C'est bon, ces deux situations problématiques sont gérés par le tuto.

La dernière étape est franchie : Planescape est moddable localement, et un script est fourni pour le rétablir à un état vierge (moddable mais sans aucun mod d'installé).
Je lance un appel aux tests maintenant que le contenu est fixé, n'hésitez pas à malmener ce tuto sur les configurations les plus exotiques possibles

Le guide a été entièrement réécrit :
* plus d'appels à root inutiles
* une intégration au système de paquets de la distribution
* des paquets copiables simplement d'une machine à une autre
* un présentation moins désagréable à lire
* une nombre d'interventions nécessaires de la part de l'utilisateur réduit au strict minimum

PS : Merci Mornagest, les infos de ton lien ont été exactement ce qu'il me fallait pour qu'enfin ce guide fasse son boulot correctement !

Salut,

Si l'utilisateur installe le mod Widescreen et choisi une autre définition d'écran, ton script pour lancer le jeu en plein écran risque de se comporter bizarrement, non ? Vu qu'il passe la définition en 640x480.

Y a pas de quoi j'avais suivi l'affaire à l'époque, de loin certes, mais je m'étais dit que ce serait sûrement utile.

J'ai la version 2 CD à la maison, je tenterai de l'installer selon ta méthode pour voir si cela fonctionne également. Autant avoir un maximum d'infos sur les différentes versions...

À moins que Mirandir se soit déjà chargé du test mais de toute façon, comme ça, j'aurais le jeu installé sur Debian, na

Encore bravo et merci

Pour widescreen, j'avais déjà repéré le problème et je pense écrire un script spécifique à l'installation de ce mod qui modifiera automatiquement la résolution appliquée par "pstorment-fullscreen".
Il ne me manque plus pour ça qu'un peu de temps, un écran large et un tube d'aspirine !

@ Mornagest : Pour installer Planescape depuis la version 2CD, tu vas devoir modifier le premier script fourni pour qu'il ne cherche plus un fichier exécutable mais un CD-ROM, ainsi que supprimer la partie concernant "ddrawfix".
J'ai déjà écrit quelques scripts pour les versions CD d'autres jeux (Freelancer, Civilization II et Une Faim de Loup pour ne pas les nommer), je pense que les adapter ne devrait pas me prendre trop de temps.

OK, je verrai donc ça (si j'y arrive sinon je te harcèlerai ici même ). Merci !

Mornagest a écrit :À moins que Mirandir se soit déjà chargé du test mais de toute façon, comme ça, j'aurais le jeu installé sur Debian, na

Non, pas testé, je n'utilise pas une distribution basée sur Debian. En plus, si je repars sur Planescape: Torment, z'êtes pas prêt de me revoir

mirandir a écrit :Non, pas testé, je n'utilise pas une distribution basée sur Debian. En plus, si je repars sur Planescape: Torment, z'êtes pas prêt de me revoir

Si tu connais un lien vers une explication simple pour construire des paquets pour Archlinux, le temps de monter une machine virtuelle et les paquets .deb ne seront plus les seuls fournis par ces scripts

Je suis tombé par hasard sur l'utilitaire innoextract…
Une partie des scripts a été réécrite pour l'utiliser : on peut maintenant créer les paquets sans Wine (il reste le moyen le plus simple pour jouer, mais on peut par exemple utiliser le paquet pstorment-data avec GemRB).

-----

Fini les lignes à copier et les risques d'erreurs qui viennent avec !
Je propose maintenant une archive contenant le paquet pstorment.deb (contenant les lanceurs et nécessitant le paquet pstorment-data.deb pour fonctionner) et le script pstorment-data-create-from-gog.sh. Il suffit de modifier ce dernier pour y renseigner le chemin vers l'installeur GOG, puis de l'exécuter pour créer le paquet pstorment-data.deb.

Script et guide mis à jour :
_ré-écriture totale du script
_support d’une installation simplifiée de quelques mods populaires (liste extensible sur demande)

Nouvelle ré-écriture du script, maintenant compatible avec les nouveaux installeurs .sh pour Linux vendus sur GOG (basés sur MojoSetup).
Comme les versions françaises des jeux ne sont pas encore de retour en ligne, une archive de traduction est proposée en deux versions (textes uniquement ou traduction complète) pour construire une version française du jeu à partir de l’installeur en version anglaise.

J’en profite pour annoncer que j’ai enfin une version sur 4 CD du jeu sous la main, et donc qu’un script gérant la construction d’un paquet .deb à partir de ceux-ci sera bientôt en travaux

À vos jeux !