La Couronne de Cuivre

En vérifiant mes conversions d'animations de Diablo, je suis tombé sur un os.

Ces animations fonctionnent parfaitement dans le jeu. En revanche, quand je les visionne avec BamWorkshop 2 (que je n'ai pas utilisé pour les produire car trop bogué !), voici ce que ça donne :
Comme vous pouvez le constater, tout ce passe bien dans DLTCEP et BamWorkshop 1, mais dans BamWorkshop 2, c'est la GROSSSE KATA !

Encore une fois, ce n'est pas très génant d'un point de vue fonctionnel puisque les animations fonctionnent "in-game". Mais ça fait franchement désordre, d'autant plus que le phénomène se produit aussi avec NI.
Et j'ai horreur de ne pas comprendre.

J'ai eu beau chercher dans les rapports de bugs (nombreux ! ) de BamWorkshop 2, je n'ai rien trouvé expliquant cet affichage.

Je précise à toutes fins utiles que tous mes fichiers .bam ont été créés de manière identique et que ce phénomène n'est apparu que sur une demi-douzaine d'entre eux (sur plus de 1 000...).


Quelqu'un a-t-il été confronté à ce genre de dysfonctionnement ou a-t-il une explication ?

Merci d'avance...

Oui, j'ai connu ce type de problème. Il arrive parfois quand on commence à jongler entre Bamworkshop I, II et DLTCEP.
La solution que j'ai trouvée consiste à faire une petite manip dans DLTCEP :
- dans TOOLS, tu choisis "Uncompress all"
- tu enregistres ton anim

Lorsque tu la charges dans Bamworkshop II, elle s'affiche correctement.
Cette manip permet de remettre l'anim "à plat", en tout cas vraisemblablement de la réorganiser. J'ai rencontré d'autres problèmes d'affichages des images (effectivement aussi dans Bamworkshop 2...) pour lesquels elle a été salutaire.

Quant à expliquer le pourquoi de ce bug...je crois que le format .BAM n'est pas très facile à manipuler par les programmeurs. En tout cas, les problèmes que l'on rencontre dans Bamworkshop I et II, et même dans DLTCEP (comment par exemple il s'emmêle les pinceaux dans les index dès que l'on commence à supprimer des séquences), montrent qu'il n'est pas encore parfaitement maîtrisé. Et qu'il faut donc toujours travailler en faisant des copies de sauvegardes.

Pourquoi mon petit doigt m'a-t-il soufflé que tu allais être sur le coup ?

Oui, j'ai connu ce type de problème. Il arrive parfois quand on commence à jongler entre Bamworkshop I, II et DLTCEP.

C'est la raison pour laquelle j'évite Bamworkshop 2 comme la peste !
En revanche, le passage entre le 1 et DLTCEP semble "plutôt" safe.


J'ai effectivement utilisé la même technique de décompression du fichier .bam pour régler le problème : ça fonctionne dans 99 % des cas.
Malheureusement, ça a échoué pour le fichier .bam SD de la Licorne (251 x 9 frames !). Mais comme j'avais prévu de le refaire plus tard, ça me donnera une raison supplémentaire de m'y coller plus tôt que prévu...
Par ailleurs, la décompression pose aussi des problèmes pour les fichiers assez lourds (supérieurs à 1,5 Mo). Mais dans les cas présents, ça roule.

Quant à expliquer le pourquoi de ce bug...je crois que le format .BAM n'est pas très facile à manipuler par les programmeurs. En tout cas, les problèmes que l'on rencontre dans Bamworkshop I et II, et même dans DLTCEP (comment par exemple il s'emmêle les pinceaux dans les index dès que l'on commence à supprimer des séquences), montrent qu'il n'est pas encore parfaitement maîtrisé. Et qu'il faut donc toujours travailler en faisant des copies de sauvegardes.

100 % d'accord à une nuance près : même si l'outil le plus adapté pour supprimer ou déplacer des séquences dans un fichier .bam reste Bamworkshop I, il est possible de le faire avec DLTCEP à condition de respecter certaines règles sous peine de plantage carabiné.
Par exemple, ne jamais insérer une séquence entre deux autres (mais la rajouter après la dernière séquence existante), ne jamais supprimer de séquence comportant la frame "0", etc...

Bref, j'ai listé bon nombre de ces "trucs et astuces" dans le tuto sur la création de bam que je suis en train de rédiger.
Malheureusement, comme tu l'as déjà expérimenté, ce domaine est tellement vaste, et surtout tellement sujet à des cas particuliers, que le tuto s'allonge de jour en jour au fur et à mesure de l'avancée de mes conversions (dont je m'inspire comme exemples pour illustrer le tuto).
Même si je n'aspire pas à couvrir tous les cas de manière exaustive, j'essaie dans la mesure du possible d'évoquer des situations qui se reproduisent régulièrement afin d'éviter des retours du style "Eh, ça ne ne marche pas ton truc !".


