[P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

Bee Gee · [↑]

Faut voir les limites de l'intérêt de tel damage mode

Pour faire mumuse et agrémenter de longs vols ennuyeux et sans intérêt, c'est bien, .... et ça apprend à gérer des pannes

Mais est ce vraiment réaliste ? A mon avis pas vraiment, un pilote professionnel sur une carrière de 30 000 heures a peu de chance de connaître une panne grave. Sur une demi carrière je n'ai connu qu'une panne moteur et encore elle n'était pas liée au moteur lui même.

On parle de Vmo, un dépassement modéré de Vmo sera sans conséquence, la limite de calcul de structure est la Vd qui est supérieure de 10% à Vmo, à 330 kt sur un avion limité à 300 on ne risque pas grand chose.

Pour les moteurs d'avion léger c'est pareil, les Lyco 360 sont limité à 2700 t/min, en fait ils sont calculés pour tenir transitoirement 3000 t/min et les voltigeurs américains les faisaient tourner à une époque à 3300 t/min sur leurs Pitts sans guère de casse excepté une usure accélérée.

So keep cool ! rires !

Kekelekou · [↑]

Bee Gee, c'est sûr que ces DamageMods sont sans pitié par rapport à la réalité. (Et encore, on peut ajouter des marges dans les critères de défaillance ou d'usure).
Mais ce qui me déprime dans FS, c'est qu'on peut faire n'importe quoi avec le moteur, tirer des g à n'en plus finir, etc etc, et... Rien, il ne se passe rien, aucune conséquence à une mauvaise utilisation de l'avion et de ses systèmes.
Avec les DamageMods, on est obligé d'être attentif à ce que l'on fait.

Kekelekou · [↑]

Pour en revenir à l'adaptation du DM à l'AirTractor, faisons donc la liste des systèmes que le mini-Canadair utilise, dans l'ordre d'apparition dans mon fichier récapitulatif (ouvrez-le pour voir à quelle gauge précise se rapporte les valeurs numériques).

Petit aparté : il y a une certaine logique dans la désignation des jauges qui permet de savoir à quoi on a affaire :
- les -log.xml régissent l'implémentation de l'usure suivant différents paramètres
- les -d.xml provoquent les effets d'une trop grande usure
- les -health.xml modifient la « barre de santé » du système sur le panneau 2D
- les -damage-status.xml affichent la mention «abimé » sur le panneau 2D
- les -repair-txt.xml remettent les compteurs à zéro et effacent les casses

Encore une fois, les valeurs proposées correspondent à des estimations de ma part à partir de la lecture des instruments de bord en vol, et peuvent être modifiées selon les goûts.

- Pilote auto : bon en l'état

- Ailerons : bon en l'état

- Annonciateurs : à supprimer
- Freins D et G : bon en l'état
- Portes : l'AT802F n'a que deux portes (n°0 et n°1, les n°2 et 3 servent à des animations), gardons uniquement les sons si les portes 1 et 2 sont ouvertes. Supprimons donc les gauges door_warn_sound4.xml et ...5.xml

- Gouv profondeur : bon en l'état si on n'utilise pas FireFighterX. La charge largable de l'AT802F est de 800 US gallons, soit 3105 litres d'eau, ce qui provoque un fort couple à piquer. Pour maintenir le palier, une action à cabrer est nécessaire même avec le trim à fond. Avec la jauge actuelle (usure si gouverne braquée à plus de 8°), il est impossible de tenir 15min en vol. J'ai donc changé la valeur à cabrer à 18°. Mais ceci ne concerne que les utilisateurs de FFX.

- Moteur : l'usure est gérée par eng1_wear_log.xml, avec deux états possibles : moteur neuf et moteur fatigué. Dans chaque cas, la première ligne correspond à des valeurs de fonctionnement normal du moteur, on peut donc les laisser en l'état. La seconde ligne décrit un état de surmenage. Le couple doit être fortement augmenté, à 4700rpm (arc jaune), pour l'ITT l'arc jaune est atteint si la temp extérieure est élevée. Une valeur de 800°C est raisonnable : comme les critères se cumulent (ils doivent tous être remplis), une valeur ITT trop élevée ici rendrait la gestion du couple inutile.

- ITT : Ici, on ne se soucie que de l'ITT, on peut donc mettre une valeur de 820°C.

- Volets et moteur volets : fait !

