Douglas DC-3 C-47 (part 1/2)

ho t'a raison patten elle est trop grosse, par contre ça va etre un merdié sans nom pour le redimentionné

Voilà les commandes de train et volets.
J'ai hésité a tout rassembler dans un seul fichier 3d avec la console centrale, mais il faudrait .png de 1024/1024.(au lieu de 2x 512/512)
Ca permettrait d'augmenter la précision de certains détails, d'un autre côté ces accessoires sont moins visibles en vol que le tableau de bord, qu'en pensez-vous?

http://dl.free.fr/ccXcIVXdC

Amicalement.
ps:

........je n'ai jamais créé de propriété d'ailleurs. Faut vraiment que j'apprenne à utiliser le nasal moi

Point besoin de nasal pour créer une prop, Alexis.

Ça m’intéresse ça de créer des propriétés, vous pourrez poster la démarche que vous avez fait ?

Ça m’intéresse ça de créer des propriétés, vous pourrez m'expliquer à moi aussi ?

Effectivement pas besoin de Nasal pour créer une propriété, cependant Nasal le permet

Comment créer une propriété en Nasal
Actuellement de plus en plus d'appareil dispose d'un fichier Nasal situé dans le dossier Nasal et portant le nom de l'appareil. On peut le voir avec le DC3 (Nasal/dc3.nas), le P92 (Nasal/p92.nas), le R44 (Nasal/r44.nas)
C'est dans ce fichier Nasal que l'on va ajouter une ligne, pourquoi ? et bien car c'est LE fichier nasal qui concerne l'appareil, il ne serait pas logique de créer une propriété "recognition-lights" dans un fichier Nasal qui gère le Dual Control ou les parachutiste par exemple.
Donc je vais partir sur le P92, imaginons que l'on veuille une propriété qui passe à True lorsque l'on a cliqué sur un interrupteur et qui contrôle les lumières de reconnaissance.
On souhaite donc créer la propriété controls/lighting/recognition-lights
En ouvrant le fichier Nasal/p92.nas on va rajouter la ligne ci-dessous au début du fichier :

Code:


props.globals.initNode("controls/lighting/recognition-lights", 0, "BOOL");


Avec ce cette ligne on vient de dire de créer la propriété "controls/lighting/recognition-lights", de mettre la propriété à 0 ( = False) et que cette propriété est une propriété Booléenne (Vrai ou Faux, True ou False, 1 ou 0).
Ensuite si l'on veut modifier cette propriété avec du Nasal il suffit d'écrire ceci :

Code:


props.globals.getNode("controls/lighting/recognition-lights").setBoolValue(1);


Et voilà on vient de mettre la variable à 1 ( = True)

Comment créer une propriété en XML :
Et bien c'est encore plus simple en fait ! En gardant l'exemple de nos lumières de reconnaissance. Nos lumières sont géré par un XML, jusque là on est tous d'accord. Et bien dans ce XML on indique quelle propriété va contrôler nos lumières. Dans le cas de nos lumières de reconnaissance on a ceci :

Code:


  <animation>
    <type>select</type>
    <object-name>Light</object-name>
    <condition>
      <and>
        <property>controls/lighting/recognition-lights</property>
        <greater-than>
          <property>systems/electrical/volts</property>
          <value>8</value>
        </greater-than>
      </and>
    </condition>
  </animation>


Cette petite partie du XML nous dit que pour que la lampe s'allume il faut que la propriété "controls/lighting/recognition-lights" soit à 1 ( = True) et que la batterie délivre plus de 8 Volts. À partir de maintenant la propriété sera créer automatiquement au lancement de FlightGear mais il manque 2 informations : le type et sa valeur par défaut, pour définir ces 2 informations il suffit de déclarer explicitement la propriété dans le XML de l'appareil (*-set.xml ou *-base.xml) en ajoutant ceci :

Code:


<controls>
  <lighting>
    <recognition-lights type="BOOL" value="0"/>
  </lighting>
</controls>


Bien entendu pour cet exemple la création de la propriété en Nasal est strictement inutile étant donné qu'elle est déjà créer pendant le chargement de l'avion au lancement de FlightGear mais c'était pour l'exemple.

Amicalement,
Clément

En xml n'est il pas plus élégant de déclarer les props dans base (ou set).xml

Code:


