[MSFS] [P3D] Release HN-433/434 - v1.5.0

Lagaffe · [↑]

Alors justement tu complètes parfaitement ma réponse, sur le P40 de A2A (désolé je n'ai que la version WOP3), les textures se répartissent comme suit:

- prop.dds est la texture qui rempli le disque externe (vu de l'avant) disque qui sert pour la partie avant de l'animation slow
- prop_in.dds est la texture qui rempli le disque interne (vu du pilote) disque qui sert pour la partie arrière de l'animation slow
- hub.dds (la goutte d'eau) est la texture équivalente de ma texture propside.png.dds (512x128) qui habille justement les pales en forme de plan

Cela correspond point à point à ma façon de modéliser à la différence que A2A prend un disque complet sur lequel il mappe deux textures (prop et prop_in) alors que je ne modélise que 2 portions de ce disque ce qui correspond sur ma vue aux deux partie surlignées en jaune qui ressemblent à deux part de tarte (avec un avant et un arrière).

Après pour ce qui est des animations et des visibilités, tout est géré par 3 déclarations, chacune porte sur un test de la variable définissant la rotation de l'hélice soit : (A:PROP MAX RPM PERCENT:1,percent)
En fonction de la vitesse de rotation, la plupart du temps comme il y a 3 stades stiil, slow et blurred, il y a trois tests avec trois paliers de vitesse.

Pour le P40 de A2A c'est entre 6 et 37%; entre 38 et 89 % et au-dessus de 89%.
Pour le Ménestrel, le code est donné dans HN433_Exterieur.xml: le code étant ouvert il n'est pas difficile d’ouvrir ce fichier dans un Notepad de modifier une valeur et de tester, tout en faisant aussi la modification identique dans HN433_Interior.xml pour que les deux restent cohérent ... à vos risques et périls

<Animation guid="61a36316-aef3-4353-ae00-796a59c4466c" length="100" name="prop1_still" type="Sim" typeParam="AutoPlay" typeParam2="prop1_still"/>
<PartInfo>
<Name>prop1_still</Name>
<AnimLength>100</AnimLength>
<Visibility>
<Parameter>
<Code>
(A:PROP MAX RPM PERCENT:1, percent) 6.25 < if{ 1 } els{ 0 }
</Code>
</Parameter>
</Visibility>
</PartInfo>
<Animation guid="dad31e0a-04db-4beb-9a10-9a113e13104c" length="100" name="prop1_slow" type="Sim" typeParam="AutoPlay" typeParam2="prop1_slow"/>
<PartInfo>
<Name>prop1_slow</Name>
<AnimLength>100</AnimLength>
<Visibility>
<Parameter>
<Code>
(A:PROP MAX RPM PERCENT:1, percent) 6.25 >
if{
(A:PROP MAX RPM PERCENT:1, percent) 12.5 < if{ 1 } els{ 0 }
} els{ 0 }
</Code>
</Parameter>
</Visibility>
</PartInfo>
<Animation guid="910d22dc-43a4-406e-a16c-b9b34efeaa15" length="100" name="prop1_blurred" type="Sim" typeParam="AutoPlay" typeParam2="prop1_blurred"/>
<PartInfo>
<Name>prop1_blurred</Name>
<AnimLength>100</AnimLength>
<Visibility>
<Parameter>
<Code>
(A:PROP MAX RPM PERCENT:1, percent) 12.5 > if{ 1 } els{ 0 }
</Code>
</Parameter>
</Visibility>
</PartInfo>

Entre le palier n et n+1 l'animation est visualisée; en deçà et au-delà elle est invisible. Les conditions de visibilités sont incluses dans les tests de vitesse de rotation.
Depuis FS2004 j'ai toujours vu ce schéma en application. Ce qui peut varier, c'est la valeur de ces paliers en fonction du nombres de tours que peut prendre l'hélice. Le nombre de tr/mn que prend un P40 n'étant pas identique à ceux d'un HN433.

Que la texture propside.png.dds ne soit pas parfaite (tout le monde peut regarder dans l'arborescence de l'avion qui est fourni et vérifier mes dires par rapport à la texture "hub"), j'en suis conscient et je compte la revoir. Par contre mon choix de modélisation est correct.
Pour ce qui est d'approcher au mieux ce rendu stroboscopique, cela passe par de nombreux essais en variant les valeurs des canaux Alpha de ces textures, les valeurs des paliers pour avoir la meilleure sensation. Cela ne se résume pas à des choix de modélisation.
Simplement une simple modification sur un matériau, une coche supplémentaire demande au moins 10 à 15 mn pour la vérifier dans le simu et passer à une autre modification. Cela prend donc un temps très conséquent.

Pour ce qui est de la réalité, effectivement je ne suis pas pilote mais j'ai approché pas mal d'avions à hélice et filmé pas mal de séquences d démarrage et de mise en puissance.

Pour ce qui est du Ménestrel, je dispose d'un film envoyé par Jean-Claude AFFLARD, film fait à partir du cockpit du F-PYKA et qui retrace une liaison et un atterrissage.
Sans doute que la réalité est différente mais j'essaye de m'approcher de ce que j'ai sous les yeux

Greenhopper · [↑]

Bonjour à tou(te)s,
J'ai enfin pu essayer la dernière version du Ménestrel ce matin et... Que du bonheur! La verrière est top, les commandes sont douces.
Et oui, ces derniers jours ont été très très chargés et je n'avais ni l'énergie, ni l'envie de démarrer mon simu même si ce "p'tit bonhomme" m'enthousiasme. Ce matin, un petit vol entre les Mureaux et Rouen au fil de la Seine m'a ravi!
Merci Didier!
Amités, GreenHopper.

Dernière modification par Greenhopper (24-06-2021 13:01:45)

Lagaffe · [↑]

Nezhaut a écrit:
...
Pour le moment, en jouant sur les traînées, j'arrive à obtenir quelque chose de correct en croisière (il faut encore affiner). J'ai beaucoup réduit l'inertie de l'hélice pour retrouver un comportement plus direct du moteur, mais effectivement, comme tu le disais, il cale au ralenti dans cette configuration. Je vais creuser.
Reste à corriger le décrochage sans trop foutre en l'air le reste. Je suis en train de reprendre le CL vs AOA pour voir.
Mais en MODERN on a moins la main sur le modèle de vol à priori, ce qui explique probablement les bizarreries de comportement en partant des fichiers FSX.
Petite question de néophyte : si je passe en mode developeur, et que je change d'avion à partir de ce mode (sans passer par le menu principal) pour faire par exemple "Ménestrel --> C152 --> Ménestrel", les modifs faites dans les .cfg sont prisent en compte, ou bien il faut relancer le simu ?

Pour ce qui est des paramètres initiaux de l'hélice, je vais les retrouver et les rajouter à la suite de ce post.

En ce qui concerne les modifs via le MODE DEV, certains pratiquent comme cela mais en chargeant le projet et en modifiant les fichiers de configuration via le projet chargé.
Ensuite si j'ai bien compris, ils compilent et rechargent l'avion. NewTV avait fait une ch'tite vidéo sur ce point.
Ceci dit j'ai essayé et il m'est arrivé de corrompre totalement l'avion qui au lancement suivant me plantait tout le simu et j'ai été obligé de recourir à une sauvegarde du projet pour m'y retrouver.
Mais même en faisant de cette façon, les tests sont extrêmement long !

Pour l'hélice et le moteur j'ai essayé aussi les paramètres de friction / efficacité pour donner "plus de couple" à bas régime mais peine perdue

Au cours de la mise au point de cet avion sous FSX, Jean/Epsilon avait fait un CR de vol assez précis (voir page 11 de ce post). Il donne des valeurs qui avait été validées par JC Afflard/HN de Chartres (voir page 12).
Tiens à ce sujet, j'ai réussi à le joindre hier et il est enthousiasmé par l'idée d'une autre version de son avion

Pour les valeurs exactes des vitesses de décrochage/décollage et autres données, il avait fait un résumé ici: http://www.pilote-virtuel.com/viewtopic.php?pid=195413#p195413
Il faut que je corrige dans la documentation que j'ai ajouté à l'addon car il y a quelques erreurs

Nezhaut a écrit:
Bon, je commence à me décourager de corriger cette vitesse de décrochage. Je n'arrive pas à comprendre l'effet des paramètres que je modifie (quasiment aucun en fait).
Le SDK dit que l'incidence de décrochage est définie par le point le plus élevé de la courbe de CL vs AOA :
Pour le paramètre "lift_coef_aoa_table" on a :
Lift function of AoA table. Influence CoL computation if not prescribed and stall angle computation (stall angle = angle for which this table reaches its maximum value)
Sauf... que je peux déplacer ce point jusqu'à l'absurde sans que l'incidence de décrochage ne change d'un iota... Donc il y a autre chose ailleurs qui prend le dessus, mais quoi ?
S'il y a un connaisseur dans le coin, je suis preneur d'une piste... wink
Bons vols !
P.S. : au passage certaines bizarreries n'ont toujours pas été corrigées. Pour les vitesses, on trouve notamment ça :
flaps_up_stall_speed : Speed at which the aircraft will stall when flaps are up, in ktas.
Depuis quand une vitesse de décrochage se définie à vitesse propre constante ?? Et pourquoi pas la vitesse sol tant qu'on y est..

Au moins sous FSX, il y avait un outil AFSD v3.55 (32 bits) que m'avait conseillé Bee Gee et qui permettait de voir finement les divers paramètres en cours de vol et l'influence des modifs. Là, sur MSFS, il y a bien le SIMVAR.exe mais c'est moins facile. Les outils dans le DEV MOD sont très confus, on a une tonne de valeurs affichées dans une fenêtre MS-DOS et pour y retrouver ses petits ... bonjour

Hier soir, j'ai essayé avec les paramètres de la version v1.0.2 de voir l'instant du décrochage: il intervient vers 80 ~ 90 knts mais l'avion s'écroule différemment que sous FSX.

Après il y a la valeur du CoG (Centre de Gravité) qui est géré de façon ubuesque par Asobo. Celui-ci influe beaucoup sur le comportement de l'appareil et avec les modifs qu'à introduit Asobo avec ce curseur de réglage du CoG, je ne sais plus quoi penser.

NezHaut · [↑]

Merci pour ton retour Didier.
Je n'arrive vraiment pas à comprendre pourquoi le comportement ne correspond pas au SDK. En théorie, si je déplace le max de la courbe CL vs AOA, je dois augmenter mon incidence de décrochage et donc réduire la vitesse de décrochage. Couplé à la vitesse de décrochage des paramètres que j'ai corrigé (la valeur était bonne, mais en km/h, pas en ktas... ), on devrait voir un effet flagrant, mais rien du tout !

Lagaffe · [↑]

Je viens de relire les page 11 à 16 de ce post et on avait statué à 69,68 km/h pour le décrochage et 70 km/h pour le décollage (en haut de la page 16) pour ce qui était du moteur FSX.
Là, expérimentalement on se situe à 80 ~ 85 km/h donc on n'est pas si éloigné. Je ne sais pas où j'ai vu la vitesse de 40 que j'ai indiqué dans la doc mais cette valeur est fausse.

J'avais fait un condensé de tout ce que nous avions écrit sur cette mise au point (Jean-Claude, Jean, Jean-Pierre, Anthony et moi), je vais essayer de la retrouver et la publier.

NezHaut · [↑]

On reste quand même un peu loin : le rapport de vol dit 80km/h en longue finale, 70 en courte, et 60 pour le toucher. Or en l'état, à 80km/h une aile est déjà partie et l'avion sur le dos... Avec l'avertisseur de décrochage qui sonne dès 90. On est pas loin d'avoir doublé les distances de décollage et d'atterrissage.

Les faibles nombres laissent croire à de faibles écarts, mais 30% d'erreur sur une vitesse c'est énorme.

Dernière modification par NezHaut (25-06-2021 10:08:59)

Lagaffe · [↑]

Je suis d'accord avec toi, ce comportement doit être revu mais "si on y arrive avec les éléments que l'on a". Je pense qu'il est du moins améliorable.

Ceci dit pour le signal de STALL, il est paramétré en dur dans un des fichiers de configuration.

bede40 · [↑]

Quand on considère qu'un avion transféré depuis FsX (avec 'Aircraft.cfg et toto.air) se comporte tel que prévu par le concepteur, avec les plus apportés par le modèle de vol 'Modern' et l'aérologie, ... on se demande vraiment ce qu' Asobo a voulu réinventer au lieu de faire évoluer l'existant.

Edit: Fôte d'ortografe

Dernière modification par bede40 (25-06-2021 12:15:19)

Lagaffe · [↑]

Tiens, personne n'a essayer d'utiliser un mix des nouveaux fichier glTF avec les anciens aircraft.cfg et hn433.air ... à voir ...

Lagaffe · [↑]

Bonsoir,

Nouvelle avancée probante par rapport à mon post du 23 Juin: ce qui me tracassait était bien un souci de matériaux/textures/paramétrages.

L'hélice en mouvement se décompose en trois mouvement:
- la partie still où l'illusion de mouvement est donnée par une modélisation
- d'un cône d'hélice
- et des deux pales de l'hélice, celle-ci tourne lentement (=> 6,5 %)
- la partie slow où l'illusion est suggérée par
- un cône d'hélice,
- deux cônes (frontal/arrière) dont le rayon externe est le diamètre de l'hélice et qui enserrent l'hélice (les parts de pizza ont été modifiés depuis le 23 Juin)
- et de triangles qui jouent les rayons de ces deux cônes et qui sont visibles dans le sens transversal
- la partie blurred avec encore :
- un cône d'hélice,
- deux cônes (frontal/arrière) dont le rayon externe est le diamètre de l'hélice et qui enserrent l'hélice (ceux-là ont été rajoutés depuis le 23 Juin)
- et de triangles qui jouent les rayons de ces deux cônes et qui sont visibles dans le sens transversal.

Les matériaux/textures/paramétrages qui étaient de mise sur Prepar3D, ne le sont plus sur MSFS, il faut utiliser d'autres techniques.
Le rôle des cônes frontal/arrière avec leurs matériaux est d'occulter les stries que vous pouviez voir sur la v1.0.2 (et qui sont dues à ces triangles en train de tourner), lorsqu'on est placé de manière longitudinale.

Pour cela on utilise un matériau MSFS Standard où est peinte l'hélice en rotation (hélice suggérée sur la texture pour le still et presque transparente pour le blurred). Le choix des paramètres du matériau est très important parce qu'il est la clé de l'effet désiré.
Si ces paramètres sont mal choisis (comme ceux de Mercredi), on remarque tout de suite les triangles qui tournent. Avec le choix de ce soir, les faces avant de ces triangles sont pratiquement occultées, rendues presque transparentes ce qui est parfait !

Pour les triangles, le matériau qui doit être pris sous MSFS est le MSFS Fresnel Bending (Sous MCX, Arno l'appelle FresnelFade).
Couplé avec le matériau précédent, il permet une visualisation de l'hélice à haute vitesse en transversal mais en vue de face ce sont les cônes dont je parlais précédemment qui prennent le relais et qui occulte les stries que j'avais en début de semaine dans la version v1.0.2 et que certains ont remarqué

Je ne vous donne pas tous les paramètres, en étudiant les avions sortis cette année via MCX on arrive à comprendre le fonctionnement de ces divers matériaux et textures puis à isoler les bons paramètres. Je garde certains secrets ... que d'autres ne tarderont pas non plus à trouver.

Voilà ce que cela donne dans Blender et qui n'est pas très éloigné de ce que l'on voit dans le simu:

[img align=c]https://i.postimg.cc/dw3ZqfPv/HN433-h-lice-termin-e.jpg[/img]

En vol, l'illusion est presque parfaite et beaucoup plus réussie que ce que l'on avait généralement sur FSX ou Prepar3D, sauf quelques éditeurs qui arrivaient à ce résultat mais en employant de "vrais graphistes", que malheureusement je ne suis pas.

La contre-partie quand on a plusieurs livrée avec des hélices différentes, c'est qu'il faut créer des textures adaptées à chaque livrée. J'ai donc créé un fichier *.PSD qui comprend sous différents "layers" ou couches, les couleurs des hélices de chaque livrée.

Certes ce soir, le PYKA est fait et validé mais il me reste les 5 autres à finir et à tester sous MSFS. Ce n'est que demain que je pourrais baptiser la v1.0.5 et la publier: DEMAIN pas ce soir

lucky · [↑]

Je suis admiratif

Lagaffe · [↑]

Le gros avantage d'avoir peaufiner cette partie, c'est qu'elle est presque entièrement transposable au HN700, qui héritera aussi des trains (avant et arrière) du HN433 et des textures que j'avais réalisé.

Cela devrait me permettre d'avancer très très rapidement sur le HN700

Lagaffe · [↑]

Fidèle à ma parole, la version v1.1.0 avec les animations des hélices revues ainsi que les textures associées a été mise en ligne à l'instant, de manière à rendre une hélice crédible en vue de côté.

Il ne restera plus que le modèle de vol à affiner si Asobo se décide enfin à stabiliser/finaliser son MDV.

Yan Solo · [↑]

Merci

Dans la boite et en vol le weekend prochain...

Amitiés

lucky · [↑]

Merci beaucoup. Pas eu le temps de tester (hélas...) mais téléchargé et précieusement installé

Lagaffe · [↑]

Bonjour,

En me levant ce matin, j'ai une idée qui m'a traversé l'esprit.
Si les commandes sont inversées pourquoi vouloir tout casser pour tout reprendre ... en multipliant les codes XML par -1 on devrait obtenir le résultat attendu en moins de temps qu'il faut pour le dire. A voir si l'idée est bonne et tant pis pour la beauté du code qui va en prendre un coup ☺️

Pour le lumignon arrière qui ne s'allume plus, c'est depuis les modifications sur la partie électrique donc il est fort possible que la solution soit dans cette partie du code : un bus mal connecté ou pas défini ... à voir !

[EDIT]
Finalement, la solution était évidente et sous mon nez.
Le code fautif:

<Animation guid="46f70366-7d13-4e5b-b9fc-a41eb2c4d645" length="100" name="aileron_gauche_key" type="Sim" typeParam="AutoPlay" typeParam2="aileron_gauche_key"/>
<PartInfo>
<Name>aileron_gauche_key</Name>
<AnimLength>100</AnimLength>
<Animation>
<Parameter>
<Sim>
<Variable>AILERON LEFT DEFLECTION PCT</Variable>
<Scale>1</Scale>
<Units>percent</Units>
<Bias>50</Bias>
</Sim>
</Parameter>
</Animation>
</PartInfo>

La variable AILERON LEFT DEFLECTION PCT varie entre -100% et 100% et l'animation est entre les images 0 et 100 (animlength)

Pour ce qui est de la correspondance entre valeur du simu et image dans le simu, la loi est:

--------------------------------------------------------------------------------
| SIM: Converts simvar to keyframes: simvar * scale + bias = keyframes |
--------------------------------------------------------------------------------

Alors déjà, il y avait une erreur car avec un biais de 50, on ne pouvait avoir qu'une plage de -50% à +50%. Donc le scale aurait du être égal à 0.5 pour que avec:
- une déflexion de -100% on puisse avoir -100 * 0.5 + 50 ce qui correspond à l'image 0
- une déflexion de +100% on aboutisse à +100 * 0.5 + 50 soit l'image 100

Pour résoudre le souci des commandes inversées, il suffisait tout bêtement de remplacer le scale de 0.5 par ... par -0.5
Cette modification est aussi à apporter à l'aileron droit.
Ainsi plus besoin de refaire les modélisations soit ... au moins 3h de gagnées !

Cerise sur le gâteau, en regardant le code de l'élévateur sur les gouvernes arrières, il y avait aussi la même erreur concernant le scale, mais lui était du bon signe donc il fallait simplement le passer de 1 à 0.5 pour retrouver la plage complète et correcte entre 0 et 100 images pour le codage de l'animation.

Donc la v1.2.0 s'approche à grand pas ... si je trouve cette histoire de beacon qui ne veut plus s'allumer ....

Bobonhom · [↑]

Tu vas le gagner ton "bacon" à travailler comme ça

Dernière modification par Bobonhom (30-06-2021 16:41:30)

Lagaffe · [↑]

Alors Bô, comment vas-tu ?

J'ai fait une petite recherche sur OXIO et je pense que ton conseil est très bon .... Par contre, j'espère que tu as trouvé ce que toi, tu cherchais
Si tu as l'occasion, passe nous voir ... sur Skype !

V1.3.0:
- l'inversion des ailerons est réglée
- la plage des valeurs utilisées pour les animations ailerons + rudder a été revue, il restait un bug non répertorié
- le beacon est désormais opérationnel avec la rubrique ELECTRICAL (system.cfg) mise au nstandard "MODERN" (et non plus Legacy~FSX)

Je referais une passe sur le modèle de vol prochainement mais là, je stoppe un peu sur cet avion, histoire de me remotiver ;-)

Yan Solo · [↑]

Merci
Dans la boite...
Plus que 4 jours avant de pouvoir le tester...
amitiés

lucky · [↑]

Merci pour cette nouvelle version que j'ai enfin pu tester hier soir : un vrai bonheur !

Taiaut57 · [↑]

Bonjour à tous,
effectivement, superbe avion, merci Didier.

D5Turbi · [↑]

Bonjour,

Testé à l'instant.
Il est impeccable.=W=W=W

TRINIDAD34 · [↑]

Bonjour,

Merci et félicitations pour cette petite merveille.
Je suis complètement fan

Dernière modification par TRINIDAD34 (30-06-2021 11:45:53)

Orangina · [↑]

Testé et approuvé. Tout ce que j'avais noté est corrigé.
Très plaisant à piloter.
Je trouve le son moteur très "généreux" et rond pour un avion de se gabarit, mais je ne connais pas vrai.

J'ai vu que tu te remets sur HN700 aussi. Super, j'ai volé deux fois dessus avec un collègue se l'étant construit et c'était vraiment très sympa.

Merci

hugues11 · [↑]

super merci Didier

#1101 [↑][↓] 23-06-2021 20:49:34

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1102 [↑][↓] 24-06-2021 12:02:12

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1103 [↑][↓] 25-06-2021 09:40:23

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1104 [↑][↓] 25-06-2021 09:47:43

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1105 [↑][↓] 25-06-2021 09:57:39

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1106 [↑][↓] 25-06-2021 10:07:20

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1107 [↑][↓] 25-06-2021 10:39:04

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1108 [↑][↓] 25-06-2021 11:08:17

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1109 [↑][↓] 25-06-2021 11:42:28

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1110 [↑][↓] 26-06-2021 20:23:21

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1111 [↑][↓] 26-06-2021 20:40:11

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1112 [↑][↓] 26-06-2021 20:43:10

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1113 [↑][↓] 27-06-2021 14:13:59

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1114 [↑][↓] 27-06-2021 20:00:51

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1115 [↑][↓] 28-06-2021 12:45:11

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1116 [↑][↓] 29-06-2021 07:23:21

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1117 [↑][↓] 29-06-2021 15:30:47

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1118 [↑][↓] 29-06-2021 16:16:29

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1119 [↑][↓] 29-06-2021 20:40:40

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1120 [↑][↓] 30-06-2021 08:22:25

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1121 [↑][↓] 30-06-2021 09:14:49

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1122 [↑][↓] 30-06-2021 09:50:15

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1123 [↑][↓] 30-06-2021 11:45:28

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1124 [↑][↓] 30-06-2021 14:46:18

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

#1125 [↑][↓] 30-06-2021 15:12:52

Re : [MSFS] [P3D] Release HN-433/434 - v1.5.0

Pied de page des forums