Je jouerai à Unvanquished le jour où il sera complètement libre et que le développement sera ouvert (c'est à dire qu'on pourra cloner les données et leurs sources sans utiliser une espèce download agent moisi).
Il y a deux problématiques là, la liberté et la manière dont on interagit avec les sources. Il est possible de faire du logiciel libre en ne distribuant que des tarballs de source, de refuser toute contribution et de ne pas révéler l’historique des modifications et son versionnement.
C’est exactement la même distinction qui fait que tu peux avoir du -nc moins libre mais avec un développement plus ouvert que du -sa ou même un simple -by très permissif.
Dans les faits, le problème des sources des données est un problème technique, tout est conçu à l’envers d’un développement à source ouverte, et pire, d’un développement où le concept de « source » à du sens. C’est un problème qui est hérité de la façon dont fonctionnent les outils d’id Software, et ça date de Quake. Pour faire simple, les éditeurs type gtk/netradiant ne savent pas travailler autrement que sur l’arborescence des fichiers finaux, cela implique plein de problèmes, par exemple quand on veut distribuer comme fichier final une texture compressée en DXT quand la source est en PNG, L’éditeur ne sait pas travailler avec autre chose que les données finales et réécrit les fichiers les uns sur les autres.
Idem pour le compilateur q3map2 qui ne sait pas compiler ailleurs que dans ~/.q3a/baseq3 par exemple pour Quake 3, et qui ne sait pas travailler autrement qu’en y cherchant sa source là, en y plaçant les fichiers générés là, et les fichiers temporaires là etc. Rien que pour ça c’est très difficile à versionner et c’est très difficile de ne pas travailler avec des fichiers de données (son, texture) qui ne sont pas dans le format final, ce n’est pas prévu !
Aussi, radiant numérote tous les éléments dans les sources, imagine si ton éditeur de texte numérotait toutes les lignes de ton code C, c’est exactement pareil, ça signifie que si tu ajoutes une ligne après la ligne 312 d’un source qui fait déjà 4518 ligne, le diff indiquera 4206 ligne modifiées parce que 4206 lignes auront été renumérotées. C’est complètement insensé et empêche tout versionnement. Ne parlons même pas d’une compilation out-of-tree, les outils ne connaissent déjà même pas le concept de source.
Bref, il y a un effort particulier qui est en train d’être fait sur sujet, mais 15 ans après la bataille. Je suis en train de patcher q3map2 pour qu’il puisse:
être utilisé sur une arborescence de source,
être utilisé sur une arborescence de source versionnée,
reposer sur d’autres arborescence de sources comme on ferait avec des bibliothèques
produire un build qui ne soit pas une source.
Non mais c’est quoi ça ? c’est censé être un compilateur ! :o
Bref, les sources des assets commencent à être douloureusement versionnées sur git, mais ça demande de modifier tous les outils existant et la manière de travailler avec qui date de plus de 15 ans, presque 20 ans en fait, parce que ces outils ne le permettent pas...
C’est un des points évoqués par mon prochain journal, en plus de ces graves défauts concernant les éditeurs et les compilateurs, il n’y a actuellement aucun outil adapté pour builder une arborescence complète de source (map, lightmap, texture) comme on compilerait Linux avec un simple make, avec un fichier de règle de compilation etc. C’est parce qu’on ne peut pas hiérarchiser les sources ni même simplement les séparer que les rares jeux libres qui versionnent leur données (comme Xonotic) utilisent un dépôt git de plusieurs Go avec tout dedans mélangé.
Si c’est pas fait pour Unvanquished, c’est parce qu’ils ne veulent pas d’une solution « un dépôt git de plusieurs Go avec tout dedans mélangé », et ils ont raison, la seule solution acceptable c’est d’adapter les outils pour qu’ils soient compatibles avec un workflow sérieux (note, tel que les outils sont conçus, on ne peut même pas imaginer un dépot git avec plusieurs submodules, ça ne marcherait pas).
Donc oui, tu pourras probablement cloner les assets d’Unvanquished un jour, mais il faut patcher des tas de logiciels pour cela, et en écrire d’autre.
Mais en ce moment je passe surtout du temps à me perfectionner à OpenArena, sur lequel je suis pas trop mauvais, et Xonotic, sur lequel je suis super nul :D
Je suis toujours un éternel débutant. La dernière fois que je suis allé sur Quake Live juste comme ça pour voir, je me suis fait kicker du serveur par des gamins qui trouvaient que je ne trick-jumpais pas assez, la première fois que j’ai touché à Quake 3 ils n’étaient même pas nés, et leurs parents ne s’étaient peut-être même pas rencontrés. Je ne me suis jamais fait kicker d’un serveur Xonotic par contre. :-) Mon problème avec Open Arena est que c’est vraiment trop moche donc en fait c’est moi qui m’autokick. :D
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C'est peut être moi ...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Comparaison des cartes entre Tremulous et Unvanquished. Évalué à 6. Dernière modification le 24 août 2015 à 21:23.
Il y a deux problématiques là, la liberté et la manière dont on interagit avec les sources. Il est possible de faire du logiciel libre en ne distribuant que des tarballs de source, de refuser toute contribution et de ne pas révéler l’historique des modifications et son versionnement.
C’est exactement la même distinction qui fait que tu peux avoir du -nc moins libre mais avec un développement plus ouvert que du -sa ou même un simple -by très permissif.
Dans les faits, le problème des sources des données est un problème technique, tout est conçu à l’envers d’un développement à source ouverte, et pire, d’un développement où le concept de « source » à du sens. C’est un problème qui est hérité de la façon dont fonctionnent les outils d’id Software, et ça date de Quake. Pour faire simple, les éditeurs type gtk/netradiant ne savent pas travailler autrement que sur l’arborescence des fichiers finaux, cela implique plein de problèmes, par exemple quand on veut distribuer comme fichier final une texture compressée en DXT quand la source est en PNG, L’éditeur ne sait pas travailler avec autre chose que les données finales et réécrit les fichiers les uns sur les autres.
Idem pour le compilateur
q3map2qui ne sait pas compiler ailleurs que dans~/.q3a/baseq3par exemple pour Quake 3, et qui ne sait pas travailler autrement qu’en y cherchant sa source là, en y plaçant les fichiers générés là, et les fichiers temporaires là etc. Rien que pour ça c’est très difficile à versionner et c’est très difficile de ne pas travailler avec des fichiers de données (son, texture) qui ne sont pas dans le format final, ce n’est pas prévu !Aussi, radiant numérote tous les éléments dans les sources, imagine si ton éditeur de texte numérotait toutes les lignes de ton code C, c’est exactement pareil, ça signifie que si tu ajoutes une ligne après la ligne 312 d’un source qui fait déjà 4518 ligne, le diff indiquera 4206 ligne modifiées parce que 4206 lignes auront été renumérotées. C’est complètement insensé et empêche tout versionnement. Ne parlons même pas d’une compilation out-of-tree, les outils ne connaissent déjà même pas le concept de source.
Bref, il y a un effort particulier qui est en train d’être fait sur sujet, mais 15 ans après la bataille. Je suis en train de patcher q3map2 pour qu’il puisse:
Non mais c’est quoi ça ? c’est censé être un compilateur ! :o
Bref, les sources des assets commencent à être douloureusement versionnées sur git, mais ça demande de modifier tous les outils existant et la manière de travailler avec qui date de plus de 15 ans, presque 20 ans en fait, parce que ces outils ne le permettent pas...
C’est un des points évoqués par mon prochain journal, en plus de ces graves défauts concernant les éditeurs et les compilateurs, il n’y a actuellement aucun outil adapté pour builder une arborescence complète de source (map, lightmap, texture) comme on compilerait Linux avec un simple
make, avec un fichier de règle de compilation etc. C’est parce qu’on ne peut pas hiérarchiser les sources ni même simplement les séparer que les rares jeux libres qui versionnent leur données (comme Xonotic) utilisent un dépôt git de plusieurs Go avec tout dedans mélangé.Si c’est pas fait pour Unvanquished, c’est parce qu’ils ne veulent pas d’une solution « un dépôt git de plusieurs Go avec tout dedans mélangé », et ils ont raison, la seule solution acceptable c’est d’adapter les outils pour qu’ils soient compatibles avec un workflow sérieux (note, tel que les outils sont conçus, on ne peut même pas imaginer un dépot git avec plusieurs submodules, ça ne marcherait pas).
Donc oui, tu pourras probablement cloner les assets d’Unvanquished un jour, mais il faut patcher des tas de logiciels pour cela, et en écrire d’autre.
Je suis toujours un éternel débutant. La dernière fois que je suis allé sur Quake Live juste comme ça pour voir, je me suis fait kicker du serveur par des gamins qui trouvaient que je ne trick-jumpais pas assez, la première fois que j’ai touché à Quake 3 ils n’étaient même pas nés, et leurs parents ne s’étaient peut-être même pas rencontrés. Je ne me suis jamais fait kicker d’un serveur Xonotic par contre. :-) Mon problème avec Open Arena est que c’est vraiment trop moche donc en fait c’est moi qui m’autokick. :D
ce commentaire est sous licence cc by 4 et précédentes