- Réservoirs carburants : 3000 lb définit le débit de transfert du carburant, et non pas la capacité du réservoir! Les 4 jauges fueladd_/fuel dump_switch.xml indiquent donc que le clic sur le "+" ou le "-" enclenchent le remplissage ou la vidange des réservoirs à 3000lb par unité de temps. Les jauges n'ont donc pas besoin d'être modifiées. (D'ailleurs, le remplissage est assez lent dans FSX, on pourrait même augmenter la valeur).

- Générateurs : bon en l'état

- Atterro brutal : L'airTractor est un amphibi avec un « petit » train. La VS maxi à l'atterro peut donc est réduire de 600 à 300ft/min

- Atterro brutal 2 (crash landing?) : là aussi, Vsmax 900 → 500ft/min

- Survitese : déjà fait !

- Suraccélération : bon en l'état

- Surchauffe pitot : bon en l'état

- Hélice : les rpm maxi sont de 1700tr/min. Je propose de changer les valeurs de 900 à 500rpm, et de jouer le son si l'hélice usée tourne à plus de 1400 rpm

- Dérive : bon en l'état

- Dégrivage : aucun sur cet avion ! A supprimer

- Pompe à vide : la vitesse de 170kn est trop élevée, ramenons-la à 145kn.
Il manque par contre les jauges pour le train et le moteur du train, ce sera pour la prochaine fois.

On vient de constater que plusieurs jauges sont inutiles. Pour que la simu n'en tienne pas compte, on a le choix entre :
- supprimer le fichier xml
- supprimer l'appel de la jauge dans le panel.cfg
- ou bien faire les deux!
Vous pouvez donc faire l'exercice pour les jauges des annonciateurs et du dégrivrage. Afin de pouvoir rajouter plus facilement les jauges du train, il est préférable de ne pas supprimer les jauges en question, elles pourraient resservir...

Prochaine étape : et si on se rajoutait un système?

edit: Correction du descriptif des jauges carburant et profondeur

Dernière modification par Kekelekou (05-10-2016 12:53:53)

Kekelekou · [↑]

Suite à des essais ce week-end, j'ai corrigé quelques points dans mes messages ci-dessus.

Kekelekou · [↑]

Ajoutons donc l'usure du train d'atterrissage et de son moteur à l'AT802F...

Les jauges pour le train ne sont pas disponibles dans le DM C208b, nous allons donc récupérer ce qui a été fait pour le Baron 58 (disponible aussi sur FlightSim). Je vous conseille d'ailleurs d'installer ce DM, puis de le tester dans FSX. Comme vous allez le constater, le panneau de maintenance est différent, ce qui va nous demander un petit plus de travail. Mais vous vous en êtes très bien sortis jusqu'à présent, il n'y a pas de raison que ça change!

Comme nous l'avons vu lors de l'installation du DM et des bidouilles, un système se décompose en 4 parties :
- les jauges d'usure et de casse ( les -log.xml et les-d.xml)
- l'enregistrement des valeurs via la jauge de Doug Dawson (via le fichier ini du dossier data)
- les sons éventuels
- les jauges du panneau de maintenance (-health.xml, -damage-status.xml...)

Il faut travailler sur chacune des 4 parties successivement afin de garantir l'intégration de ces nouvelles jauges. Une attention particulière est à apporter sur le nom des variables.

11 fichiers sont à récupérer dans Damage_Mod_Baron58.CAB, et à coller dans le dossier panel/Damage_Mod_AT802F. J'ai rajouté à la fin de ligne les “nouvelles” variables sollicitées par ces jauges .

Gear_Down_Sound.xml → Sons (L:SB_Sound10, number)
gear-d.xml → Usure et casse (L:GEAR, number)
gear-d-log.xml → Usure et casse (L:GEAR, number) (L:SB_Sound09, number)
gearmotor-d.xml → Usure et casse (L:GEARMOTOR, number)
gearmotor-d-status.xml → Panneau (L:GEARMOTOR, number)
gearmotorRepair.xml → Panneau (L:GEARMOTOR, number)
gearmotortxt-d.bmp → Panneau
gearmotor-wear-log.xml → Usure et casse (L:GEARMOTOR, number)
gearmotor-wear-soun.xml → Sons (L:GEARMOTOR, number) (L:SB_Sound21, number)
gearRepair.xml → Panneau (L:GEAR, number) (L:GEARMOTOR, number)
gearstatus-test.xml → Panneau (L:GEAR, number)
geartxt-d.bmp → Panneau

1) Jauges d'usure et de casse

