Le projet Enemy Territory: Legacy est basé sur le code source de Wolfenstein: Enemy Territory, un jeu vidéo de tir subjectif multijoueurs se déroulant durant la Seconde Guerre mondiale et développé par Splash Damage. Sorti en 2003, ce jeu gratuit tournant sur une version modifiée du moteur id Tech 3 (plus connu sous le nom de Quake Ⅲ engine) fut libéré en avril 2010 par Id Software sous licence GNU GPL v.3.
Les buts majeurs du projet ET:Legacy sont d’éradiquer les bogues du moteur, nettoyer le code et le rendre jouable sur les principaux systèmes d’exploitations, tout en restant compatible avec les serveurs de la version propriétaire ET 2.60b, ainsi qu’avec autant de mods existants que possible. Le mod Legacy livré par défaut vise à ajouter de nombreuses fonctionnalités et améliorations, tout en restant proche de la jouabilité d’origine.
En attendant une version stable qui se fait attendre, voici quelques nouvelles du front…
Sommaire
- De Wolfenstein 3D à ET:Legacy
- La reprise du développement et le problème juridique
- Les tentatives d’amélioration
- Jouabilité
- Nouveautés depuis la version 2.60b
- Configurations prises en charge
- Le futur d’ET:Legacy
- En conclusion
- Et pour tester ?
De Wolfenstein 3D à ET:Legacy
ET:Legacy tire ses plus profondes racines de Wolfenstein 3D, l’ancêtre de Doom, developpé par Id Software en 1992 (et communément appelé « Wolf 3D »). Le joueur incarne un soldat Allié qui se retrouve prisonnier dans un château nazi dont il doit s’échapper. Ce jeu a rendu populaire le genre du tir subjectif (FPS).
Publié en 2001, toujours par Id Software, Return to Castle Wolfenstein (RTCW) est un reboot couronné de succès de Wolf 3D. En effet, son mode multi-joueurs est devenu la partie la plus renommée du jeu, ayant même une influence considérable sur le genre. Ayant travaillé sur quelques unes des cartes de l’édition « Game of the Year » de RTCW, le studio indépendant londonien Splash Damage s’est vu confier le travail sur la partie multijoueurs de la suite de RTCW.
Wolfenstein: Enemy Territory était à l’origine prévu pour être publié en tant qu’extension de RTCW, puis plus tard comme un jeu autonome. Toutefois, en raison de problèmes avec la partie solo, la sortie commerciale fut annulée tandis que la partie multijoueur du projet fut mise à disposition en mai 2003 en tant que jeu gratuit, ce qui explique sa popularité et sa très longue longévité. En janvier 2004, un SDK fut publié au profit de la communauté, permettant de créer de nouvelles cartes et modifications.
Tandis que le code du moteur de Quake 3 était disponible depuis 2005, les versions modifiées des moteurs d’Enemy Territory et de Return to Castle Wolfenstein n’ont été libérées qu’en 2010, permettant alors à la communauté de s’essayer à la maintenance et à l’amélioration du logiciel.
La reprise du développement et le problème juridique
Avec une base de code commune à Quake 3, les développeurs derrière le projet libre ioquake3 chez icculus.org se sont naturellement intéressés à ce nouveau code libéré, annonçant immédiatement que le travail sur iowolfet et iortcw commençait. Cependant, si la base de code est très similaire, il existe une cruciale différence qui n’a rien à voir avec la technique, mais relève d’une question juridique : le moteur de Quake 3 a en effet été publié à l’origine sous licence GPLv2, tandis que les nouveaux moteurs sont sous licence GPLv3.
En d’autres termes, il n’était pas possible de transférer les améliorations du moteur iowolfet dans le code de ioquake3, bien plus avancé et plus propre sur de nombreux points grâce au travail apporté sur plusieurs années. L’unique solution consistait ainsi à transférer dans iowolfet les améliorations déjà faites dans ioquake3. Cependant, comme personne n’aime faire le travail deux fois, et à cause de possibles ambiguïtés juridiques liées à certaines parties de code dans ioquake3 qui étaient à l’origine sous GPLv2 uniquement, les dépôts iowolfet et iortcw d’Icculus ont végété dans leur coin, sans modifications notables.
Mais différents projets ont surgi à de nombreux endroits à travers le web. La plupart (sinon la totalité) d’entre eux ne se souciaient pas vraiment de mélanger du code GPLv2 et GPLv3. En pratique, personne ne viendra faire une réclamation légale de toute façon… probablement.
Les tentatives d’amélioration
Voici une vue d’ensemble des principaux projets qui ont vu le jour :
wolfet-merge était une tentative pour inclure les fonctionalités spécifiques à Enemy Territory dans ioquake3, puisqu'ioquake3 disposait déjà d’une base de code bien plus propre. Ceci s’est révélé plus facile à dire qu’à faire, ce qui a conduit au projet suivant.
raedwulf-et a essayé de rafistoler les problèmes, en empruntant des améliorations à ioquake3. Ce projet a duré un certain temps et a été forké quelques fois. On peut dire qu'il a été assez réussi bien que quelques détails gênants ne soient pas réglés. Il est cependant maintenant mort.
ET:XreaL est une importante refonte d’Enemy Territory. Le fonctionnement interne du moteur est devenu proche de celui d’idTech 4 et le contenu du jeu a été modifié en partie pour obtenir des textures et effets visuels plus nets et brillants, afin de démontrer les capacités du moteur. Son auteur a depuis quitté le projet ET:Xreal pour travailler sur idTech 4.
Open Territory était un fork d’ET:XreaL qui était destiné à devenir ce que OpenArena est à ioquake3. Ce projet a été de courte durée aucun artiste n’ayant été trouvé.
OpenWolf essayait d’être à la fois comme ETXreaL et raedwulf-et en ayant deux moteurs de rendu : le moteur original OpenGL 1.3 et le moteur de rendu OpenGL 3.2 issu du projet Xreal. En y ajoutant la gestion de l’ancien et d’un nouveau format d’animation. Cependant, après la libération par GarageGames du moteur Torque3D sous licence MIT en septembre 2012, l’auteur d’OpenWolf a stoppé son projet et a commencé à travailler sur quelque chose de totalement nouveau avec cet autre moteur.
ET: Legacy, le présent projet, est à l’origine un fork de raedwulf-et. À un certain moment dans le développement, l’auteur de raedwulf-et a commencé à remplacer SDL en faveur de GLFW dans son projet. Tout le monde n’a pas apprécié ce changement et le code a été forké pour commencer une autre vie.
Ainsi, parmi les différentes tentatives d’amélioration les plus connues, seul le projet ET:Legacy est toujours actif et en constant développement depuis son lancement.
Tandis que les projets ET:XreaL et OpenWolf se concentraient surtout sur la modernisation du jeu avec un moteur graphique renouvelé et de nombreux effets modernes, ET:Legacy choisit au contraire de se focaliser avant tout sur la résolution de bogues gênants et sur les failles de sécurité en rétroportant les améliorations issues de ioquake3, tout en restant compatible binairement avec les serveurs et clients originaux du jeu, ainsi qu’avec ses mods.
En somme, ET:Legacy ambitionne de vous permettre de jouer à l’ancienne, tout simplement !
Le jeu réutilise les données du jeu d’origine, non libres, mais téléchargeables gratuitement.
Jouabilité
Aperçu de la jouabilité de Wolfenstein: Enemy Territory.
Un bunker anti-débarquement sur la carte « Seawall Battery ».
Deux équipes s’affrontent dans le contexte de la Seconde Guerre mondiale, les Alliés et les forces de l’Axe. Une équipe doit réaliser un ou plusieurs objectifs dans un temps imparti, tel que dynamiter un dépôt de carburant ou capturer un objet, tandis que l’autre équipe doit faire son possible pour empêcher cet objectif de se réaliser.
Ingénieur de l’Axe désamorçant une bombe posée par un ingénieur Allié.
Chaque joueur peut choisir entre cinq classes différentes, chacune proposant des armes et capacités de combat uniques. Les Covert Ops peuvent voler les uniformes des ennemis tombés au combat et effectuer une reconnaissance discrète derrière les lignes ennemies, tandis que les ingénieurs peuvent planter et désarmer des mines, ainsi que construire des structures sur le champ de bataille pour obtenir des avantages pour leur équipe. Les médecins assurent les soins et la réanimation des coéquipiers tombés, tandis que les Field Ops assurent le ravitaillement en munitions et utilisent leurs jumelles pour marquer les positions ennemies pour une attaque aérienne ou un pilonnage de batteries amies. Les soldats assurent l’essentiel du combat avec des armes lourdes, telles que mitrailleuses défensives, mortiers, lance-flammes ou lance-roquettes.
Les Alliés doivent escorter ce tank volé sur la carte « Gold Rush ».
La coordination de toutes les classes est ainsi nécessaire pour atteindre l’objectif et obtenir la victoire. Les joueurs éliminés réapparaissent sur la carte par vagues, évitant les temps d’attente trop longs.
Combat près d’un avant poste sur « Supply Depot », une carte additionnelle très jouée.
Lors de la partie, chaque joueur engendre des points d’expérience qui permettent d’améliorer son personnage, au fur et à mesure des combats et de ses actions. Ce jeu de tir subjectif dispose donc aussi d’éléments de jeu d’aventure.
La carte « Fuel Dump » sous la neige, d’autres missions se passent plutôt sous la chaleur du désert.
Six cartes différentes sont disponibles dans le jeu de base, mais plusieurs centaines d’autres sont disponibles et seront téléchargées automatiquement lors de la connexion aux serveurs.
Nouveautés depuis la version 2.60b
Contrairement à certains mods populaires qui ajoutent une grande quantités d’armes disponibles ou d’autres fonctionnalités modifiants en grande partie la jouabilité d’origine, le mod Legacy vise à conserver l’expérience authentique du jeu de base, simple et efficace.
Néanmoins, de nombreuses fonctionnalités et améliorations utiles ont été ajoutées. Parmi celles-ci, citons :
Nouveaux modèles 3D pour les armes, à des fins de cohérence historique : les alliés utilisent maintenant le couteau Ka-bar, le Browning MG et le bazooka en lieu et place de la dague allemande, de la mitrailleuse MG 42 et du Panzerfaust. Les joueurs de l’Axe ont quant à eux accès au Granatwerfer au lieu du mortier allié.
Équilibrage des armes : le M1 Garand allié dispose du même nombre de cartouches que la carabine K43, tandis que le temps de rechargement de cette dernière a été diminué.
Amélioration de la jouabilité : les joueurs qui se penchent au détour d’un mur sont maintenant visibles par tous, les déstabilisations dues aux explosions sont plus réalistes. Une icône s’affiche sur les cover ops déguisés amis ainsi que sur la carte, améliorant leur visibilité. Désormais, le porteur de l’objectif peut aussi être localisé rapidement sur la carte. La barre d’endurance est quant à elle remplacée par une barre de respiration restante lorsque le joueur est sous l’eau.
Amélioration de l’interface présentée au joueur : les polices floues font partie du passé et l’affichage tête haute (HUD) est maintenant complètement personnalisable. Des icônes additionnelles sont utilisées afin de rendre les messages d’évènements plus explicites, les objectifs sont maintenant visibles directement via une fenêtre pop-up. Le nom des joueurs est désormais affiché pour les spectateurs en « vue libre ».
Nouveau mode de jeu Map Voting, permettant de choisir la prochaine carte à jouer via un vote. Ce dernier mode s’ajoute aux modes existants Objective, Campaign, Stopwatch et Deathmatch.
Configuration « Compétition » : de nombreuxparamètres pour configurer finement une partie ont été ajoutés, les paramètres des clients peuvent être forcés à une certaine valeur par le serveur via un ensemble de règles prédéfinies. Ces fonctionnalités sont inspirées du mod propriétaire « etpro », qui n’est plus développé depuis 2006 et est incompatible avec ET:Legacy.
Extensibilité via des scripts Lua. En particulier, toute la suite d’administration des joueurs est codée en Lua et facilement extensible, au contraire des interfaces d’administration incluse dans les mods existants. Notons aussi l’ajout de la compatibilité avec la dernière version en développement du mod d’intelligence artificielle Omni-bot.
Bien sûr, le mod Legacy profite de la résolution de très nombreux bogues et d’autres ajustements variés. Entre autres, l’ensemble des patches issus du Project: Bug Fix ont été implémentés.
Et sur le plan technique, citons les améliorations suivantes :
Changements : sous Windows, les profils utilisateurs et les données téléchargées sont maintenant séparées des données du logiciel, comme sous GNU/Linux. En outre, ET:Legacy utilise maintenant son propre dossier de configuration (
~/.etlegacy
sur GNU/Linux et\ETLegacy
sous Windows), permettant l’installation distincte en paralèlle du Wolf:ET original. Les clients reçoivent le Message of The Day (MOTD) directement de la part de etlegacy.com, l’icône a été modifiée et, au passage, on peut noter qu’elle est désormais intégrée dans le binaire sous Windows.Audio : raedwulf avait corrigé plusieurs problèmes de son et ajouté la gestion d’OpenAL. Le passage à la SDL permet une gestion ALSA native, évitant des bidouilles monstrueuses afin de rediriger le vieux système son OSS vers ALSA. On peut désormais couper le son lorsque le jeu est minimisé !
Rendu : le moteur permet désormais de rendre des polices TrueType ttf ou OpenType otf via Freetype, un bogue qui affectait le rendu de léger brouillard est corrigé, le client console a été porté sur ncurses et interprète les codes couleurs tout comme ioquake3 !
Internationalisation : la possibilité de traduire le jeu a été ajoutée, et quelques traductions ont déjà été ajoutées, profitant du tout nouveau rendu des polices via Freetype. Un bogue qui affectait l’affectation des touches sur les claviers non-QWERTY a été corrigé.
Réseau : Le serveur différencie maintenant les joueurs humains des joueurs AI (visible pour les serveurs ET:Legacy dans le navigateur des serveurs), l’algorithme de Nagle pour les connexions TCP a été désactivé pour une plus grande réactivité.
Autres corrections en vrac : quelques bogues trouvés avec des outils d’analyse statique ont été corrigés ainsi que des fuites mémoires (classique) ;-). Le bug du pointeur de souris retenu par la fenêtre en mode fenêtré a été contourné. Les serveurs maîtres recevaient toujours des paquets keep-alive même après déconnexion du joueur, c’est corrigé.
Compilation : le système de compilation est passé de SCons au plus puissant « moteur de production » multiplate-forme CMake. Les bibliothèques SDL 2, libcurl et libjpeg6 utilisées sont désormais liées dynamiquement. La prise en charge de la libjpeg-turbo a également été ajoutée. Il est désormais possible de compiler ET:Legacy pour Windows depuis GNU/Linux grâce au système de compilation croisée MinGW.
Portabilité : Les routines assembleur i386 ont été remplacées par les routines équivalentes développées par le projet ioQuake3. ptitSeb, développeur très actif dans le projet OpenPandora (un projet communautaire de console de jeu de poche tournant sur GNU/Linux), a porté le moteur sur l’architecture ARM et a implémenté la gestion d’OpenGL ES afin de pouvoir rajouter ET:Legacy à la logithèque de Pandora ; BZsili a rajouté la prise en charge des systèmes AROS et MORPHOS ; enfin Jonathan Gray s’est occupé de la prise en charge d’OpenBSD.
Configurations prises en charge
ET:Legacy prend donc en charge les systèmes GNU/Linux, *BSD, OS X, Windows, AROS et MORPHOS, et les architectures x86, x86_64 et ARM.
Les binaires OS X sont compatibles seulement avec Mountain Lion (10.8) ou supérieur et les mods « Silent » et « Legacy ».
Seules les configurations 32 bits sont compatibles avec les serveurs Wolf:ET d’origine. Les mods les plus populaires sont pris en charge, à l’exception du mod « etpro » dont le module anti-cheat intégré dans la partie cliente vérifie explicitement la présence du binaire d’origine 2.60b.
Il est possible d’utiliser ET:Legacy en 64 bits, mais on ne pourra se connecter qu’aux serveurs proposant moteur et mod en version 64 bits (ET:Legacy avec Legacy mod pour l'instant). Le même problème se pose pour les architectures nouvellement supportées. Le module de joueurs IA Omni-bot a lui aussi été récemment porté en version 64 bits.
Le futur d’ET:Legacy
ET:Legacy proposera également un moteur openGL 3.2, mais contrairement à ET:XreaL l’ancien est toujours disponible. Dérivé en partie du travail fait sur ET:XreaL et OpenWolf, le code a été porté de C++ à du C pur pour ET:Legacy. Le travail sur le nouveau moteur avance petit à petit, mais est loin d’être terminé. Aussi, un set complet de nouvelles textures haute résolution pour accompagner le nouveau moteur est en cours d’élaboration.
Le code libéré d’Enemy Territory ne contient pas le code spécifique à l’anti-triche propriétaire PunkBuster, qui a de toute façon abandonné la prise en charge de Wolf:ET en 2011. Un anti-triche étant difficile a mettre en œuvre dans un code ouvert, ET:Legacy vise à mettre en place un système d’authentification libre, permettant de bannir les tricheurs plus aisément.
Puisque les données du jeu d’origine ne sont pas libres, ET:Legacy n’est pas par définition un jeu entièrement libre, posant une certaine difficulté d’empaquetage dans les distributions GNU/Linux. À plus long terme, le projet désire remplacer toutes les textures, modèles 3D et sons par des équivalents librement modifiables et distribuables. Se pose alors l’identité même d’Enemy Territory : que deviendrait l’authentique expérience Wolf:ET sans sa fameuse identité sonore ( « Mediiiiic ! ») ?
EasyGen est un outil permettant de générer facilement des terrains pour des cartes personnalisées. Le programme n’avait pas été mis à jour depuis plus de 10 ans (!), mais après la libération des sources (merci à Francesco Bancalà, son créateur, d’avoir pris en compte cette demande), ET:Legacy a l’intention d’ajouter ce générateur de cartes très utile dans sa boîte à outils.
Le code a déjà été adapté pour pouvoir le compiler sur Visual Studio (2008-2012), tandis que le système de bibliothèque d’images obsolète a été remplacé. La prochaine étape est de porter le code vers le framework Qt afin de permettre aux systèmes d’exploitation autres que Windows de l’utiliser. À l’avenir, des outils de conversion de modèles seront introduits afin de permettre une création de modèles plus aisée. Vous trouverez le dépôt de ce projet annexe d’ET:Legacy ici.
Enfin, il faut peut-être citer ET:Live, une tentative pour obtenir l’équivalent de Quake Live, à savoir ET jouable dans un navigateur. Ce projet parallèle à ET:Legacy et préparé par une équipe totalement distincte veut utiliser le code d’ET:Legacy comme base de travail. On peut cependant questionner la pertinence du projet, à l’heure où Quake Live repart sur une installation traditionnelle suite à l’abandon des greffons NPAPI par les navigateurs, ainsi que la synergie inexistante avec le projet amont.
En effet, ET:Live ressemble plus à une boîte noire, sans communication avec l’équipe d’ET:Legacy et, il semblerait, une duplication importante de travail, notamment par rapport aux améliorations graphiques du nouveau moteur de rendu en préparation d’ET:Legacy.
En conclusion
Quatre ans après sa libération, le code de Wolfenstein: Enemy Territory vit toujours au travers de l’actif projet ET:Legacy. En deux ans, le dépôt de code a vu défiler plus de 3 800 commits par 33 contributeurs différents, tandis que près de 400 tickets ont été fermés sur le bugtracker.
Le chemin est encore long, mais le projet propose des améliorations notables et attendues dans le moteur et ceci pour plusieurs plate-formes. Le mod Legacy proposé, quand à lui, a su repartir d’un code plus ancien que ses alternatives propriétaires existantes et se remettre à niveau, afin d'offrir une jouabilité plaisante et sous code libre.
Parce que c’est du code libre et que c’est facile (et que ça ne coûte pas cher de demander :p), notons encore que le développement d’ET:Legacy est un effort collaboratif fait d’une manière ouverte, transparente et conviviale. Si vous avez l’âme d’un codeur, d’un artiste ou d’un traducteur : engagez-vous ! Tout le monde est le bienvenu ! Vous trouverez plus d’information sur le site du projet et sur le canal IRC #etlegacy sur Freenode.
Et pour tester ?
Depuis la quatrième Release Candidate de juin dernier, de nombreuses modifications ont été apportées. En particulier, le projet a décidé de fusionner sa branche SDL 2, en test depuis de nombreux mois, permettant de corriger un grand nombre de bogues présents dans la branche principale avec la version SDL 1.2. En outre, un important travail au niveau du nouveau moteur de rendu a été effectué, même s'il ne sera sans doute pas compilé par défaut dans la première version stable officielle.
La version stable ne sera donc probablement pas publiée tout de suite. En attendant celle-ci, vous pouvez bien entendu tester le projet en installant l’un de ces paquets :
Version officielle (RC4) : la dernière Release Candidate disponible, compilée statiquement et compatible avec n’importe quelle distribution. Notez que cette version 32 bits nécessite les bibliothèques graphiques et audio 32 bits adéquates si vous utilisez un système 64 bits.
-
Paquets expérimentaux (RC4) : des paquets pour les distributions majeures sont disponibles. Attention, ces paquets ne sont pour le moment proposés qu’en version 32 bits et 64 bits. Si vous désirez jouer sur les serveurs existants :
- utilisateurs d’openSUSE et de Fedora 64 bits, veillez à installer la version i586 ;
- utilisateurs de Debian et d’Ubuntu 64 bits, installez plutôt la version officielle ci-dessus ;
- utilisateurs d’Arch Linux 64 bits, installez plutôt le paquet etlegacy disponible dans l’AUR après avoir lu le PKGBUILD.
Notez également qu'en raison de restrictions légales, les données requises ne peuvent pas être incluses dans les paquets proposés. Mais vous pouvez les télécharger gratuitement et légalement sur le site officiel de Splash Damage. Alternativement, vous pouvez utiliser ce script pour récupérer les fichiers nécessaires automatiquement.
Vous avez besoin des fichiers pak0.pk3
, pak1.pk3
et pak2.pk3
qui doivent être placés dans ~/.etlegacy/etmain
ou dans le répertoire etmain
situé dans le même répertoire que le binaire etl
. Cette étape est faite automatiquement pour les utilisateurs d’Arch Linux.
Pour les plus courageux d’entre vous qui voudraient utiliser la toute dernière version de développement, vous trouverez les instructions de compilation dans le dépôt GitHub du projet ; les utilisateurs d’Arch Linux pourront installer le paquet etlegacy-git disponible dans l’AUR.
Merci tout particulièrement à Spyhawk qui a coécrit cette dépêche, ainsi qu’à M5oul et BAud pour leurs précieuses et minutieuses corrections.
Aller plus loin
- Enemy Territory: Legacy (857 clics)
- Changelog complet (72 clics)
- Journal : Quelques actus vidéoludiques - Première Release Candidate d'ET:Legacy (143 clics)
- Dépêche : ID Software libère Wolf: ET et RTCW (91 clics)
# Typo
Posté par reynum (site web personnel) . Évalué à 4. Dernière modification le 14 novembre 2014 à 14:24.
Merci pour cette dépêche intéressante, comme quoi le jeu libre avance (lentement mais sûrement) en qualité et en quantité ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: Typo
Posté par M5oul (site web personnel) . Évalué à 1.
Oui, j’avait pas ossé la corriger. Je me suis dit que ça se dit peut-être…
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
C’était bien sans doute, /o\
…En plus il me semblait l’avoir corrigée celle-ci. :/
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par Spyhawk . Évalué à 2.
Mon "copié collé" a du la réintroduire quand j'ai déplacé cette phrase dans ce paragraphes lors des toutes dernières modifications. Désolé :(
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Ah voilà tout s’explique. :D Pas de problème !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Je ne sais pas si le modèle libre permettra un jour de tenir le rythme des studios à gros budget et de fournir un travail équivalent, mais ce qui est sûr et certain, c’est que le modèle libre est très bien adapté pour faire tenir un projet dans la durée. Il y a plein de jeux libres ou de jeux non libres mais dont le moteur a été libéré qui sont toujours jouables et joués, et c’est super.
Personnellement, je n’ai pas vraiment besoin de plus d’ailleurs, il y a toujours des gens qui jouent aux cartes ou aux dés, ou aux sept familles, le fait qu’un jeu utilise une technologie qui semble désuète à coté d’autres plus modernes et plus sexys n’enlève rien au fait que c’est un jeu, et que ça sert à jouer ! Ça ne ressemble pas ou plus à une super production actuelle, mais on peut y jouer, que demander de plus ?
Ce qui est super aussi, c’est qu’on peux très facilement se rapprocher d’un projet comme celui-là. Il suffit de zieuter le forum de temps en temps, laisser un client IRC ouvert sur le canal officiel et lurker un peu, faire le tour du dépôt de code, faire quelques commentaires, échanger avec les un les autres. Le jeu prend alors une toute autre dimension avec des hommes derrières.
J’ai tendance à préparer mes dépêches un peu de cette manière, et en plus avec le projet XQF que je reprends je me retrouve non seulement à écrire sur les gens, mais à devoir travailler avec eux, même si je ne contribue pas directement à leur code. J’ai lu des trucs à eux, j’ai du leur poser des questions, certains ont lu mon code, ont fait des suggestions. Et puis rapidement on retrouve les uns et les autres dans différents projets frères. On retrouve d’ailleurs habituellement les membres de chaque projet connectés aux canaux IRC des autres projets. ;-)
Et puis, un peu comme ce qu’Alan Cox disait rechercher récemment, ce sont des projets à taille humaine, et c’est ludique.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par reynum (site web personnel) . Évalué à 3.
Il y a même des gens qui jouent au Go qui est aussi vachement vieux :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Typo
Posté par Anonyme . Évalué à 3.
Ho, tu sais, si c’est pour imiter Ubisoft et sortir un AC tous les ans, vendu à prix d’or, complètement bogué, incapable de tourner sur une machine moyenne gamme de début d’année et dont le scénario viol de plus en plus l’Histoire dans la bouche, c’est pas la peine.
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
C’est l’idée que je défends, dans le sens que ces jeux qui peuvent paraître vieillots sont maintenus et jouables au moins, ce qui est un prérequis pour un jeu.
Un autre argument est aussi qu’il y a toujours des serveurs. En cherchant des serveurs maîtres pour différents jeux dans XQF, je suis tombé sur des forums où d’autres personnes posaient des questions similaires, et souvent, deux trois personnes répondaient à cette question mais une bonne moitié du bruit consistait en messages de personnes qui exprimaient leur étonnement de voir que ces jeux existaient encore et que des gens pouvaient y jouer, j’ai lu beaucoup de messages de ce genre à propos de jeux qui n’avaient même pas deux ans au moment où les gens écrivaient ces messages.
Certains jeux voient leurs serveurs être éteints même pas deux ou trois après leur sortie, pour moi ça n’a aucun intérêt, je n’ai même pas envie de commencer à y jouer si c’est comme ça.
Personnellement je ne consomme pas les jeux pour les jeter ensuite, deux semaines plus tard, et oublier même que j’y ai joué un jour. Si un jeu me plaît, j’aime pouvoir y rejouer plus tard, même longtemps après.
Je joue à Nexuiz/Xonotic depuis 7 ou 8 ans maintenant, j’y joue peu parce que je ne suis pas un grand joueur, mais si on venait me proposer un jeu multijoueur Ubisoft dernier cri, je répondrai qu’il lui manquerait probablement quelque chose d’essentiel : de pouvoir y jouer encore dans 8 ans.
Je n’ai absolument rien compris à cette phrase.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par reynum (site web personnel) . Évalué à 2.
Tiens encore un qui a vu ou joué au dernier AC (et qui n'arrête pas sa réflexion aux 'jolis' graphismes) :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 15 novembre 2014 à 12:37.
Hum bon, j’ai du rater un épisode… J’ai donc recherché des infos sur le dernier Assassin's Creed (je suppose que vous parlez de ça vu que vous parlez d’Ubisoft ?) et je suis tombé sur cette bande annonce.
Dans cette bande annonce la voix off dit :
Je trouve que ce texte correspond très bien à la la façon dont cette période de notre histoire est enseignée. On peut comparer par exemple avec cette fiche du CNED en instruction civique et morale :
Vu la notoriété du CNED (Centre National d'Enseignement à Distance) en tant qu’établissement public français du ministère de l'Éducation nationale, je trouve cette bande annonce d’Assassin's Creed remarquablement bien faite : ça correspond tout à fait à ce que l’on enseigne.
Bon ça a l’air assez violent, les têtes au bout des piques ils les montrent cash, mais sur le plan historique, on ne peut pas leur reprocher ça. Après il y a sûrement des prises de liberté pour satisfaire le gameplay, mais en tout cas, à la vue de cette bande annonce, je suis assez impressionné par la fidélité.
Ça ne m’intéresse pas d’y jouer, mais ça pourrait faire un bon film d’animation (ce qui est souvent ma critique envers certains jeux actuels, ce n’est pas ça que je cherche).
[Edit, cela dit, je n’ai toujours pas compris ce que signifie « viol de plus en plus l’Histoire dans la bouche », je ne comprends pas ce que peut vouloir dire « histoire dans la bouche » ou « violer dans la bouche »]
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par reynum (site web personnel) . Évalué à 4. Dernière modification le 15 novembre 2014 à 12:56.
Il y a d'autres lectures de ce jeu (bande annonce). Par exemple :
http://www.20minutes.fr/culture/1480615-20141114-video-jean-luc-melenchon-revolte-assassin-creed-unity
Cela veut il dire que c'est vrai pour autant ?
Manipuler l'enseignement c'est manipuler l'opinion publique dans 30 ans.
Je ne m'engagerais pas sur ce terrain, mais beaucoup de découvertes sur les origines et le déroulement de la révolution Française ne sont étrangement jamais entrées dans les livres d'histoire, mais sont restés dans des émissions d'histoires à des heures de petite audience et jamais rediffusées.
kentoc'h mervel eget bezan saotred
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Intéressant cet article.
Mais justement, je ne comprends pas Mélanchon quand il reproche que ce jeu représente le peuple comme des barbares et des sauvages sanguinaires, je comprendrais qu’il reproche la violence des images à la rigueur, mais c’est tout de même un fait historique que la prise de la bastille (pour rester sur cet exemple) s’est faite avec dépeçage et décapitations. D’ailleurs je suis assez étonné de son langage quand il parle de « République une et indivisible », l’emploi de ce vocabulaire dogmatique et religieux est étonnant, peut-on soumettre l’histoire au dogme ?
Après la bande annonce n’est qu’une bande annonce, elle ne montre pas l’ensemble du jeu c’est évident.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par Zenitram (site web personnel) . Évalué à -8.
tu as déjà compris Mélenchon une seule fois, à part que son fond de commerce est de cracher sur tout et n'importe quoi pour faire parler de lui et récupérer les "anti-systèmes" de tout bord?
[^] # Re: Typo
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
S’il y a bien un bord particulier d’anti-sytème qu’il ne pourra pas récupérer après ça, ce sont les royalistes. /o\
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Typo
Posté par barmic . Évalué à 6.
Il s'y connaît le bonhomme en manipulation des faits, mais tenter de nous faire croire que les révolutionaires et la période durant la quelle on a fait le plus de guillotinnage était mené par une bande de bisounours qui se battaient à coup de câlin tout doux. Il faut pas abuser. De la même manière affirmer que Robespierre qui a contribué à la terreur, était un doux, c'est de la réécriture de l'histoire.
Donc le problème ce n'est pas le jeux vidéo, mais l'enseignement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Typo
Posté par Zylabon . Évalué à -2. Dernière modification le 16 novembre 2014 à 22:04.
Tu as lu l'article ?
Robespierre n'avait rien d'un tendre, on ne peut pas être tendre lorsque l'on essaye d'arracher un pouvoir illégitime à des gens puissant. Mais il n'avait rien d'un monstre.
Le problème ici n'est pas de condamner la terreur, mais de condamner la révolution.
Please do not feed the trolls
[^] # Re: Typo
Posté par barmic . Évalué à 6.
Tu sais ce que c'est la terreur ? Il ne s'agit pas uniquement d'"arracher un pouvoir illégitime à des gens puissants", mais aussi (surtout ?) d’asseoir son pouvoir par la violence. On parle d'un pouvoir qui tue tout opposants politiques après des procès expéditifs. Et par opposants politiques, on est loin du manichéisme royaliste/révolutionnaire.
Comme dans tout mouvement qui a un peu d’ampleur, il y avait des barbares et Robespierre s'il n'en fait pas parti leur a laissé les coudées franches pendant plusieurs années.
Mélanchon, comme toi et moi n'avons pas fini le jeu donc on parle sur des hypothèses, mais note qu'il y a une différence entre montrer que la révolution était sanglante et la condamner (ou alors il est possible d'avoir une condamnation partielle). Je doute qu'un jeu dans le quel le héro est un protagoniste de la révolution défend l'idée que l'on aurait pas dut faire de révolution.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Typo
Posté par Zylabon . Évalué à 0.
Je cite l'article (encore une fois, même citation).
Please do not feed the trolls
[^] # Re: Typo
Posté par barmic . Évalué à 7.
Et toi tu a vu la vidéo ? Qui parle justement de la terreur et qui décrit des faits uniquement. Pour ce qui est du jugement sur la révolution c'est Melanchon qui invente parce que dans la vidéo il n'y a pas ce jugement. Ça montre qu'après notre révolution, on a connu une période noire (sincèrement renseigne toi sur ce qui s'est passé et sur les montagnards par exemple). Personnellement je trouve que ça montre que notre révolution n'est pas si différente de pleins d'autres comme celle des tunisiens et qu'il est très difficile de gérer un pouvoir que l'on vient de prendre par la force.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Typo
Posté par anaseto . Évalué à 7. Dernière modification le 16 novembre 2014 à 18:28.
Une façon un peu plus précise d'expliquer les choses serait de dire que, comme la France venait de passer plusieurs années assez noires pour l'économie (mauvaises récoltes en particulier il me semble), les bourgeois (donc pas les gens pauvres) en ont profité pour mobiliser les gens (du moins dans les villes comme Paris, où ils avaient du poids) pour mettre dehors leurs concurrents (le roi, les nobles, etc.). Mais c'est sûr que, dit comme ça, ça fait moins bisounours que la façon dont c'est enseigné (qui s'attache à nous expliquer les droits de l'homme, etc., mais ne s'attarde pas trop sur le contexte économique et ce genre de choses).
[^] # Re: Typo
Posté par flan (site web personnel) . Évalué à 7.
Il n'y a pas qu'Ubisoft ; Blizzard sort (beaucoup plus rarement) des jeux qui sont en général plus que corrects : peu de bugs, suivis très longtemps, (dernier patch de Warcraft III au bout de 9 ans, pour Starcraft au bout de 11 ans), scénario riche (mais pas toujours très fidèle à l'Histoire, je l'admets ;) ), et qui fonctionnent sur une machine moyenne.
[^] # Re: Typo
Posté par Kwiknclean . Évalué à 2.
Et on attend toujours les portabilités sous Linux …
[^] # Re: Typo
Posté par ZeroHeure . Évalué à 2.
Corrigé, merci.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# C'est le genre de projet que j'aimerais aider financièrement ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Même si je n'ai jamais été un grand joueur de ET, j'ai passé quelques dizaines (centaines ?) d'heures dessus, et s'il y a un FPS que je retiens c'est bien celui-là.
S'il y a un autre jeu pour lequel j'adorerais trouver un tel projet (et déjà une libération du code), c'est POD. Un univers vraiment sympa et un jeu de course de voiture original dont je n'ai jamais trouvé d'équivalent, les jeux plus récents cherchant à reproduire la réalité au lieu d'inventer un monde.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: C'est le genre de projet que j'aimerais aider financièrement ...
Posté par KiKouN . Évalué à 4.
Ha, ça mouahh aussi, j'en ai passé des heures dessus, mais ça doit bien se compter en millier.
Faut dire qu'entre les serveurs publics ( dont l'un des plus populaires en france ) et les matchs de mon équipe, il y en eu du ketchup au sol.
# Emplacement fichiers de config
Posté par jihele . Évalué à 3.
J'ai lu en diagonale et tiqué là-dessus :
Quitte à changer, pourquoi pas adhérer aux specs Freedesktop ?
Cf. par exemple réponse de Juliano à cette question SO.
(Oui, c'est un détail.)
[^] # Re: Emplacement fichiers de config
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Parce que c’est plus complexe que cela… /o\
En fait Freedesktop c’est quoi… ce serait la config dans
~/.config/etlegacy
, le cache dans~/.cache/etlegacy
, des fichiers partagés dans~/.local/share/etlegacy
. Mais il faut faire avec l’historique, et l’historique, c’est la manière de faire d’Id Software.En gros ça marche comme ça
/dossier_utilisateur/
surcharge/dossier_système/
.Par exemple
/dossier_utilisateur/fichier_de.conf
surcharge/dossier_système/fichier_de.conf
Et si tu as
Le jeu voit en fait un dossier unifié :
Et ça va même plus loin que ça puisque les archives
.pk3
sont en fait deszip
d’une partie de l’arborescence.Par exemple une archive "jeu.pk3" contiendrait :
et une archive
map-monde.pk3
contiendrait :Le jeu verra :
Ici, le dossier système serait par exemple
/usr/share/games/etlegacy
, et le dossier utilisateur~/.etlegacy
, et les dossiers de jeux/mod seraientetmain
(Wolf:ET) ettcetest
(TrueCombat:Elite). Les organisations suivantes sont équivalentes :1.
2.
Je ne sais pas si ET:Legacy l’utilise, mais il existe une bibliothèque dédiée pour ça, PhysicsFS, que j’avais présenté dans une précédente dépêche.
Puisqu’il faut rester compatible avec les mods, seulent peuvent être changés les noms de dossier qui contiennent les fichiers du jeu, mais l’organisation de l’arborescence ne peut pas être changée. Au mieux, etlegacy pourrait travailler dans
~/.local/share/etlegacy
, mais tout y serait, même la configuration qui devrait être dans~/.config/etlegacy
.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Emplacement fichiers de config
Posté par Spyhawk . Évalué à 4.
C'est exactement cela. Aussi, la nouveauté dans la séparation données système et données utilisateurs concerne avant tout la version Windows. En effet, avant Windows 7/Vista, tout était dans le même répertoire dans
C:\Program Files
, tandis que la version Linux avait déjà cette séparation dans~/.etwolf
.[^] # Re: Emplacement fichiers de config
Posté par Thrillseeker . Évalué à 2.
Qu'il soit difficile de choisir entre tout mettre dans le dossier des données ($XDG_DATA_HOME) et tout mettre dans le dossier des configurations ($XDG_CONFIG_HOME) ne doit fort heureusement pas obligatoirement conduire à créer son propre dossier de config/données n'importe où.
Par contre, choisir de pourrir le $HOME c'est facile. Les spécifications de Freedesktop permettent justement d'éviter la situation d'avoir 800 fichiers/dossiers qui commencent par un "." dans le dossier $HOME.
Les spécifications de Freedesktop ne sont heureusement que des recommandations, ce qui permet toujours de faire ce que l'on veut, cela permet donc de mélanger données et configuration dans $XDG_DATA_HOME (ou $XDG_CONFIG_HOME).
Et quand on y pense, un fichier de configuration c'est juste une donnée spéciale. Quand on a pas le choix, tout irait dans le dossier des données, bien que je constate que la majorité des applications mélangent tout dans le dossier de configuration.
[^] # Re: Emplacement fichiers de config
Posté par Spyhawk . Évalué à 1.
C'est un point de vue, mais un fichier de configuration c'est aussi un fichier qui doit être trouvé facilement. Perso, je préfère retrouver mon fichier de config là où j'attends le trouver, c'est à dire surtout pas dans $XDG_DATA_HOME.
Mais dans le cas d'ET:L, "suivre" la recommandation Freedesktop tout en la foirant en connaissance de cause dans un sens ou dans l'autre n'a pas d'intérêt. Le dossier directement sous ~/ est le plus adapté.
[^] # Re: Emplacement fichiers de config
Posté par Thrillseeker . Évalué à 1.
Peut-être faut-il suggérer à Freedesktop d'ajouter ~/.bordel quand une application mélange données et configuration xD
Il ne faut pas prendre la recommandation de Freedesktop comme la meilleure pratique à suivre. Personnellement, je trouve "~/.local/share" incohérent comme chemin pour des données que Freedesktop qualifie de "user specific data" (".local" est redondant car on est déjà dans ~, et "share" est un non sens car c'est justement spécifique à l'utilisateur). Mais c'est surement pour ressembler à "/usr/local/share/".
Pour ma part, je m'attends à trouver les fichiers de config dans le dossier de config, avec en bonus directement les données au même endroit (et si c'est le cas ça m'arrange), sinon à aller les chercher dans ~/.local/share. Dans le pire des cas, je regarde dans ~.
Si je fouille dans mon .config, je vois qu'il y a déjà Chromium qui mélange tout dedans, Transmission, Inkscape, LibreOffice, KVirc, etc. Après c'est sûr que ce n'est pas parce que d'autres le font, qu'il faut faire pareil.
[^] # Re: Emplacement fichiers de config
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Personnellement je défend à fond la spécification XDG_MACHIN pour les données/config/cache personnels, mais pour une seule raison: il faut un standard et je ne vais pas en inventer un second qui n’en serait plus un.
Le standard XDG_MACHIN a d’énormes défauts. Il ambitionne de faire le ménage dans tous les ~/.quelquechose qui polluent
${HOME}
, et la première chose qu’il fait c’est de pondre~/.cache
,~/.config
,~/.local
et peut-être d’autres, déjà, XDG_MACHIN a échoué pour moi.Autre défaut, c’est de reproduire d’un coté dans
~/.local
une surcharge de/usr
, comme/usr/share/
et~/.local/share/
, et d’un autre coté, de ne pas aller jusqu’au bout pour la configuration ou le cacheil y a
/usr/share/applications
et~/.local/share/applications
il y a
/usr/share/icons
et~/.local/share/icons
Et puis il y a
/usr/share/nautilus
et~/.local/share/nautilus
,/usr/share/totem
et~/.local/share/totem
, etc.Cette partie-là est super bien pensée, on a
/usr
pour les trucs installés par la distro,/usr/local
pour les trucs installés à la mano mais pour tout le système, et~/.local
pour les trucs uniques à l’utilisateur. Et ça marche super bien, par exemple il m’est arrivé parfois d’installer des trucs que pour moi en faisant./configure --prefix=~/.local
et ça marche super bien !Mais voilà, ils ont déplacé
~/.icons
dans~/.local/share/icons
(très intelligent), pour aussitôt créer un~/.cache
, (n’importe quoi) !Au final, je me demande à quoi sert
~/.local
étant attendu qu’il ne contient que deux dossiersshare
, ettemp
.D’ailleurs on peut se demander pourquoi officiellement
~/.local/share/applications
, et officiellement~/.local/share/Trash
avec une majuscule.Au final, on voit que le standard se prend les pieds dans le tapis rien que pour organiser les fichiers d’un autre standard, celui des « Desktop files » qui décrit les icônes et les menus :
Les fichiers
.desktop
qui décrivent le nom de l’application, le commentaire, les catégories, les mimetypes associés, la commande etc. sont enregistrés dans~/.local/share/applications
(la surcharge de/usr/share/applications
, mais pour déclarer que cette application est à démarrer à l’ouverture de session, il faut surcharger ce fichier avec l’option qui va bien dans~/.config/autostart
(la surcharge de l’ancien/usr/share/autostart
désormais/etc/xdg/autostart
), mais pour surcharger/usr/share/desktop-directories
qui décrit les catégories (.directory
), il faut écrire dans~/.local/share/desktop-directories/
et pour définir un menu (.menu
) et surcharger/etc/xdg/menus
, c’est dans~/.local/menus
.Si vous avez bien suivi, pour cacher Lollypop du menu il faudrait surcharger
/usr/share/applications/lollypop.desktop
par~/.local/share/applications/lollypop.desktop
avec la valeur qui va bien, mais pour que Lollypop se charge à l’ouverture de session, il faudrait surcharger/usr/share/applications/lollypop.desktop
par~/.config/autostart/lollypop.desktop
avec la valeur qui va bien. Ah oui, dernière chose,~/.config/monappli
est sensé surcharger/etc/xdg/monappli
, si vous suivez toujours.Il auraient pu faire ceci (je ne toucherais pas à
/etc
,/var
et/usr
pour des raisons historiques évidentes) :Ou un truc similaire et propre (peu importe les noms). On pourrait même inventer un
/xdg
vu qu’on a bien inventé/run
récemment, pour mettre fin aux/etc/machin/run
…Mais non, on a un standard branlant. Je le défends tout de même parce qu’au moins il est écrit et reconnu et qu’il vaut mieux un standard branlant que pas de standard du tout.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Emplacement fichiers de config
Posté par claudex . Évalué à 3.
Je ne vois pas l'intérêt de tout mettre dans
.local
, je préfère justement l'éclatement dans plusieurs dossiers, ça évite un niveau de répertoire pour rien. Parce que, pour moi, l'intérêt de ce standard n'est pas d'éliminer au maximum le nombre de fichier cachés, c'est d'éviter d'en avoir 200 et surtout de pouvoir faire de l'administration facilement. C'est-à-dire que je peux facilement décider (en tant qu'utilisateur, pas administrateur) de ne backuper que le$XDG_CONFIG_HOME
(pour$XDG_DATA_HOME
ça dépend un peu des applications) et de pouvoir vider régulièrement$XDG_CACHE_HOME
. C'est bien plus simple que de faire ce travail pour chaque application installée.Pour moi, la seule erreur, c'est d'avoir un
~/.local/share
au lieu d'un seul répertoire.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Emplacement fichiers de config
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
C’est là qu’il y a les goûts et les couleurs, moi je préfère un niveau de répertoire supplémentaire si ça réduit le nombre de fichiers dans
${HOME}
. :DLe fait d’avoir
$XDG_CONFIG_HOME
,$XDG_DATA_HOME
et$XDG_CACHE_HOME
dans un unique dossier n’empêche pas de traiter ces trois dossiers séparément.Ben oui, soit on fait trois dossiers bien séparés et sans niveau de répertoire supérieur, soit un met les trois avec un niveau de répertoire supérieur, mais on ne mélange pas les façons de faire !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Emplacement fichiers de config
Posté par claudex . Évalué à 3.
On parle de passer de 1 à 3 dossiers cachés, et ça doit être quasiment les seuls dossiers cachés qui existent dans
$HOME
, ça ne semble pas excessif. Ça veut dire que le nombre de dossiers dans$HOME
est facilement sous la dizaine (dans une organisation classique, qu'on retrouve par défaut dans les distributions par exemple). Bien sûr, c'est une histoire de goût.Je n'ai pas dit ça, ou alors je m'exprime très mal.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Emplacement fichiers de config
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je veux appuyer le fait que se limiter à un seul dossier caché dans
${HOME}
n’empêche pas de faire ce que tu souhaites, c’était donc possible de satisfaire ce que tu veux (traiter les dossiers séparément) et satisfaire ce que je veux (n’avoir qu’un seul dossier caché), les deux en même temps.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Emplacement fichiers de config
Posté par claudex . Évalué à 3.
Bien sûr, mais je veux aussi 3 dossiers séparés pour limiter la longueur des chemins.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Emplacement fichiers de config
Posté par claudex . Évalué à 4.
Ça tombe bien, la norme Freedesktop, c'est d'utiliser la variable d'environnement
$XDG_DATA_HOME
et de n'utiliser$HOME/.local/share
uniquement si cette dernière n'est pas configurée. Donc, tu peux la définir à$HOME/.local
.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Emplacement fichiers de config
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 15 novembre 2014 à 11:24.
Oui mais bon, j’aime bien utiliser les choses dans leur configuration par défaut, ça limite la maintenance et les surprises à long terme, et ça limite les problèmes si quelqu’un suit mal la norme ou qu’un bug est introduit par la suite… C’est pour ça que je préfère quand les normes sont cohérentes…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Emplacement fichiers de config
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Idem, c’est pour cela que pour XQF pour le moment j’ai déplacé
~/.qf
vers~/.config/xqf/
mêmes si certains fichiers peuvent êtres considérés comme du cache. C’est déjà moins pire…Il y a plein d’autres applications qui ne respectent pas bien le standard XDG, par exemple 0ad qui met des logs dans
~/.config/0ad/logs
et smplayer qui met des screenshots dans~/.config/splayer/screenshots
, mais tant qu’ils ne me pourrissent pas mon /home, je m’en contente.ce commentaire est sous licence cc by 4 et précédentes
# Format ecran
Posté par stilobique (site web personnel) . Évalué à 2.
C'est cool cette news ; vraiment un très bon jeu !
Est-ce que le format des ecrans actuelle est pris en charge avec cette version ? Switcher en 16/9|16/10 ?
[^] # Re: Format ecran
Posté par Spyhawk . Évalué à 3.
C'était déjà possible avant en jouant avec des paramètres manuellement, mais c'est maintenant supporté nativement: la résolution est détectée automatiquement.
[^] # Re: Format ecran
Posté par stilobique (site web personnel) . Évalué à 1.
Cool, merci beaucoup pour t'a réponse ;) . Va falloir que je me plonge dessus.
# PIMI pour installer des mods facilement.
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
La plupart des mods de Wolf:ET consistent à changer quelques aspects du gameplay indépendamment des cartes ou des personnages ou des armes. Ce n’est pas vrai pour une minorité d’entre eux qui sont des conversions complètes, comme les mods TrueCombat.
Après m’être rendu compte qu’ET:Legacy arrivait à lancer ceux-ci et qu’il était possible de rejoindre des serveurs, et qu’en fait c’était la première fois de ma vie que j’arrivais à lancer ces mods parce que ça fait déjà quelques années que c’est devenu quasiment impossible de le faire avec le binaire obsolète officiel de Wolf:ET sur nos distros modernes, j’ai écrit un script pour simplifier l’installation de ces mods que j’ai nommé PIMI, et qu’on trouve sur Github.
L’utilisation est assez simple, pour installer TrueCombat:Close Quarters Battle, il suffit de faire :
Après coup, je l’ai modifié pour permettre d’installer Wolfenstein: Ennemy Territory comme mod d’ET:Legacy (ce que fait aussi le script officiel cité dans la dépêche), il suffit alors de faire :
On peut passer des paramètres au script pour installer dans d’autres chemins (d’autres moteurs par exemple), l’aide
./pimi.sh
est assez complète.Par défaut le script ne supprime pas les fichiers temporaires, on peut les purger avec
./pimi.sh -p
. Il faut savoir que certains mods sont bizarremnt distribués, par exemple le mod TrueCombat:Elite est distribué sous la forme d’un exécutable gzippé qui est un script shell qui embarque un tarball gzippé lui aussi, qui contient un installeur et un tarball bzipé, qui contient finalement les fichiers. Installer un tel mod va extraire toutes ces étapes une par une avant de copier les fichiers utiles dans le bon répertoire, donc ça peut vite prendre quelques Go dans votre dossier temporaire.Mon script ne repose pas sur le mécanisme d’installation des installeur fournis (à la différence du script d’ET:Legacy pour etmain) car je ne leur fait pas confiance, je picore dans chaque archive le bon fichier pour l’installer à sa bonne place, et laisse les fichiers inutiles (le script d’ET:Legacy lui fait le ménage après coup à coup de
rm
). Ma méthode est d’autant plus remarquable lorsqu’on installe un mod qui est distribué en plusieurs parties, par exemple un installeur pour linux et une archive de patch avec des fichiers à écraser… Le mode TC:E pour Wolf:ET par exemple est distribué comme un installeur pour GNU/Linux et accompagné d’un zip pour Windows, Mac OS et GNU/Linux. PIMI extrait donc les fichiers de l’installeur sans l’exécuter, et extrait les fichiers propres à GNU/Linux et uniquement ceux-ci dans le zip de patch. Autre exemple, le mod TrueCombat pour Quake3 est distribué sous forme d’un zip complet pour la version 1.1, puis de deux zips de patchs pour la version 1.2 et 1.3, avec chacun de ces zip de patchs qui écrasent le précédent… PIMI picore dans chacune de ces archives les bons fichiers nécessaires à construire un installation de la version 1.3 du premier coup.Ça donne donc ça (copies d’écran de TC:E et CQB prises avec ET:Legacy) :
Pour différentes raisons que je n’ai pas approfondi, il semble seulement possible de se connecter à des serveurs distants de TC:E et CQB. J’ai réussi je ne sais pas comment à lancer la toute première et unique fois une partie en local, mais je n’ai pas reproduit depuis. Ce n’est pas la faute à PIMI mais à l’obsolescence de ces mods.
Je ne sais pas si on peut lancer un serveur TCE ou CQB avec ET:Legacy, et si ça ne marche pas il faudra probablement utiliser le Wolf:ET obsolète sur une distro obsolète… Actuellement tous les serveurs TCE et CQB que je vois en ligne sont sous Windows ou bien sous GNU/Linux avec un build maison de Wolf:ET. :/
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: PIMI pour installer des mods facilement.
Posté par KiKouN . Évalué à 3.
Ha, TC:E, c'est pas un mods pour stressés cela. Là dessus aussi, j'en ai passée des heures. Principalement à attendre durant les matchs.
En public, ce jeu a un gameplay assez basique. Mais durant un match, c'est tout autre chose. Si on défends, on essaye de tenir une position. Ce qui se résume à attendre un possible mouvement ( en général, pendant 3 à 4 minutes ) et à tirer une ou deux balles au bon moment et, de temps en temps, ça s'emballe. En attaquant, le but est de prévoir la possible position de la défense ( en général, pendant 3 à 4 minutes ) et à tirer une ou deux balles au bon endroit. Mais des fois, faut prendre son courage à deux mains et foncer dans le tas.
[^] # Re: PIMI pour installer des mods facilement.
Posté par Spyhawk . Évalué à 5.
C'est pour ça que, perso, je n'ai jamais aimé les Counter-Strike like. En fait, je n'aime pas vraiment les FPS de type Quake non plus. Mais ce que j'apprécie énormément sur ET, c'est cette dimension jeu tactique d'équipe + objectif à atteindre. On peut faire gagner son équipe sans faire un seul kill, et à l'inverse faire le plus de kill et perdre!
# Pas de listes de serveurs
Posté par Cyber Kobold (site web personnel) . Évalué à 1.
J'ai installé le jeu sous windows 7 (64 bits)
Au lancement il n'y a pas de listes de serveurs.
et le jeu ne se connecte pas, même si j'entre manuellement l'adresse IP d'un serveur (celui de et4life par exemple).
Dommage je me serai bien remis à ET…
[^] # Re: Pas de listes de serveurs
Posté par Spyhawk . Évalué à 2.
Vérifie ton pare-feu, il y a bel et bien plusieurs centaines de serveurs disponibles.
[^] # Re: Pas de listes de serveurs
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
En ce moment, 376 exactement, donc oui, il y a un problème ailleurs sur le réseau. :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas de listes de serveurs
Posté par Cyber Kobold (site web personnel) . Évalué à 1.
quels ports utilise ET ?
j'ai quelques règles sur mon routeur et peut être quelles entrent en conflit avec ET ?
[^] # Re: Pas de listes de serveurs
Posté par Spyhawk . Évalué à 2.
Essai d'ouvrir les ports 27950 (master list), 27951 (MOTD, update) et 27960 (serveur local).
# Pseudo drama juridique
Posté par bubule . Évalué à 4.
La section sur les licences et les "problèmes" juridique est de la fantaisie.
Quake 3 Arena est sous GPLv2+ donc aucun soucis pour l'utiliser avec du GPLv3+.
Maintenant pour ce qui s'est passé avec ioquake3 c'est principalement du drama et de la crise d'ego de quelques types.
Lorsque RTCW et ET sont passés sous GPL le plan de certains (et logique, pour éviter de repartir à la chasse aux nombreuses failles de sécu de quake3) était d'étendre ioq3 afin de pouvoir les faire tourner comme des mods du moteur.
Les différences sont minimes au niveau des moteurs Q3 et Wolf.
Sauf que les mainteneurs de ioq3 ont appliqué la fameuse inégalité de l'«open source», BSD 3 clauses >>>>> GPLv2 > GPLv3.
S'en ai suivis le lot habituel de FUD et de grand n'importe quoi pour conclure que la GPL c'est de la merde trop compliquée mais que la version 3 était encore pire. Du coup hors de question d'avoir du code souillé s'intégrer à leur projet.
Et cela a plus ou moins stoppé la discussion et démotivé les enthousiastes qui voulaient se lancer là dedans.
Si les projets iowolf et iowolfet n'ont rien donné c'est que personne chez les ioboys ne s'est bougé.
Du coup les autres projets qui se sont développé indépendamment sont tout ce qu'il y a de plus légal juste que l'aboutissement ultime, social et professionnel de ces projets n'est (peut être) pas de finir sur steam ou de se faire remarquer par dieu Gabe pour avoir un CDI au paradis et leur revendre son code BSD.
Voilà mon témoignage à 2 centimes sur comment casser les bonnes dynamiques, saper le morale des gens motivés et suffisamment ralentir les développement pour que tout le monde meurt de vieillesse avant d'avoir une release.
ET:Legacy est bouffée d'air fraîche dans ce milieu.
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3. Dernière modification le 16 novembre 2014 à 16:59.
Tu devrais relire le paragraphe en question: il n'est nulle part question de soucis pour réutiliser du code GPLv2+ avec du code GPLv3, mais de l'inverse. Si le code des moteurs Quake et Wolf:ET sont relativement similaires au niveau des fonctionalités, on ne peut pas simplement jeter 5 ans d'optimisation, réécriture et autre nettoyage de code sur un coup de tête.
C'est dommage que des questions juridiques ont démotivé certains contributeurs, mais sur le fond ils ont parfaitement raison. La BSD est claire et limpide, tandis que dans le monde de la GPL c'est une catastrophe pour s'y retrouver. J'irai presque jusqu'à dire que c'est tout à l'honneur des gens d'icculus de ne pas s'aventurer dans une jungle incompréhensible avec des transferts de code très difficile à contrôler.
Car il y a bel et bien des problèmes juridiques potentiels envers du code GPLv2. Le code de Quake 3 d'Id Software n'a pas été libéré explicitement sous une version précise sous la formule bien connue "[…] released under GPLv2/released under GPLv2 or any later version"), mais simplement accompagné d'un fichier COPYING.txt avec le texte de la GPLv2 dedans.
La section 9 de la GPLv2 est la suivante:
Ioquake a fait le choix de la GPLv2+, mais ce n'est pas le seul projet basé sur le code source d'Id Software. Pour te donner un exemple plus concret, ET:Legacy avait besoin d'un patch issue du code du projet Quake 3 Movie Maker's Edition pour résoudre un bug de synchronisation du son et de la vidéo lors de l'enregistrement des demos dans le format .avi, au lieu du format .dm_84 interne. Q3MME est cependant un projet disponible sous licences GPLv2 et LGPLv2. Cette partie de code a pu être passé dans ioquake sans problème, mais pour ET:L il a fallut demander explicitement l'autorisation aux auteurs originaux afin de relicencier le code en question sous GPLv3. Et pour obtenir une permission, c'est toujours très long et très compliqué de contacter la bonne personne.
Comme Thomas a fait la remarque dans un commentaire plus haut, les personnes d'un certain projet se retrouvent dans la communauté des autres, et je doute fortement qu'il n'y ait pas du code GPLv2 only dans le code actuel d'ET:Legacy, tellement que les les patchs virevoltent d'un projet à un autre (tous ces projets sont sous licence GPLv2 ou v2+). Dans l'équipe de dev d'ET:Legacy on s'accorde à dire que cette licence GPLv3 est une vrai plaie dont on aurait préférée se passer.
Je n'ai absolument pas compris ce que ce paragraphe a en lien avec le code ioquake et sa licence.
[^] # Re: Pseudo drama juridique
Posté par benoar . Évalué à 4.
Tu n'es même pas allé lire le lien que tu pointes… tu m'étonnes que tout le monde s'embrouille si les gens ne vont même pas lire l'en-tête du code dont ils parlent :
Bon, après, le non-respect des licences chez les gamers est quand même un phénomène assez répandu en général, malheureusement.
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3.
Mea culpa, j'ai complètement raté le coche ici. J'ai bêtement assumé que la version aurait du être mentionné dans le README :/
[^] # Re: Pseudo drama juridique
Posté par benoar . Évalué à 3.
Pas de problème, ma réponse était peut-être inutilement agressive par contre.
Effectivement, ça aurait pu être le cas, mais souvent il faut aller voir directement dans les sources, car la licence d'un projet « au complet » n'est souvent pas si facile que ça à déterminer : on inclus souvent des bouts de code sous d'autres licence, plus permissives, et c'est bien de le mentionner. La FSF dans son guide d'utilisation de la GPL précise bien qu'il faut ajouter les éléments de licence « dans chaque fichier source ». Autre exemple, Debian fait bien attention de mentionner (de manière lisible par une machine !) les licences de chaque fichier d'un paquet : http://dep.debian.net/deps/dep5/.
Ces précautions sont dues, je pense, au fait qu'on peut facilement trimbaler un fichier à droite à gauche comme « unité de code », et que de noter sa licence dans un en-tête dans le fichier est le moyen le plus pratique pour ne pas perdre ces informations.
De même, comme on le voit dans ce thread sur la confusion sur le passage d'une licence à une autre, ajouter un patch GPLv3+ à un projet GPLv2+ ne transforme pas — d'une certaine manière — d'un coup « tout le projet » en GPLv3+ : toute modification du projet qui n'est pas déterminée comme un travail dérivé du patch en question peut tout à fait continuer à exister sous GPLv2+. Tout comme un bout de code BSD n'est pas « transformé » en GPL s'il est inclus dans un projet GPL : si on peut faire des modifications à ce bout de code en particulier, de manière indépendante du projet, et qu'on souhaite qu'il reste en BSD, on peut. Alors oui, ça n'est pas évident comme nuance, mais cela n'est pas dû à la GPL ni à la FSF, mais au droit d'auteur et au principe de travail dérivé, choses qui ne sont pas évidentes à appréhender. La BSD est plus simple non pas par ses clauses réduites, mais de part le fait qu'elle ne se soucie pas des travaux dérivés d'un code BSD, ce qui effectivement simplifie les implications légales.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Ben, pour ce qui est du code, c’est vrai, si j’inclus un patch GPLv3+ dans un projet GPLv2+, toute personne qui clone le dossier des sources peut retirer ce patch, et ce qui reste après nettoyage est effectivement un code sous GPLv2+.
Maintenant, si ladite personne retire le patch et publie un binaire, les utilisateurs du binaire peuvent exiger différentes choses selon les termes de la GPLv2+. Si ladite personne ne retire pas le patch et publie un binaire, les utilisateurs du binaire peuvent exiger différentes choses selon les termes de la GPLv3+.
C’est pour ça que j’ai plutôt utilisé le verbe teinter que le verbe transformer, c’est déjà ce mot là qui est utilisé lorsque par exemple on compile et charge un module propriétaire sur un système Linux. L’ensemble « Linux + module » est soumis aux termes des licences de l’ensemble de ses parties (qui peuvent être incompatibles, d’où l’impossibilité de redistribuer).
Si tu distribues un binaire ioquake3, à partir du moment où tu le distribues avec un patch GPv3+, il faut que tu fournisses en plus une copie de la GPLv3+ avec ton binaire, ça ne change rien au fait qu’effectivement l’écrasante majorité du code est et restera du code GPLv2+.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
Merci pour ce post détaillé et tes éclaircissements!
Et bien, je savais que Debian était très à cheval sur les licences, mais je ne pensais pas qu'ils iraient jusqu'à traquer les licences de chaque fichier…
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je ne savais pas qu’ils allaient jusque là non-plus, mais ça ne m’étonne pas et c’est pour ce genre de chose que j’apprécie Debian. :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
C’est moins la GPLv3 qui est une plaie que le fait qu’id Software a distribué du code sous GPLv2 comme celui de Quake 3 et du code sous GPLv3 comme celui de Wolf:ET et Doom3 (je fais abstraction ici des « + », « if any » et autres nuances).
Il était évident que ça allait poser des problèmes chez les développeurs actuels, ne serait-ce que de devoir se prendre la tête sur des questions juridiques au lieu de coder. C’est d’autant plus vrai entre le code de Quake 3 et celui de Wolf:Et qui sont deux branches d’un même moteur (alors que celui de Doom3 diffère beaucoup plus).
Il était évident que des personnes allaient vouloir merger les deux bases de code, et cette publication sous GPLv3 ressemble vachement à une décision de juriste déconnecté des réalités qui a fait un excès de zèle et qui a choisi une licence par fondamentalisme au mépris complet des réalités techniques et au mépris complet de l’existant.
Imaginez si par exemple Firefox était publié sous GPLv2 un jour et Thunderbird sous GPLv3 le jour d’après, parce que finalement Mozilla préférerait la GPLv3?
Ou encore si LibreOffice Writer et LibreOffice Calc n’avaient pas la même licence ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 2.
Ouai enfin ils ont surtout pris la dernière version en cours de la GPL. S'il y a ce genre de problème faut surtout en parler à la FSF qui sors des versions de sa licence phare sans prendre en compte ces problèmes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
C'est gratuit et non étayé, vu les longues discussions ayant eu lieu durant le processus d'écriture de la GPLv3, avec le fait que la GPLv3 introduit de nouvelles compatibilités (APL 2.0 par exemple) et avec le fait que la FSF recommande toujours de prévoir « version x ou suivantes ».
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 4.
Leurs licences sont des casse-têtes. Assez infernal comparé à la majorité des autres licences libres (reconnu comme tel par l'OSI par exemple).
Oui ils créent des incompatibilités et tentent de résoudre, mais on est très loin d'une situation "propre".
Ils ont même parlé de le rendre obligatoire à une époque, c'est proche d'un multilicencing et c'est plus une manière de se raccrocher aux branches qu'autre chose.
Entendons-nous bien. C'est cool ce qu'ils essaient de faire et je comprends qu'ils cherchent à résoudre de vrais problèmes, mais ils le font de manière tellement compliqués que soit les gens utilisent la GPL sans chercher à comprendre "parce qu'il paraît que c'est bien" soit ils se détournent et vont vers de la simplicité. Il faut comprendre qu'une partie des problèmes qu'ils résolvent ne concerne que très peu de logiciel (la tivo par exemple).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Ils n’avaient aucune obligation de prendre la dernière, surtout quand ils ont déjà du code sous une licence donnée.
La GPL est un contrat juridique qui définit entre autre comment peuvent être assemblées deux bases de code, quand on a déjà une base de code sous une licence, on ne choisit pas le contrat de la seconde base de code juste parce que c’est la dernière.
Peut-être que la GPLv3 est mauvaise et qu’on peut reprocher à la FSF certains termes de cette licence, mais on ne peut pas reprocher à la FSF le fait qu’un tiers mélange des licences FSF potentiellement incompatibles dans son propre catalogue de logiciels.
C’est un peu comme si quelqu’un publiait deux dérivés d’une même bibliothèque en GPL et en LGPL, avec des petites variantes en GPL et d’autres variantes en LGPL. Ce ne serait pas la faute à la FSF si le juriste prend des décisions qui empêchent de travailler correctement.
Il n’y a aucune obligation à prendre la GPLv3 parce que c’est la dernière, il ne faut choisir une licence que parce que les termes de ce contrat nous satisfont, pas parce que c’est la FSF qui l’a écrit et que c’est la dernière que la FSF a écrit.
Franchement, si je paie un juriste pour me trouver une licence satisfaisante, en pesant chaque close en fonction des contraintes spécifique de notre production, et qu’il me choisit la GPLv3 parce que c’est la FSF qui l’a écrite et que c’est la dernière que la FSF a écrite, je vire le gars.
Ici, la GPLv3 n’était pas satisfaisante pour les dérivés d’idTech 3, ce n’est pas la faute de la FSF si quelqu’un a choisi la mauvaise licence.
La prochaine fois que j’irai voir une compagnie d’assurance, je prendrai leur toute dernier contrat parce que c’est le dernier et uniquement pour cela, même si c’est une assurance de voiture alors que j’ai besoin d’une assurance rapatriement sur piste pour aller au ski, tiens, ça sera rigolo.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3.
Pour être honnête, j'ai plus l'impression que le service juridique de Zenimax a balayé le passage sous licence libre en 2 coups de cuillère à pot, et qu'aucune réflexion n'a été faite sur le choix de la licence à part "on prends la plus récente".
Je faisais évidemment référence à la GPLv3 comme une plaie dans le contexte de l'écosystème de projets existants sous GPLv2/v2+
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 3.
C'est archi faux…
Zenimax a très bien utilisé la GPLv3 et ses clauses sur les trademarks par exemple.
Ils savent très bien ce qu'ils font.
(dernier paragraphe…)
https://github.com/id-Software/RTCW-SP/blob/master/COPYING.txt
Le deal a toujours été le suivant: "On vous donne le code de nos moteurs sur lesquels on ne fait plus notre business pour qu'ils puissent être étudié (principale raison) mais on ne veut pas créer un projet qui puisse nous concurrencer."
En gros on "académise" notre code mais cela doit le rester, la GPL est parfaitement justifiée pour cela.
Au passage cela permet à quelques vieux groupes de poileux de s'amuser dans leur garage.
Mais quant à l'idée de voir des business concurrents émerger, ils ont pris soin de s'en protéger.
Il n'y a aucune incompatibilité entre les différents codes et licences du côté de l'éditeur.
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3.
Oui, mais je faisais ici explictement référence à la problématique GPLv2 vs GPLv3, qui ne semble avoir aucun sense à part le fait qu'ils ont pris la dernière version parce que c'est la plus récente.
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 4.
Et je maintiens qu'il n'y a pas de problématique à part celle crée (artificiellement par les devs en bout de chaîne) qui est donc plus politique et qui n'a rien à voir avec les (problèmes de) licences.
Du coup ils ne veulent pas des quakeboy (like) qui sortent sur le marché. La GPLv3 s'impose directement pour clarifier ces points (et d'autres) + les histoires de brevet (cf doom3 aussi).
Ils ont pris la dernière version parce que c'est la meilleure par rapport à leurs objectifs.
Et accessoirement aussi pour les joueurs mais s'en rendent-ils compte ?
L'idée est de partager la connaissance technique et cette connaissance doit reste ouverte, inconditionnellement.
(Je ne sais pas comment faire plus clair).
Alors que pour certains devs avec leur dure labeur face à cette montagne de code, la réaction est plutôt: "avec mon super patch qui apporte des features trop oufs et quelques skins je dois bien pouvoir me faire (un peu) de blé."
Et du coup pour ceux là GPLv2+ est déjà trop restrictive mais quand même moins que la v3 (mais pourquoi ?) donc il faut garder la v2 et expliquer pourquoi tout ça c'est trop mal les licences, que BSD c'est bien pour faire comme apple et chercher les sous chez les fidèles pour résoudre ce soucis et sortir une bouse proprio de plus sur steam.
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 4.
Mais c'est bien pour ça que les moteurs sont libérés uniquement lorsque leur potentiel économique est épuisé! Le moteur iDTech 3 est sorti il y a ~15 ans, et il ne vaut plus rien commercialement.
S'ils ne voulaient pas de nouveaux dérivés, ils leur suffit de ne pas libérer leur moteur. Sous entendre qu'Id Software ou Zenimax ont "bloqué" en connaissance de cause le développement du code WolfET avec la GPLv3 pour ne pas avoir de concurrents, alors même que le moteur réécrit iDTech 4 plus récent a été libéré seulement une anné plus tard, ça tient de la théorie du complot paranoïque.
On parle de la GPLv2/v3, je ne vois pas ce que ton délire sur la BSD et Steam viennent faire ici.
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 1.
Heu ??????????????????????????????????
Prend le temps de relire mes messages.
Et donc je répète encore un fois.
L'idée est de partager la connaissance technique et cette connaissance doit reste ouverte, inconditionnellement.
Donc si la GPLv2 est connue pour avoir des failles par rapport à ces objectifs (et c'est le cas), ce n'est pas la licence à utiliser. Donc la GPLv3+ est un bon choix. Et par rapport à ces objectifs c'est une bonne chose que les codes se mettent à jour.
Faux! Tu peux partager (pour pleins de raisons) ton code sans vouloir que le premier qui arrive à le compiler le remette sur le marché et se remplisse les poches sans valeur ajoutée.
Mon délire c'est qu'une partie des devs (de ioquake3 par exemple) sont très "corporate" et dans l'industrie du JV. Donc c'est pas toujours fun pour eux de ne pas simplement pouvoir c/c le code et en faire leur gagne pain. L'aspect liberté les concerne bien peu, c'est juste pratique que le code soit dispo pour se faire la main et se faire remarquer.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 18 novembre 2014 à 10:59.
Hum, je ne sais pas à quelle réalité ces affirmations correspondent…
Tu connais beaucoup de personnes qui
Qui plus est, il y a des choses que la GPLv2 ou GPLv3 empêchent, mais pas de se faire du blé. La GPL empêche seulement certaines manières de se faire du blé comme le fait de vendre un binaire sans les sources, mais parce que le problème n’est pas de vendre mais de distribuer les binaires sans accès aux sources.
Tu aurais un exemple concret d’abus de la GPLv2+ avec le code de Quake 3 qui aurait pu être évité avec la GPLv3+ ?
[Edit : et qui vaille le coup de licencier sous deux licences différentes deux branches d’un même code avec les interrogations que cela soulève ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 2.
Ce que j'ai oublié de dire c'est que généralement avoir un code libre ferme pas mal de portes par rapport à l'industrie du JV.
Donc certains cherchent des solutions hybrides (et fumeuses à mon goût) pour avoir le meilleur des 2 sans les devoirs. (cf Urban Terror ?)
Du coup pour ces cas là les licences BSDs font plus saliver.
Je n'ai jamais dis que ces gens étaient rationnels ou compétents juste qu'il subsiste dans l’inconscient populaire (pour certains) que BSD > GPLv2 > GPLv3. Omettant les intentions de ceux ayant publié le code originel.
Donc je ne parle pas de double licence ou d'abus.
Juste que la position disant que la GPLv2+ est arrangeante est:
1. Non fondée (sauf cas particulier déjà évoqué).
2. Entraîne beaucoup de confusion et de désinformation (qui décourage les nouveaux venu).
3. Empêche l'amélioration du code avec des nouvelles fonctionnalités utiles comme nouvelle référence.
(rien n’empêche de faire ça à travers un nouveau projet comme ET:L)
Au final c'est un soucis politique et social avec une perte de temps et de volontaires impressionnante pour des raisons douteuses mais que certains pensent arrangeante (pour eux).
Et lancer un projet après l'annonce médiatique de la disponibilité du code ou 4 ans après change beaucoup de choses en terme de dynamique.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 18 novembre 2014 à 14:21.
Ah je veux bien croire que certains ont des solutions fumeuses et opposent des arguments non rationnels, et ton exemple d’Urban Terror est extrêmement pertinent, ils ont officiellement et publiquement justifié leur retour au propriétaire pour deux raisons (traduction libre du fond de ma mémoire) :
En utilisant le code du SDK propriétaire et non celui d’ioquake3, Urban Terror qui était déjà standalone ne serait plus un mod, mais un vrai jeu.
En utilisant le code du SDK propriétaire et non celui d’ioquake3, ils pourront améliorer le code, et tout le monde aime les améliorations.
Pour le premier argument fumeux, ça doit être l’effet « cours des grands ». C’est fumeux mais ça compte vachement pour certains. Pour le second argument fumeux, ils devaient sous-entendre que tant qu’ils avaient obligation de distribuer leurs modifications, ils ne modifieraient rien.
Quoi qu’il en soit, ces arguments ne tiennent pas, ioquake3 n’empêche pas de faire un standalone (ils l’ont fait eux-même) et ioquake3 n’empêche pas de modifier le code. Donc oui, c’est fumeux et ça cache des motivations non dites qu’ils n’ont pas voulu assumer publiquement.
Le troll GPLv2+/GPLv3+ est stérile, mais ça par contre c’est super intéressant, tu pourrais détailler plus ? :)
Le projet Urban Terror se justifie avec des argumentations fumeuses, mais ils ambitionnent d’être pris au sérieux, quelles portes pourraient s’ouvrir pour eux en fermant leur code ? Ça ils se sont bien gardés de le détailler…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 1.
Au final urt est quasi mort (juste qu'il y a encore beaucoup d'amour de quelques personnes pour le faire survivre comme c'est possible mais sans les sources l'issue est connue).
Leur moteur (enfin le mod surtout) est incompatible avec les autres moteurs (ioq3 et dérivé) et clairement à la ramasse niveau perf.
Et au final ils font un nouveau jeu sur UT4…
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
C’est ce qu’il me semblait parce que bon dans les faits, il n’a pas beaucoup évolué.
J’avais vu ça mais je ne sais pas si c’est encourageant. Rien à voir avec UT4, mais ça fait plusieurs fois qu’il me semble les entendre annoncer prendre un nouveau départ et que ça irait mieux après, même si cette fois, avec un changement de moteur, c’est assez conséquent. Disons que pour le moment je vois les annonces qui s’enchaînent années après années, mais rien de vraiment concret en sortir.
Par contre de manière générale, si tu as plus de détails sur :
n’hésite pas. :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
Mouai, alors ça je ne sais pas si c'est vraiment le cas. Un contre exemple est l'auteur d'OpenWolf qui a décroché un job dans l'industrie du jeu vidéo justement grâce à ses démonstrateurs.
Après, c'est sur qu'un jeu en GPL est très difficilement viable économiquement par rapport à du code BSD que l'on peut fermer (pour les versions futures) et en faire un jeu proprio.
[^] # Re: Pseudo drama juridique
Posté par Zenitram (site web personnel) . Évalué à 2.
Rien à voir : tu peux fermer du code GPL autant que BSD, la licence de diffusion n'est pas le sujet.
L'important est de savoir qui a les droits sur le code (exemple : diffusion en GPL mais demande de CLA pour accepter du code externe au tiens)
Sans compter la facilité "BSD = viable" qui est limite du FUD…
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3.
Oui, tu as entièrement raison à propos du CLA. Ce n'est cependant pas le cas des projets basés sur ioquake et j'ai oublié ce "détail" dans ce contexte. Merci de l'avoir rappelé!
J'aurais du utiliser les termes "du code libre est plus difficilement viable que du code que l'on peut fermer". Un code proprio n'obtient bien évidemment pas forcément le succès escompté.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Tu peux me dire en quoi la GPLv3+ l’empêche ?
N’importe qui peut prendre le moteur de Ddoom 3 sous GPLv3, changer toutes les données (comme l’on fait les gars du Dark mod), et vendre le produit fini. Surtout que bon, là, y a vraiment moyen de se faire du blé en vendant les pk4 d’un jeu complet. Le moteur lui-même n’est plus commercialement viable, mais il y a toujours moyen de vendre le travail d’une équipe de scénaristes, de graphistes, d’animateurs et de musiciens dans un package qui contient une version compilée du moteur libre de Doom 3 et un set de pk4 bien ficelés et aux sources farouchement gardées.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 0.
Il y a donc une valeur ajouté et les sources restent dispo.
Pas de soucis du coup.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
ET?
La GPLv3 ne contraint pas à ajouter de la valeur.
La GPLv2 suffit à garantir cela.
Ben oui il n’y a pas de souci, c’est pourquoi ton troll est complètement farfelu.
Tu n’as toujours pas donné un exemple concret de « souci », si ce n’est d’attribuer des propriétés complètement fausses à la GPL (valeur ajouté, revente) ou complètement fausse sur la différence GPLv2 / GPLv3 (disponibilité des sources)
Qu'est ce qui m’empêche de mettre en vente un CD comprenant un clone du repo d’Id Software sans aucune valeur ajoutée ? Rien, pas même la GPLv3 !
Je reprends ton affirmation :
Explique-moi en quoi la GPLv3 empêche
Explique-moi maintenant comment au moins un seul de ces quatre points est empêché par la GPLv3 et pas par la GPLv2.
Bon courage.
Si le juriste d’Id Software/Zenimax a choisi la GPLv3 pour ces raisons, qu’on ne lui donne même pas un boulot auprès de la photocopieuse.
Id Software / Zenimax ont certainement de très bonnes raisons d’avoir choisi la GPLv2 un jour, puis la GPLv3 un autre jour, enfin j’espère pour eux, dans ce cas là quelles sont ces raisons ?
Parce que tu es très fort pour expliquer que ne pas prendre à la légère la différence de licence entre deux branches d’un même code est du pinaillage, mais tu ne nous a pas montré en quoi la différence de licence entre deux branches d’un même code n’est pas du pinaillage pour Id Software/Zenimax.
Si tu trouves qu’Icculus pinaille sur cette différence de licence et que ça ne vaut pas le coup de se prendre la tête, le premier a avoir pinaillé c’est Id Software/Zenimax. Si la différence GPLv2/GPLv3 est du pinaillage, la GPLv2 allait très bien et ça ne valait pas la peine de se prendre la tête à changer de contrat de licence entre deux branches d’un même code.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3. Dernière modification le 18 novembre 2014 à 12:23.
Oui, et je ne vois toujours pas où tu veux en venir. Si tu essais de dire qu'IdSoftware/Zenimax ont envie de partager du code mais d'empêcher un concurrent commercial de venir les embêter sur leur plate bandes avec ce code, c'est déjà fait: En ne mettant à disposition le code que lorsqu'il est obsolète commercialement.
Si tu veux dire qu'IdSoftware/Zenimax veulent partager du code tout en empêchant des dérivés "amateurs" (voire commerciaux?) d'apparaître, alors non, un choix de licence qui permet la modification, redistribution et vente comme la GPL n'est certainement pas un bon choix.
J'avais bien compris, mais je ne vois pas quel est le rapport avec la GPLv2/v3. Si des dev veulent démontrer leur compétences avec du code libre pour obtenir leur boulot de rêve dans l'industrie du jeu vidéo, et bien tant mieux! Leur contributions au code est libre et ça peut profiter à d'autres. Aussi, la viabilité du modèle économique du logiciel libre dans le domaine du jeu reste entièrement à prouver (mais ça c'est un tout autre sujet).
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à -1.
Donc on est en accord ?!
La GPL (et v3+ en particulier) est bien pour protéger les joueurs quelques soient les intentions des devs. Cela offre une pérennité à long terme.
Le "problème" de licence avec les anciens clients GPLv2+ dérivés de Quake1/2/3 est purement politique et social mais en rien juridique et "la GPL c'est de la merde et ça crée des soucis" est de la fantaisie.
Surtout en prenant en compte l'idée de départ de l'éditeur: la connaissance technique doit être partagée et cette connaissance doit reste ouverte.
Que la GPLv2+ ne garanti plus.
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 5.
Il n'y a pas masse de projet dans le libre qui sont en mesure de comprendre la GPL (quelque soit la version).
Tu le répète à chaque phrase. Ils n'ont obligation à rien. Ils auraient pu ne pas publier le code ou le faire avec la licence CDDL si ça leur faisait plaisir. C'est pas sûr qu'ils aient des juristes à pleins temps ni qu'ils aient demandé à un de leur juriste son avis là dessus la publication du code n'est pas une priorité de l'entreprise, c'est une démarche qui est faite en marge probablement poussé par les techos et qu'ils font avec les moyens qu'ils ont.
Maintenant quand on ne comprend pas tous les détails juridiques. On peut voir que la licence du moment, celle qui est poussée par la FSF c'est la v3, que selon la FSF elle est mieux, qu'elle protège mieux le code (anti-tivo et meilleure internationalisation par exemple). Bref c'est pas non plus totalement crétin de passer son code sous v3. Sachant que dans les règles de l'art leur code sont sous licence GPLvX+. Il a était maintes fois demandé à Linus s'il y avait un plant pour passer Linux en GPLv3, eux l'on fait.
Bref il n'y a rien de délirant là dedans.
Alors là oui ta va prendre leur dernier contrat. Ils ne te laisseront pas le choix. Ce dont tu parle c'est de prendre la GPL ou la LGPL, ce n'est pas une question de version, mais de type. Mais si tu veux va voir Orange et demande leur un forfait OLA pour voir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Quand je choisis une licence de la FSF comme la GPL pour couvrir mon code, c’est moi qui fournit des droits et des devoirs, pas la FSF. La FSF a formulé les termes de la GPL, mais c’est moi qui fournit le service "code sous GPL". Si la FSF supprime sa GPLv2 et que moi je la ressors du placard pour protéger mon code, ce contrat lie mes contributeurs, mais ne lie pas la FSF.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 1.
En effet comme quoi ton analogie est vraiment pourrie.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Mon analogie portait sur la volonté de prendre le dernier parce que c’est le dernier, elle est forcément pourrie quand il s’agit d’illustrer la volonté de prendre ce qui a été remplacé parce que ça été remplacé.
Et la GPLv3 ne remplace pas la GPLv2.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3.
Et c'est justement pour ça qu'ils auraient du choisir un autre nom, àmha.
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 6.
Bref toute la rhétorique officielle ou non indique que la GPLv3 > GPLv2 et le présente comme un remplaçant (on ne devrait plus utiliser GPLv2 qui pose des problèmes).
Sincèrement quand on lit sur le site officiel :
Il est clair, que l'objectif de la FSF est de faire passer le maximum de logiciels en GPLv3(+).
Parce que c'est la seule qu'on te présente, parce que dès qu'on te parle de l'autre c'est pour dire que la GPLv2 a pleins de problème et que bon garder la GPLv2 ça peut se faire mais vaut mieux migrer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Le film Terminator 2 ne remplace pas le film Terminator.
Une licence est un texte écrit, ce n’est pas un corps organique. Richard Stallman n’est plus l’homme qu’il était le jour de la publication de la GPLv2 ni même celui du jour de la GPLv3, mais la GPLv3 n’a pas évolué en GPLv2 en se substituant à la GPLv2. La GPLv3 est une copie modifiée de la GPLv2.
Tant que quelqu’un utilise la GPLv2, ce contrat est actuel.
Quand bien même la FSF ferait tout pour qu’on choisisse la GPLv3 et ferait de l’obstruction lorsque certains chercheraient la GPLv2, si je ressors la GPLv2 de dessous mon lit pour distribuer mon code, ce contrat ne serait pas rendu caduque par la GPLv3, mon code serait sous GPLv2 et la GPLv3 ne changera rien à cette réalité tout à fait actuelle.
Tant qu’un seul code est couvert par la GPLv2 et qu’un seul homme s’y soumet, cette licence est actuelle, même s’il existe une version plus récente nommée GPL.
Id Software/Zenimax avait une branche du code actuel sous une licence actuelle, ça aurait grandement simplifié les choses de soumettre l’autre branche du code actuel sous cette même licence actuelle.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 4.
Tu mélange 2 choses volontairement.
Oui je peux même prendre la première GPL ou une version draft de n'importe la quelle et m'en servir. Légalement ça a une valeur tout comme la licence rien à branler ou la beerware. Personne n'a jamais dis le contraire.
Ce que je dis c'est que tout est fait pour supprimer la GPLv2. L'organisation qui l'a créé ne veut plus en entendre parler. Il n'est donc pas surprenant de voir tout les projets et codes libéré se mettre à utiliser ou passer en GPLv3 comme le recommande la FSF.
Sur ce à moins que tu arrête la langue de bois et la mauvaise fois, je m'arrêterais là, je ne vois pas ce qu'il y a des plus à dire à se sujet, on va commencer à tourner en rond.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
Il est clair que la FSF ne met pas la GPLv2 en avant, mais s'ils voulaient vraiment tout faire pour la supprimer ils auraient du rendre la partie "version x ou suivantes" obligatoire légalement. Parce que là, ils ont fait la même "erreur" avec la GPLv3 et ça risque de leur péter à nouveau à la figure quand la GPLv4 sortira dans quelques années.
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 3.
Il me semble que c'est une idée qui avait était émise et qui a suscité une grosse controverse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
En même temps en licenciant « version x ou suivantes », on signe un chèque en blanc au bénéfice de la FSF, tant qu’ils sont dignes de confiance ça va, mais ils ont tout pouvoir sur le contrat qui couvre ton code dès lors qu’ils publient une licence nommée « GPL version x+n ».
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 2.
Pour moi les licences sont très claires et il n'y a aucun problème juridique, juste un choix des devs. Peux être que mon message n'était pas assez clair…
Le dernier paragraphe est juste pour laisser une note sur une partie des dev pour qui l'aspect liberté de la licence est (presque) le dernier de leur soucis. Leur modèle de réussite étant valve et steam. Les projets "open source" sont surtout là pour se faire remarquer et embaucher. Il y en a tout de même qui font ça comme (simple) hobby.
Et je ne vois pas pourquoi. Éternel débat inutile. GPLv3 ~ GPLv2 + anti tivo + souplesse dans les clauses pour les entreprises.
Le point final reste généralement "La GPL ça pue et BSD stro bien", indépendamment des versions.
Et donc suivant les points de vue la GPL est une très bonne choses pour se protéger des gens qui ne comprennent pas ce qu'il se passe dont l'ego explose rapidement avec le nombre de patchs.
Ceux qui en sont aussi bénéficiaires au final sont les joueurs et les nouveaux/futurs développeurs et c'est très bien comme ça.
Pour conclure, il n'y a aucun soucis à prendre un code GPLv2+ et (à ta discrétion) le passer en GPLv3+ pour ton projet. Le problème ici est que petit jeune que tu es, on te dit que tu seras tout seul, tes améliorations ne seront pas "backporté" dans ce qui est sensé servir de moteur de référence, les gens qui connaissent bien le code resteront loin de toi et ensuite avec tout la désinformation sur les licences, que tu n'a pas le droit de le faire si ça reprend du quake3 + patchs. Du coup pour trouver une bonne dynamique…
[^] # Re: Pseudo drama juridique
Posté par barmic . Évalué à 4.
Ce qui est dis dans la dépêche c'est que le problème c'est l'inverse. Passer du code GPLv3 à du code GPLv2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 3.
Bon, j'abandonne je crois…
Une dernière tentative.
ioquake sert de moteur de référence pour de nombreux projets, il est sous GPLv2+ (puisque c'était la licence en vigueur l’époque de la libérations du code).
Avec la sortie de RCTW et ET (sous GPLv3+) certains veulent mettre les quelques nouvelles fonctionnalités directement dans ioquake (en faire encore un meilleur moteur au passage) ce qui implique de passer le code sous GPLv3+.
Les devs ne VEULENT pas (mais le pourraient).
Du coup pour lancer le projet il faut faire un énième fork dans son coin etc…
avec les problèmes et le FUD que j'ai déjà évoqués.
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 0.
Qu'est-ce qui te fait dire qu'ils peuvent?
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 2.
La licence ?
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 1.
C'est-à-dire? Tu peux expliciter ton raisonnement?
Parce que là, j'ai plutôt l'impression que tu démontres que "la GPL c'est de la merde trop compliquée" à comprendre.
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 3.
ioquake3 est sous GPLv2+.
donc:
Où est l'imbroglio, le texte est on ne peut plus clair ?
ioquake3 pourrait très bien être GPLv3+ (légalement parlant).
Sinon il y a aussi le wikipedia de la licence.
La FAQ de la licence doit aussi discuter ce point.
(ou à la toute fin)
https://www.gnu.org/licenses/rms-why-gplv3.html
ou
https://www.gnu.org/licenses/rms-why-gplv3.fr.html
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
Bien sûr que ioquake peut légalement passer en GPLv3! (du moins en théorie, en pratique je ne sais pas comment ça se passe. Qui décide? Les contributeurs doivent-ils donner leur accord pour le changement de licence? etc.)
Mais le problème principal n'est pas là: tu n'as jamais réalisé que passer le "moteur de référence" en GPLv3 veut dire forcer tous les projets qui piquent dans le code à passer en GPLv3? Parce que Ioquake en GPLv3, ça n'arrange que marginalement les forks de WolfET, mais ce serait un vrai problème pour tout le reste de l'écosystème ioquake. Et c'est justement parce que le code IoQuake est la référence que garder la GPLv2+ est la décision la plus saine possible.
Se pose également le soucis de s'assurer que tous les patchs inclus ne posent pas de problèmes légaux (patchs GPLv2 only?).
[^] # Re: Pseudo drama juridique
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 17 novembre 2014 à 17:40.
celui qui redistribue décide
bin, ils l'ont déjà donnée en proposant leur code en GPL-2+ (relis les passages des licence cités par bubule<)
Rien de trop compliqué…
En revanche, tu as mis le doigt sur ce qui a coincé :
les dévs' pouvaient passer en GPL-3+ (déjà accordé par la GPL-2+), mais ils ne le voulaient pas pour diverses raisons n'étant pas liées à la licence en tant que tel.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Ils ne veulent peut-être tout simplement pas imposer un changement de licence à ceux qui développent des branches dérivées, quand bien même ces branches dérivées ne reverseraient pas leur code dans la branche master ?
Je ne sais pas si c’est la raison, mais elle est tout à fait recevable.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par BAud (site web personnel) . Évalué à 3.
En quoi cela imposerait un changement de licence ? Seuls les codes sources bénéficiant de patchs venant de GPL-3+ doivent voir leur entête modifié. La GPL-2+ étant compatible avec la GPL-3+, les codes sources en GPL-2+ non modifiés peuvent rester en GPL-2+, le binaire résultant sera néanmoins en GPL-3+.
Bon, si les patchs sont dans un petit peu tous les fichiers sources, il ne restera peut-être plus grand chose en GPL-2+ effectivement…
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3. Dernière modification le 17 novembre 2014 à 18:03.
Oui, je voulais dire: "En pratique, qui chez ioquake décide?" Je ne sais pas comment est organisé ce projet: à la Debian, avec une majorité nécessaire des contributeurs principaux? Ou ont-ils un BDFL avec tout pouvoir?
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Ben, dès le premier commit en GPLv3, cela teinte tout le projet.
C’est le vrai problème, du jour au lendemain quelqu’un qui synchronise son code sur celui d’ioquake3 voit la licence de son propre code changer lors d’un simple pull. On râle souvent à propos des services qui contraignent à accepter leurs nouvelles CGU et que tant qu’on ne signe pas ces CGU, ils font de la rétention de donnée et on perd le service, mais c’est exactement le même problème.
Si ioquake3 importe un seul commit sous GPLv3, je suis dès lors contraint d’accepter la GPLv3 pour mon propre projet au prochain pull. Si pour une raison ou une autre la GPLv3 ne me plaît pas, ma branche est coupée du tronc et menace de mourir.
Je comprends tout à fait que les gens d’ioquake ne veulent pas imposer cette problématique à tous ceux qui utilisent leur code.
Si on importe un seul patch GPLv2 only dans ioquake3, l’ensemble d’ioquake3 comprenant entre autre ce patch devient définitivement GPLv2 only. Un fork GPLv2 only peut pull le master de ioquake3 qui est GPLv2+, mais si un fork GPLv2 only propose un pull request à ioquake3, il devra relicencier en GPLv2+ avant, enfin, j’espère que les gars d’ioquake3 auront la présence d’esprit de ne pas teinter leur code en GPLv2 only…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 4.
Si et je ne vois toujours pas le soucis.
Mais de nouveau je pense que c'est se tromper de cible et voir la GPL comme un problème (cf post sur la position de ID et Zenimax sur leur code).
La GPLv3+ c'est kifkif bourricot la GPLv2+ mieux rédigée, moins de bugs et plus de protections pour l'utilisateur futur.
De plus elle est compatible avec la GPLv2+.
Le seul cas pouvant poser problème est un link du moteur avec une biblio GPLv2 only mais je n'ai pas echo de cas concret (et il y a peu de chances que ce soit un vrai problème difficile à surmonter, par rapport à laisser le code GPLv2+).
Il n'y a plus d'echosystème "ioquake". C'est mort et enterré. Il reste ioquake et c'est tout. Les forks actifs de ioquake sont surtout par les devs eux même.
Tous les autres projets dérivés étaient soit déjà morts lors de la release de RTCW/ET ou alors en conflit ouvert entre les différents groupes de devs et incompatibles (au niveau du code pas des licences).
Mais là aussi rien n'empêche le passage vers la GPLv3+ ou pas et rien ne dit que les autres développeurs sont hostiles à cette transition.
Et il n'y a aucun intérêt à se baser sur ce moteur actuellement pour lancer un nouveau projet.
Puisqu'il y manque un bon lot d'améliorations (surtout sur les mods) qui sont présents dans RTCW, les trucs pratiques que les joueurs veulent.
Les maj de sécu ne sont pas leur priorité (aux joueurs), suffit de voir le nombre de gens utilisant des clients russes douteux.
Du coup il faut repartir de ET ou RTCW et (re)patcher les bugs.
Travail long, fastidieux et surtout déjà fait ailleurs, donc frustrant.
Ce sont des années de temps perdu (entre le manque de main d’œuvre, les blocages administratifs et le temps de refaire les MAJ).
Donc je suis heureux du travail fait sur ET:L mais quelle douleur pour arriver là.
Ma avis serait, c'est justement parce que le code se voulait servir de référence qu'il est bon d'y mettre le meilleur code possible pour les joueurs, les administrateurs etc… à savoir OSP (présent dans RTCW) et garantir qu'il reste communautaire (donc GPLv3+ est bienvenu).
Pour conclure, le problème principal est l'ignorance des joueurs sur les licences (cf ce journal) et la formation de petits clans où toutes les excuses sont bonnes pour que le code ne circule pas, chacun cherchant son lot de gloire avec son patch auprès des fidèles. La plupart de ces raisons sont au mieux malhonnêtes et très ego-centrés, le reste du mensonge ou de la désinformation (à mon avis).
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 3.
Il y en a peut-être peu, mais on peut compter Unvanquished et OpenJK, par exemple. Ca fait toujours plus que zéro.
C'est certainement vrai, il y a d'autres possibilités plus modernes (IdTech 4 pour ne citer que celui là).
Tout à fait, mais ça ne concerne pas le moteur, c'est entièrement codé dans la partie mod au dessus.
D'ailleurs, ce qu'il faudrait c'est un framework/code prémaché qui permettent d'inclure ce code commun dans tous les mods, mais c'est complètement orthogonal à la problématique du moteur. Une bonne âme généreuse pour nous pondre ça?
Ca tombe bien, le travail est globalement fait comme tu dis et il semblerait que tu n'ai pas souffert le moins du monde :)
Honnêtement, on sent bien ta déception vis à vis de l'équipe ioQuake. Je ne connais pas l'équipe de ce projet, donc je ne vais pas dire qu'il n'y a pas de problème qui relève de l'humain et pas de la technique. D'ailleurs c'est plutôt la norme dans le logiciel libre ça.
Aujourd'hui, le code d'ET:L dispose d'un code moteur qui est globalement bon, d'un nouveau moteur de rendu qui repose en partie sur l'effort de projets qui aujourd'hui ne sont plus (XReal, OpenWolf) et d'autres qui sont toujours très actif (unvanquished). Ne serait-ce pas l'opportunité de dépasser ioquake en pondant du meilleur code (et sous GPLv3)?
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Très pertinent, d’ailleurs je crois que je vais cesser de nourrir le troll licence, cette problématique que tu soulèves est bien plus intéressante.
Une des principales raisons de toute cette dispersion vient je pense du fait que le moteur est conçu pour être forké. C’est comme cela qu’il était vendu, d’où le fait que les Jedi Knight, RTCW et Wolf:ET sont des forks, premièrement, et qu’il n’y a pas eu vraiment de remontée de code pour intégrer une branche supérieure.
Mais pourquoi est-ce toujours vrai une fois que le moteur est libéré ?
Le wiki d’ioquake3 pose la question Mod ou Standalone ?
Une des premières raisons est :
Et c’est la principale raison parce que cela fait référence à une contrainte, pas une possibilité. Le reste des arguments évoqués sont des possibilités (modifier le code du moteur est une possibilité du fork par exemple).
Pourquoi ne peut-on pas lancer avec le moteur ioquake3 un mod complet ne reposant sur aucune donnée de Quake3 sans posséder les données de Quake3? Pourquoi ne peut-on pas lancer avec le moteur openarena un mod complet ne reposant sur aucune donnée tierce sans installer les données d’OpenArena?
Pourquoi le chemin du "game" doit être compilé et doit être vérifié avant de lancer un "mod", quand bien même ce "mod" est un jeu complet?
Je rappelle l’organisation :
Ce qui fait que “baseq3” est un “game” et “q3urt4” et “q3rally” sont des “mods” n’est là que parce que c’est la chaîne “baseq3” qui est compilé pour le “game”.
Pourquoi ne peut-on pas lancer “q3urt3” si “baseq3” n’est pas installé ? C’était compréhensible lorsque Quake 3 était commercialement viable, mais ioQuake3 n’a pas à s’encombrer de cela. D’autres moteurs le permettent, par exemple, j’ai pu installer le mod « Goldeneye Source » avec le moteur « Source » sans avoir à acheter « Half-Life ».
Il est tout à fait possible de jouer à OpenArena avec le moteur de Quake 3, il suffit de mettre les données d’OpenArena dans le dossier de Quake 3 :
/usr/share/games/quake3/baseoa/
, à condition que les données de Quake 3 soient installées :/usr/share/games/quake3/baseq3/
.Il est tout à fait possible de jouer à Quake 3 avec le moteur d’OpenArena, il suffit de mettre les données de Quake 3 dans le dossier d’OpenArena :
/usr/share/games/openarena/baseq3/
, à condition que les données d’OpenArena soient installées :/usr/share/games/openarena/baseoa/
.Pourquoi cette contrainte ? Pourquoi contraindre à recompiler le moteur pour distribuer un standalone, pourquoi ne pas pouvoir distribuer le moteur compilé par Icculus, non modifié, avec seulement des données nouvelles ?
Le projet ioquake3 pouvait très bien distribuer un “game” simpliste, qui ne soit qu’un menu vers les jeux installés pour gérer le cas ou le moteur serait lancé sans paramètre, et tout jeu standalone distribuerait un lanceur qui ferait
ioquake3 +set fs_game gamename
, même sibaseq3
est absent.ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
J'ai jeté un oeil au code de ioquake, et je ne vois pas vraiment de raisons techniques que le fait de s'assurer que l'utilisateur dispose des données d'origine avant de se connecter. Peut être pour limiter la quantité en download, les données représentant une quantité de Mo pas négligeable s'il faut les télécharger à la volée (surtout il y a 10-15 ans).
Par contre, il est possible de compiler ioquake avec le paramètre "STANDALONE" qui enlève cette limitation pour les mods qui ne réutilisent aucunes données, c'est juste pas fait par défaut donc ça semble plus être un souci de packaging ici.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 18 novembre 2014 à 16:40.
Ah bien ! Donc en fait il ne reste qu’à convaincre les uns et les autres, il est tout de même dommage de se farcir plusieurs ioquake pour chaque jeu…
C’est un ajout d’ioquake ou c’était comme cela dans le moteur quake 3 de base ?
Il aurait été super (mais ça arrive un peu tard maintenant) de lancer une initiative unifiée pour que chacun des mods qui voulaient devenir standalone puissent reposer sur le même moteur. Par exemple décrire un chemin parent standard (
/usr/share/games/unified/
,~/.local/share/unified/
).Un truc excellent aurait été de livrer un mod minimaliste ne faisant que proposer un menu pour les jeux installés, dans le cas où l’on aurait lancé le moteur seul et non pas un lanceur pour le jeu, et pour pouvoir tester le moteur même sans installer de jeu. La distribution de jeux aurait même pu se faire uniquement en espace utilisateur (comme fait pimi) une fois le moteur installé par la distro.
Le moteur spearmint ambitionne d’avoir ce rôle de moteur générique, parce qu’il est vrai qu’ioquake3 est trop lié à Quake 3 dans la façon dont il est distribué.
Si le moteur ioquake3 est générique, il est distribué uniquement pour être un remplaçant à Quake 3 et pour lancer (et nécessiter)
baseq3
. Alors qu’au contraire, tel qu’il est conçu, une distro pourrait distribuerspearmint
le moteur quel que soit le jeu, etmint-arena
pour les joueurs de Quake 3.Après, je ne sais pas si le moteur spearmint est bien connu par les uns et les autres (je pense par exemple au projet Smokin’ Guns qui voit sa 1.2 plutôt incertaine).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
Ca semble être rajouté par ioquake. Sinon, le projet lui même ne distribue pas de binaire "standalone", mais ça peut aussi se faire au niveau des distributions pour la version Linux. C'est peut être même très logique de découper ioquake par défaut pour éviter les redondances avec d'autre jeux basés sur ioquake.
Un moteur commun, oui très bonne idée, mais faut que chaque projet y mette la volonté.
Spearmint je connaissais, mais je n'ai aucune idée de sa popularité dans le milieu.
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 1.
Unvanquished à divergé de ioq3 depuis un bon moment (genre 10 ans ?).
Et voilà une autre source de soucis sociaux.
Cette idée que le mod est séparé… du reste (du monde).
Le mod se link avec le moteur et le code du mod est aussi en GPLv2+ ou 3+ pour RTCW/ET. Du coup là aussi ça ne fait pas de sens de ne pas voir les mods comme de simples plugins du moteur (concrètement ce sont des .so chargés dynamiquement).
Je n'ai jamais dis l'inverse et c'est ce qu'il se passe effectivement.
[^] # Re: Pseudo drama juridique
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Oui, mais cela ne vient-il pas du fait qu’ioquake3 a toujours été distribué comme un remplaçant du moteur de Quake 3 pour faire tourner Quake 3 et nécessiter Quake 3, quand bien même le moteur pouvait être distribué comme un moteur générique et agnostique ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 2.
Le point que j'essayais de souligner est que ça ne sert pas à grand chose d'avoir du code de type OSP dans le moteur. Tu as plus l'air d'en vouloir à ioquake parce qu'ils n'ont pas fait évolué la partie mod dans ce sense, mais ce n'était pas forcément leur objectif.
Implicitement, je voulais faire passer l'idée que tes contributions à ET:Legacy seraient bienvenues :), puisque tu avais l'air motivé à travailler sur le code de WolfET (à moins que tu pensais plutôt à WolfSP).
[^] # Re: Pseudo drama juridique
Posté par bubule . Évalué à 2.
En fait je n'ai pas était assez clair.
Il n'a jamais était question de faire passer le code GPLv3+ en code GPLv2+ ce serait absurde.
Mais de faire fonctionner le code GPLv2+ avec le nouveau GPLv3+.
Ceci est possible sans soucis.
Sauf que linker du GPLv3+ avec du GPLv2+ rend de facto le projet GPLv3+ ce que les devs refusent.
[^] # Re: Pseudo drama juridique
Posté par Spyhawk . Évalué à 4. Dernière modification le 17 novembre 2014 à 11:32.
C'est vrai, et c'est justement ce qui se passe, mais c'est pas le sujet de la dépêche, qui parle de l'autre direction.
Oui, et ça c'est également vrai: on est tout seul (3-4 dev réguliers à temps partiel) et il y a eu une floppée de tentatives qui n'ont pas survécues dans le temps, les améliorations ne sont pas backportées dans ioquake, les gens de ioquake qui connaissent bien le code restent loin du projet, cette histoire de licence est un casse tête avec les éventuels patchs GPLv2. Mais c'est pas impossible de trouver une bonne dynamique, la preuve, même si l'équipe du projet est relativement petite, ET:Legacy le fait!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.