Vous n'êtes pas identifié(e).
Hello,
mmm pas simple...
Peux-tu vérifier que dans Blender tes animations soient bien définie sur la même plage de clés que dans le Modeldef.xml, à savoir 0 à 360 dans le cas présent. On pourrait mettre aussi 0 - 50 cela ne changerait rien, mais il faut que l'on ai la même chose entre Blender et le Modeldef...
A+
Fro'
(...)
J'ai les messages suivants lors de la compilation sous MCX:
09:40 XtoMDL Information <!-- ++++ Processing Animation : Ambient ++++ -->
09:40 XtoMDL Information <!-- ++++ Processing Animation : appontage ++++ -->
09:40 XtoMDL Information <!-- ++++ Processing Animation : hangar_door ++++ -->
Hello,
OK, les animations sont bien exportées et compilées... Donc maintenant le problème me parait circonscrit soit à une question xml dans le Modeldef.xml soit de fonctionnement avec la gauge RFN dans FSX.
Concernant le code XML celui affiché avait été utilisé avec succès par Lagaffe pour sa Frégate Aquitaine... Vérifie au cas où qu'il n'y a pas dans ton Mdeldef.xml de faute de frappe ou de copier-coller qui rendrait la condition jamais atteinte.
Côté GaugeRFN, fonctionne t'elle avec la frégate Aquitaine : abaissement des barrières lorsque calé sur la frégate et ouverture de la porte lorsque activation de la Commande1?
A+
Fro'
bonsoir micpni,
j'ai toujours un scintillement important sur les portes avions de la RNF sous direct 9 ou 10 et scenery fixer
si tu as une ou des solutionsmerci
Hello,
Si les réglages de la carte graphiques n'arrivent pas à corriger ce pb de scintillement, la seule solution que je connaisse est d'ajouter des MipMap aux textures (*) du pont d'envol (principales causes de scintillement a priori).
Par contre, en ayant mis des mipmap il faut modifier son FSX.cfg en mettant TEXTURE_MAX_LOAD = 2048
Sans ce paramétrage, FSX ne chargera plus les textures à 2048px et n'affichera plus que celles à 1024px au mieux... ce qui n'est plus suffisant pour obtenir un pont d'envol net à courte distance.
A+
Fro'
(*) L'ajout de MipMap peut se faire en utilisant un outil comme DXTbmp.exe ou le Plugin Photoshop de Nvidia
Salut Fro', je pense que c'est au niveau de Blender/MCX que ça ne fonctionne pas car la gauage active bien la porte/barrière de l'Aquitaine. Il faut que je comprenne ou ça ne va pas et pourquoi.
Hello,
Il y a 2-3 petites choses que tu peux vérifier afin d’y voir plus clair :
- Est-ce que les 2 animations personnalisées (porte du hangar et barrière) apparaissent bien dans la liste des animations proposée par Blender ? => Si non, il y a pb dans ton fichier Modeldef.xml
- Est-ce que, lors de l’export de Blender->fichier .x, un fichier.xanim est bien généré ? Non vide ? => Si non, il y a un pb dans la définition/paramétrage Blender de l’anim
- Est-ce que dans ce fichier.xanim tu retrouves bien tes 2 animations ? => Si non, il y a un pb soit dans le paramétrage de l’export, soit un pb dans le ModelDef.xml
- Lors de la compilation .x->.mdl, si tu regardes les logs de compilation, est-ce que tu vois bien apparaitre les 2 animations dans la liste des animations compilées (qui s’affiche en fin de fichier après les traces de compilation du modèle 3D) => Si non, il y a un pb dans le ModelDef.xml
En fonction de ces réponses on devrait arriver à identifier plus précisément où se situe ton problème…
A+
Fro’
Hello Seb,
Que veux-tu dire ? C'est au niveau de Blender que tu ne retrouves pas les animations porte et/barrières ou c'est dans FSX que la gauge ne semble pas commander les animations?
A+
Fro'
Hi,
Super ! Le rendu est vraiment bien!
On voit apparaître des diagonale sur la surface du pont d'envol... bizarre...
Vérifie que dans Blender ces triangle ne sont pas isolés/disjoints? Autre possibilité, la surface n'est peut-être pas totalement plane, au pire applique dessus un smooth..
Dernier point, pour réaliser les animations de la porte, le sujet avait été abordé avec la Frégate Aquitaine et Lagaffe avait bien résumé la manip', donc plutôt que de le paraphraser, voici le lien vers son post : Animation Commandée
Concernant la barrière, c'est exactement le même principe, mais on utilise alors une autre variable crée par la Gauge RFN (en rouge ci-après). Cela donne le code d'animation suivant:
<PartInfo>
<Name>appontage</Name>
<AnimLength>360</AnimLength>
<Animation>
<Parameter>
<Code>
(L:FLOLS_is_valid) if{ 360 } els{ 0 }
</Code>
<Lag>15</Lag>
</Parameter>
</Animation>
</PartInfo>
Bon courage!
A+
Fro'
Graaaah... c'est bô!
En plus c'est "ma" Latouche!! 
Vivement la suite!!
A+
Fro'
Hello Seb,
Tu avances vraiment très bien!!
Juste une remarque/conseil, je note que tu as mappé les barrières avec un couche d'Ambiant Occlusion, ce qui avec le jeu de la symétrie des barrières, génère une zone noire pour la partie au contact du pont d'envol.
Pour toutes ces pièces de détails, je préfère utiliser un carré de couleur unie car d'une part le rendu n'est pas impacté (petite surface et peu d'effet de relief sur la pièce à mettre en valeur) et d'autre part cela génère pas mal de boulot pour mapper et produire l'AO pour ce genre de pièces (beaucoup de corrections à apporter)...
Tu as beaucoup plus de courage que moi, qui par fainéantise, ai rapidement simplifié au maximum la peinture de tous les petits objets...
En parlant de petits détails, n'hésites pas à enrichir ton modèle des détails comme les systèmes d'arrosage, haut parleurs, projecteurs, escaliers, échelle, etc... Les navires de cette époque en ont beaucoup, c'est parfois même très chargé (cf au-dessus de la porte du hangar hélico...).
Réalisés en low-poly cela ne alourdira pas trop ton modèle et cela "habillera" celui-ci bien plus efficacement que des texture en trompe-l'oeil... Accompagné d'ambiant Occlusion sur les parois du navire (pour mettre en valeur ces détails), le réalisme sera alors très bluffant.
Bon courage!
Fro'
Bonsoir Michel,
J'ai essayé l'ETD, ça a été mieux une seule fois ...
Les autres fois sont restées sans réaction du bouton de commande que j'ai programmé en 'Shift+Ctrl+U', même en insistant plusieurs fois !
Cette commande est tout de même très aléatoire, elle est parfois lue mais très souvent inactive ...Je n'ai pas les outils pour investiguer plus loin dans cette procédure.
Mais, c'est comme si une variable était mal définie, ou mal placée, ou encore partagée avec une autre procédure.Je conserve de toute manière FS-X pour les opérations aéronavales ...
A Bientôt.
Patrick
Hello Patrick,
Pas simple ton problème car les tests que l'on a pu faire de notre côté (P3D v2.3 et Zéphyr+GaugeRFN) semblent indiquer que la gauge fonctionne normalement...
De plus le côté aléatoire a tendance à me faire penser davantage à un pb d'interférence qu'un pb intrinsèque de la gauge sous P3D...
As-tu d'autres modules installés avec tes avions et/ou P3D qui pourraient interférer?
A+
Fro'
Hello!
Je ne sais pas exactement comment cela se présente dans Blender, mais il faut que tu paramètres les propriétés de ton material qui contient le filet afin que FSX prenne bien en compte la couche alpha pour la transparence.
Tu as une description des paramétrages kivonbien ici : SDK P3D "Modeling material"
Il s'agit du SDK de P3D mais c'est exactement pareil pour FSX (le SDK en ligne de FSX/ESP est buggé, les pages du Modeling material ne sont pas interactives...)
Je te conseille de faire une petite texture spécifique pour les filets mais aussi pour les antennes radar (par ex) afin de gérer séparément tous tes objets qui nécessitent une couche alpha pour la transparence : alpha noir => zone invisible, alpha gris => zone semi transparente, alpha blanc => zone opaque
J'ai fait cela avec le CDG et cela marche plutôt bien ("CDG_Details_T.dds")
A+
Fro'
Hello Vincent,
Pas simple de te répondre car il y a potentiellement beaucoup de réponse possible...
De mon point de vue le choix de ton avion peut lui aussi très fortement modifier l'organisation de l'équipe à mettre en face.
Dans un projet FSX, outre la partie modélisation, beaucoup d'aspects vont être très rapidement conditionnés par les possibilités et les contraintes du SDK : par exemple, les aspects rendus graphiques et performances seront à prendre en compte au niveau du mapping et du paramétrage des matériaux utilisés dans le modèle, ou encore les aspects commandes de vols, instruments et avionic nécessiteront l'utilisation des variables FSX du SDK pour définir les animations...
Il est difficile de séparer totalement la modélisation des aspects "intégration dans FSX".
Après c'est surtout une affaire de goût : certains vont apprécier animer les gauges 3D et jongler avec les variables et le xml (petite "programmation"), d'autres se font plaisir sur les textures, etc...
Si ton projet n'est pas trop complexe comme un petit avion à instruments à aiguilles, je te conseillerai d'aller au bout tout seul avec l'aide de tutoriaux et de créateurs sur les forum (comme ici) car cela te permettrait de toucher à tous les aspects d'un projet FSX au moins une fois.
Sur un projet plus complexe, comme un avion militaire ou un avion avec une avionic complexe, tu seras obliger d'étoffer ton équipe pour prendre en compte les aspects programmations (je pense notamment à de C++ ou du XML plus pointu pour simuler les systèmes)...
N'oublies pas non plus qu'un projet FSX ne se limite pas aux modèles externe et interne : il y a aussi tous les paramétrages des sytèmes (le fichier Aircraft.cfg) et le modèle de vol!
Difficile de réaliser tout cela sans l'aide de personnes spécialiste pour ne pas dire experts...
Personnellement je pense qu'il est plus simple de travailler à 2 modélisateurs responsables chacun d'un mdl dans son ensemble (externe ou cockpit virtuel) que d'être plusieurs à intervenir sur un même modèle.
Peut-être que des gens sur ce forum ont essayé ces différentes mode d'organisations et pourraient nous faire un retour d'expérience?
A+
Fro'
Hello,
Voici une 2ième vidéo où l'on voit un peu mieux les différents modes dont parle Michel (Searching-Acquisition-Tacking)
Notez aussi que Michel, sur cette vidéo, a augmenté l'intensité du viseur afin que les réticules soient un plus visibles sur la vidéo... Sur cette version du scope Radar et Viseur, les éléments visuels (réticules, fond, etc..) sont réglables de manières progressives en intensité et en taille...
A+
Fro'
Magnifique !
ce radar sera t il importable sur d'autres appareils ?
Hi,
Le radar permet de détecter tout les types d'objets AI de FSX, on a simplifié en ne gardant que 3 modes : avions, navires et tout type.
Après est-ce que l'on laissera la possibilité dans le Crouze de modifier ces modes je ne sais pas, disons qu'actuellement cela est pratique pour faire nos tests...
Importable dans d'autre avions? Mmm je ne sais pas, actuellement le code est repris pour le MirrageIIIC de Restauravia, mais est-ce que je compléterai le code pour pouvoir le mettre partout? Je ne sais pas car il y a quand même pas mal de fonctions implémentées qui nécessiteraient d'être gérées d'une manière où d'une autre...
A titre d'exemple, dans le scope Radar du F-8 on peu gérer:
- échelle de distance
- intensité du fond
- intensité/taille des échos
- intensité/taille des réticules
- mode de fonctionnement (Normal ou automatique Range)
- mode d'objets AI détectés
- sélection des objets
- bascule en mode acquisition
etc...
Autre possibilité, je pourrais proposer juste le scope "Contrôleur" avec le (futur) module de guidage d'interception(*) dans une dll séparée... A voir si cela peut être intéressant...
A+
Fro'
(*) : on travaille sur un module qui permet de simuler le contrôleur radar qui guide le chasseur lors de son interception... Pas simple, mais il y a quelques experts "Chasse" dans l'équipe ce qui rend ce module vraiment réalisable... enfin je pense ...
Hi,
Pas de soucis, je regarde commet je peux te packager cela et reviens vers toi par mail.
Concernant les feux de nav, comme l'a dit Neptune, on voit les caissons d'intérieur noir juste sous les baignoires de la passerelle. N'hésites pas à grossir un peu ces caissons afin de pouvoir y mettre des feux relativement visibles (le caisson sert à obtenir un feu visible de l'avant jusqu'à 120° sur son coté).
Pour les feux blancs, perso je ne mettrais que le feu de sommet du mat principale (visible sur tout l'horizon), les autres ne sont pas utilisés par les navires militaires en dehors du mouillage...
A+
Sylvain
PS : quel format est le plus simple pour Blender?
Neptune, vieux marin, le pavillon de proue c'est la destination? non? et le pavillon de poupe l'appartenance? non?
Hello,
Poupe et/ou Proue ne sont principalement utilisées à quai et/ou au mouillage (il y a aussi qqs cas particuliers comme les revue navale par ex).
En mer le pavillon national est habituellement hissé dans la mature. A voir pour la Suffren si il y a un emplacement privilégié qui correspondrait à une situation "polyvalente" : haut du mat principal? mat "radar"?...
Là il va falloir éplucher qqs photos...
A+
Fro'
Hello,
Vraiment superbe!! On retrouve toute l'élégance de ces belles frégates!
Si tu rentres en mode "retouche", en plus de la peinture des canons (qui devrait normalement être dans le même gris Marine Nationale que la coque), j'ajouterai bien un petit effet d'ombre à l'intérieur des baignoires/ailerons que l'on a de chaque côté de la passerelle => cela permettrait de faire ressortir les volumes qui, sous FSX, sont noyés dans le gris MN
Autre détail, les vitres de la passerelle devraient (de mon point de vue) être plutôt horizontales que verticales comme actuellement => il faudrait mettre davantage de gris en dessous et au-dessus.
Enfin, pas de soucis pour te passer des personnages 3D, va faire un tour sur le Clem, tu y verras, outre les personnels du pont d'envol, une dizaine de marins (en tenue années 90 ou 70 selon les cas) : du pacha au mataf de base, de quoi peupler qqs ailerons ou même une passerelle si tu décides de la découper/modéliser.
A+
Fro'
Pour répondre à Rico83S,
J'ai réussi à exporter un partie de ma frégate avec le toolkit directement en .MDL en voici la preuve :
...
Comme on peut le voir sur les images, tous les objets qui constituent mon modèle ne s'exportent pas. La superstructure arrière et les radars de conduite de tir des masurca, le malafon, les exocet, les canots, les tourelles et les accastillages sont tous les objets qui ne s'exportent pas. Certains sont sur une texture, d'autres sur la seconde.Ce que je trouve quand même très étrange, c'est que certaines parties s'exportent sans problème et d'autres non.
Hello,
Je ne suis pas sûr de comprendre le phénomène. Le mdl que tu affiches est le résultat de la compilation de tout le navire avec le message d'erreur que tu affichais à 16h17? Un mdl partiellement généré malgré le message d'erreur?
Ou alors, ce que tu montres est le mdl le plus complet que tu as pu obtenir sans plantage lors de la compilation?
Cela ressemble à un export du modèle qui plante en raison d'un pb sur un ou plusieurs objets du modèle. La cause pourrait être, par exemple, un objet corrompu (son mesh? son material? un attached point foireux? etc...) ou une animation corrompu (modeldef.xml introuvable ou erroné? )...
Le message d'erreur remonté précédemment n'est pas très clair pour moi, as-tu essayé de faire des exports partiels afin de chercher à isoler l'objet (ou le groupe d'objet) qui causerait ces erreurs?
A+
Fro'
Hello,
Lagaffe a raison de préciser qu’il faut être très vigilant au Xtomdl.exe utilisé.
Dans mon cas je travaille avec 3DSmax7 donc j’utilise le Xtomdl.exe fourni par le SDK qui correspond à 3DSmax7.
En utilisant Blender, il faudra placer le .bat dans le répertoire donné par le BlenderToolkit comme l’a clairement expliqué Lagaffe.
En faisant cela, il faudra aussi modifier le .bat en donnant le bon chemin relatif vers le fichier Modeldef.xml :
XtoMdl /KEEP /XANIM /DICT:..\..\bin\modeldef.xml Toto.X >> Resultat_Compil.txt
A noter que Model Def.xml ne sert qu’aux animations, donc pas la cause a priori des problèmes actuels de la Frégate...
Sinon je suis d’accord avec Bede40 pour dire que 64k n’est pas, normalement, une limitation pour la taille globale du modèle : tous mes porte-avions dépassent largement sans problème les 64k sans autres résultats que les warning dont parle Bede40.
Après, est-ce que le Xtomdl pour Blender se comporte différemment que celui de 3DSmax7 que j’utilise ?? Cela serait une mauvaise nouvelle…
Enfin, si il n’y a pas (a priori) de limite globale à 64k, il y a une limite par Material : le compilateur refusera qu’un material soit utilisé par plus de 64k de textured vertices (on va dire vertices pour faire simple). Il s’agit d’une limitation du moteur graphique et de la gestion des Draw Calls qui sont limités à 64k…
Une fois que la question de la cohérence des versions compilateurs sera réglée, il sera assez simple de comprendre si il y a un problème de limitation ou non…
A+
Fro’
non j'ai bien fait attention de tout "terminer", de plus j'ai coché la case "apply modifier" à l'export.
Demain, j'essaierai de voir du coté de FSdeveloper s'ils n'ont pas une solution dans le forum dédié à Blender.
Merci de votre aide, de mon coté, je vais aller faire un somme car demain boulot boulot
Seb
Hello,
J'utilise un moyen très simple pour compiler les fichiers .x tout en conservant les messages d'erreur du Xtomdl.exe
Il suffit de créer un fichier.bat avec dans ce fichier la ligne de commande suivante:
XtoMdl /KEEP /XANIM /DICT:..\..\bin\modeldef.xml Toto.X >> Resultat_Compil.txt
Tu mets ton fichier Toto.x et ce fichier .bat dans ton dossier du SDK où se trouve Xtomdl.exe.
Chez moi c'est ici :
C:\Program Files\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Modeling SDK\3DSM7\Plugins
Normalement le fichier Modeldel.xml (qui contient les éléments pour les animations) se trouve ici :
C:\Program Files\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Modeling SDK\bin
Pour compiler tu double-cliques sur le .bat et un fichier.mdl sera généré ainsi que le fichier Resultat_compil.txt qui contiendra les logs de compilation.
Comme l'ont dit déjà les petits camarades, je pense très fortement à une saturation d'un de tes 2 material.
Personnellement je fais une texture pour la coque et une autre pour les superstructures. Si cette dernières continue à saturer, va mapper les petits objets (garde-fous, antennes, etc...) sur un petit carré de couleur de ta texture "Coque": le rendu sera identique mais cela te permettra de basculer certainement pas mal de vertices d'un material à l'autre...
A+
Fro'
Hello Ferondoe,
Très beau travail!!
Juste une petite question/remarque : il me semble que la casserole est normalement de la couleur de la flottille, à savoir bleu pour la 12F, rouge pour la 17F, blanc pour la 14F et noir pour la 15F.
A confirmer bien-sûr...
A+
Fro'
Hello,
Super initiative cela!!
Entre cette belle Dudu et la Suffren de Rafalemirage, il ne va manquer qu'une Latouche-Treville (ou consœur) pour avoir une belle escadre au complet!!
...Bon, j'ai juste un peu peur qu'il ne soit pas FPS friendly, mais bon je verrais bien avec mes futurs export sous FSX...
De ce côté là je pense que tant que tu resteras sous les 100k le modèle pourra être vraiment light pour FSX. Après on peut faire déjà beaucoup de chose rien qu'avec 60k de polygones...
Pour infos le CDG montent jusqu'à 170k, mais j'ai 10 avions parqués et plus de 50 personnages 3D, et un longueur de garde-fous assez importante 
.
Tant que tu n'utilise pas des cylindres 12 faces pour faire la moindre barrière (par ex), je pense que tu ne devrais pas avoir de pb. Pense surtout à bien économiser tes "material" : il vaut mieux n'avoir qu'une ou 2 textures de 1024px plutôt qu'une multitude de petit texture voir pire utiliser des "solid color"...
Bon courage!
Fro'
PS1: les fond de carène et autre bulbe ne sont pas forcément visibles une fois le navire à l'eau... donc pourquoi pas couper et en faire l'économie?
PS2 : Si tu es intéressé, j'ai des plans de la Durance... jamais eu le temps de la faire...:8
... il faudrait que je trouve de bonnes photos de profil pour faire une texture photo. ...
Hello,
Très beau projet rafalemirage !! Personnellement je ne t’encouragerais vraiment pas à faire du Photoréalisme sur ton navire.
D’abord parce que il est difficile de trouver des photos exploitables (pb de dimension du navire, balance des couleurs dont le gris qui est infernal, etc…) et ensuite parce que je suis convaincu qu’il y a moyen d’avoir des résultats nettement meilleurs via photoshop et une couche Ambiant Occlusion…
Je t’encourage donc plutôt à faire un mapping bien à plat sans chevauchement des principales parties de ton modèle (coque, superstructure, pont, hangar, mât, etc) pour que Blender calcule de belles « Occlusion » Map.
Pour les objets plus petits (échelles, escaliers, antennes, garde-corps, etc..) pour lesquels une AO n’aurait pas d’intérêt particulier, alors mappes-les sur des carrés de couleur placé dans une de tes textures.
Une fois cela fait, tu n’as plus qu’à ajouter, dans les textures, les détails kivonbien (numéros de coque, nom du navire, les valeurs, des traces de salisseurs, etc…) et tu obtiendras ainsi un rendu, qui mettra en valeur tous les détails 3D, d'une qualité bien supérieure à tout photomontage…
A+
Fro'
Aaaarrrrgh Michel m'a grillé!!
Bon je laisse quand même ma réponse...
Hello,
Je peux te répondre, Michel complétera si besoin.
L'ETDIVM n'avait pas de centrale inertielle, il s'agit d'un calculateur d'estime alimenté par différents instruments du bord. Ce système était loin d'être précis ce qui nécessitait des recalages au cours de la mission. Tu noteras ainsi que les missions élaborées par Michel contiennent toujours des points remarquables notamment juste avant les phase d'attaque. Les centrales inertielles ont fait leur apparition seulement avec le Super Etendard et la version modernisée du IVP (présence du système UNI)
Concernant la mire dont tu parles (Triangle peint sur la piste oblique) il s'agit d'un élément visuel utilisé par les pilote de SUé/SEM à l'appontage : il s'agit de caler la base de ce triangle sur un réticule du HUD afin de garantir d'être sur la bonne pente...
C'est un système pas évident à mettre au point sous FSX comme tout ce qui touche les HUD en général (n'est-ce pas BeeGee! 
)
A+
Fro'
Bonjour à tous,
Tout d'abord je profite de ce message pour remercier encore toute l'équipe qui nous à offert l'ensemble des addon "made in RFN"qui restent pour moi les numéro un pour fsX tant sur le plan de la réalisation que de l'intérêt ludique.
J'avais deux question pour micpni:
-Je me demandais comment fonctionnait le système de navigation de l'Etendard IV M, est ce une centrale inertielle?(Ce qui me paraîtrais étonnant pour un avion de l'époque et de cette taille, mais je ne suis pas spécialiste).
-A quoi sert le grand triangle strié peint à l'extrémité du pont oblique du Clémenceau ou du Foch? (On peut voir sur les photographies de début de carrière qu'il n'est même pas présent).
Ces deux questions ont un rapport lointain avec l'addon mais c'est ici que je pense trouver l'expert pouvant éclairer ma lanterne!
... j’ai crue comprendre que M2M ne simulera pas les emports A/G (Air to Ground sur le M2KC et bien d’autres systèmes qu’une boîte comme VRS aurais pris le temps de simuler, même pour voler à l’ancienne ! ...
Hello,
je ne suis pas sûr de bien te suivre dans ton raisonnement... Je ne vois rien de choquant à ce que M2M propose un M2KC sans emport A/G. D'abord parce qu'il s'agit avant tout d'un chasseur pour la supériorité aérienne (OK il a aussi des capacités Air-Sol, mais le C c'est d'abord et surtout un chasseur) et ensuite parce que justement VRS ne peut pas être la référence pour un projet Payware : leur projet FA-18 a été beaucoup trop complexe et donc trop long à sortir pour servir de projet référent!! On a tendance à oublier combien l'accouchement du FA18 a été douloureux par VRS: de très nombreux reports (et donc frustrations) et beaucoup de retard au final...
Travaillant depuis quelque mois maintenant sur un pur chasseur, le F-8E(fn), je peux déjà vous annoncer que tous les amateurs de F-18, F-16 ou autre Rafale vont être déçus. Pas de navigation sophistiquée, pas d'armement varié et/ou intelligent, la mission type d'un intercepteur version "guerre froide" est à 180° de la forme d'imagerie d’Épinal générée par des avions comme le F-16!!
De plus, depuis quelques temps maintenant, l'exigence apparente(*) du public ont conduit les projets payware à revoir la complexité de leur projet à la hausse. Résultat : rien!! On a plein de projets qui ont démarré depuis des mois/années et rien ne sort ou est en passe de sortir (je parle pour les avions militaires)...
Si en choisissant un avion plus restreint en terme de missions et donc d'avionic/armement, M2M est capable de sortir leur avion en moins de 2 ans, moi je dis très bon choix!!
A+
Fro'
(*) Je dis "apparente" car je ne suis pas convaincu que le "hard core" soit une attente si généralisée chez les acheteurs potentiel d'avions militaires...
...
1 - le bouton rotateur du Transpondeur (OFF/STD/TEST/ON) qui ne veut rien savoir,
2 - et les 2 boutons de la COM qui fonctionnent eux mais ne veulent pas tourner ... les fréquences sont par contre modifiables parfaitement !
... mais là je pense que c'est un problème de code XML pour les 2 soucis rencontrés.
Hello,
N'hésites pas à m'envoyer ton XML, des fois un oeil externe repère plus facilement des éventuelles coquilles.
J'ai parfois eu des pb au niveau de 3Dsmax lorsque je mappais l'animation. Dans ce cas la seule solution était de de-mapper l'animation et de la re-mapper à nouveau (bug/pb dans le script d'export du SDK)
A voir...
A+
Fro'