Il suffit de reproduire le précédent exercice sur ces 4 jauges, en adaptant les valeurs numériques à notre appareil, principalement la vitesse au-delà de laquelle le train sorti casse.
gear-d.xml → Rien à faire!
gear-d-log.xml → 152 → 130kn (d'après mon expérience de décollages poussifs à pleine charge)
gearmotor-d.xml → Rien à faire!
gearmotor-wear-log.xml → on peut penser que le moteur de relevage du train commence à peiner à partir de 100kn, par contre le rythme d'usure de 0.01 est trop faible, mettons 1.

Là encore, la valeur du seuil est estimée à la louche faute de données plus précise, et il est tout à fait permis de la moduler en fonction des goûts de chacun (ou de sa doc!).

Pour plus de “réalisme”, on peut aussi compléter les jauges hardlanding.xml afin de prendre en compte la dégradation du train en cas d'atterrissage brutal.
J'ai ainsi rajouté les bouts suivants à la fin des lignes concernées :

hardlanding.xml, ligne 12 : (L:GEAR, number) 100 + (L:GEAR, number) (L:GEARMOTOR, number) 50 + (L:GEARMOTOR, number) } }

hardlanding2.xml, ligne 10 : 1000 (>L:GEAR, number) 500 (>L:GEARMOTOR, number) } }

2) Enregistrement des états

Nous venons d'incrémenter les variables d'usure de nos nouveaux systèmes. Mais si ces valeurs ne sont pas mémorisées d'une session à l'autre, le DamageMod n'a plus vraiment d'intérêt.
Il faut donc déclarer ces nouvelles variables pour que la gauge de configuration AT802F_config.gau puisse les stocker.
La déclaration se fait dans le fichier data\AT802F_config.ini. Il contient deux grandes parties.
La partie [Lvars] permet à la jauge de savoir quelle variables doivent être surveillées, et la partie [Floats] inscrit les valeurs correspondantes.
Les nouvelles jauges font appel aux variables L:GEAR et L:GEARMOTOR, ajoutons-les donc à la liste :
...
Lvar_17=DAMAGE
Lvar_18=GEAR
Lvar_19=GEARMOTOR
Lvar_20=

Ca y est, les valeurs d'usure de nos systèmes seront bien enregistrées! Un grand merci à Doug Dawson qui a créé cette jauge super pratique.

3) les sons

L'inspection des nouvelles jauges a mis en évidence que 3 sons étaient pilotés: les SB_Sound 09, 10 et 21. Mais attention, ce sont là des sons du Baron 58, et non pas ceux du C208b que nous avons pris comme base. Et si on regarde le dossier FSX/Sound/DM_AT802F, on constate dans le fichier sound.ini (même principe que le config.ini) que ces emplacements sont déjà utilisés.

Pour le Baron, les couples variable/fichier son sont les suivants (à voir dans FSX/Sound/DM_Baron58 si vous avez bien installé le DM) :

SB_Sound09 : SB09_GearD.wav
SB_Sound10 : SB10_baron_geardn.wav
SB_Sound21 : SB21_gearmotorwear.wav

En comparant avec le DM_AT802F/Sound.ini, il apparait que les SB_Sound09 et 21 pilotent les bons fichiers son. En revanche, le SB_Sound10 de l'AirTractor déclenche un SB10_caravan_fire_detect.wav, rien à voir avec le train. Il nous faut donc un autre créneau, que l'on obtient en rajoutant à la fin de la section [Sounds] :

Sound30=./Sound/DM_AT802F/SB30_geardn.wav

A la fin de la section [Lvars] :

Lvar30=SB_Sound30

Le fichier SB10_baron_geardn.wav est donc copié du dossier Baron et collé dans FSX/Sound/DM_AT802F, où on le renomme en SB30_geardn.wav.
Ce son est piloté par la gauge Gear_Down_Sound.xml, qui est corrigée en remplaçant

if{ 1 (>L:SB_Sound10,number) }

par

if{ 1 (>L:SB_Sound30,number) }

La partie sonore est terminée! Ne reste plus que l'affichage des infos et des boutons de réparation dans le panneau de maintenance.

Edit : Modif vitesse d'usure train baissé et de l'incrément d'usure.

Dernière modification par Kekelekou (06-10-2016 15:57:09)

coyotte · [↑]