Bref, à force d'à force, on finit par se retrouver dans les zones d'ombre inexpliquées et non résolues du modding !
C'est là qu'on aimerait bien que BG:EE serve à quelque chose : dépoussiérer le moteur et livrer quelques infos techniques dignes de ce nom. Eux qui voulaient travailler sur le graphisme, je suis sidéré que les développeurs n'aient pas songé une seconde à régler le problème des fichiers .bam qui sont la principale base d'effets graphiques du jeu, et je ne leur demande même pas de rajouter par exemple un champ ou une variable pour gérer l'alpha blending...

C'est là qu'on aimerait bien que BG:EE serve à quelque chose : dépoussiérer le moteur et livrer quelques infos techniques dignes de ce nom. Eux qui voulaient travailler sur le graphisme, je suis sidéré que les développeurs n'aient pas songé une seconde à régler le problème des fichiers .bam qui sont la principale base d'effets graphiques du jeu, et je ne leur demande même pas de rajouter par exemple un champ ou une variable pour gérer l'alpha blending...

Oui, c'est pour moi son véritable intérêt. L'idéal serait qu'ils puissent employer des programmeurs pour retravailler véritablement le moteur du jeu, et refondre des formats de fichier comme le .bam, avec comme tu le signales, la prise en charge des niveaux de transparence comme le fait la couche alpha, la taille des images etc.
Mais je ne pense pas que ce soit dans leurs objectifs immédiats, car cela se justifierait surtout dans une démarche créative, où l'on ajoute du nouveau contenu au jeu. Avec un peu de chance, on pourrait imaginer que si tout ce passe bien pour eux (bonnes ventes, éditeur qui suit) ils vont "préparer le terrain" avec BGEE & BG2EE en faisant tout le travail de réadaptation du moteur aux configurations actuelles (réseau, différents supports & systèmes), et s'attaquer à l'aspect graphique pour BG3 (les anims des PJ datent vraiment trop par exemple, j'imagine pas qu'on puisse faire un nouveau jeu avec elles)

Bref, j'ai listé bon nombre de ces "trucs et astuces" dans le tuto sur la création de bam que je suis en train de rédiger.

Je suis curieux d'en prendre connaissance : c'est fou le temps qu'on perd parfois sur des bugs ou des fonctionnements que l'on ne comprend pas, au point d'en être parfois démotivé.

Je pense le livrer comme "cadeau de fin d'année" à la Couronne - si tout va bien...

Plusieurs sections sont quasi terminées. Reste les captures d'écrans (plus les fichiers d'exemple) et l'agencement des sections : création d'un fichier .bam de décor (id. splitté), création d'animations IWD, BGI (splittées ou non), BGII, introduction et test d'une animation dans une carte, sans compter le chapitre sur le test et l'implémentation d'une nouvelle animation de créature dans le jeu...

J'espère ne rien avoir oublié. Ah, si, la rubrique "trucs et astuces" !

De quoi ? Les bams divisés entre droite et gauche ne sont que des bugs d'affichage sous Bam Workshop II et ça fonctionne ingame ?
Un jour j'ai resizé un paquet de bam de PST dont j'avais besoin pour le SDG et j'ai obtenu ce résultat là. Bams abandonnées, idée abandonnées, sorts abandonnées (je n'ai pas testé ingame). Et en fait ça s'affiche ingame ?. Bon, j'arrete de radoter, je vous laisse, j'ai du boulot..............

deratiseur a écrit :De quoi ? Les bams divisés entre droite et gauche ne sont que des bugs d'affichage sous Bam Workshop II et ça fonctionne ingame ?
Un jour j'ai resizé un paquet de bam de PST dont j'avais besoin pour le SDG et j'ai obtenu ce résultat là. Bams abandonnées, idée abandonnées, sorts abandonnées (je n'ai pas testé ingame). Et en fait ça s'affiche ingame ?

Il semble que celles créées avec DLTCEP ("Import Many") puis retravaillées avec BamWorkshop I fonctionnent ingame. En tous cas, je n'ai rencontré aucun problème avec mes fichiers .bam de créatures.

