Aichi D3A (VAL pour les alliés)

Salut à tous,

Après le Nakajima B5N (Kate) voici donc le Aichi D3A. L'un des avions qui a coulé le pus grand nombre de navires alliés.


Tout deux, Kate et Val étaient en service sur l'Akagi.

Seul petit souci, actuellement impossible pour moi de lancer FG. Je pensais que cela venais de mon vieux pilote Nvidia incompatible avec le tout nouveau Xorg, mais actuellement tout mes jeux et logiciels 3D (Blender, OpenArena, Supertuxkart, Nexiuz etc..)) fonctionne parfaitement et sont accélérés nickel chrome. Il n'y a que FG (et OSG en l'occurrence) qui fait planter tout cela. Non seulement si je lance FG il plante mais ensuite toute ma 3D est foutue. Obligé de relancer l'instance graphique.

Du coup concernant le tableau de bord, j'ai travaillé en aveugle avec seulement Blender pour voir ce que je faisais. Pas de FGRun pas de FG rien pour vérifier la position ou la taille des instruements. Aussi, avant de le diffuser directement dans mon hangar (et sur GIT) j'aimerais vous le proposer en avant première pour que vous puissiez me faire quelques photos du tableau de bord dans FG. Et bien sur tout autre remarque si vous le jugez utile

Le voici :
http://helijah.free.fr/flightgear/tar.gz/val-27-06-2011.tar.gz]http://helijah.free.fr/flightgear/tar.gz/val-27-06-2011.tar.gz
Il est maintenant dispo dans mon hangar et sur GIT

Dans l'attente de vos photos et remarques

Amicalement Emmanuel

Salut Emmanuel,

Tu nous offre là encore une très belle modélisation ! Bravo !











Je le trouve vraiment magnifique ce moteur ....









Dis Emmanuel, tu as vu le nouveau système d'évaluation des appareils ? http://wiki.flightgear.org/Formalizing_Aircraft_Status
Je trouve ça bien ! On va pouvoir télécharger des appareils sans se dire "J'espère qu'il a au moins quelques instruments sur le tableau de bord" et avoir la mauvaise surprise de tomber sur un appareil "nu"

Ça va t'en faire du boulot entre les ombres visible en MP + le système dévaluation... tu vas pouvoir revisiter tous tes appareils lol. Je pense que tout le monde pourrait mettre du sien et mettre à jour ton hangar.

[Hors sujet]
Tiens j'en profite pour te demander, toi qui a longtemps été analyste programmer, si tu avais quelques pistes pour permettre les ombres via OSG ? J'ai déjà repéré où ça se passait dans les sources de FG, c'est un certain fichier "renderer.cxx" dans lequel une vingtaine de lignes concernant les ombres OSG sont commenté avec écrit "OSG FIXME" un peu partout...
J'ai très très peu de base en C++, openGL et OSG mais je commence à m'y mettre : redbook, bluebook, tuto, manual reference... enfin bon ça manque pas d'infos (du pure OpenSource !) Alors si je peux me permettre une première question : Quelle différence entre un .cxx et un .hxx ? De ce que j'ai compris le .hxx déclare toutes les variables utilisé dans le .cxx mais bon, faire un fichier juste pour ça c'est pas très judicieux... donc je dois rater quelque chose.
[/Hors sujet]

Amicalement,
Clément

Un seul mot, MAGNIFIQUE ! Comme d'habitude, quoi ...

AMicalement,

Salut Clément et un grand merci pour les photos. Du coup, je me rend compte que même en aveugle, j'arrive encore à faire des trucs sympas Je vais pouvoir le mettre à disposition dans mon Hangar et sur GIT.

Pour ce qui est de render.cxx je viens de zieuter rapidement.....Malheureusement plusieurs choses m'empêche de te donner une réponse claire. Comme je l'ai déjà dit, j'ai arrêter de coder depuis plus de 7 ans mais surtout, je suis d'une école beaucoup plus ancienne. Tout ce qui est langage objet m'est assez étranger J'ai essayé plusieurs fois mais je n'accroche pas. J'ai besoin de repères qui ont disparus dans ce type de programmation. Une chose est sur, il y a effectivement un début de codage (sûrement réalisé par Tim MOORE - timoore sur IRC ) et cela semble utiliser les fonctions d'ombre de OSG.

Tiens histoire de te donner une idée voici l'un des mes sources, qui date d'une autre époque : http://helijah.free.fr/EB_MODEL.lst tu y trouveras absolument tout Projection 3D->2D, dessin point par point d'un randu de Gouraud ou de Phong, etc....

Tout ce que je peux te conseiller c'est de tenter de contacter Timoore sur IRC (canal #flightgear) pour avoir plus d'info, voir proposer ton aide. C'est un américain, mais il vit à Bordeaux et parle parfaitement le Français.

Maintenant parlons un peu du système de classement. Deux problèmes existent. Tout d'abord et tu as commencer à en parler. Les petits malins qui inventent se genre de chose n'ont pas d'avions à leur actif, ou alors 1 ou 2. Ils n'imaginent absolument pas ce que cela représentent pour 190 appareils Mais surtout, contrairement à moi qui fait l'effort de fournir une grande partie de mon site en Anglais (bon pas toujours bien traduit, mais traduit), aucun d'eux ne fait l'effort d'une traduction, même imparfaite, de leur pages. Du coup, tant que tout cela sera en anglais je ne ferais pas l'effort de le lire ou de le mettre en oeuvre.
Et puis qui va juger de l'état d'un avion. L'auteur ? Un avion n'est jamais fini pour l'auteur. Si je m'écoute je met alpha et 1 ou 2 en indice pour tous. Alors ? Qu'elle est ou qu'elles sont les personnes qui vont prendre sur leur temps pour juger de l'état d'un appareil et placer les indices et l'état dans les xml ? Parce que bien sur, placer des règles c'est facile. Dire "faites ceci et cela" c'est rapide. Mais le faire c'est autre chose n'est pas.

Tiens au passage puisque tu veux mettre les mains dans les sources de FG. Je pense qu'il serait important, aussi, voir totalement prioritaire de revoir un peu les sources concernant YASim......... Extinction des Turboprop et réacteurs par exemple..... Cela montrerais à tous que YASim n'est pas mort (étant une partie intégré à FG il ne peut mourir mais certains le croient). Toi qui a déjà joué la dessus en Nasal, cela devrait t'amuser de le faire directement dans les sources non ?

Aller je fini ici avec les hxx et les cxx...... en fait c'était déjà ainsi en C avec les .c et les .h Cela peut paraître étrange c'est vrai. Mais si une fonction n'est pas définie elle ne fonctionnera pas. Aussi par convention toutes variables, fonction, procédure etc... d'un sont déclarées dans un .h de même nom. Et du coup, par extension en C++ cela est devenu .hxx pour les .cxx. Cela peut paraître étrange mais c'est ainsi C'est une organisation qui, avec le temps, fait ses preuves. Bien sur il est toujours possible de tout mettre en vrac dans un fichier .cxx mais sur de gros projets comme FG, par exemple, tu comprendras très vite de l'intérêt des .h (par exemple dans le EB_MODEL.lst donné plus haut, si j'avais pu sortir toutes les déclarations du source dans un fichier spécifique, cela aurait rednu ce dernier beaucoup plus légé et simple à comprendre. Malheureusement le langage utilisé ne le permettait pas).

Amicalement Emmanuel

P.S. Merci JM