Merci en tout cas ! =W=W
Voilà un bel esprit de partage qui mérite largement un petit +1 ![small](*)[/small]

Je m'étais contenté de singer un tuto pour équiper un ou deux zincs de la VA.
Mais ta contribution est une belle relance !

[img align=C]http://img4.hostingpics.net/pics/335060damagemodtest30091314.jpg[/img]

COYOTTE

[small](*)[/small] je suis toujours étonné de voir que ceux qui partagent et prennent le temps d'expliquer patiemment à la communauté comment améliorer l'ordinaire ont des réputations largement plus faiblardes que ceux qui, au hasard, postent simplement des screens, même si ça demande évidemment du boulot et mérite parfois qu'on s'y attarde.
N'oublions pas de remercier aussi les "créateurs", ou dans le cas présent ceux qui aident à la créations. Ça reflète un peu mieux l'intérêt qu'on peut avoir pour leur travail !
Quant aux "screeners", je tiens à le préciser, j'critique pas ce qu'ils font et postent ! Je mets juste en parallèle

Dernière modification par coyotte (04-10-2016 15:58:00)

Kekelekou · [↑]

Merci Coyotte, mais tu sais, je ne fais pas la course à celui qui a la plus grosse renommée!
En fait, j'avais promis de le faire, dont acte, et puis ça m'oblige à formaliser la démarche, et donc mettre un peu d'ordre dans le bazar de mon cerveau. Et c'est peu de le dire!

Par contre, moi, j'aimerais vachement que tu partages tes jolis pompiers en bord de piste, prêts à charger les zincs en retardateur...

coyotte · [↑]

Kekelekou a écrit :

Merci Coyotte, mais tu sais, je ne fais pas la course à celui qui a la plus grosse renommée !

Je m'en doute bien... C'est juste une réflexion que je tenais à partager...

Kekelekou a écrit :

Par contre, moi, j'aimerais vachement que tu partages tes jolis pompiers en bord de piste, prêts à charger les zincs en retardateur...

En fait, il s'agit de retardant... Un produit miracle, sauf quand tu en as plein les pompes/ les fringues/ le bahut =8=8
Le pélicandrome est l’œuvre d'un collègue, mais à la suite d'indélicatesses (pour ne pas dire autre chose), comme beaucoup d'autres créateurs, il ne distribue plus. Désolé !

COYOTTE

Kekelekou · [↑]

Il ne nous reste qu'à mettre à jour le panneau de maintenance afin de pouvoir aller bombarder les incendies...

Deux systèmes doivent être rajoutés sur ledit panneau. Or, vous pouvez constater qu'il est actuellement complet.
Le système de dégivrage ne nous est pas utile, on va donc recycler son emplacement sans aucune vergogne pour le système “train”. Pour le moteur de train, on verra ensuite.

1) Ajout d'un système par “recyclage” d'une ligne du panneau

Nous allons donc substituer les jauges du train à celles du dégivrage :
strdeice_damage_status_txt.xml : affiche sur le panneau l'image “damage”, on garde!
strdeice_health.xml : pilote la barre d'usure sur le panneau, on garde!
strdeice_overheat-log.xml : commande l'incrémentation de l'usure, inutile, on jette!
strdeice_repair_txt.xml : remet à zéro le compteur d'usure si on clique sur “repair”, on garde!
strdeice_txt.bmp : intitulé de la zone du panneau, on garde!
strdeice_txt.xml : affiche l'image ci-dessus, on garde!
strdeiceoverheat.xml : modélise la casse du dégivrage, inutile, on jette!

On commence par renommer les jauges en remplaçant strdeice par gear. On peut ausi corriger le nom de chaque jauge dans l'en-tête <Gauge Name=...>.
Dans ces jauges, on voit apparaître des (A:GENERAL ENG1 COMBUSTION, bool) ! -(A:SIM ON GROUND, bool) && … Ces conditions permettent d'activer le panneau de maintenance uniquement si l'avion est au sol, moteur éteint, etc.

gear_txt.xml : facile, on remplace strdeice_txt.bmp par gear_txt.bmp

gear_damage_status_txt.xml : cette jauge affiche l'image “damage” (= casse) si le seuil de casse est dépassé, ou l'image “health” sinon. Ce seuil est celui qui apparait dans la jauge -d.xml. Pour le train, c'est donc lorsque L:GEAR dépasse les 1000. On modifie donc la ligne 6 de la jauge comme en remplaçant les L:DEICETEMP par L:GEAR et :

