RobinDR-400 jsbSim 120cv

@Christian: Le résultat sera exactement le même que sur le DC-3. Il faudra juste choisir si par défaut les détails sont chargé, ou pas... La décision va être difficile !

Je fais les modifs sur GIT, dans un premier temps je pars du principe que les détails ne sont pas chargé par défaut juste pour voir si il y a une différence (mais bon avec nos machines un peu puissante j'ai bien peur que ni toi ni moi ne voyons la moindre différence.) Ensuite ce sera juste un 0 à remplacer par un 1

PS: le fichier "sauvegarde_dr400.ac" il sert encore à quelque chose ?

Très difficile, Patten, de répondre à ta question car cela dépend de ce que l'on attend de l'avion.....
Moi, par exemple, je ne m'intéresse qu'au pilotage donc tout ce qui concerne l'extérieur du cockpit pourrait disparaître au profit d'un FDM et d'un intérieur super réalistes. Mais je comprends parfaitement que d'autres soient attirés par le graphisme!
L'idéal serait de créer deux modèles, voire trois pour ceux qui veulent à la fois le réalisme graphique et le comportement élaboré... en payant le prix en MO.
JM

Pour cerner le soucis, il faut bien distinguer le temps de chargement, et des fps bas qui nuisent au vol.

Concernat le temps de chargement:
Pour le temps de chargement, je viens de tester à LFLR :
- Le DR400 =28s
- Le DC-3 =20s
- Le B 1900D =18s
- Le DA42 =20s
- Le EC 135 =20s
On chipote pour 8.5s en plus de moyenne.
Si vous voulez bien faire le même test pour voir les écarts de durée de chargement entre chaque avion.

Remarque: c'est sur la partie "loading scenery" que le lanceur reste le plus longtemps lors du lancement.

aco a écrit:Très difficile, Patten, de répondre à ta question car cela dépend de ce que l'on attend de l'avion.....
Moi, par exemple, je ne m'intéresse qu'au pilotage donc tout ce qui concerne l'extérieur du cockpit pourrait disparaître au profit d'un FDM et d'un intérieur super réalistes. Mais je comprends parfaitement que d'autres soient attirés par le graphisme!
L'idéal serait de créer deux modèles, voire trois pour ceux qui veulent à la fois le réalisme graphique et le comportement élaboré... en payant le prix en MO.
JM

Salut JM, j'y ai pensé aussi, un intérieur volant serait peut-être une piste à creuser, dans l'esprit du cockpit 2D du C172P.

patten a écrit:Pour cerner le soucis, il faut bien distinguer le temps de chargement, et des fps bas qui nuisent au vol.

Concernant le temps de chargement:
Pour le temps de chargement, je viens de tester à LFLR :
- Le DR400 =28s
- Le DC-3 =20s
- Le B 1900D =18s
- Le DA42 =20s
- Le EC 135 =20s

A LFLR :

- Le DR400 =à 4min, toujours en "loading scenery
- Le DC-3 =à 4min, toujours en "loading scenery
- Le B 1900D =23s
- Le DA42 =33s
- Le EC 135 =32s

Mais je le redis, hors de question de stopper le développement !!!

Amicalement,

A oui, quand même, 4mn, tu as le temps de faire la check-list.

Bizarre que tes écarts entre chaque avion ne soient pas proches des miens.

Il y a un dr400 sans détails 3d dans Models, tu sauvegardes (ou non) ton dr400.ac, et tu renommes le -sauvegarde_dr400.ac- en -dr400.ac- qui se trouve dan Models, et si tu veux bien nous dire combien de secondes (minutes) tu gagnes...
Sans le GPS, je tombe à 23s.
Le pilote semble assez gourmand aussi (encore que je parle en secondes).

@Christian, j'ai les même résultat à la seconde près et pareil pour la partie "loading scenery"

Sur GIT, les détails sont maintenant séparé de l'avion. Il y a donc un fichier dr400.ac et details.ac
J'ai refait la liste des objets de chaque fichier AC dans les XML, ainsi on peux très exactement savoir quelle objet est dans quel fichier.

La chose est simple, tout ce qui est vis et écrous c'est dans détails.ac tout le reste est donc resté dans dr400.ac (bouchon réservoir, jauge huile, poignées, tringlerie...)
Le fichiers dr400.ac pèse 1,6 Mo
Le fichier details.ac (qui contient uniquement vis et écrous) pèse 5,7Mo

Par défaut les détails ne sont pas chargé, 2 solutions pour les charger :
1 - Ajoutez " --prop:/sim/model/config/details-high=true " dans votre fichier .fgfsrc (c'est comme pour le DC-3 donc si c'est déjà fait pour le DC-3 vous n'avez rien à faire)
2 - Allez dans le menu du DR400-jsbSim et cochez "Details high"

PS: le fichier "dr400_avec_details.ac" est le fichier "original" avant mon intervention.

Je vais mettre en place un système de sauvegarde des paramètres (comme pour le garmin196 et le da42) pour sauvegarder l'état d'affichage des détails.
Si on le souhaite on peut tout à fait passer la tringlerie, les poignées, les bouchons et antenne dans les détails... (personnellement je pense qu'ils sont bien où ils sont actuellement)

Pour ceux qui n'utilise pas GIT vous pouvez tester la version "détails séparé" en la téléchargeant ici : http://clemaez.fr/flightgear/DR400-jsbSim-JM26.tar.gz

Désormais pour modifier le fichiers détails.ac il faut charger le fichier dr400.ac sinon on ne sait pas où on va. Pour cela il suffit d'utiliser les calques de Blender. Comment faire ?
1- Vous ouvrez Blender, puis importez dr400.ac (jusque là c'est comme d'habitude)
2- Vous changez de calque, par exemple calque 2, en cliquant sur la 2ème case de ce truc :
3- Vous importez details.ac puis avec la touche SHIFT vous cliquez sur le calque 1
Et voilà les 2 calques sont visibles et vous voyez dr400.ac ET details.ac, maintenant vous savez où poser les boulons. Attention cependant à créer les boulons dans le calques 2.

Amicalement,
Clément

JM-26 a écrit:

patten a écrit:Pour cerner le soucis, il faut bien distinguer le temps de chargement, et des fps bas qui nuisent au vol.

Concernant le temps de chargement:
Pour le temps de chargement, je viens de tester à LFLR :
- Le DR400 =28s
- Le DC-3 =20s
- Le B 1900D =18s
- Le DA42 =20s
- Le EC 135 =20s

A LFLR :

- Le DR400 =à 4min, toujours en "loading scenery
- Le DC-3 =à 4min, toujours en "loading scenery
- Le B 1900D =23s
- Le DA42 =33s
- Le EC 135 =32s

Mais je le redis, hors de question de stopper le développement !!!

Amicalement,

A LFLR aussi:
-DR400 = 57sec
-DC3 = 45sec
-B1900d= 32sec
-DA42 = 38sec
-EC135 = 32sec

On dirait que Mac digère mal quelque chose dans le Dr400 et le DC3?
Pour les autres j'ai sensiblement les mêmes temps que JM

Amicalement.

Bonjour,

J'ai trouvé le responsable de mon anomalie "1/4 d'image" (voir mon post du 09 avril 15:08). C'est l'appel au fichier Systems/instrumentation.xml. Je dis bien le fichier, pas le KR87 lui-même. Le fichier appelé avec lignes KR87 commentées provoque encore l'anomalie. Son absence d'appel, non (comme auparavant). Ce fichier me semble une manière "tordue" d'appeler le KR87 (puisque tous les autres instruments fonctionnent sans).
Comme je comprends mal la syntaxe et procédure d'appel de ces fichiers dans le -set.xml et associés, je n'arrive pas à trouver de solution alternative. N'y a t-il pas une manière plus simple d'appeler ce satané KR87 (par exemple directement depuis le dr400-base.xml) ? Il fonctionne sans problème dans le Cessna 172P. Je n'arrive non seulement pas à trouver comment faire autrement mais pas non plus à trouver où est le fichier nasal associé. Bizarre...

Commencez par virer l'ancien pilote à coup de pieds au ...

Il fait n'importe quoi de toute manière.

dany93 a écrit:Bonjour,

J'ai trouvé le responsable de mon anomalie "1/4 d'image" (voir mon post du 09 avril 15:08). C'est l'appel au fichier Systems/instrumentation.xml. Je dis bien le fichier, pas le KR87 lui-même. Le fichier appelé avec lignes KR87 commentées provoque encore l'anomalie. Son absence d'appel, non (comme auparavant). Ce fichier me semble une manière "tordue" d'appeler le KR87 (puisque tous les autres instruments fonctionnent sans).
Comme je comprends mal la syntaxe et procédure d'appel de ces fichiers dans le -set.xml et associés, je n'arrive pas à trouver de solution alternative. N'y a t-il pas une manière plus simple d'appeler ce satané KR87 (par exemple directement depuis le dr400-base.xml) ? Il fonctionne sans problème dans le Cessna 172P. Je n'arrive non seulement pas à trouver comment faire autrement mais pas non plus à trouver où est le fichier nasal associé. Bizarre...

Il nous fait suer ce KR87
Bizarre que ça influence l'affichage

Pour te dépanner tu peux copier ces lignes dans ton "data/Aircraft/Generic/generic-instrumentation.xml"

Code:


<KR-87>
        <name>kr-87</name>
        <number>0</number>
 </KR-87>


Et retirer (ou commenter) l'appel dans dr400-base.xml
Ici ça fonctionne.

Ily a 2 KR87 ou plutôt un KR87 et un KR87-adf en circulation.
On a peut-être tiré le mauvais numéro. J'essaierais d'installer le KR87-adf un de ces jours.
c'est celui qui est dans le c172 et le Lancair.

Amicalement.

pour le bug du 1/4 d'écran, si vous ne spécifiez pas de nom de fichier d'instrumentation, fg par défaut utilise:

Aircraft/Generic/generic-instrumentation.xml

ce fichier contient un appel pour le radar, et le bug est présent en cas d'absence de ce radar (le pourquoi on n'en sais rien )

donc si vous faites un fichier d'instrumentation personnalisé, pour ne pas avoir le bug, il suffit d'y ajouter une session pour le radar:

<radar>
<name>wxradar</name>
<number>0</number>
</radar>


pour le temps de chargement, z'avez qu'a en faire une version dds , mais il faut la version png aussi pour ceux qui ne peuvent utiliser le dds, donc avoir des branches, ou faire un script pour exporter la version png en dds.

jano

F-JJTH a écrit:Sur GIT, les détails sont maintenant séparé de l'avion. Il y a donc un fichier dr400.ac et details.ac
J'ai refait la liste des objets de chaque fichier AC dans les XML, ainsi on peux très exactement savoir quelle objet est dans quel fichier.

La chose est simple, tout ce qui est vis et écrous c'est dans détails.ac tout le reste est donc resté dans dr400.ac (bouchon réservoir, jauge huile, poignées, tringlerie...)
Le fichiers dr400.ac pèse 1,6 Mo
Le fichier details.ac (qui contient uniquement vis et écrous) pèse 5,7Mo

Amicalement,
Clément

YOUPI !!!
Temps de chargement pour le DR400 : 29s

Merci

Amicalement,

Tu vois, plus la peine de changer d'ordi.

Ah en voilà une bonne nouvelle !
Il ne reste plus qu'à avoir de bonnes nouvelles de dany (grace aux infos de jano) et on sera à nouveau sur le bon ch'min

Du coup on fait quoi pour le chargement des détails : présent par défaut ou absent par défaut ? Il faut aussi savoir que les détails ne sont jamais chargé en MP. Si jamais quelqu'un active les détails il ne verra que les détails de son appareil. Si vous volez avec quelqu'un qui a activé les détails chez lui, vous ne chargerez pas les détails.

PS: pour info F-EFEL m'a précisé que depuis la dernière mise à jour les instruments (y compris le KR87) fonctionnait parfaitement bien chez lui

Le KR87 fonctionne sans bug d'image !

Merci F-sig pour ce contournement facile et efficace, merci jano pour tes explications (je ne l'aurais pas deviné), merci Clément de te préoccuper de mon sort...

F-Sig a écrit:Il y a 2 KR87 ou plutôt un KR87 et un KR87-adf en circulation.
On a peut-être tiré le mauvais numéro. J'essaierais d'installer le KR87-adf un de ces jours.

Sans doute pas la peine, pas le bon chemin. Je n'ai pas l'impression que le fichier du KR87 soit la cause (voir ma description de la panne plus haut) puisque le bug existe même en éliminant l'appel au KR87 du fichier FlightGear\data\Aircraft\DR400-jsbSim\Systems\instrumentation.xml. C'est l'appel au fichier instrumentation.xml, avec ou sans KR87, qui provoque le bug 1/4 d'image . Ce bug est vraiment bizarre et pas commun, je ne crois pas qu'ils aient cerné la cause ni trouvé de solution dans le bug tracker (juste un contournement).

Dany

Grace à Jano on sait ce qui provoquait le souci de Dany, enfin dans savoir vraiment puisque
la cause reste inconnue et mystérieuse

Je vais essayer de changer de KR87 quand' même, celui du c172P et du Lancair (KR87-adf)
reprend les fréquences de "Radio Settings".(voir quelques posts plus haut)
Comme ça aco sera content aussi

Amicalement.

KR87 échangé! Pushé

Reste un petit problème:
Au chargement le KR87 est allumé.La prop. "instrumentation/adf/power-btn" est "true"
Alors que je la mets à "false" ici:(dans dr400-base.xml, comme pour le KX165)

Code:


  <adf n="0">     
     <power-btn type="bool">false</power-btn>
          <volume type="double">0</volume>
     <adf-btn type="bool">true</adf-btn>
    </adf>
   
</instrumentation>

ces lignes sont bien prises en compte, "adf-btn" est bien mis à "true" au chargement.

Par la suite "power-btn" est gérée correctement, on peut couper par le bouton, par "Autostart"
ou directement dans l'arbre des props.

Je ne trouve pas ce qui la met à "true" au début.
Clément, si tu as le temps de jeter un oeil

Amicalement.

Guillaume a écrit:Oui je vais améliorer la traînée qui est encore trop forte à certaines incidences. Mais comme les photos, pas cette semaine… Vous pouvez le faire si vous voulez, et je peaufinerai quand j'aurai le temps.

Bonjour Guillaume,

J'ai cherché à rendre les virages à inclinaison 60° possibles sans perte d'altitude (pleine charge : env. 1984 lb). Par le "drag due to alpha", je n'y arrive pas, ou alors la finesse devient trop bonne. Cependant, en observant bien, ce n'est pas étonnant : les virages à 52 -55° (60° en diminuant la traînée) se font avec un angle d'attaque d'env. 6.8 - 7° (170 km/h) et la descente gaz coupés (135 km/h) avec 6.8 - 6.9° ==> si on diminue la traînée pour les virages, on améliore forcément la finesse en plané (même angle d'attaque). Or, ta finesse est bonne (10.5 en mesurant la perte d'altitude sur 1 ou 2 mn). Je ne vois pas ce qu'on peut faire sans augmenter la traction de l'hélice.

Question : le DR400 120 Ch réel est-il capable de tenir des virages à 60° à pleine charge (le FDM actuel tient 52 - 55°) ?

Amicalement,

Dany

@F-Sig: le KR87 est désormais éteint au démarrage Ce bug est présent sur quelques instruments. Je lui ai mis un petit coup de Nasal dans la tête et maintenant il obéit au doigt et à l'œil
Ligne 325 et 326 de dr400.nas :

Code:

  setprop("/instrumentation/nav[0]/power-btn",0); #force OFF
  setprop("/instrumentation/adf[0]/power-btn",0); #force OFF

dany93 a écrit:Question : le DR400 120 Ch réel est-il capable de tenir des virages à 60° à pleine charge (le FDM actuel tient 52 - 55°) ?

Personnellement je ne pense pas... 120ch c'est pas énorme, alors si on mets avec 4 personnes à bord je suis vraiment pas certain qu'il tienne ce genre d'inclinaison. Mais bon je dis ça c'est juste parce que j'étais présent lors d'un crash d'un DR400 120ch dans une montagne avec 3 personnes à bord. Le mec était un peu bas, et puis la montagne est devenu un peu plus raide et là il a beau avoir mis plein gaz... à 3 dans un DR400-120 ils sont pas monté... et BOUM^^

F-JJTH a écrit:@F-Sig: le KR87 est désormais éteint au démarrage Ce bug est présent sur quelques instruments. Je lui ai mis un petit coup de Nasal dans la tête et maintenant il obéit au doigt et à l'œil

Ben ouais, faut juste savoir ou mettre le coup

Merci, Clément!

JM-26 a écrit:
Je m'aperçois que le 19 février dernier le fichier "dr400.ac" faisait 1 Mo, et là tout allait bien !
Aujourd'hui, ce même fichier fait 7,7 Mo, et là je m'interroge ... même le dc3 fait presque 4 fois moins.

patten a écrit:On manque de contributeurs, faire la liste de ce que vous voudriez voir disparaître est une contribution et ne nécessite aucune compétence particulière, si quelqu'un veut s'en charger, pas de soucis, le menu du DC3 est génial, moi je traîne les pieds pour défaire ce que j'ai fait pendant des jours et des jours pour vous contenter...

Et comme je te comprends Christian!
Ne prends surtout pas ce qui suit pour une dénigration de ton formidable travail, mais je pense que nous devons
prendre en compte quelques réalités. Et, d'autre part ce serait dommage de se passer de certains détails.
Je vais donc essayer de contribuer

En regardant de près "details.ac" je m'aperçois:
1- il y a une série d'écrous qui ont pas mal de points en double, que l'on peut retirer sans déformation.

2- les "ecrous-prof" ont un diamètre éxterieur de 2-3mm, quand on sait que pour un écrou M3 on a besoin d'une clé de 6 ... , sont'ils vraiment si petits? Et, dans ce cas est il nécessaire de les modéliser ?

3- il me semble que les écrous, par rapport aux têtes de vis, comportent beaucoup de points.
J'ai donc essayé de faire avec moins et je suis passé de 391 à 151 avec je pense, une fois texturés le même résultat visuel. Surtout avec un téxturage de précision "à la patten" ( j'ai pu en apprécier la technicité en prenant ces écrous sous la loupe, chapeau!)



En limitant les points sur de très petits objets on ne perd pas beaucoup en qualité visuelle, et quand ce objets sont répétitifs le gain est évident.

Amicalement.

Bonjour à tous,

Merci Ernest, bonne piqûre de rappel.
je débute dans Blender, et je tâtonne donc, heureusement que tu n'as pas mis le nez dedans lors de la pose des premières vis et et des premiers boulons Nysltop, c'était une tuerie de réalisme, mais plus lourds que des vrais, et puisque la mode est au light...

C'est vrai qu' avec la 3d on se laisse facilement prendre au jeu, et de détailler au maximum est passionnant.

Mais il faut penser à nos pauvres ordinateurs qui doivent animer tout ça

Amicalement.