En revanche, je n'ai pas essayé après les avoir resizés (cf. autre sujet de discussion).

Tu viens me donner une idée : je vais refaire le test et voir ce que ça donne.

Mauvaise nouvelle.

Je viens de réaliser le test suivant avec des séries de fichiers .bam de créatures :

1. Diminution de 75 % avec Bamresize.
2. Visualisation ingame.
3. Décompression avec DLTCEP.

Résultats :

1. Décalage des images dans les fichiers de sortie.
2. Seul un fichier sur trois fonctionne ingame.
3. La méthode de décompression ne fonctionnne pas. Par ailleurs, au chargement, DLTCEP "réorganise" le fichier .bam resizé. Encore une des subtilités du format bam que les outils de modding semblent avoir du mal à gérer...

Bref, je te conseille de faire des essais et il est possible que dans le tas, quelques fichiers .bam soient utilisables.
Sinon, il te reste la solution empirique, mais éprouvée : utiliser la fonction "Resize" de BamWorkshop 1 qui, elle fonctionne parfaitement. C'est relativement rapide avec un fichier d'une trentaine de frames maximum. Au-delà, ça devient pénible !

Petite astuce : effectue aussi une diminution avec Bamresize qui calcule automatiquement la modification des positions des frames, ce que ne fait pas BamWorkshop. Il te restera ensuite à rentrer ces nouveaux paramètres dans DLTCEP...

Voilà voilou....

deratiseur a écrit :De quoi ? Les bams divisés entre droite et gauche ne sont que des bugs d'affichage sous Bam Workshop II et ça fonctionne ingame ?
Un jour j'ai resizé un paquet de bam de PST dont j'avais besoin pour le SDG et j'ai obtenu ce résultat là. Bams abandonnées, idée abandonnées, sorts abandonnées (je n'ai pas testé ingame). Et en fait ça s'affiche ingame ?. Bon, j'arrete de radoter, je vous laisse, j'ai du boulot..............

Bonne nouvelle !

Je suis en contact avec Sam et Miloch, les mainteneurs de I.A. Sam a eu la gentillesse de passer un peu de temps sur le sujet et semble avoir trouvé l'origine du dysfonctionnement qu'il essaie de recoder dans le script python de Bamresize.

Je vous tiens au courant de la suite des événements.

Oyez, Oyez, braves moddeurs !

Sam vient de publier une mise-à-jour de Bamresize qui règle le problème de corruption de la compression des bams (maintenant lisibles dans Bam Workshop 1 sans manip supplémentaire) et corrige le bug de transfert de la partie droite des frames sur la gauche lors de la diminution.

Téléchargez le ici et amusez-vous bien !


La commande bat pour l'utiliser est "python.exe bamresize.py -p [nn avec toujours 75 par défaut] [fichier].bam".

Merci à toi FreddyGwendo de nous signaler ça. Bon, ben il ne me reste plus qu'à retrouver toutes les bams et les idées de sorts qui vont avec que j'avais écarté à cause de l'ancien bug qui n'existe plus désormais :/

De rien !


C'est la moindre des choses de partager ce genre d'infos. Et mon petit doigt me disait que Luren et toi n'allaient pas manquer le message.


De plus, comme je suis l'un des rares à m'intéresser aux bam sur Spellhold, je participe à la Working Room d'I.A. Comme Sam est plutôt l'informaticien du groupe, il se penche occasionnellement sur certains cas.
C'est comme ça qu'il a corrigé le bug que personne là-bas n'avait remarqué.


Par ailleurs, Miloch vient de m'envoyer un MP me confirmant sa collaboration avec l'équipe de BG2:EE. Je ne pense pas spoiler une partie de son message puisqu'il l'a déjà évoquée dans un forum.
Bref, il travaille actuellement sur la faisabilité d'un nouvel outil de recomposition des fichiers bam (le but du jeu étant notamment d'arriver à convertir toutes les animations de PsT entre autres et de les redimensionner, le tout au format BG).
Sur le principe, il s'agit de convertir les fichiers bam en .txt et de modifier leur structure en utilisant WeiDU. Ainsi, on pourrait aisément créer des fichiers G1, G2, G3 à partir de fichiers d'actions sans trop se casser la tête, de modifier les positionnements des frames, etc...

Bien évidemment, je vous tiens au courant de la suite quand j'aurai plus d'infos.

Par ailleurs, la future version d'Infinity Animations est dans les tuyaux et modifiera pas mal de choses (en fait, les simplifiera).