if{ (L:CHECKA, bool) } if{ (L:GEAR,number) 1000 > } </Value>

gear_health.xml : la barre de santé translate en fonction de la valeur d'usure. L:GEAR varie entre 0 et 1000, il faut donc corriger les valeurs des points de <Nonlinearity> en prenant exemple sur flaps_health.xml par exemple.

Pas besoin de changer eng1_health.bmp, l'image de la barre de santé est la même pour tous les systèmes.

Le décalage (<Shift>) intervient entre 0 et 1000, corrigeons également <Value Minimum="0" Maximum="205"> en <Value Minimum="0" Maximum="1000">

Et dernier point, c'est bien L:GEAR qu'on prend en compte, la fin de la ligne 23 devient donc :
if{ (L:CHECKA, bool) } if{ (L:GEAR,number) }

gear_repair_txt.xml remet l'usure à zéro. On remplace simplement tous les L:DEICETEMP par L:GEAR en ligne 11. Je crois d'ailleurs que le dernier signe doit être une } et non une )

if{ 0 (>L:DEICETEMP,number) (>K:SIM_RESET) }

Une dernière jauge doit être mise à jour, c'est maintenace.xml (avec la faute de frappe). Elle répare tous les systèmes en un clic, mais uniquement si elle connait les systèmes en question.
On se contente de rajouter un (>L:GEAR, number) à la longue liste des variables d'usure à réinitialiser.

Les infos sont maintenant prêtes à être affichées sur le panneau de maintenance.
Les coordonnées d'affichage des images, barre de santé, etc sont fournies dans le panel.cfg.
Nous avons “volé” le créneau du dégivrage, on regarde donc les lignes gauge77 à gauge80 de la section [Window03], et on substitue gear à strdeice sur les 4 lignes.
Sous [Vcockpit01], les jauges gear-d.xml et gear-d-log.xml doivent aussi être déclarées à la place des strdeice (si ce n'est pas déjà fait).
Allons tester notre modif sous FSX.
Je crois que nous avons oublié un point. Et oui, pas de système “Gear”, il est toujours écrit “deice” sur l'image gear_txt.bmp! Le fichier peut être très facilement retouché avec Paint ou GIMP. La police est Arial taille 16, couleur 464646.
On en profite d'ailleurs pour créer un fichier gearmotor_txt.bmp avec comme texte “Landing Gear Motor” de la même manière.

Tout va mieux sous FSX.

2) Ajout d'un système à une ligne vierge du panneau de maintenance

Il nous reste à loger le moteur du train dans le panneau de maintenance, mais, gros problème, toutes les cases sont pleines.
La solution consiste donc à rajouter des cases! Il va falloir pour cela agrandir un peu le fond du panneau c'est-à-dire le fichier chkmain.bmp directement présent dans le dossier panel.
Paint peut suffir pour cet exercice :
- on attrape la poignée (le petit carré blanc) en bas au milieu de l'image
- on tire vers le bas pour rajouter de l'espace blanc
- on copie-colle la dernière ligne, qu'on déplace pour la faire rabouter proprement
- on reprend la poignée médiane inférieure, et on la remonte jusqu'à tangenter le cadre
Notre panneau fait désormais 320x849px.

La taille du panneau a été modifié, il faut mettre à jour les informations de l'en-tête de la section [Window03] du panel.cfg :

[Window03]
file=chkmain.bmp
size_mm=320,849
window_size_ratio=1.000
position=0
visible=0
ident=90
render_3d_window=0
window_size= 0.320, 0.849
window_pos= 0.060, 0.060
update_rate=1

Ca y est, le panneau est prêt à accueillir notre dernier système, pour lequel nous allons créer les jauges d'affichage/réparation selon la même méthode que pour le recyclage d'une ligne au 1).
On copie les 4 jauges gear_txt.xml, gear_damage_status_txt.xml, gear_health.xml et gear_repair_txt.xml, qu'on renomme en gearmotor... puis on effectue le travail d'adaptation décrit plus haut, y compris pour maintenace.xml.

