Journal de développement 18
Publié : dim. oct. 21, 2007 3:05 pm
Et hop, voilà la traduction 
:
"Bienvenue pour le Journal numéro 18!...
Bon c'est le secret le plus mal gardé de l'histoire de Fighter Ops que nous sommes actuellement en plein dans la phase Alpha du cycle de développement logiciel de Fighter Ops. Comme il l'a été indiqué dans la Zone 51 depuis le précédent journal de développement, nous avons effectivement rencontré quelques embûches sur le chemin, et le résultat c'est que le début de la phase Alpha en a été retardée. La géniale nouvelle, cependant, c'est que notre équipe de développement dévouée et extrêmement talentueuse a pu dégager ces obstacles les uns après les autres. On vous en dira davantage à ce sujet plus loin dans ce journal, mais deux des plus importants était l'intégration de "Speed Tree" et le modèle aérodynamique. Beaucoup d'entre vous doivent connaître Speed Tree ; c'est un code qui offre une manière très élégante de présenter des arbres et des forêts extrêmement réalistes, mais malheureusement personne n'avait jusqu'ici utilisé Speed Tree sur un terrain mondial. Cela a entraîné une série de problèmes quant à la rotation et l'affichage des arbres, mais heureusement ces problèmes ont été récemment résolus, et l'un des plus gros obstacles est à présent bien derrière nous. Le second problème était le modèle aérodynamique: je suis en effet certain que vous pouvez vous imaginer que représenter toutes les subtilés imbriquées de la physique du vol sur un PC domestique n'est pas une tâche facile, surtout si on veut le faire avec le plus grand réalisme. Avec littéralement des centaines de milliers de calculs il y a d'innombrables opportunités que de petites erreurs s'y glissent et créent des résultats inattendus. Il y a eu quelques retards de cette nature pour ce qui est d'amener le code du modèle aérodynamique jusqu'à un stade qui permette de l'intégrer au moteur principal. Je suis cependant très heureux d'annoncer que nous en sommes à présent à ce stade-là.
Une partie qui a été un peu, pardon pour le jeu de mots, "silencieuse", c'est le département son. Nos ingénieurs du son ont progressé sur un certain nombre d'aspects, de la génération réaliste de sons de moteur en passant par les pistes musicales. Le code de génération synthétique du son des moteur du T-38 est à présent terminé et devrait bientôt être incorporé au moteur principal. Plus bas se trouve un lien pour une première démo de ce dont le code est capable. Il s'agit d'un son purement synthétique qui répond aux manoeuvres de la manette des gaz-
http://www.fighterops.com/downloadstmp/t38c.mp3
Le département graphique a avancé à allure régulière dans la production des modèles 3D pour la phase un de Fighter Ops. Beaucoup d'appareils sont en cours tandis que beaucoup d'autres sont terminés. Cela inclut des appareils pilotables tout comme un large assortiment d'appareils de l'IA (militaires et civils). En plus de ces appareils, nous avons travaillé sur divers véhicules terrestres. Nos véhicules terrestres incluent les véhicules IA de soutien qui permettent les opérations sur la base et le vol des appareils. Qui plus est, nous avons une large variété de véhicules IA civils qui peupleront les routes dans le monde de Fighter Ops.
Fighter Ops ne serait évidemment pas complet sans les bases aériennes depuis lesquelles voler. Eh bien ne craignez rien, parce que nos bases ne sont pas seulement en cours de réalisation, mais beaucoup sont achevées et très belles. Ainsi que beaucoup d'entre vous le savent, des membres de notre équipe ont visité la base de Laughlin, et là-bas ont bien sûr pris des photos d'absolument tout ce à quoi ils avaient accès. Le résultat de cette opportunité est un modèle méticuleusement détaillé de Laughlin, auquel sont inclus tous les détails possibles, comme montré récemment sur le forum de la Zone 51. Bien entendu, nous avons également modélisé beaucoup d'autres bases avec un niveau de détail semblable, et beaucoup d'autres vont arriver.
Dans une grande entreprise comme l'est Fighter Ops, réaliser des modèles 3D n'est pas la seule tâche à laquelle doit faire face le département graphique. Pour fournir tout le détail de ce dont nous avons donné des aperçus à la communauté, et bien davantage qui n'a pas encore été vu en dehors de l'équipe, beaucoup de travail doit être effectué dans le domaine de l'optimisation. Autrement, l'ordinateur moyen serait complètement surchargé lors de l'exécution du programme. Là encore, ne craignez rien, parce que nous avons dévolu beaucoup d'efforts à la recherche des derniers trucs et techniques, tout en travaillant en relation étroite avec le département codeurs en sessions de brainstorming, pour développer des solutions qui nous sont propres aux problèmes de performances. Nous avons actuellement des expériences en cours, et plus à faire dans les mois prochains, afin de déterminer les meilleures manières d'approcher les problèmes auxquels faire face dans le développement d'objets graphiques pour un produit logiciel complexe. Ces expériences incluent tout, depuis les différentes manières de gérer les LODs selon les circonstances jusqu'aux divers types de cartes et les autres techniques permettant le plus de détail possible tout en imposant le moins de charge de calcul possible lors de l'exécution. Non seulement c'est important pour offrir davantage de détail graphique, mais également prendre en considération toutes les autres complexités qu'il sera nécessaire de gérer simultanément, entre autres le modèle de vol, la modélisation des systèmes, la modélisation des armes, la modélisation de la météo, etc.
Notre équipe Beta/Recherche a bien sûr continué son très difficile travail. Sachant que chacune des nouvelles sorties s'appuiera sur les sorties précédentes il est vraiment important que nous nous assurions que la structure globale de Fighter Ops est aussi préparée que possible pour des extensions futures.
Cela inclut le fait de rechercher tous les facteurs dont le développement est nécessaire au moteur de l'Intelligence Artificielle pour qu'on puisse planifier les choses au fur et à mesure que de nouvelles capacités, de nouveaux items et éléments sont introduits dans la simu. En faisant ça nous évitons d'avoir à retourner en arrière dans le code de l'IA lorsque nous voudrons ajouter quelque chose dans une sortie future, parce que nous ne l'aurions pas pris en compte en créant le code de l'IA de base. Retourner en arrière dans le code pour quelque chose comme ça n'est en général pas très sage, si vous avez à faire ça trop souvent il en résulte souvent un code spaghetti, très difficile à entretenir et enclin aux bugs.
Notre équipe de recherche a eu pour tâche de rechercher chaque type d'entité civile ou militaire qui pourrait possiblement nécessiter qu'on lui assigne une forme d'IA. Cela a été comme vous pouvez l'imaginer une tâche assez énorme, mais comme pour toutes les tâches précédentes ils ont fait un boulot fantastique.
La recherche porte sur des sous-marins déployant des forces spéciales en canoés et zodiacs, des véhicules d'assaut amphibie déchargeant des unités du génie, des foules de civils, etc, etc. Sachez que lorsque vous observerez l'IA dans n'importe quelle sortie, la base en aura été apportée par notre équipe de recherche, le code IA ne pouvant être qu'aussi bon que les informations qu'ils nous fournissent, et, croyez-moi, ils ont fait un sacré boulot!
Le département des modèles de vol progresse bien et de manière régulière.
A ce stade, nous sommes en train d'intégrer le Modèle Aérodynamique de Test (Airframe Test Model) du T-38C dans un environnement 3D pour tester sur ce modèle la précision des données et de l'aérodynamique. Par l'observation visuelle et celle des données, nous pouvons déterminer si notre approche et notre grand travail ces dernières années ont finalement payé. Ainsi que certains d'entre vous le savent peut-être, notre premier Modèle Aérodynamique de Test avait rencontré certains problèmes que nous avions finalement pu identifier, et auxquels nous avions pu trouver des solutions, la plupart d'entre eux étant des erreurs de calcul dans les équations. Par exemple, nous avions des problèmes de tangage et de roulis engendrés par des valeurs d'inertie calculée trop basses, qui faisait en sorte que l'avion entrait peu à peu en vol non contrôlé. Presque tous, sinon tous, ces problèmes devraient être résolus avec l'actuel Modèle Aérodynamique de Test, qui est en train d'être implémenté dans l'environnement 3D pour test tandis que nous parlons. Le truc important est que cette étape a été atteinte tandis que le modèle aérodynamique est à présent suffisamment stable pour être incorporé au moteur pour test final, et qu'il ne devrait nécessiter que des corrections mineures à présent.
Jusqu'ici, notre Modèle Aérodynamique de Test inclut (modélisés aérodynamiquement) les ailes et les stabilisateurs gauche et droit, la dérive, le fuselage, les contrôles de vol (ailerons et stabilisateurs gauche et droit et palonnier), les aérofreins et le train d'atterrissage (roues gauche et droite et roulette de nez). Tous ces composants nous permettent de tester ce Modèle de cellule dans l'air dans toutes ou presque les conditions de vol (contrôlées ou non contrôlées) et seront testés dans les prochaines semaines.
A ce stade, nous nous focalisons sur 2 aspects importants en ce qui concerne notre Modèle de Test Aérodynamique ; le premier c'est la méthode de calcul complexe (à comprendre) nécessaire pour représenter correctement le comportement aérodynamque d'un appareil dans un environnement 3D virtuel, et le second c'est le test intensif de validation des données aérodynamiques du T-38C.
Selon ces résulats de test et ce que nous trouverons, nous serons en mesure d'implémenter à ce modèle davantage de caractéristiques, comme les réactions de la cellule au sol et les opérations intermédiaires (sol-air/air-sol). En outre nous affinerons intensivement les données aéros pour qu'elles offrent un comportement au Modèle de Vol du T-38C aussi fidèle que possible. Par ailleurs nous serons également en mesure de commencer à affiner et étendre les données d'opération des moteurs, et détailler les données de contrôle des moteurs pour usage dans le cockpit. A ce point, nous disposons seulement d'une base de données simplifiée pour les données moteur, mais déjà nous avons un code de modélisation du moteur capable de calculer tout ce qui est nécessaire dans le cockpit, et possède déjà incorporée une méthode de calcul des performances moteur correcte. Donc notre but premier est d'affiner les données moteur qui seront utilisées pour les calculs de performance des J85-GE-5 installés sur le T-38C.
En ce qui concerne les systèmes et l'avionique installés sur le modèle du T-38C, le codeur avionique et systèmes a terminé presque tous les systèmes non liés à l'avionique (électrique, hydraulique, carburant, pitot, canopée, etc.). La plupart de ces systèmes possèdent déjà une liste étendue de pannes possibles telles que décrites dans l'emergency procedure manual. A ce stade, notre codeur systèmes et avionique a conçu un environnement de test sur lequel il peut "brancher" tous les systèmes et l'avionique conçus, les tester et connecter tous les systèmes entre eux et les faire opérer ensemble. Il a commencé à implémenter le système électrique à l'environnement de test et celui-ci sera testé en premier, plus tard il commencera à lui ajouter davantage de systèmes et terminera tous les systèmes restants qui nécessitent du travail supplémentaire ou terminera les pannes des systèmes manquantes. Une fois cela fait, il commencera à travailler sur les problèmes liés à l'avionique, tels que la radio (VHF, UHF, etc.), l'INS, le GPS, etc. Après que tous ces sytèmes et cette avionique pour le T-38C auront été terminés, il commencera à implémenter d'autres pannes à son design des systèmes et de l'avionique, afin de permettre à l'utilisateur une attention plus réaliste au comportement de l'avion.
Après cette étape de conception du T-38C, la même chose sera effectuée pour le plus simple T-6 Texan II. Une étude préliminaire de cet appareil a déjà été terminée et la plupart des informations requises ont été déjà été rassemblées afin de fournir à l'utilisateur une représentation aussi réaliste que possible de l'appareil. Donc dès que le modèle du T-38C se sera avéré fiable et efficace, le modèle du T-6 sera juste une affaire de quelques mois, afin d'avoir prêts les deux avions d'instruction pour la sortie finale.
En ce qui concerne la modéalisation des armes et dommages, notre designeur/codeur a réalisé des progrès réguliers. Il a déjà réalisé une grande partie du comportement des missiles pour ce qui est du guidage et des explosions, et à présent le comportement aérodynamique de ces missiles (et bombes) en est encore à une première étape, mais montre déjà que nous tâchons au maximum de penser en avance, en travaillant déjà sur des aspects futurs de ce programme (c'est-à-dire le sortie "combat").
Après plusieurs années de travail sur ce projet, l'équipe de modèle de vol s'est transformé en un groupe travailleur et fiable. Même après tout ce temps (presque 2 ans et plus), les mêmes personnes travaillent toujours dans cette équipe, lentement mais s'améliorant et devenant de plus en plus efficaces. La courbe de progression grimpe ce qui signifie que nous sommes capables de fournir la même quantité de travail dans une plus courte période de temps. Et c'est bon signe pour le futur!
Enfin, mais ça n'est en aucun cas le moins important, notre département codage a réalisé quelques avancées fantatiques-
Interface:
L'infrastructure du code pour l'interface (UI, pour User Interface) a été créée. L'UI a été implémentée en utilisant DirectX 9 et supporte divers contrôles communs (boutons, fenêtres d'édition, fenêtres multples, etc.) La visualisation et l'interaction avec les entités du jeu ont été implémentées. La visualisation du terrain est aussi permise sans restriction. Cet ensemble de fonctionnalités centrales sera utilisé comme blocs pour construire l'UI de Fighter Ops.
Nous travaillons actuellement sur la création d'un support pour la présentation d'un matériel d'instruction qui inclut du texte, des images, de la vidéo et du son.
Le joueur doit entrer un login pour jouer. Les logins peuvent être soit locaux soit distants. Les informations de login local sont stockées localement sur la machine sur laquelle Fighter Ops est installé. Les informations de login distant sont stockées à distance sur un serveur privé (un serveur appartenant à une escadrille virtuelle par exemple) et/ou sur le serveur de XSI selon le type de serveur sur lequel vous volez, et de cette manière les progressions et logbooks des joueurs peuvent être stockés en ligne. Une possibilité serait qu'un simple site web d'escadrille puisse être utilisé pour accéder à l'information en ligne et l'afficher, et en conséquence les stats et les logbooks de pilotes virtuels pourraient, par exemple, faire partie du site web d'une escadrille virtuelle de manière transparente. Quand le jouer se loggera, il sera en mesure de choisir un "rôle" spécifique dans la simulation. Dans la première sortie seul le rôle "pilote en instruction" sera disponible, et dans les sorties et améliorations futures d'autres rôles, tels que "pilote de chasse", "pilote d'hélicoptère", "ATC", "contrôleur AWACS" seont disponibles avec chacun leur UI unique.
Tous les réglages du jeu peuvent être modifiés via un login "Administrateur" spécial. La création de profil de joueur, les réglages multijoueurs et les réglages multi-écrans sont quelques-unes des capacités de l'Administrateur. Nous explorerons plus en profondeur ce login spécial dans les prochains journaux de développement.
Support du muti-écrans:
Je sais que ce souci a été abordé dans une courte entrée d'un journal de développement précédent, mais j'aimerais expliquer brièvement ce que cela signifie et comment les utilisateurs en bénéficieront. Le jeu multi-écrans peut être réalisé via l'une ou les deux des configurations suivantes:
a)Une carte graphique avec deux sorties (ou un total de quatre sorties avec un scénario CrossFire ou SLIA)
b)L'utilisation d'écrans d'ordinateurs connecté au système principal en LAN
Dans le premier cas, plus d'un écran peut être lié à l'ordinateur et Fighter Ops peut être configuré pour utiliser les affichages disponibles. Dans ce cas le nombre d'affichages disponibles sera de deux ou quatre.
Dans le second cas, le(s) écran(s) de n'importe quel ordinateur d'un LAN peuvent être configurés pour être utilisés par l'installation de Fighter Ops sur l'ordinateur principal. Par exemple, s'il y trois ordinateurs en plus de l'ordinateur principal disponibles sur le LAN, et que Fighter Ops est installé sur les quatre ordinateurs, le système principal peut utiliser les cartes graphiques et écrans des trois autres systèmes pour afficher des vues supplémentaires.
Dans les deux cas les écrans supplémentaires peuvent être utilisés soit pour étendre une vue existante, soit pour afficher d'autres vues supplémentaires à la vue affichée sur l'écran principal.
Moteur météo:
Nous avons finalisé la conception basique du moteur météo pour Fighter Ops. Cette conception nous permet une distribution arbitraire des divers éléments météos (type de terrain, température, humidité, nuages, précipitations, pression et vent) de par le globe.
La prochaine étape pour le moteur météo est la construction de la dynamique de l'atmosphère par-dessus les fonctionnalités décrites plus haut.
Le moteur météo est conçu de telle manière qu'il peut tourner sur un processeur séparé ou sur un coeur séparé, ou sur un ordinateur appartenant à un LAN. Ainsi, par exemple un ordinateur sur le réseau avec Fighter Ops installé peut être configuré de telle façon que seul le moteur météo tourne dessus. Bien entendu le module du moteur météo sera inactif sur l'ordinateur principal afin d'économiser des cycles CPU. C'est le premier exemple du concept de "partage de charge" qui est l'un de nos objectifs de conception majeurs pour cette simulation.
Avionique:
Une plate-forme virtuelle est actuellement conçue et développée afin de contenir tout le code nécessaire à la simulation de l'avionique des appareils de Fighter Ops. Cette plate-forme virtualise des ensembles d'avionique entiers, des boutons dans le cockpit (entrées, inputs) aux affichages du cockpit (sorties, outputs) et tout ce qui se trouve entre les deux. Cette plate-forme permettra la création et la modification des systèmes de l'avionique sans qu'il soit nécessaire de communiquer directement avec le code de Fighter Ops. En conséquence, le codage de l'avionique sera plus facile pour le développeur et plus sûr pour Fighter Ops. En outre la simulation de la machine virtuelle de l'avionique peut facilement être assignée à un processeur ou à un coeur séparé dans ce schéma. Pour de futures sorties de Fighter Ops nous pouvons envisager l'utilisation des technologies de virtualisation matériel qui ont été introduites par AMD et Intel à cette fin.
Autres Développements:
-La Librairie Speed Tree a été intégrée au moteur graphique. Nous évaluons actuellement l'ensemble et nous déciderons d'inclure ou non Speed Tree dans Fighter Ops.
-Une version opérable du modèle de vol du T-38 a été livrée au département codage. Elle sera intégrée au moteur graphique très bientôt.
-La possibilité d'ajouter du statique aux sons (ceux qui sont liés aux communications) en temps réel a été implémentée. Du statique peut être ajouté aux comms quand sont présents du brouillage ou de mauvaises conditions météos."
__________________
:"Bienvenue pour le Journal numéro 18!...
Bon c'est le secret le plus mal gardé de l'histoire de Fighter Ops que nous sommes actuellement en plein dans la phase Alpha du cycle de développement logiciel de Fighter Ops. Comme il l'a été indiqué dans la Zone 51 depuis le précédent journal de développement, nous avons effectivement rencontré quelques embûches sur le chemin, et le résultat c'est que le début de la phase Alpha en a été retardée. La géniale nouvelle, cependant, c'est que notre équipe de développement dévouée et extrêmement talentueuse a pu dégager ces obstacles les uns après les autres. On vous en dira davantage à ce sujet plus loin dans ce journal, mais deux des plus importants était l'intégration de "Speed Tree" et le modèle aérodynamique. Beaucoup d'entre vous doivent connaître Speed Tree ; c'est un code qui offre une manière très élégante de présenter des arbres et des forêts extrêmement réalistes, mais malheureusement personne n'avait jusqu'ici utilisé Speed Tree sur un terrain mondial. Cela a entraîné une série de problèmes quant à la rotation et l'affichage des arbres, mais heureusement ces problèmes ont été récemment résolus, et l'un des plus gros obstacles est à présent bien derrière nous. Le second problème était le modèle aérodynamique: je suis en effet certain que vous pouvez vous imaginer que représenter toutes les subtilés imbriquées de la physique du vol sur un PC domestique n'est pas une tâche facile, surtout si on veut le faire avec le plus grand réalisme. Avec littéralement des centaines de milliers de calculs il y a d'innombrables opportunités que de petites erreurs s'y glissent et créent des résultats inattendus. Il y a eu quelques retards de cette nature pour ce qui est d'amener le code du modèle aérodynamique jusqu'à un stade qui permette de l'intégrer au moteur principal. Je suis cependant très heureux d'annoncer que nous en sommes à présent à ce stade-là.
Une partie qui a été un peu, pardon pour le jeu de mots, "silencieuse", c'est le département son. Nos ingénieurs du son ont progressé sur un certain nombre d'aspects, de la génération réaliste de sons de moteur en passant par les pistes musicales. Le code de génération synthétique du son des moteur du T-38 est à présent terminé et devrait bientôt être incorporé au moteur principal. Plus bas se trouve un lien pour une première démo de ce dont le code est capable. Il s'agit d'un son purement synthétique qui répond aux manoeuvres de la manette des gaz-
http://www.fighterops.com/downloadstmp/t38c.mp3
Le département graphique a avancé à allure régulière dans la production des modèles 3D pour la phase un de Fighter Ops. Beaucoup d'appareils sont en cours tandis que beaucoup d'autres sont terminés. Cela inclut des appareils pilotables tout comme un large assortiment d'appareils de l'IA (militaires et civils). En plus de ces appareils, nous avons travaillé sur divers véhicules terrestres. Nos véhicules terrestres incluent les véhicules IA de soutien qui permettent les opérations sur la base et le vol des appareils. Qui plus est, nous avons une large variété de véhicules IA civils qui peupleront les routes dans le monde de Fighter Ops.
Fighter Ops ne serait évidemment pas complet sans les bases aériennes depuis lesquelles voler. Eh bien ne craignez rien, parce que nos bases ne sont pas seulement en cours de réalisation, mais beaucoup sont achevées et très belles. Ainsi que beaucoup d'entre vous le savent, des membres de notre équipe ont visité la base de Laughlin, et là-bas ont bien sûr pris des photos d'absolument tout ce à quoi ils avaient accès. Le résultat de cette opportunité est un modèle méticuleusement détaillé de Laughlin, auquel sont inclus tous les détails possibles, comme montré récemment sur le forum de la Zone 51. Bien entendu, nous avons également modélisé beaucoup d'autres bases avec un niveau de détail semblable, et beaucoup d'autres vont arriver.
Dans une grande entreprise comme l'est Fighter Ops, réaliser des modèles 3D n'est pas la seule tâche à laquelle doit faire face le département graphique. Pour fournir tout le détail de ce dont nous avons donné des aperçus à la communauté, et bien davantage qui n'a pas encore été vu en dehors de l'équipe, beaucoup de travail doit être effectué dans le domaine de l'optimisation. Autrement, l'ordinateur moyen serait complètement surchargé lors de l'exécution du programme. Là encore, ne craignez rien, parce que nous avons dévolu beaucoup d'efforts à la recherche des derniers trucs et techniques, tout en travaillant en relation étroite avec le département codeurs en sessions de brainstorming, pour développer des solutions qui nous sont propres aux problèmes de performances. Nous avons actuellement des expériences en cours, et plus à faire dans les mois prochains, afin de déterminer les meilleures manières d'approcher les problèmes auxquels faire face dans le développement d'objets graphiques pour un produit logiciel complexe. Ces expériences incluent tout, depuis les différentes manières de gérer les LODs selon les circonstances jusqu'aux divers types de cartes et les autres techniques permettant le plus de détail possible tout en imposant le moins de charge de calcul possible lors de l'exécution. Non seulement c'est important pour offrir davantage de détail graphique, mais également prendre en considération toutes les autres complexités qu'il sera nécessaire de gérer simultanément, entre autres le modèle de vol, la modélisation des systèmes, la modélisation des armes, la modélisation de la météo, etc.
Notre équipe Beta/Recherche a bien sûr continué son très difficile travail. Sachant que chacune des nouvelles sorties s'appuiera sur les sorties précédentes il est vraiment important que nous nous assurions que la structure globale de Fighter Ops est aussi préparée que possible pour des extensions futures.
Cela inclut le fait de rechercher tous les facteurs dont le développement est nécessaire au moteur de l'Intelligence Artificielle pour qu'on puisse planifier les choses au fur et à mesure que de nouvelles capacités, de nouveaux items et éléments sont introduits dans la simu. En faisant ça nous évitons d'avoir à retourner en arrière dans le code de l'IA lorsque nous voudrons ajouter quelque chose dans une sortie future, parce que nous ne l'aurions pas pris en compte en créant le code de l'IA de base. Retourner en arrière dans le code pour quelque chose comme ça n'est en général pas très sage, si vous avez à faire ça trop souvent il en résulte souvent un code spaghetti, très difficile à entretenir et enclin aux bugs.
Notre équipe de recherche a eu pour tâche de rechercher chaque type d'entité civile ou militaire qui pourrait possiblement nécessiter qu'on lui assigne une forme d'IA. Cela a été comme vous pouvez l'imaginer une tâche assez énorme, mais comme pour toutes les tâches précédentes ils ont fait un boulot fantastique.
La recherche porte sur des sous-marins déployant des forces spéciales en canoés et zodiacs, des véhicules d'assaut amphibie déchargeant des unités du génie, des foules de civils, etc, etc. Sachez que lorsque vous observerez l'IA dans n'importe quelle sortie, la base en aura été apportée par notre équipe de recherche, le code IA ne pouvant être qu'aussi bon que les informations qu'ils nous fournissent, et, croyez-moi, ils ont fait un sacré boulot!
Le département des modèles de vol progresse bien et de manière régulière.
A ce stade, nous sommes en train d'intégrer le Modèle Aérodynamique de Test (Airframe Test Model) du T-38C dans un environnement 3D pour tester sur ce modèle la précision des données et de l'aérodynamique. Par l'observation visuelle et celle des données, nous pouvons déterminer si notre approche et notre grand travail ces dernières années ont finalement payé. Ainsi que certains d'entre vous le savent peut-être, notre premier Modèle Aérodynamique de Test avait rencontré certains problèmes que nous avions finalement pu identifier, et auxquels nous avions pu trouver des solutions, la plupart d'entre eux étant des erreurs de calcul dans les équations. Par exemple, nous avions des problèmes de tangage et de roulis engendrés par des valeurs d'inertie calculée trop basses, qui faisait en sorte que l'avion entrait peu à peu en vol non contrôlé. Presque tous, sinon tous, ces problèmes devraient être résolus avec l'actuel Modèle Aérodynamique de Test, qui est en train d'être implémenté dans l'environnement 3D pour test tandis que nous parlons. Le truc important est que cette étape a été atteinte tandis que le modèle aérodynamique est à présent suffisamment stable pour être incorporé au moteur pour test final, et qu'il ne devrait nécessiter que des corrections mineures à présent.
Jusqu'ici, notre Modèle Aérodynamique de Test inclut (modélisés aérodynamiquement) les ailes et les stabilisateurs gauche et droit, la dérive, le fuselage, les contrôles de vol (ailerons et stabilisateurs gauche et droit et palonnier), les aérofreins et le train d'atterrissage (roues gauche et droite et roulette de nez). Tous ces composants nous permettent de tester ce Modèle de cellule dans l'air dans toutes ou presque les conditions de vol (contrôlées ou non contrôlées) et seront testés dans les prochaines semaines.
A ce stade, nous nous focalisons sur 2 aspects importants en ce qui concerne notre Modèle de Test Aérodynamique ; le premier c'est la méthode de calcul complexe (à comprendre) nécessaire pour représenter correctement le comportement aérodynamque d'un appareil dans un environnement 3D virtuel, et le second c'est le test intensif de validation des données aérodynamiques du T-38C.
Selon ces résulats de test et ce que nous trouverons, nous serons en mesure d'implémenter à ce modèle davantage de caractéristiques, comme les réactions de la cellule au sol et les opérations intermédiaires (sol-air/air-sol). En outre nous affinerons intensivement les données aéros pour qu'elles offrent un comportement au Modèle de Vol du T-38C aussi fidèle que possible. Par ailleurs nous serons également en mesure de commencer à affiner et étendre les données d'opération des moteurs, et détailler les données de contrôle des moteurs pour usage dans le cockpit. A ce point, nous disposons seulement d'une base de données simplifiée pour les données moteur, mais déjà nous avons un code de modélisation du moteur capable de calculer tout ce qui est nécessaire dans le cockpit, et possède déjà incorporée une méthode de calcul des performances moteur correcte. Donc notre but premier est d'affiner les données moteur qui seront utilisées pour les calculs de performance des J85-GE-5 installés sur le T-38C.
En ce qui concerne les systèmes et l'avionique installés sur le modèle du T-38C, le codeur avionique et systèmes a terminé presque tous les systèmes non liés à l'avionique (électrique, hydraulique, carburant, pitot, canopée, etc.). La plupart de ces systèmes possèdent déjà une liste étendue de pannes possibles telles que décrites dans l'emergency procedure manual. A ce stade, notre codeur systèmes et avionique a conçu un environnement de test sur lequel il peut "brancher" tous les systèmes et l'avionique conçus, les tester et connecter tous les systèmes entre eux et les faire opérer ensemble. Il a commencé à implémenter le système électrique à l'environnement de test et celui-ci sera testé en premier, plus tard il commencera à lui ajouter davantage de systèmes et terminera tous les systèmes restants qui nécessitent du travail supplémentaire ou terminera les pannes des systèmes manquantes. Une fois cela fait, il commencera à travailler sur les problèmes liés à l'avionique, tels que la radio (VHF, UHF, etc.), l'INS, le GPS, etc. Après que tous ces sytèmes et cette avionique pour le T-38C auront été terminés, il commencera à implémenter d'autres pannes à son design des systèmes et de l'avionique, afin de permettre à l'utilisateur une attention plus réaliste au comportement de l'avion.
Après cette étape de conception du T-38C, la même chose sera effectuée pour le plus simple T-6 Texan II. Une étude préliminaire de cet appareil a déjà été terminée et la plupart des informations requises ont été déjà été rassemblées afin de fournir à l'utilisateur une représentation aussi réaliste que possible de l'appareil. Donc dès que le modèle du T-38C se sera avéré fiable et efficace, le modèle du T-6 sera juste une affaire de quelques mois, afin d'avoir prêts les deux avions d'instruction pour la sortie finale.
En ce qui concerne la modéalisation des armes et dommages, notre designeur/codeur a réalisé des progrès réguliers. Il a déjà réalisé une grande partie du comportement des missiles pour ce qui est du guidage et des explosions, et à présent le comportement aérodynamique de ces missiles (et bombes) en est encore à une première étape, mais montre déjà que nous tâchons au maximum de penser en avance, en travaillant déjà sur des aspects futurs de ce programme (c'est-à-dire le sortie "combat").
Après plusieurs années de travail sur ce projet, l'équipe de modèle de vol s'est transformé en un groupe travailleur et fiable. Même après tout ce temps (presque 2 ans et plus), les mêmes personnes travaillent toujours dans cette équipe, lentement mais s'améliorant et devenant de plus en plus efficaces. La courbe de progression grimpe ce qui signifie que nous sommes capables de fournir la même quantité de travail dans une plus courte période de temps. Et c'est bon signe pour le futur!
Enfin, mais ça n'est en aucun cas le moins important, notre département codage a réalisé quelques avancées fantatiques-
Interface:
L'infrastructure du code pour l'interface (UI, pour User Interface) a été créée. L'UI a été implémentée en utilisant DirectX 9 et supporte divers contrôles communs (boutons, fenêtres d'édition, fenêtres multples, etc.) La visualisation et l'interaction avec les entités du jeu ont été implémentées. La visualisation du terrain est aussi permise sans restriction. Cet ensemble de fonctionnalités centrales sera utilisé comme blocs pour construire l'UI de Fighter Ops.
Nous travaillons actuellement sur la création d'un support pour la présentation d'un matériel d'instruction qui inclut du texte, des images, de la vidéo et du son.
Le joueur doit entrer un login pour jouer. Les logins peuvent être soit locaux soit distants. Les informations de login local sont stockées localement sur la machine sur laquelle Fighter Ops est installé. Les informations de login distant sont stockées à distance sur un serveur privé (un serveur appartenant à une escadrille virtuelle par exemple) et/ou sur le serveur de XSI selon le type de serveur sur lequel vous volez, et de cette manière les progressions et logbooks des joueurs peuvent être stockés en ligne. Une possibilité serait qu'un simple site web d'escadrille puisse être utilisé pour accéder à l'information en ligne et l'afficher, et en conséquence les stats et les logbooks de pilotes virtuels pourraient, par exemple, faire partie du site web d'une escadrille virtuelle de manière transparente. Quand le jouer se loggera, il sera en mesure de choisir un "rôle" spécifique dans la simulation. Dans la première sortie seul le rôle "pilote en instruction" sera disponible, et dans les sorties et améliorations futures d'autres rôles, tels que "pilote de chasse", "pilote d'hélicoptère", "ATC", "contrôleur AWACS" seont disponibles avec chacun leur UI unique.
Tous les réglages du jeu peuvent être modifiés via un login "Administrateur" spécial. La création de profil de joueur, les réglages multijoueurs et les réglages multi-écrans sont quelques-unes des capacités de l'Administrateur. Nous explorerons plus en profondeur ce login spécial dans les prochains journaux de développement.
Support du muti-écrans:
Je sais que ce souci a été abordé dans une courte entrée d'un journal de développement précédent, mais j'aimerais expliquer brièvement ce que cela signifie et comment les utilisateurs en bénéficieront. Le jeu multi-écrans peut être réalisé via l'une ou les deux des configurations suivantes:
a)Une carte graphique avec deux sorties (ou un total de quatre sorties avec un scénario CrossFire ou SLIA)
b)L'utilisation d'écrans d'ordinateurs connecté au système principal en LAN
Dans le premier cas, plus d'un écran peut être lié à l'ordinateur et Fighter Ops peut être configuré pour utiliser les affichages disponibles. Dans ce cas le nombre d'affichages disponibles sera de deux ou quatre.
Dans le second cas, le(s) écran(s) de n'importe quel ordinateur d'un LAN peuvent être configurés pour être utilisés par l'installation de Fighter Ops sur l'ordinateur principal. Par exemple, s'il y trois ordinateurs en plus de l'ordinateur principal disponibles sur le LAN, et que Fighter Ops est installé sur les quatre ordinateurs, le système principal peut utiliser les cartes graphiques et écrans des trois autres systèmes pour afficher des vues supplémentaires.
Dans les deux cas les écrans supplémentaires peuvent être utilisés soit pour étendre une vue existante, soit pour afficher d'autres vues supplémentaires à la vue affichée sur l'écran principal.
Moteur météo:
Nous avons finalisé la conception basique du moteur météo pour Fighter Ops. Cette conception nous permet une distribution arbitraire des divers éléments météos (type de terrain, température, humidité, nuages, précipitations, pression et vent) de par le globe.
La prochaine étape pour le moteur météo est la construction de la dynamique de l'atmosphère par-dessus les fonctionnalités décrites plus haut.
Le moteur météo est conçu de telle manière qu'il peut tourner sur un processeur séparé ou sur un coeur séparé, ou sur un ordinateur appartenant à un LAN. Ainsi, par exemple un ordinateur sur le réseau avec Fighter Ops installé peut être configuré de telle façon que seul le moteur météo tourne dessus. Bien entendu le module du moteur météo sera inactif sur l'ordinateur principal afin d'économiser des cycles CPU. C'est le premier exemple du concept de "partage de charge" qui est l'un de nos objectifs de conception majeurs pour cette simulation.
Avionique:
Une plate-forme virtuelle est actuellement conçue et développée afin de contenir tout le code nécessaire à la simulation de l'avionique des appareils de Fighter Ops. Cette plate-forme virtualise des ensembles d'avionique entiers, des boutons dans le cockpit (entrées, inputs) aux affichages du cockpit (sorties, outputs) et tout ce qui se trouve entre les deux. Cette plate-forme permettra la création et la modification des systèmes de l'avionique sans qu'il soit nécessaire de communiquer directement avec le code de Fighter Ops. En conséquence, le codage de l'avionique sera plus facile pour le développeur et plus sûr pour Fighter Ops. En outre la simulation de la machine virtuelle de l'avionique peut facilement être assignée à un processeur ou à un coeur séparé dans ce schéma. Pour de futures sorties de Fighter Ops nous pouvons envisager l'utilisation des technologies de virtualisation matériel qui ont été introduites par AMD et Intel à cette fin.
Autres Développements:
-La Librairie Speed Tree a été intégrée au moteur graphique. Nous évaluons actuellement l'ensemble et nous déciderons d'inclure ou non Speed Tree dans Fighter Ops.
-Une version opérable du modèle de vol du T-38 a été livrée au département codage. Elle sera intégrée au moteur graphique très bientôt.
-La possibilité d'ajouter du statique aux sons (ceux qui sont liés aux communications) en temps réel a été implémentée. Du statique peut être ajouté aux comms quand sont présents du brouillage ou de mauvaises conditions météos."
__________________
je ferai le suivant 
coller dans un traducteur vocal (mode fénéant:sweatdrop )vocal:jerry: et 10min plus tard..Wouhaao_O la vache.