<controls>
 <lightning>
  <recognition-lights  type="bool">false</recognition-lights>
ou
  <recognition-lights  type="bool" value="false"/>
 </lightning>
</controls>


ainsi on lui attribue un type bien défini et une valeur de départ, ce qui élimine toute ambiguité et
économise et temps et mémoire.(ce qui est fait en nasal aussi)
Et on rejoint cette citation du Wiki:
http://wiki.flightgear.org/Property_Tree/Explained

When creating your own properties, it is generally considered good practice to chose the most suitable data type, as well.
It is important to keep in mind that storing a property without its type (i.e. untyped), will inevitably result in a conversion being performed somewhere to convert the data to a non-string representation.
So, to avoid unnecessary performance penalties it's always a good idea to also define valid types for your properties.
Likewise, using the proper access means to avoid unnecessary conversions, is also important.

Amicalement.

oups, oui tu as raison F-Sig, j'ai oublié l'assignation du type. D'ailleurs c'est bien ce que j'ai fait pour le DC3, une erreur d'inattention

Code:


    <lighting>
      <passing-lights type="bool" value="0" />
      <running-lights type="bool" value="0" />
      <tail-lights type="bool" value="0" />
      <cabin-lights type="bool" value="0" />
      <recognition-lights n="0" type="bool" value="0" />
      <recognition-lights n="1" type="bool" value="0" />
      <recognition-lights n="2" type="bool" value="0" />
      <compass-lights type="bool" value="0" />
      <formation-lights type="bool" value="0" />
    </lighting>


Je corrige mon post précédent pour ajouter ta correction.

Amicalement,
Clément

voila : bonne immat et porte à la bonne taille
http://dl.free.fr/mon.pl?i=13523796&h=jZOsOJMz

bibi a écrit:voila : bonne immat et porte à la bonne taille
http://dl.free.fr/mon.pl?i=13523796&h=jZOsOJMz

Ton lien ne fonctionne pas chez moi:

Session inexistante??

Sinon, j'avais çà immat amovibles sur calques, portes et charnières à la bonne taille et au bon endroit:

ah oui bizarre pour le lien,à priori tu as fait mieux que moi donc je ne réactualise pas

bibi a écrit:ah oui bizarre pour le lien,à priori tu as fait mieux que moi donc je ne réactualise pas

??

Donc c'est là:


http://download939.mediafire.com/38n72xcahikg/qig487dz84y78cr/Pack+livr%C3%A9e+pour+BIBI.zip

donc voilà le nouveau pack avec les 2 xml les 2 png et le .xcf, merci a patten pour la correction de mes erreurs ^^
voici le lien http://dl.free.fr/getfile.pl?file=/fVqseMp4

Bonsoir à tous,

@F-Sig: Peux-tu fournir ton fichier "Models/Interior/Panel/panel.xml" car j'imagine que c'est dans ce fichier que tu as mis les coordonnées du "gear-flaps.xml"
@bibi: le fichier "intra.xcf.gz" que tu fournis pèse 13,6 Mo ce qui fait beaucoup, les autres fichier *.xcf.gz ne pèse que 1Mo à 1,6Mo. Pourrais-tu supprimer voir comment réduire le poids de ce fichier ?

Je sais pas vous mais moi j'avais un peu perdu le fil avec toutes ces mises à jour^^ Actuellement, à ma connaissance, on a
F-Sig qui travaille sur le pedestal et ses alentours
bibi qui travaille sur les liveries
patten qui travaille sur les textures de la cabine passager
helijah qui travaille sur le pas variable des hélices
Alexis qui travaille sur le tableau de bord
Moi qui se tourne les pouces !

La dernière version "stable" date du 05/09/2011, nous avons plusieurs mise à jour publié depuis cette date. La question est "Quels travaux attends-t-on avant de fournir une nouvelle version stable ?" le fait de fournir des versions stables régulièrement devrait beaucoup moins effrayé les nouvelles personnes qui souhaiterai participer au développement mais qui sont perdu avec toutes ces mises à jour. D'ailleurs, Emmanuel, lorsque tu annonces un version stable, peux-tu l'écrire en gros et rouge afin qu'on puisse la voir facilement au milieu de ces centaines de messages !