Il ne reste plus qu'à déclarer ces 4 nouvelles jauges dans la section [Window03] du panel.cfg.
Mais cette fois-ci, il va falloir faire attention aux chiffres derrière le nom de la jauge.
Le SDK nous apprend que ces 4 chiffres “XYWH” sont en fait les positions X,Y de la jauge sur l'image de fond, puis la largeur (width) et la hauteur (height) de la jauge elle-même. Le tout en pixels.
Les X ne seront pas modifiés, il nous suffit de savoir la hauteur d'une ligne. En mesurant sur chkmain.bmp, je trouve 51 px.
On peut donc recopier les 4 lignes de jauges gear, puis rajouter 51 px aux valeurs Y des 4 jauges gearmotor :

gauge83=Damage_Mod_AT802F!gearmotor_txt, 4,801,100,24
gauge84=Damage_Mod_AT802F!gearmotor_health, 4,825,100,14
gauge85=Damage_Mod_AT802F!gearmotor_damage_status_txt, 108,805,70,14
gauge86=Damage_Mod_AT802F!gearmotor_repair_txt, 106,824,74,21

On vérifie que les jauges d'usure et de casse (gear-d.xml, gear-d-log.xml, gearmotor-d.xml et gearmotor-wear-log.xml) sont elles aussi bien déclarées dans la section [Vcockpit01], et on peut aller contrôler son boulot dans la simu!
Bon, je sais , les jauges gearmotor ne sont pas parfaitement bien en place. Un peu d'ajustement sur les valeurs Y du XYWH et tout rentrera dans l'ordre.

Tout marche? Parfait! Quelque chose ne va pas? Dites-le sur ce fil, je vais aussi faire le SAV!

La toute dernière étape consiste à faire le ménage si on le souhaite, en recompilant le dossier Damage_Mod en CAB. Pour ce faire, il faut avoir installé le SDK, copier le fichier SDK\SimObject Creation Kit\Cabdir SDK\cabdir.exe, et le coller dans le dossier panel.
Un glisser-déposer du dossier Damage_Mod sur ce fichier cabdir.exe va lancer la création du CAB.
Pas la peine modifier les déclarations dans le panel.cfg, FSX retrouve très bien son chemin.
On peut au préalable supprimer les gauges inutiles, c'est à dire celles qui n'apparaissent pas le panel.cfg.

Et c'est avec ces CAB que je termine ce tuto un peu long, mais aussi précis et exhaustif que possible. Je l'espère en tout cas. Comme dit plus haut, si des points ne sont pas explicites, n'hésitez pas à faire remonter le problème, je vais tâcher de remanier le texte.

Je n'ai pas traité le cas des moteurs à explosion (Ismail Hakki Güzel en propose plusieurs) et des turboréacteurs (pas de modèle pour celui-ci), mais les principes restent les mêmes, seuls les noms des variables surveillées changent.
Et comme je l'ai dit plusieurs fois, les valeurs des seuils ne sont pas gravées dans le marbre et sont librement adaptables à vos goûts ou vos attentes. Il ne faut pas se casser la tête non plus, des estimations sont suffisantes en l'absence de données "grandeur". Et de toute façon, on fait ça pour s'amuser. C'est là l'essentiel, il ne faut pas l'oublier!

---------- /// *** \\\ ----------

Vous en savez désormais autant que moi sur ces DamageMods. Ils sont certes un peu compliqués, mais avec un peu de patience et de persévérance, tout le monde peut s'en fabriquer un sur mesure pour son appareil favori.

Un grand merci à Ismail Hakki Güzel d'avoir partagé sa trouvaille, et à Lagaffe qui a initié ce sujet et dont le Ti'Bush m'a fait tomber dans le bain des jauges! Et merci à vous de m'avoir lu jusqu'au bout!

PS : J'ai corrigé certains points de mes commentaires précédents, n'hésitez pas à tout relire (ça fera rentrer le tout dans la tête!)

Dernière modification par Kekelekou (06-10-2016 16:33:04)

Lagaffe · [↑]

Bonjour,

Puisque je t'ai fait tombé dans la marmite, je t'en propose encore une autre ... toujours sur le même sujet, mais cette fois çi cela portera sur les simus 32 ou 64 bits

On a vu que la plupart des jauges 32 bits de Doug Dawson sont des fichiers *.gau sauf en ce qui concerne le fule qui est déjà un *.dll.
Pour ce qui est des jauges portées sur l'environnement 64 bits: elles sont toutes au format dll.

Quand on intègre un Damage Mod sur un avion et que l'on veut utiliser cet avion sur les deux types d’environnement: on se retrouve coincé avec l'obligation de recommencer tout le travail et de gérer deux avions. Avec ce que je vais vous expliquer, on pourra ne gérer qu'une archive correspondant à un seul avion mais qui pourra être utilisé sur les deux environnements avec un minimum de manipulations: un renommage d'un seul fichier !

