CheckSix Forums

Bonjour,

Je fais un post pour parler plus particulièrement des MFD, comme apparemment c'est un sujet qui pose problème.

Je n'ai à peu près aucune idée de comment FLX a codé le système donc je ne fais qu'émettre des idées et des propositions, je me doute bien que selon les cas ce ne sera pas forcément réalisable.
D'après ce que j'ai lu, il serait possible de mettre des instruments personnalisés, mais il faudrait utiliser des MFD génériques, au moins dans un premier temps. Je suppose donc qu'on peu juste cnfigurer une partie du modèle pour correspondre à des critères pour une utilisation par la classe correspondant à l'instrument, et que le problème des MFD tient au fait qu'il faudrait toucher directement au code de la classe pour en modifier le comportement.

Mon idée serait donc d' "externaliser" les classes, comme ce qui se fait sur Operation Flashpoint ou Armed Assault : on a un fichier de configuration en cpp qui est interprété par le moteur pour ajouter des classes correspondant aux véhicules, aux anims, et également au HUD ou au MFD. Je me demandais donc s'il était possible de mettre en place un tel système dans Digital Fighters. Une classe de MFD de base dont on ferait hériter les MFD tierce partie, qui seraient alors ajustables pour coller au mieux à la réalité, sans pour autant avoir besoin de toucher au code du programme. Il en serait de même pour les HUD.

Ça vous paraîtrait faisable ?

Salut Chris...

tout d'abord si je me trompe pas tu travailles sur le projet ofrp ? un excellent mod au demeurant...

nous sommes justement entrain de discuter avec Flx des possibilités.... et en effet nous pensons à l'externalisation... non pas seulement des mfds... mais de toute l'avionique....

est ce que tu pourrais nous donner des exemples de ces classes sous arma ou ofp ? car a l'heure actuelle nous n'avons pas encore toutes les cartes en mains pour nous décider sur quel système adopté... donc si tu nous donnes des infos nous sommes preneur...

mais en effet c'est bien le but .... arriver à avoir une avionique externalisée au maximum... comme ca on pourra créer a peu pres tout ce que l'on veut...


je laisserai FLX en parler car c'est lui le codeur

Salut Heero,

Oui je suis bien de l'équipe d'OFrP, content que tu apprécies notre travail.

Pour vous donner une idée de comment ça marche sous ArmA, voici un petit lien vers le Wiki qui contient toutes les ingos concernant l'édition sur ArmA, page concernant les HUDs (pas de MFD dans le jeu de base) :

http://community.bistudio.com/wiki/HUD

Vous pouvez aller voir ce qui concerne les anims et le cfgVehicle, tout ce qui permet de gérer les propriétés d'un véhicule et ses parties animées est contenu là-dedans.

Bien sûr si le fonctionnement vous semble un peu obscur hésitez pas à me demander des précisions.

merci pour la réponse rapide

Comme la dit Heero, pour l'instant nous sommes encore dans une étude de faisabilité.

Voici déjà une première analyse :
- Les modèles 3D des cockpits contiennent 3 types d'instrument
1 - les cadrants classiques (anenometre, VOR, conservateur de cap, .... par exemple) dans ce cas, on gère ces cadrants avec les animations du modèle 3D et une monenclature des noms des éléments pour que le simulateur place l'élément dans l'animation en fonction de la valeur à afficher. Tous cela sera géré pas une liste d'élément pré-calculé par le simulateur.
2 - MFD dit générique (à définir) dans ce cas le modèle 3D utilise une texture dont le nom est pré-definie et cette texture est mise à jour par le simulateur en temps réel.
3 - les cadrants / MFD système, dans ce cas la diversité est si grande que nous regardons pour créer un langage script (comme par exemple LUA) qui permet de définir le comportement du système et les affichages à réaliser (toujours sur le même principe, le modèle 3D comporte des textures qui seront remis à jour en temps réel par le script).
- Les modèles 3D des cockpit contiennent 2 type de commandes
1 - les commandes classiques (comme le train d'atterrissage, ...) sont gérées en fonction d'une monenclature (ceci permet d'associer une commande à une action, et comme le principe des animations est conservé, la commande prendra la position souhaitée (on gére ainsi les interrupteurs, les boutons, ....)
2 - les commandes non classiques et les écrans tactiles, ben c'est le script qui va prendre les entrées et qui associera la commande à des états du système....


C'est notre première analyse, biensûr pour la première version de DF qui devrait sortir courant février, rien ne sera codé .... il nous faut un peu de temps...

Ok, merci pour la réponse. Ça me paraît pas mal comme système.