N'hésitez pas à aller voir cette page : http://wiki.flightgear.org/Fr/Douglas_DC-3-C47 vous verrez alors les choses qu'il reste à faire si vous voulez mettre les mains dedans

Amicalement,
Clément

F-JJTH a écrit:Bonsoir à tous,


patten qui travaille sur les textures de la cabine passager

Moi qui se tourne les pouces !

N'hésitez pas à aller voir cette page : http://wiki.flightgear.org/Fr/Douglas_DC-3-C47 vous verrez alors les choses qu'il reste à faire si vous voulez mettre les mains dedans

Amicalement,
Clément

Accessoirement, afin de ma laver un peu les pupilles, je bidouille un peu les sons, afin de trouver un son de démarrage réaliste en attendant que Baboon revienne

Une petite livrée en cours aussi.

Çà m'étonnerait que tu te tourne les pouces.

Si c'est le cas, trouve moi ou fais moi des fauteuils d'avion années 30, ceux que tu as vu n'ont pas d'accoudoirs, çà fait salon de thé

F-JJTH a écrit:
@F-Sig: Peux-tu fournir ton fichier "Models/Interior/Panel/panel.xml" car j'imagine que c'est dans ce fichier que tu as mis les coordonnées du "gear-flaps.xml"

Oups, j'ai oublié ça dans le patch:

Code:


<!--Commandes Gear + Flaps-->
 <model>
    <path>Aircraft/Douglas-Dc3/Models/Interior/Panel/Pedestal/gear-flaps.xml</path>
    <offsets>
      <x-m> -0.06 </x-m>
      <y-m>  0.00 </y-m>
      <z-m>  0.01 </z-m>
    </offsets>
  </model>


a copier dans "Models/Interior/Panel/panel.xml"

Amicalement.

Ce que je vous propose c'est de sortir la version stable aux alentours du 25 septembre, c'est à dire dans deux semaines. Je dis ça car j'ai presque achevé le tableau de bord, il est possible que je le termine en fin de semaine, mais il est beaucoup plus probable que ça se termine fin de semaine prochaine ! Je pense qu'en 2 semaines, tout le monde aura terminé, corrigé d'éventuels bug, ajouté le plus de détails possibles ect... Qu'en dites-vous ? ça fait un peu comme les dev de FG qui travaillent suivant des cycles de 6 mois (pour sortir 2 versions stables par ans).

Pour reprendre ce que dit clément, n'hésitez pas à vous rendre sur la page http://wiki.flightgear.org/Fr/Douglas_DC-3-C47 et à la compléter avec des info, d'ajouter des choses dans la todolist et de vous en attribuer d'autres..

Si dans la prochaine version on a un cockpit bien avancé, de belles livrés, un compartiment passager bien foutu, il va sérieusement falloir commencer à annoncer ça sur les sites anglophones (newsletter, forum ect...) et pourquoi pas comme le dit helijah contacter les éditeurs de magazines comme micro sim. Après tout, je crois bien que cet avion est une première dans tous les simulateurs confondu, je ne crois pas que dans FS ou X-plane, on puisse embarquer des passagers réels. Vous imaginez un peu une page entièrement dédiée à notre DC3 ! quel coup de pub pour FG et notre forum !

Bon moi j'ai du raté une mise à jour.... ou alors je n'ai pas la procédure, mais ici impossible d'allumer les feux de positions et tout ce qui est lumière extérieur d'ailleurs

Amicalement Emmanuel

Alexis a écrit:
Si dans la prochaine version on a un cockpit bien avancé...

A condition que:

Alexis a écrit:

Alors pour les soucis d'UVmap, il va falloir mettre les choses au point, se faire une petite ligne de conduite : Toujours se mettre d'accord sur le fait que les UVmap sont achevées et optimales avant de s'attaquer aux textures, sinon c'est le bordel comme on vient de le voir. On ne fait pas la peinture avant d'avoir posé le placo alors on ne texture pas avant les UVmap définitives !

On en est où avec les UVmap cockpit?.

"Chat échaudé craint l'eau froide".

De mon coté patten, ce que j'ajoute maintenant sera en plus et ne viendra pas modifier les UV Map existant

Ok, parfait Emmanuel, on part sur quels tons de teinte Alexis?

Ton tableau il est de quelle couleur?.

Nan parce que j'ai des pots de peinture entammés, faut pas gâcher .