Premièrement, il faut savoir que les jauges de Doug peuvent être renommées de manière à calquer le nom de son appareil.
Secundo, dans ce cas, il faut renommer de la même façon le fichier ini pour qu'il corresponde au nom du fichier jauge.
Tertio, il faut stocker ce fichier ini et préciser sa localisation dans les déclarations du fichier panel.cfg.

Et c'est là que l'astuce apparaît:
- si le fichier jauge et le fichier ini sont placés dans le même répertoire, il n'est pas nécessaire de donner cette fameuse localisation, le fichier jauge le trouve tout seul, comme un grand.

Donc on va créer un répertoire panel\Configs dans lequel on va déposer tous les fichier jauges utilisés en 32 et en 64 bits plus leurs fichiers d'initialisation. Bien entendu il faudra renommer cela comme indiqué au début pour bien "séparer les pommes et les poires".
En prenant l'exemple du C150, cela nous donne cela:

Config_x32.gau ....................... pour le fichier dsd_xml_config.gau qui gère en 32 bits la sauvegarde des données calculées du Mod
Config_x32.ini ......................... pour son fichier ini qui lui correspond
Config_x64.dll ....................... pour le fichier dsd_p3d_xml_config_x64.dll qui gère en 64 bits la sauvegarde des données calculées du Mod
Config_x64.ini ......................... pour son fichier ini qui lui correspond
Fuel_x32.dll .......................... pas besoin de faire un dessin, vous devez avoir compris
Fuel_x32.ini
Fuel_x64.dll
Fuel_x64.ini

Il nous reste la gestion du son qui lui va aussi bénéficier d'un répertoire particulier pour y mettre le fichier jauge, le fichier d'ini, les sons et le fichier XML de gestions des sons: faisant la correspondance entre un évènement du simulateur et le son à jouer suite à cet évènement.

Sound_x32.gau ....................... pour le fichier dsd_xml_config.gau qui gère en 32 bits la sauvegarde des données calculées du Mod
Sound_x32.ini ......................... pour son fichier ini qui lui correspond
Sound_x64.dll ....................... pour le fichier dsd_p3d_xml_config_x64.dll qui gère en 64 bits la sauvegarde des données calculées du Mod
Sound_x64.ini ......................... pour son fichier ini qui lui correspond
KeyEvent_SND.xml .................. pour gérer la correspondance entre un évènement et un son

Maintenant, tout va se jouer dans le fichier Panel.cfg qui va être modifié comme suit pour un Prepar3D 64bits:

// Doug S. Dawson files -----------------------------
gauge54=Sounds/Sound_x64!Sound, 0,0,20,18
gauge55=Sounds!KeyEvent_SND, 0,0,1,1
gauge56=Configs/Fuel_x64!Fuel_dump, 2,2,2,2
gauge57=Configs/Config_x64!Config, 94,268,20,20

On voit qu'il n'y a plus besoin de localiser les fichier ini et de UN, c'est propre et rangé et de DEUX ... et cerise sur le gâteau, si on modifie très légèrement cette déclaration comme cela (voir les parties en gras):

// Doug S. Dawson files -----------------------------
gauge54=Sounds/Sound_x32!Sound, 0,0,20,18
gauge55=Sounds!KeyEvent_SND, 0,0,1,1
gauge56=Configs/Fuel_x32!Fuel_dump, 2,2,2,2
gauge57=Configs/Config_x32!Config, 94,268,20,20

Et là on a un Panel.cfg qui marche pour FSX en 32 bits ou les version Prepar3D v1.x, v2.x, v3.x

Si on ne fait donc qu'une archive pour notre avion, archive pour presque tous les simus d'origine FSX et pour un surplus en taille de moins de 500 ko ... qui dit mieux ? French-VFR vous rembourse la différence si vous trouvez mieux aillieurs !

Pour passer d'un avion FSX à un avion P3D v4, il suffira de renommer le fichier panel_x32 ou panel_x64 en panel.cfg.

Voilà une astuce à 10 sous qui m'a pris quand même plus de 3 semaines de modifications et d'essais avant d'arriver à ce résultat tout simple. Certains diront: suffisait d'y penser

Kekelekou · [↑]

