Vous n'êtes pas identifié(e).
Hello,
Le .cab n'est qu'un format comprimé (comme il y a .zip ou .rar) que sait gérer FS.
Tu peux ne pas comprimer tes fichiers (images et .xml) et laisser simplement ceux-ci dans un dossier au nom du .cab : cela fonctionne exactement comme si ils étaient dans le .cab mais c'est nettement plus simple pour faire tes modifications de code ou d'image (pas besoin de recompiler le .cab)... Personnellement je complie le .cab qu'au dernier moment, pour faire beta tester ceux-ci...
Concernant le ModefDef.xml, oui tu peux fonctionner juste avec les animations nécessaires à ton avion en cours. Il faut alors bien gérer tes sauvegardes pour ne rien perdre au passage... 
Ils avaient prévu une gestion de groupe de gauges afin de s'y retrouver plus facilement, mais je ne m'en sers pas car la déclaration dans les groupes m'a toujours paru pénible avec une manipulation supplémentaire du GUID...
Dernière remarque, si il est très agréable de n'avoir dans le ModelDef.xml que les éléments utilisés dans l'avion en cours (fichier nettement plus réduit), il faut quand même bien générer à chaque fois un nouveau GUID car cela te permettra de faire des copier-coller sans risque à partir de tes ModelDef.xml archivés : le GUID doit impérativement être unique sous peine de plantage!!
A+ et bon courage,
Fro'
Hello Jankees,
Tu es trop fort!!!
=W=W
Merci!
Sylvain
...C'est réussi, j'ai remplacé le panel que j'avais créé par celui d'un avion dont je savais avoir plusieurs portes et BINGO cela fonctionne.
Ok je dois tout refaire correctement maintenant,mais la commande shift/E+n fonctionne...
Content que le problème soit identifié!!
La saturation de FS par un gauge est quelque chose qui peut se produire assez facilement si on n'y prend pas garde: un test mal "protégé" et on se retrouve avec un code qui s'éxecute en boucle 18 fois par seconde!! (cf discussion sur le flooding par ailleurs)
Dans notre cas il semblerait que si une instuction vient s'exécuter entre le "MajE" et le "Select n" alors il devient impossible de faire fonctionner les ouvertures secondaires bien que côté FPS tout apparaisse OK...
Si je devais donner conseiller qq chose à un développeur de gauge, ce serait d'avoir toujours une porte secondaire sous la main pour pouvoir tester les éventuels impacts de son code au fur et à mesure de sa progression... 
(sur l'Etendard, j'ai utilisé la canne de ravitaillement comme étalon...)
En tout cas bon courage à tous!!
Fro'
Hello,
Je ne suis pas sûr de comprendre le pb...
Je proposerais de séparer les sources potentielles de soucis:
- d'un côté l'animation de ton ouverture liée à la variable (A:EXIT OPEN:1)
- de l'autre la gestion du code pour déclencher l'ouverture de cette même porte
Il est important de savoir si c'est l'animation qui pose problème ou la commande.
J'ai déjà eu des problèmes avec "MajE+n" car j'avais une gauge par ailleurs qui me saturait FSX rendant le passage de paramètre "n" impossible et FSX ne voyait alors que Maj+E seul...
Si les porte secondaires sont bien déclarées dans aircraft.cfg, il y a peut-être qq tests à faire du côté d'un flooding... En commençant par enlever toutes les gauges du Panel.cfg par exemple...
A+
Sylvain
Hello,
Concernant la gestion des portes, Pépé, je te conseille fortement de partir avant tout d'avions existants, cela simplifie nettement les tests.
Ainsi, pars , par exemple du bloc [Exits] de l'ETD où tu constateras que seul le 1er paramètre est renseigné: pas de position ni de type de sortie...
Par principe je pars toujours du plus simple en compliquant seulement si nécessaire : dans notre cas, les coordonnées et type semble servir avant tout pour les liners et la gestion des servitudes d'aéroport...
Concernant la question des "Lever", "Switch", etc..., je pense que vous vous compliquez la tâche...
Les noms sont libres et purement indicatif sans aucun impact sur le modèle en dehors de la variable à laquelle FS lie l'animation.
Prenons le cas d'in interrupteur de feux de Nav. Dans le ModelDef.xml, on aura mettons ceci :
<PartInfo>
<Name>switch_nav_light</Name>
<AnimLength>50</AnimLength>
<Animation>
<Parameter>
<Sim>
<Variable>LIGHT NAV</Variable>
<Units>bool</Units>
<Scale>50</Scale>
</Sim>
<Lag>400</Lag>
</Parameter>
</Animation>
<MouseRect>
(...)
</MouseRect>
</PartInfo>
Son nom est "switch_nav_ligh", mais ce qui est important c'est qu'elle est liée à la variable (A:LIGHT NAV, Bool) et qu'elle s'étend sur 50 frames.
Ce dernier point signifie que l'objet est sur frame 0 si (A:LIGHT NAV, Bool) est faux, sur frame 50 si (A:LIGHT NAV, Bool) est vrai, et quand (A:LIGHT NAV, Bool) passe de faux à vrai, l'objet va passer de la frame 0 à la frame 50 en 1/8 de seconde (50 frames avec un lag de 400).
Par contre dans Gmax tu es totalement libre d'utiliser à ta guise les 50 frames de l'animation pour bouger le/les objet(s) 3D de ton choix!!
Si tu veux faire un inter, OK créés une animation de bascule, mais si tu veux un rotateur, libre à toi : il n'y a rien dans le code de l'animation qui présuppose le type de mouvement qu'aura l'objet dans Gmax si ce n'est que le mouvement se fait sur 50 frames...
Donc qu'importe le nom donné à l'animation dans ModelDef.xml: levier, interrupteur, rotateur, poignée, palette, bouton, manche, etc... peu importe, tout ceci se passe avant tout dans Gmax lorsque tu modélises ton animation en affectant des frames à ton objet. Après tu as toujours la possibilité d'adapter éventuellement le code de l'animation à tes besoins dans Gmax: rallonger la durée ou le nombre de frame par exemple...
Personnellement, Je créé dans ModelDef.xml toutes les animations nécessaires à mon Virtual Cockpit, les animations existantes par défaut sont celles qui ont servies aux concepteurs du P51, F18, etc..., en standard dans FSX, c'est pratique car cela donne une bonne base pour faire sa propre collection... rien de plus car je vous conseille de travailler sur vos tags sinon on s'y pert vite...
A+
Fro'
Hello,
Je te conseillerai de ne pas te limiter au seul nom des tags car ils ne sont pas suffisants pour les comprendre, il faut surtout regarder quelles variables sont impliquées derrières.
Dans les exemple que tu donnes, il y a deux choses qui n'ont rien à voir : un code d'animation (défini ente les balises "<Animation> ... </Animations>" et un code d'interaction souris qui lui est défini entre des balises "<MouseRec> ... </MouseRec>".
Sous un même nom on peut trouver dans le ModelDef.xml différents types de code qui sont définis/structurés via des balises (animation, MouseRec, visibility...) donc il ne faut pas les confondre car cela n'a pas du tout les mêmes effets et ils ne sont pas intégrés dans le modèle de la même façon : MouseRec et Visibilty s'intègre eux dans la zone "Propriété" de l'objet...
Pour répondre aux questions sur les Portes, il faut se rapprocher de ce qui est déclaré dans Aircraft.cfg pour s'y retrouver : les index :0 à :3 correspondent aux touches MajE+1 à MajE+4 => il y a un décalage...
Assures-toi que toutes tes sorties sont bien définies dans aircraft.cfg sinon FS ne les animera pas...
Une gauge type "BlackBox" est de mon point de vu incontournable pour travailler le code de ModelDef.xml elle te permet de monitorer facilement la valeur des toutes les variables et donc être sûr qu'elles prennent bien les valeurs que l'on pense a priori!!
Enfin, il y a une nuance intéressante entre la variable liée à un Levier/Poignée et celle liée à l'objet lui-même: par exemple "TailHook Handle" vs "TailHook Position".
Si vous animez la poignée de commande de la crosse sur la 2ième variable vous verrrez la poignée bouger à la vitesse où la crosse descend, alors que si vous utilisez la 1ière variable, la poignée sera tirée/abaissée rapidement : le mouvement du levier est liée à l'ordre qu'il déclenche mais pas à son exécution. C'est la même chose avec le train ou les volets...
A+
Fro'
Hello,
Personnellement je n'utilise pas vraiment les animations déjà présentes dans le ModelDef.xml, je m'en inspire parfois mais en général je créé les animations dont j'ai besoin. Ainsi pour chaque modèle, je me fait une collection d'animation sur mesure...
Avec cette approche je n'accorde donc pas beaucoup d'importance aux noms des tags par défaut car lorsque je modélise j'ai le Modeldef.xml ouvert en permanence et tout le travail se fait directement sur les variables FS (trouver la bonne variable sur laquelle appuyer l'animation) et le code (notamment pour "calibrer"/synchroniser frames et valeurs).
NotePad++, le site du SDK en ligne et "Maj+F" sont mes amis incountournables dans ses moment là!!
Enfin, lorsqu'on est sur un Cockpit virtuel, il y a en plus tous les aspects fonctionnels qu'il faut intégrer ("gestion du clic", "gestion des Event/interaction sur les variables" et infobulles) ... C'est loin d'être négligeable...
A+
Fro'
Hello,
En complément de ce qui a déjà été dit, je vous conseille la lecture de cette rubrique du SDK :
SDK - Adding New Animation
C'est assez clair et très complet pour ce qui concerne la structure du Modeldef.xml.
Ensuite pour le code proprement dit c'est du XML comme on le trouve dans les Gauges 2D...
Enfin, le ModelDef.xml initial est déjà rempli de pas mal de codes d'animation utilisées pour les avions de FSX, c'est une source très riche pour réaliser ses propres animations... Pensez-donc à faire des sauvegardes du ModelDef.xml!!
A+
Fro'
...Selon toi, le problème rencontré sur le modèle intérieur ne viendrais pas du nombre de vertex ... Pour ce qui est des textures, j'en ai 7 de 1024x1024 ... Sont-elles trop chargées ? Je pense que ce que tu veux dire par "Drawcall" c'est que si trop de petites pièces sont "mappées" sur une seule texture, FSX va faire beaucoup trop d'appels à ce fichier et générer ces effets indésirables à l'affichage.
Effectivement le tableau de bord dénombre plus de 400 objets et petits de surcroît (les interrupteurs) qui sont tous sur une seule texture. Je pensais que si on regroupait le plus possible sur une texture cela limitait justement les appels de FS ...
=> Il faudrait donc répartir ces pièces sur plusieurs textures ?
Hello,
Oui, c'est à peu près cela que je voulais dire... FSX est moins sensible au nombre totale de vertices qu'au nombre de drawcall utilisés ... Ce terme que je traduierais par "appel pour affichage" définit l'élément qui sert à l'interface entre FSX et la carte graphique: un "godet de paramètres" en quelque sorte.
FSX organise tous ces appels à la carte graphique en les regroupant par propriétés d'affichage (quasiment le material tel qu'il est défini dans Gmax avec une texture principale).
Comme chaque carte graphique est limitée en nombre de Drawcalls gérables en même temps, l'influence du modèle 3D d'un avion sur le performance sera donc liée à un compromis entre nombre de drawcals utilisés par l'avion et poids de chacun de ceux-ci...
Enfin, FSX limite à 64k le nombre de "textured vertices" par drawcall... (le Textured vertex se traduirait par "point du mesh mappé"... un vertice affecté de coordonnées UVW donc).
Donc, oui, c'est intéressant d'économiser ses textures, mais lorsqu'on a beaucoup d'objets quasi identiques, il faut parfois les répartir quand même sur plusieurs textures pour éviter de saturer le drawcall correspondant...
Bon après si il s'agit d'interrupteurs qui utilisent tous la même petite texture, il est assez simple de caser un petit carré de couleur dans plusieurs textures existantes afin de répartir les objets sur ces textures sans pour autant devoir créer une nouvelle texture...
J'espère que tout ceci n'est pas trop obscure...Sinon voici un article intérerssant qui (bien qu'en anglais) détaille ces question de Drawcalls..
Article de Torgo 3000
A+
Fro'
PS: En complément voici une série d'articles très intéressants mais hélas en anglais qui traite de ces question des performance dans FSX : Performance Art - Torgo 3000
Hello!
Je lis régulièrement tes post sur la progression de ton travail, car c'est une très belle bête que tu nous fais là!!
J'ai 2 remarques, d'abord je ne penses pas que, d'en l'absolu, il y ait une limitation du nombre total de vertices. Par exemple, la dernière version de mon Clemenceau fait plus de 210k vertices et le compilateur FSX le supporte sans (trop) râler. Après peut-être que Gmax a un contrôle (issu de FS9) qui bloquerait l'export, mais XtoMdl.exe lui le supporte.
Par contre il y une limitation au niveau du Drawcall (plus ou moins équivalent au Material) à 64k ... donc il faut éviter de trop charger sur une seule texture surtout si on a beaucoup de petites pièces...
Pour y voir plus clair personnellement je compile le XtoMdl.exe via un fichier.bat afin de stocker les logs de compilation dans un .txt... très pratique pour comprendre les humeurs du compilateur... 
L'autre remarque concerne un petit défaut de Smooth que j'ai remarqué au niveau du bord de fuite de l'intrados...
En tout cas bravo et bon courage pour la suite!!
A+
Fro'
Et cette fonction "coup de frein" est tout simplement géniale! Je vais invistiguer sur l'adaptation en question sur d'autres avions lors de mes infidélités au magnifique Etendard.. :)
Hello et merci!
Tu trouveras dans le package destiné au catapultage du T45 (dispo dans la rubrique "Créations RFN" de la RFN of course) qqs explications pour intégrer cette fonction à n'importe quel avion. N'hésites à demander si tu as des questions bien-sûr!
A+
Fro'
Hello Messieurs,
Content de voir, MirrageIII2009, que la fonctionnalité de catapultage amélioré te soit si naturelle que tu en oublies la fonction standard FSX... =D
En effet, le coup de frein pour le lancement est une fonction de contournement faite, à la base pour l'ETD et le Zéphyr, à partir de FSUIPC et d'une dll de RCBCO 3.0. Elle permet d'avoir des vitesses de sortie de pont nettement plus réalistes dépendant de paramètres de l'avion et de sa masse..
D'ailleurs , cette fonction s'adapte assez facilement à d'autres avions (d'ailleurs j'ai fait cet été une adaptation pour le T45C de Dino)...
A+
Fro'
Avant de clôturer le débat comme l'a suggéré Bee Gee, je souhaiterai poser une dernière question. Je suis le topic depuis ca création et particulièrement les derniers posts mais j'ai une question qui me trotte dans la tête et je n'ai pas réussi à y répondre en lisant les dernières pages :
- qu'aurai du faire concrètement Rollus pour nous faire un Rafale pour FSX et ne pas avoir de problème avec Dassault ?
Je pense que c'est une question que va maintenant se poser tout créateur.
Amicalement votre
Seb
PS: moi aussi j'ai loupé le rafale de Rollus et maintenant je m'en mords les doigts
Hello,
Ta question est intéressante mais pas forcément simple car il faut ben comprendre que le monde de la simu d'aviation n'est pas (encore?) spécialement verrouillé donc il n'y a pas de règle systématique et on est plutôt dans une situation où tout se traite au cas par cas ...
Je dis cela car il y a d'autres domaines où les droits sont clairement verrouillés et donc les règles très claires: par exemple l'automobile où la plupart des constructeurs et/ou organisateurs exercent leur droits avec virulence sur tous les produits qui touchent à leur marque... Essayez de mettre à dispo un addon d'une Ferrari ou un championnat de Formule 1 pour un jeu comme rFactor... et ceux même en gratuit!!
Dans l'aviation, finalement les choses sont nettement plus ouvertes, beaucoup d'avions bénéficient d'une certaine clémence pour peu qu'ils soient anciens. De plus, je ne connais pas d'exemple où un avion ait été interdit de diffusion en freeware et seul quelques constructeurs US comme Cessna ont clairement verrouillé leur droit sur le payware...
Pour le cas du Rafale, je ne m'aventurerais pas à donner a posteriori quelque leçon que ce soit à Roland, car avant cette histoire qui savait qu'un cabinet d'avocat était mandaté pour surveiller aussi les addons payants de FSX ??
Sinon, le principe, c'est: tu prends contact avec l'ayant droit ou son représentant pour qu'il t'autorise à distribuer ton produit, avec le risque que tu génères chez lui un "intrérêt" fatal à ton projet... Sur un malentendu, ton constructeur peut s'imaginer qu'il y a des sommes folles en jeu ou pire, son représentant, payé à la commission, peut sans scrupule te ranger dans la catégorie "demande de licence pour distribution worldwide" avec un Mattel, Lego ou équivalent...:8
Je caricature un peu, mais encore une fois, le monde de l'aviation est, globalement, tout sauf un milieu où les droits sont particulièrement verrouillés (et c'est tant mieux) et Dassault est loin d'être le diable que décrit certains comparativement à ce qu'on trouve dans des milieux comme le sport, l'automobile ou le cinéma...(au hasard...)
Il reste plus qu'à espérer que Roland arrivera à trouver les bons interlocuteurs qui débloqueront cette situation un peu paradoxale sans y laisser trop d'énergie et de motivation...;)
A+
Fro'
Hello,
J'avais fait un rapide calcul sous excel pour présenter le principe, mais effectivement il y a qq chose qui cloche ...
Il faut donc oublier mes calculs... désolé...
Pour les doubles dans les valeurs, je ne sais pas mais j'imagine qu'en terme de traînée il y a des configurations d'emport qui sont équivalentes mais que Rollus a tout de même différentié... Je ne pense pas que cela soit problématique finalement...
A+
Fro
...par contre le Desinstallateur ne fonctionne pas il laisse tous les fichiers dans le répertoire de fsx, ....
Hello,
Non le dėsinstalleur n'est pas en cause, il ne fait que supprimer les fichiers d'origine. Si dans un dossier un fichier est modifiė/ajouté alors le fichier/dossier n'est pas supprimé par le désinstalleur... Rien d'anormal à tout ça...;)
A+
Fro'
...Donc dans l'exemple de configuration du Rollus, il faut ajouter à la condition une vérification supplémentaire pour savoir si es volets sont déjà dans la bonne position sinon l'événement est floodé...
OK je n'avais pas saisi qu'initialement cette condition n'était pas présente...
Oui de mon point de vue, il me semble important de l'avoir, afin de ne déclencher le K:Event que lorsque c'est nécessaire : à savoir lorsque les volets n'ont plus la position kivabien.
...C'est pas très fiable car si une mise à jour de l'appareil modifie la configuration des volets, le développeur doit penser à modifier les gauges où se trouve les différentes configurations...
Non, je ne trouve pas cela "peu fiable"... en tout cas un avion regorge potentiellement de cas de dépendances plus ou moins complexe entre les codes : cela peut être entre des gauges et le aircraft.cfg comme ici, mais aussi entre le code inclu dans les modèle 3D et des gauges, etc...
C'est bien pour cela que cela prend beaucoup de temps car on a beau être très organisé, consciencieux, etc... il y a toujours des petits détails qui passent au travers...la preuve, non?
A+
Fro'
PS: Est-ce que avec cette modif le Rafale "flood" moins?
je voulais dire celle qui permet de prendre des photos la IV P, celle du screen car la IV M fonctionne pas
Hello,
Le IVP fonctionne sans problème mais pas le IVM???
De mon point de vu : il y a 99% de chance que tu as un problème d'installation : un conflit avec des fichiers résiduels de la version beta...
Je te conseille de désinstaller la version 1.0 via le programme de désinstalle, d'aller dans FS/SimObjects/Airplanes et de supprimer (ou déplacer) tout dossier "Etendard" qui resterait. Une fois cela fait, ré-installe la version 1.0 via l'auto-install, et je ne serais pas surpris que tout rentre dans l'ordre...
A+
Fro'
Hello JardY,
Je sais que tu as posé qqs questions sur FSDevelopper sur le sujet, mais je vais répondre ici quand même.
Tout d'abord, en interne, FS gère tout ce qui est pourcentage non pas comme un nombre réel compris entre 0 et 100, mais comme un entier compris ente 0 et 16383... C'est comme ça...
Avec une simple règle de 3 on s'y retrouve et cela permet d'être très précis (16 363 positions possibles entre 0 et 100 c'est plutôt fin!!).
Dans le cas des FLAPS, il faut aussi prendre en compte ce qui est déclaré dans Aircraft.cfg.
En effet, dans le bloc [FLAPS], on définit les positions des volets en faisant correspondre à chaque index (de 0 à 9 dans le cas du Rafale de Rollus) un angle d'inclinaison spécifique.
Pour le Rafale c'est particulier car il n'y a pas de volet visible (l'avion n'en a pas dans la réalité), et ceux-ci sont détournés pour simuler les différentes trainées liées à la configuration d'emport de l'avion.
Après, quand tu veux positionner tes volets via l'event (K:FLAPS_SET) à qui il faut passer le % du cran souhaité sous la forme de l'entier dont je parle ci-dessus.
Dans le cas du Rafale, on a:
flaps-position.0= 0 0,00% 0
flaps-position.1= 1 7,00% 1147
flaps-position.2= 2 14,00% 2294
flaps-position.3= 3 21,00% 3440
flaps-position.4= 4 28,00% 4587
flaps-position.5= 5 35,00% 5734
flaps-position.6= 5 35,00% 5734
flaps-position.7= 6 42,00% 6881
flaps-position.8= 6 42,00% 6881
flaps-position.9= 7 100,0% 16383
Après FS ne gère pas les positons intermédiaires et donc ne positionne pas les volets entre 2 crans : si tu ne tombes pas exactement sur un cran (pb d'arrondi par exemple) il te possiotnnera sur le cran le plus proche (le fameux "closest increment" dont parle le SDK).
Dans le code que tu montrais, je pense que les conditions de test sont bonnes et qu'elles ne doivent pas flooder sausf si les valeurs passées au K: Event ne sont pas bonnes/cohérentes et génèrent un cycle infernal...
Là je ne sais pas car je n'ai pas le code complet sous les yeux...
En espérant que cela t'aide?
A+
Fro'
...je suis un peu perdu...
Hello,
Je te comprends car moi-même je ne vois pas ce qui se passe (ou qui ne se passe pas...)
Je ne suis pas sûr que le démarreur, les voyants carburant ou d'alerte incendie aient changé entre la première beta et la dernière version...
Donc, il m'est difficile de déterminer la cause de ton soucis...
A partir d'une installation réalisée dans de bonnes conditions et au cours d'un vol lancé simplement (sans passage par un avion exotique ou via un vol enregistré particulier), l'Etendard n'a aucun problème de fonctionnement connu...
Donc je ne sais pas quoi te conseiller...(as-tu "forcé" la configuration avant-vol via menu de configuration et "Moteur stoppé, prêt au démarrage"?)
A+
Fro'
... De mémoire, il m'avait expliqué que les variables de types L: pouvait être problématiques en réseau, parce que si celle-ci était mises à jour de façon continuelle (ex : par l'utilisation dans l'équation d'une incidence, d'une assiette), elle pouvait donc surcharger la connexion...
Là, tu m'intrigues Bruno, par exemple, lors de la mise au point du parachute de l'ETD on a été confronté a des interférénce de variable L: mais sans jamais que celles-ci soient transmise d'un joueur à l'autre...
Concrètement, j'avais une variable L: qui gérait l'état du parachute et lorsque le joueur A ouvrait son parachute, il voyait l'ETD du joueur B qui larguait son parachute aussi. => Tous les ETD vus par le joueur A avaient leur variables L: synchronisées!
Par contre le joueur B ne voyait ni le parachute du joueur A ni le sien => sur son PC, la variable L:, commune à tous les ETD avait une valeur à 0.
J'en concluait que les variable L: étaient partagées avec tous les avions d'un même PC, mais pas au niveau réseau/multijoueur.....
Par contre, une variable L: mal gérée peux te mettre par terre ton PC... je sais, je l'ai fait assez régulièrement lors de la mise au point de l'ETD...
Par exemple, il suffit de confondre l'évenement "sortir le train" et la situation "train sorti" pour notre test soit vrai tant que le train est sorti et youpi, on exécute l'action 18 fois par seconde tant que le train n'est pas rentré...
... L'exemple typiquement est le Rafale de Rollus avec les différentes configurations de volets. Toutes les configurations de volets en fonction de l'emport en armes et en carburant sont dans des balises d'éléments qui ne sont pas liées à un événement de click. Le Rafale "pétarade" donc énormément !
...
Tu as raison, les développeurs sont souvent contraints à essayer de détourner des fonctions de FSX pour modéliser des animations ou des comportements. Encore mon parachute, qui n'est au final qu'un cran "caché" de volet qui est commandé via un code par ailleurs.
En faisant ce genre de manip, on est obligé d'ajouter un code quelque part pour commander cette fonctionnalité de contournement (dans le cas de mon parachute : interdire de mettre le cran de volet "parachute" sauf si c'est une commande explicite de sortie du parachute)... Et là, méfiance, car on s'expose à une mauvaise protection vis à vis de la sur-sollicitation de FS.
Pour déclencher un Event de FS, il faut pouvoir détecter le bonne évènement nécessaire et suffisant pour servir de trigger. Or d'expérience, on a parfois du mal à définir puis coder cet évènement: ce que l'on souhaite c'est détecter lorsque le joueur sort le train (l'évènement), on met un test sur le % du train et finalement notre contrôle est mauvais car on détecte le "train sorti" (l'état)... Et là ça déclenche à tout va...
C'est parfois un vrai casse-tête car comme dans mon exemple, il y a souvent plusieurs façon de soritr le train et donc il est très dur de tout surveiller (clavier, joystick, cockpit, etc...)
Personnellement, dans ces cas, je conseillerais de se tourner vers un codage en C++ qui offre d'avantage de possibilités que le xml... mais ceci est une autre aventure...
A+
Fro'
Hello Laurent,
Tout d'abord merci de lancer la discussion car c'est un moyen des plus efficaces (de mon point de vue) pour résoudre un problème: chacun apporte sa vision, sa compréhension permettant au globale de faire ressortir une solution...
Le problème que tu soulèves est intéressant mais aussi complexe. Si FSX n'est pas simple à comprendre, son moteur multijoueur est lui encore plus obscure.
Au travers des travaux faits avec la RFN (très nombreux vols en réseaux, gamespy ou autre, et plutôt variés), je me suis fait quelques convictions qui ne sont pas toujours en phase avec ce que tu énonçais dans ton post.
1) Impact d'un code mal optimisé
Je suis OK avec toi.
L'exemple que tu donnes où l'Event K: est déclenché systématiquement sans test préalable est très impactant car il sur-sollicite FSX inutilement.
Mais de mon point de vue on est totalement dans un cas d'erreur de conception qui ne se produit pas avec des gauges 3D : le code d'exécution se situe alors dans un tag Callback qui ne s'éxécute que sur sollicitation... Donc pas de cycle à 18Hz possible...
Par contre c'est vrai qu'en gauge 2D, il est vite fait de saturer FS avec un code mal conçu. Je dis "mal conçu" car quel est le principe des K: Event si ce n'est déclencher un évènement? Quel est le sens du code en question si il se déclenche en continu?? La philosophie des Event est, naturellement, de lier les évènements entre eux : si Evènement A se produit alors je déclenche Evènement B
Par exemple : "je clique sur le bouton A => je mets à jour le transpondeur" ou "Je passe la vitesse X avec le train sorti => je déclenche l'alerte B"
Ne pas mettre de condition au déclenchement d'un K:Event me parait être un peu violent...
Par contre, là où je suis d'accord avec toi, c'est que cela arrive quand même car, parfois, on se plante dans le code de la condition utilisée. On pense que cela déclenchera le K:Event qu'une fois alors qu'en pratique cela le déclenche en permanence... Dans ce cas, d'expérience, je peux te certifier que la punition est immédiate : tes FPS chutent immédiatement, des combinaisons de touches du clavier ne sont plus interceptées par FSX (MajE+2 par ex), etc...
=> FSX est saturé...
Donc pour moi, la sanction d'un code mal optimisé se fait dès le vol solo et donc a fortiori, aussi en vol multi....
2) Impact des variables échangées en multijoueurs
Il s'agit là d'une question plus obscure car il touche directement le mode fonctionnement du moteur MP de FSX.
Tout d'abord il y a 3 types de variables dans FSX:
- les variables non partagées
- les variables partagées en multijoueur
- les variables paratagées exclusivement en cockpit partagé (cas très particulier du vol MP)
Comme tu l'as dit, le serveur de session MP va distribuer les variables partagées de chacuns des joueurs à tous les autres avec une fréquence données . Remarque : hors cockpit partagé, je ne pense pas que l'on monte aux mêmes fréquences de rafraichissement que celles de maj des gauges (18HZ) : intérêt??
Par contre, comment FS fonctionne t'il? Par delta, en ne donnant que les nouvelle valeurs des variables modifiées? En full en synchronisant systématiquement la totalité des variables? Je en sais pas...
Quand on regarde quelles sont les variables paratagées, on constate qu'il s'agit essentiellement des variables qui servent au modèle extérieur (position train, volet, spoiler, feux, etc...) auxquelles s'ajout le transpondeur et les COM.
En mode SharedCockpit la liste s'allonge de nettement plus avec beaucoup de variables pour synchroniser les instruments (RPM, température, manettes en tout genre, etc...).
Au vu de ces variables, je ne vois vraiment pas comment un développeur pourrait s'amuser à coder des gauges qui satureraient en maj des variables de trains, volets, etc...??
3) Mon sentiment
Je pense que les lags plus de chance d'être générés par un joueur dont l'avion sature son FSX(local) qui par conséquent, n'arrive plus à émettre les paquets d'infos demandés/nécessaires par le serveur MP, répendant ensuite ce retard à toute la session...
La session MP nécessite de la part des PC de chaque joueur, une surcharge d'activité pour gérer les synchros avec le serveur MP (d'autant plus lourd qu'il y a plus de joueurs en session). Si le PC est limite du fait d'un avion gourmand (essentiellement au niveau de la CPU) alors il aura du mal a étaller la surcharge... Ceci ne se traduit pas forcément au niveau FPS car la carte graphique peut "cacher" partiellement ce phénomène...
Cette "théorie" est limitée car par exemple elle n'explique pas forcément les écarts de tailles des paquets échangés d'un avions à l'autre (cf une autre discussion sur le sujet il y a qq semaines)....
Donc je pense qu'il manque encore pas mal de pièces à notre puzzle...
A+
Fro'
Hello,
Il se pourrait que le problème soit lié à la barre de catapultage, ce qui me fait dire ça c'est que c'est en gros à cet endroit que l'Attachpoint est.
Bye,
Hello,
J'ai déjà eu ce pb avec l'ETD... Il semblerait qu'il y ait parfois des conflits entre les attachpoints de la Launchbar (voir de la crosse aussi) avec des effets inclus dans le VC via attachpoint...
N'ayant jamais vraiment compris la cause exacte de ces conflits, j'ai donc supprimé tout effet inséré via attachpoint de mon VC (les effets déclarés via le aircraft.cfg sont eux nettement plus simples et sans effet secondaire...).
Dans le cas du Rafale, je vous conseille donc d'essayer un autre cockpit virtuel, cela devrait remettre de l'ordre dans tous ça...
A+
Fro'
Bonsoir micpni,
Malgré la réinstallation de fsuipc j'ai les même problèmes,
- Pas de témoin lumineux Test signalisation train et signalisation train ( par contre Becs Volets Compensateurs Crosse fonctionne bien )
- Jaugeurs ( pas de cairo )
- Lampe feu (testable) mais reste inopérante s'allume pas
- Test jaugeurs
- Interrupteur sur "P + G" ( je n'arrives pas a le faire bouger )
- impossible d'actionner Parachute frein malgré ( Volets : complètement sortis,Vitesse : entre 90 et 150 kt ,Avion : au sol
- Lampes de transfert ne s'allument pas
- DEMARRAGE jusqu’à 1100 t/min n'a aucune action ( malgé La manette des gaz qui est sur stop )
- malgré avoir mis l'interrupteur du viseur sur position "Jour" ou "Nuit", et sélectionner la fonction "Bombe vent" pas de HUD ( n'étant pas dans le réel c'est pas très gênant )ce qui est bizarre c'est que j'avais pas tous ces soucis avec la première version
Merci et bon vol a tous
Bonsoir Fabrice,
Je ne comprends pas vraiment ce qui se passe dans ton cas.
Les éléments du VC dont tu parles n'ont pas de spécialement de point commun dans leur fonctionnement...
Il semblerait que pour certain bouton il y ait une animation de l'objet 3D mais pas d'effet d'éclairage (voyant feux par ex) et pour d'autre carrément aucune action du code associé à l'instrument...
Au finale je me demande ce qui fonctionne dans ton VC tellement ta liste est longue...
Es-tu bien sûr d'avoir installé l'ETD normalement? Avais-tu désinstallé la version précédente au préalable?
Enfin pour le Badin, je ne vois pas où se trouve ton soucis, car si il fonctionne (ce qui n'est peut-être pas le cas) l'aiguille indique la vitesse de l'avion... rien d'autre qu'une lecture directe...
A+
Fro'
...est-ce que ça ne peut pas mettre l'embrouille dans le trafic?
Hello,
Non la gauge ne peut pas polluer le trafic AI, par contre il est possible qu'un parasitage avec des VOR perturbe la détection des porte-avions par celle-ci.
Le plus simple est de modifier dans le fichier Carrier.xml les fréquences utilisées pour le Foch et/ou l'Ark Royal et de tester pour voir si le Tacan retrouve le chemin des porte-avions...
Personnellement je n'ai jamais eu de soucis comme cela mais avec FS on en trouve tout les jours...
A+
Fro'
Hello,
La gauge sert à la fois pour être ravitaillé que pour ravitailler un autre ETD, il s'agit donc du bouton de sélection du mode choisi:
- "Plane" => "l'avion du joueur se ravitaille sur l'avion sélectionné"
- "Tanker" => "l'avion du joueur va ravitailler l'avion sélectionné"
A+
Fro'