Pour vous montrer la tête ça aura, voilà une photo prise rapidement dans FGrun :


Sinon je vous passe le fichier png et le xcf, ça sera plus pratique si on veux utiliser les mêmes teintes (surtout pour le panneau supérieur) : http://dl.free.fr/getfile.pl?file=/qaMXdvD0

Voilà, je vais probablement pas pouvoir me reconnecter avant vendredi soir. Êtes-VOUS ok pour sortir la version stable le 25 ?, le temps de faire la chasse aux bug et imperfections...

@++

@Emmanuel : Je suis à jour donc je te fournirai ma version
@F-Sig : Merci pour le petit bout de code ! J'ai donc pu admirer ton travail, c'est magnifique ! toujours de grande qualité je suis bluffé !
Les leviers sont animés mais pas (encore) cliquable, je pense que pour les rendre cliquable on peut utiliser le même principe que les leviers de gaz, c'est à dire : une zone pour augmenter les flaps, une zone pour les réduire. Pour rendre cliquable le levier des trains d'atterrissage on a qu'à faire simple : ON/OFF à l'aide d'un petit "property-toggle" sur la propriété "controls/gear/gear-down" et pis c'est tout Tu peux te charger de ça ?
J'ai vu aussi que tu avais animé le levier qui semble gérer la pression du circuit hydraulique. J'ai très peu d'information sur le fonctionnement de l'hydraulique... J'imagine qu'il fallait pomper à l'aide de ce levier pour amorcer/mettre en pression le circuit hydraulique, une fois le circuit hydraulique sous pression il était alors possible de sortir/rentrer le train d'atterrissage. Je crois aussi que les Flaps était contrôlé par le circuit hydraulique. J'imagine alors qu'on avait besoin de différente pression selon ce qu'on voulait faire du genre :
4 mouvements de pompage = 15 Psi = assez de pression pour ajouter ou enlever 1 cran de volets
8 mouvements de pompage = 30 Psi = assez de pression pour ajouter ou enlever 2 cran de volets
[...]
16 mouvements de pompage = 60 Psi = assez de pression pour rentrer ou sortir le train d'atterrissage (genre on pompe 16 fois = on peut rentrer le train ensuite si on veut ressortir le train il faut à nouveau pomper 16 fois)

A chaque action la pression redescend, et si on veut rajouter 1 cran de volets par exemple et bien il faut repomper 4 fois. Bon après je dis ça mais j'y connais rien, c'est juste comme ça que j'imagine que ça fonctionne. Si vous en savez plus dites-le

Si tel est le fonctionnement : le simule-t-on ? ou bien oublions-nous le système hydraulique afin que l'avion soit utilisable par les "non initié" ?
Moi ça me dérange pas de simuler l'hydraulique

@Alexis : Je pensais à fournir une version stable un peu plus tôt mais uniquement pour les quelques personnes qui développe afin d'être sur que nous travaillons tous sur la même base. On ne doit pas parler de la même version "stable" Par contre je suis d'accord avec toi d'attendre le 25 Sept pour sortir une version stable "Grand Public" ce qui permet, comme tu le soulignes, de rendre nos derniers travaux et de corriger les quelques bugs.

@patten : le cockpit semble encore un sujet "sensible" lol, je veux dire par là qu'il a été précédemment aborder le sujet des rebords de fenêtre, du matelas qui doit être très légèrement raccourcis pour ne pas venir recouvrir les rebords de fenêtres... etc Je pense qu'il faut discuter de tout ça sur la chatBox du forum... on prend RDV !? Ce soir 21h ? (tout le monde est invité à participer et donner son avis !)

Amicalement,
Clément

OK pour moi le 25.

OK pour moi 21h ce soir.

Çà n'empêche pas Mumble, à priori Emmanuel nous entend il me semble...

euuuh je viens de relire mon message donc pour éviter tout malentendu : quand j'écris "(encore)" en parlant des zones cliquable c'est dans le sens "c'est pas fait mais ça va l'être rassurez-vous" et non pas "encore une fois c'est pas cliquable non de dieu". Avec les écrits on arrive pas toujours à donner le ton qu'on veut

Amicalement,
Clément

Juste une parenthèse pour vous dire bravo pour votre organisation et pour vos avancés. Un très grand bravo.
Bon courage à tous.