Merci pour les explications Lagaffe! Les créateurs n'ont vraiment plus aucune excuse pour ne pas faire frire leur moteur!

Lagaffe · [↑]

Le seul souci ... c'est que les créateurs sont un espèce en voie de disparition.

Vu le peu d'intérêt que ces posts suscitent, à part Bernard, Gaston, Micpni, Pierrot, Papy Daniel, Cro, toi et quelques autres la plupart attendent avec impatience les produits à 100 brouzoufs pour se ruer dessus et n'ont que peu à faire des "bidouilleurs". Et pourtant ...

Et pourtant, je te parie que si je publiais quelques screens sur mon dernier projet en cours, un vieux trucs que j'ai exhumé ce week-end pour m'aérer l'esprit, on aurait une remontée en flèche de cette rubrique. Mais bon, c'est comme cela.

En tout cas, cette "bidouille" fonctionne très bien dans le temps et j'ai même essayé de la souffler aux oreilles de Milton Shupe pour ces derniers avions en cours de portage sur FSX/P3D mais pas de retour.

Bon, tant pis je retourne à mes vertex et mes pixels sur mon Gadjet en cours.

Bobonhom · [↑]

Eh Oh, moi les avions à 100 Balles non merci...

Alors dépêche toi de nous faire un bijoux patron

Dernière modification par Bobonhom (03-09-2017 20:31:13)

pierrot78 · [↑]

Ne dis pas ça, Bô, il va partir à fond sur son "Gadjet" et on va attendre des lustres le TiBush 64 ! :)
Je me suis amusé à lui remettre nos anciennes textures, c'est cool et ça ne coûte pas un rond, en plus : c'est tout de la gratte de fonds de tiroirs

[img align=c]http://nsm07.casimages.com/img/2017/09/03//17090306342015745615253196.jpg[/img]

Bobonhom · [↑]

Moi présentement, je peux attendre étant donner que mon simu est dans les cartons

Après, je descend personnellement lui botter les fesse en France, je suis sûr qui aimerait trop ça

Lagaffe · [↑]

Bonjour,

Je relance ce sujet pour vous alerter de deux nouvelles version du gestionnaire de son :

pour FSX : dsd_fsx_xml_sound, v5.3.2, December 17 2018
A gauge which plays sounds based on commands received from XML gauges. This gauge will allow XML gauge programmers to add sounds to their FS9 and FSX projects. Now includes support for Windows known folders, as well as muting sounds when FS loses focus. It does presume a fair degree of XML knowledge, and is not for beginners. Freeware

pour P3D: dsd_p3d_xml_sound_x64, v1.2.1, December 16 2018
A 64 bit gauge which plays sounds based on commands received from XML gauges. This gauge will allow XML gauge programmers to add sounds to their P3Dv4 projects. In order to better support Lockheed Martin’s desire that we not install add-ons in the P3D folder structure, it now supports Windows known folders, in addition to following P3D’s Mute On Lost Focus option. It does presume a fair degree of XML knowledge, and is not for beginners. Freeware.

source: https://www.fsdeveloper.com/forum/threads/sound-gauges-updated.444341/#post-812783

Pour ce qui est des liens de téléchargement, je vous renvoi sur le site de Doug: https://www.douglassdawson.ca

Dernière modification par Lagaffe (19-12-2018 13:20:25)

#26 [↑][↓] 29-09-2016 13:40:34

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#27 [↑][↓] 29-09-2016 14:50:50

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#28 [↑][↓] 29-09-2016 14:54:41

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#29 [↑][↓] 03-10-2016 13:53:47

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#30 [↑][↓] 04-10-2016 09:44:20

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#31 [↑][↓] 04-10-2016 11:15:43

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#32 [↑][↓] 04-10-2016 13:57:31

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#33 [↑][↓] 04-10-2016 15:53:31

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#34 [↑][↓] 06-10-2016 16:23:18

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#35 [↑][↓] 27-08-2017 17:02:47

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#36 [↑][↓] 03-09-2017 09:25:58

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#37 [↑][↓] 03-09-2017 10:38:51

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#38 [↑][↓] 03-09-2017 14:11:38

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#39 [↑][↓] 03-09-2017 17:08:27

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#40 [↑][↓] 03-09-2017 20:33:48

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

#41 [↑][↓] 19-12-2018 12:52:31

Re : [P3D][FSX] Les Damage Mod d'Ismael Hakki Güzel à la loupe

Pied de page des forums