De l'instabilité de F4AF avec les skins addons
Publié : lun. nov. 07, 2005 2:01 pm
Je poste ce sujet ici afin de ne pas irriter les gens volant sur AF.
On recemment lu ici beaucoup de choses discordantes sur la possibilité de faire des addons de textures.
Mon but ici n'est pas de descendre F4AF ou ses développeur, mais d'essayer d'apporter une explication aux déclarations faites sur l'instabilité de AF face aux skins addons et la cause probable de cette instabilité.
Etant donné mon travail sur les modèles 3D de falcon, je pense commencer à comprendre le fonctionnement de falcon sur ce plan.
Voici mon analyse en 3 étape
1) Pour commencer, il faut revenir loin en arrière dans l'histoire de Falcon. à un âge révolu où les textures n'était pas en DDS.
A cette époque, n'était pas gêrée en tant que fichiers indépendants, mais était regroupés dans une base de données.
pour ajouter ou modifier des textures, il fallait les intégrer dans la base de données. une erreur à l'encodage, et le plantage était assuré. Une erreur dans la palette de couleurs, et le plantage était assuré.
2) Cette époque a ensuite été balayée avec l'apparition d'executable gérant les textures DDS. A partir de ce moment, les textures était toujours déclarées dans une base de données, mais les textures utilisées par le jeux, elles, se trouvaient sous forme de fichiers indépendants en DDS. La conséquence de ceci fut que l'édition des textures s'est trouvée grandement facilitée, car pour modifier une texture, il suffisait de remplacer le fichier DDS par un autre, même de taille différente. Car la texture utilisée dans la base de donnée restant la même, la base de donnée reste intacte et ne fais pas planter le jeu.
Seul l'ajout d'une nouvelle texture nécessitait alors la modification de la base de données pour déclarer la nouvelle entrée. Il y avait donc à moment là un risque de corruption de la base, mais uniquement si la manipulation n'était pas bien faite, ou si le format de texture n'était pas bon. Or la plupart des patchs n'ajoute pas de textures ou, si ils le font (par exemple mon cockpit 3D), l'installateur fait le boulot proprement).
A partir de ce moment là, il est devenu presque impossible de faire planter le jeu avec des textures (ce qui rejoint l'argumentaire de Scrat, Wild Angel, ou Famas sur le forum AF).
3) Revenons maitenant dans le présent et plus particulièrement à AF.
En effet, même si AF utilise un nouvel exe, cet exe se base forcément sur une version précédente de l'exe de falcon. Or, cette version qui a servi de base semble (malheureusement?) être antérieure à l'apparition des DDS.
Il en résulte que le système de gestion des textures nous ramène aux problèmes de la structure évoquée en (1), et les risques d'instabilité qui en découlent.
Donc, OUI, il y a bien un risque d'instabilité lié à la modification des textures sous AF.
Il reste donc plusieurs possibilités d'évolution à cette situation :
- Que LP intègre des textures issues de la communauté dans ses futurs patchs. Pas en tant que textures de remplacement obligatoires mais en tant que skins alternatives (accessibles via l'écran des munitions)
- Que LP fournisse un SDK intégrant des outils permettant d'intégré des textures sans risque de corruption de la base de données.
Voila, c'est tout
Cette analyse s'appuie en partie en partie sur des faits, et pour le reste sur de fortes suppositions. je ne considère pas avoir la science infuse vous propose donc cette petite réflexion sans prétention aucune.
Toutefois, si je peux vous donner un conseil :si vous souhaitez modifier des skins, pensez à faire une sauvegarde de votre rep falcon AF avant
.
On recemment lu ici beaucoup de choses discordantes sur la possibilité de faire des addons de textures.
Mon but ici n'est pas de descendre F4AF ou ses développeur, mais d'essayer d'apporter une explication aux déclarations faites sur l'instabilité de AF face aux skins addons et la cause probable de cette instabilité.
Etant donné mon travail sur les modèles 3D de falcon, je pense commencer à comprendre le fonctionnement de falcon sur ce plan.
Voici mon analyse en 3 étape
1) Pour commencer, il faut revenir loin en arrière dans l'histoire de Falcon. à un âge révolu où les textures n'était pas en DDS.
A cette époque, n'était pas gêrée en tant que fichiers indépendants, mais était regroupés dans une base de données.
pour ajouter ou modifier des textures, il fallait les intégrer dans la base de données. une erreur à l'encodage, et le plantage était assuré. Une erreur dans la palette de couleurs, et le plantage était assuré.
2) Cette époque a ensuite été balayée avec l'apparition d'executable gérant les textures DDS. A partir de ce moment, les textures était toujours déclarées dans une base de données, mais les textures utilisées par le jeux, elles, se trouvaient sous forme de fichiers indépendants en DDS. La conséquence de ceci fut que l'édition des textures s'est trouvée grandement facilitée, car pour modifier une texture, il suffisait de remplacer le fichier DDS par un autre, même de taille différente. Car la texture utilisée dans la base de donnée restant la même, la base de donnée reste intacte et ne fais pas planter le jeu.
Seul l'ajout d'une nouvelle texture nécessitait alors la modification de la base de données pour déclarer la nouvelle entrée. Il y avait donc à moment là un risque de corruption de la base, mais uniquement si la manipulation n'était pas bien faite, ou si le format de texture n'était pas bon. Or la plupart des patchs n'ajoute pas de textures ou, si ils le font (par exemple mon cockpit 3D), l'installateur fait le boulot proprement).
A partir de ce moment là, il est devenu presque impossible de faire planter le jeu avec des textures (ce qui rejoint l'argumentaire de Scrat, Wild Angel, ou Famas sur le forum AF).
3) Revenons maitenant dans le présent et plus particulièrement à AF.
En effet, même si AF utilise un nouvel exe, cet exe se base forcément sur une version précédente de l'exe de falcon. Or, cette version qui a servi de base semble (malheureusement?) être antérieure à l'apparition des DDS.
Il en résulte que le système de gestion des textures nous ramène aux problèmes de la structure évoquée en (1), et les risques d'instabilité qui en découlent.
Donc, OUI, il y a bien un risque d'instabilité lié à la modification des textures sous AF.
Il reste donc plusieurs possibilités d'évolution à cette situation :
- Que LP intègre des textures issues de la communauté dans ses futurs patchs. Pas en tant que textures de remplacement obligatoires mais en tant que skins alternatives (accessibles via l'écran des munitions)
- Que LP fournisse un SDK intégrant des outils permettant d'intégré des textures sans risque de corruption de la base de données.
Voila, c'est tout
Cette analyse s'appuie en partie en partie sur des faits, et pour le reste sur de fortes suppositions. je ne considère pas avoir la science infuse vous propose donc cette petite réflexion sans prétention aucune.
Toutefois, si je peux vous donner un conseil :si vous souhaitez modifier des skins, pensez à faire une sauvegarde de votre rep falcon AF avant
![Wink ;)](./images/smilies/wink.gif)