[FSX] Lettre ouverte aux développeurs d'appareils

JardY · [↑]

(Lettre ouverte aux développeurs d'appareils mais aussi à tous les pilotes qui veulent comprendre pour certains appareils ne tiennent pas sur des sessions GameSpy)

Bonjour à tous,

I) Introduction

Cela fait déjà un moment que j'ai envie de poster ce sujet très sérieux. Je ne souhaite pas accabler les développeurs de gauges que ce soit des développeurs d'appareils paywares ou frewares. Je souhaite une fois pour toute expliquer un phénomène lié au multijoueur par défaut de FSX que tous les créateurs devraient savoir.

Pour commencer, je me présente, JardY, je m'occupe de développements en tout genre pour la session Praetorians-Fs que certains connaissent déjà. Je sais ce que certains pensent du multijoueur par défaut de FSX (qu'on appelle souvent "GameSpy") mais justement ce sujet est totalement lié aux sessions FSX sur GameSpy et il va permettre d'y voir plus clair sur le soit-disant manque de fiabilité de ce réseau.
[---]
II) Le problème

Vous avez peut être déjà vu sur un forum ou sur un support technique, des personnes rapporter des problèmes du genre : "Je me fais déconnecté d'une session avec cet appareil", "J'ai le message l'hôte a terminé la session", "Mon PC rame plus en multijoueur qu'en solo".

Les réponses en général sont toutes bêtes : "Le serveur sur lequel tu voles n'a pas une bonne connexion", "Ta connexion Internet ne fonctionne pas bien", "Ta configuration n'est pas assez costaud" ou simplement : "GameSpy c'est de la merde".

Il est temps que tout le monde sache pourquoi des appareils ne "tiennent" pas en multijoueur !
[---]
III) La source du problème

Je vais essayer de schématiser le problème puis ensuite de rentrer dans les détails. Lorsqu'on développe une gauge (un instrument de bord), on utilise souvent des variables de simulation et des événements de simulation. Par exemple pour le transpondeur, on peut utiliser l'événement (K:XPNDR_SET). Les événements s'écrivent toujours (K:LE_CODE_DE_L_EVENEMENT). Lorsqu'on est connecté en multijoueur sur FSX, l'utilisation d'un événement déclenche l'envoi d'une information. Autrement dit, le pilote règle un code transpondeur et le simulateur envoie une information au serveur informant du changement de code transpondeur.

Tous les événements de type "K:" n'envoient pas une information au serveur FSX mais les événements basiques le font comme les COM, le transpondeur, les lumières, les volets, le train, etc.. Lorsqu'on utilise un événement "K:" sur un click de souris sur un bouton d'une gauge pas de souci, l'événement est envoyé une fois car il est lié à une action du pilote. Au contraire dans une gauge xml lorsqu'on utilise une balise <Element> à la racine de la gauge, le code est exécuté tout le temps. Plus précisément au rythme de rafraichissement de la gauge (soit environ 16 fois par seconde). Si on ne protège pas ce code, un packet réseau est envoyé à chaque passage dans le code soit 1000 fois par minute environ ce qui est hélas 999 informations de trop.

C'est ça qui est très problématique.
[---]
IV) Conséquences sur une session FSX

Que se passe t'il sur une session FSX lorsqu'un appareil envoit en boucle un événement ?

Il envoit jusqu'à 50 fois plus d'informations qu'à la normale. On pourrait dire que ce n'est pas grave si cela impactait uniquement le pilote envoyant en boucle un événement sauf que tous les autres pilotes doivent répondre à ces envois ! Au lieu de répondre une fois, "Transpondeur mis à jour", tous les autres pilotes de la session sont obligés de répondre environ 1000 fois par minute "Transpondeur mis à jour". Evidemment, je vulgarise un peu mon discours. Sur une petite session à quelques connectés, ce n'est pas bien grave mais sur une session hébergeant plus de 20/30 joueurs, ça devient beaucoup plus problématique.
[---]
V) Un exemple concret

J'ai construit une petite gauge xml toute bête pour illustrer mon propos. Evidemment, ceci est un exemple, il ne faut pas y voir un intérêt aéronautique mais un exemple de mauvaise utilisation d'un événement du simulateur (événement qui je le rappelle est de la forme "K:").

Voici le code n°1 (code non protégé) :

<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document Type="AceXML" version="1,0" id="ExempleEnvoiEvenement">
<Descr>AceXML Document</Descr>
<Filename>ExempleEnvoiEvenement.xml</Filename>
<SimGauge.Gauge id="ExempleEnvoiEvenement" ArtDirectory=".">
<FloatPosition>0.000,0.000</FloatPosition>
<Size>500,500</Size>
<Element id="eltNbEvents1">
<FloatPosition>25.000,150.000</FloatPosition>
<GaugeText id="ggtNbEvents1">
<BackgroundColor>red</BackgroundColor>
<Bold>True</Bold>
<FontColor>white</FontColor>
<FontHeight>16</FontHeight>
<GaugeString>%((L:COMPTEUR_EVENEMENTS_1,NUMBER))%!d!%</GaugeString>
<Size>100,50</Size>
<Transparent>True</Transparent>
</GaugeText>
</Element>
<Element id="eltFlood">
<FloatPosition>0.000,0.000</FloatPosition>
<Select id="sltSelect1">
<Expression id="expNonProtegee">
<Script>7777 s0 10 % l0 10 / int 10 % 16 * + l0 100 / int 10 % 256 * + l0 1000 / int 4096 * + (>K:XPNDR_SET) (L:COMPTEUR_EVENEMENTS_1,NUMBER) 1 + (>L:COMPTEUR_EVENEMENTS_1,NUMBER)</Script>
</Expression>
</Select>
</Element>
</SimGauge.Gauge>
</SimBase.Document>

Cette gauge fait deux choses, elle affiche un compteur qu'on incrémente dès qu'on utilise l'événement (K:XPNDR_SET). Et une zone "Element" qui affecte toujours le code 7777 au transpondeur. La zone "Element" contient un select et une expression. Cette technique est couramment utilisée pour être sûr que le code du select sera toujours exécuté et effectivement c'est le cas, il est exécuté autant de fois que la gauge se met à jour (je parlais précédemment de taux de rafraichissement de la gauge). Dans ce code n°1, on affecte simplement 7777 au transpondeur et comme je l'ai dit, si vous êtes connecté en multijoueur, vous enverrez un packet / une information réseau à chaque affectation du transpondeur. Autrement dit, vous allez "flooder" le serveur.

Je le rappelle une fois de plus, seules les variables d'événement de type "K:" sont susceptibles de déclencher l'envoi d'un packet en multijoueur.

Voici le code n°2 (code protégé) :

Je ne recopie pas tout le contenu de la gauge mais simplement la balise "Element" et son script associé. Ici, je veux protéger mon code pour ne pas déclencher l'événement du transpondeur si je n'en ai pas besoin. Comment faire ? Simplement en regardant si la valeur du transpondeur n'est pas déjà dans la valeur que je veux lui affecter :

<Element id="eltFlood">
<FloatPosition>0.000,0.000</FloatPosition>
<Select id="sltSelect1">
<Expression id="expNonProtegee">
<Script>(A:TRANSPONDER CODE:1,NUMBER) 7777 != if{ 7777 s0 10 % l0 10 / int 10 % 16 * + l0 100 / int 10 % 256 * + l0 1000 / int 4096 * + (>K:XPNDR_SET) (L:COMPTEUR_EVENEMENTS_1,NUMBER) 1 + (>L:COMPTEUR_EVENEMENTS_1,NUMBER) }</Script>
</Expression>
</Select>
</Element>

Pour bien comprendre ce principe, j'ai fait une petite vidéo d'exemple :

(Désolé, c'est trop sombre, il faut la visualiser plein écran pour y voir quelque chose)

Rappel : Attention, ceci est un exemple bien sûr comme je le dis, les événements de type "K:" sont à affecter avec la plus grande prudence pour éviter de les affecter en boucle et donc de rendre instable un appareil en mode multijoueur.
[---]
VII) Conclusion

Comme dit au départ, sur des forums, nous voyons souvent des demandes de support à propos de "problèmes" en mode multijoueur. On peut certes avoir un serveur pas très puissant ou sa propre connexion un peu dans les choux mais la plupart du temps, ces problèmes ne sont jamais résolus !

Et bien voilà la solution, aussi complexe soit elle, les corrections à apporter aux appareils sont mineures. Encore faut-il prendre le temps de vérifier son code. Pour finir, je propose mon aide à tous les développeurs d'appareils qui souhaitent se renseigner et tester leurs appareils. Nous avons déjà évoquer ce sujet à demi-mot, de mémoire, pour le Rafale de Rollus, mais aussi et c'est d'actualité pour le PMDG 737 NGX. Voici l'explication globale du problème.

Ce sujet a simplement pour but d'informer les développeurs d'appareils qui sont soucieux que leurs appareils soient stables en multijoueur. J'aimerais ajouter que ce problème peu connu ronge les sessions GameSpy depuis le début de FSX sans qu'il soit décrit de façon clair. C'est chose faite ! En espérant avoir été pris au sérieux car PMDG en plus de nous prendre de haut, ne nous a jamais écouté depuis la sortie de son 737 et ce n'est pas faute d'avoir essayer.

Pour finir, je comprends tout à fait que ce sujet n'intéresse pas grand monde mais il me semblait important de le faire.

Bonne journée à tous.

Laurent Jardillier.
http://www.praetorians-fs.com

Dernière modification par JardY (16-04-2013 00:37:10)

Lagaffe · [↑]

D'un point de vue technique, j'adhère complètement et je vais même jusqu'à dire que j'essaierais d'appliquer ce principe/postulat sur mes gauges.

Néanmoins, tous les développeurs d'avions ne font pas tout de A à Z et certains se limitent à la 3D, voire rajoute un modèle de vol et rares sont ceux qui font leurs propres gauges. Dans ce dernier cas, ils vont "utiliser" celles qui sont disponibles sur Internet en demandant l'autorisation ... ou pas (c'est un autre problème).

Maintenant, si cette problèmatique veut aborder certains développements auxquel je pense (certains chalumeaux de dernière voire d'avant-dernière génération), je laisse le soin à ces personnes de s'exprimer sur ce point.

FlipFlap · [↑]

Bonsoir

merci pour l'explication et l'exemple.

Je me pose maintenant une question de néophyte : est-il possible d'installer sur son PC son appareil est ses Gauges faits maison et ce que j'appellerai un "serveur d'écoute" pour visualiser ce que tu explique (le trafic engendré par une Gauge perso) ?

Et si oui, comment faire et avec quoi .... (ce qui fait maintenant trois question ... ).

Dernière modification par FlipFlap (05-10-2011 19:44:25)

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'

aeronef · [↑]

bonsoir fro

tu nous prépare quelque chose pour bientôt???? dans quel millésime ....
@+

Thor's Hammer · [↑]

Bonjour tout le monde,

Lotus m'avait un jour parlé de ce problème de surchargement de mises à jour de variables. 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. Si la variable n'était mises à jour que de façon ponctuelle (ex : On/Off), il n'y avait pas surcharge. J'ai appliqué ses conseils pour une gauge de mon HUD, en supprimant une variable L: et en l'intégrant dans l'équation finale... Vive les équations en RPN... ^^

J'avoue que je ne connait pas grand choses aux gauges 2d, sachant que j'essaye de faire le cockpit du Rafale intégralement en 3D, de l'horloge aux écrans. J'ai réussi à avoir jusqu'à maintenant un HUD extrêmement fluide, mais je dois faire des compromis qui, je pense, serai plus facile à contourner en 2D.

Bonne soirée,

Bruno.

JardY · [↑]

Merci déjà de réagir à ce sujet qui me tient particulièrement à coeur ! :)

Comme je l'ai dit lorsqu'un événement est floodé, tous les autres joueurs d'une session sont impactés. Je serais ravi d'en discuter avec toi Fro' (nous avons un mumble chez PFS et j'aimerais beaucoup échanger avec toi sur le sujet).

J'aimerais revenir sur une partie de ta réponse :

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...??

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 !

J'ai entamé une discussion avec Rollus à ce propos.

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...

Uniquement les événements au fur et à mesure, jamais de resynchro complète.

Je reviens également sur ce que dit FlipFlap :

Je me pose maintenant une question de néophyte : est-il possible d'installer sur son PC son appareil est ses Gauges faits maison et ce que j'appellerai un "serveur d'écoute" pour visualiser ce que tu explique (le trafic engendré par une Gauge perso) ?

Hélas, tout le problème est là. A part rechercher dans toutes les gauges d'un appareil (et encore je parle que du code xml et pas d'autres langages), un développeur doit regarder tous les "K:" events pour vérifier leurs utilisations. Comme je l'ai dit lorsqu'on utilise ce type d'événement sur une action de la part du pilote, aucun problème. Par contre si on est dans un élément que j'appelle "libre" comme dans mon exemple, ça commence à être problématique.

Maintenant PFS a développé des outils assez poussés de "monitoring" et on peut côté serveur checker un appareil et vérifier ses événements mais c'est très complexe. C'est pour ça que je proposais mon aide à ceux qui le veulent.

Merci encore pour vos réponses, ça fait chaud au coeur !

Dernière modification par JardY (05-10-2011 22:05:01)

JardY · [↑]

Thor's Hammer a écrit :

Bonjour tout le monde,
Lotus m'avait un jour parlé de ce problème de surchargement de mises à jour de variables. 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. Si la variable n'était mises à jour que de façon ponctuelle (ex : On/Off), il n'y avait pas surcharge. J'ai appliqué ses conseils pour une gauge de mon HUD, en supprimant une variable L: et en l'intégrant dans l'équation finale... Vive les équations en RPN... ^^
J'avoue que je ne connait pas grand choses aux gauges 2d, sachant que j'essaye de faire le cockpit du Rafale intégralement en 3D, de l'horloge aux écrans. J'ai réussi à avoir jusqu'à maintenant un HUD extrêmement fluide, mais je dois faire des compromis qui, je pense, serai plus facile à contourner en 2D.
Bonne soirée,
Bruno.

Les valeurs L: sont locales aux gauges et normalement jamais passées en multijoueur. Par contre les événements ET les événements personnalisés oui.

loac56 · [↑]

salut à tous,
Ce sujet est très interressant mais j'ai juste une petite remarque à faire sur la compréhension de celui-ci, beaucoup de simples utilisateurs comme moi ne comprendront pas tout dans ce message, peut-on résumer en disant que lorsque la session saute, ce n'est donc pas forcément de la faute de tel ou tel avion puiqu'en général, et je le redis , on ne sait pas forcément quel type de programme est utilisé pour certains avions. Est-que je peux dire en résumé a certaines personnes sur les sessions qui se permettent de nous dire:"c'est ton avion qui fait planter la session " sans savoir quelles types de gauges on a qu'ils ont en parti tort.
Merci beaucoup de la part d'un passioné qui prend juste du plaisir a voler avec des superbes appareils sans savoir tout sur le charabia utilisé pour creer ceux-ci.
loac56

JardY · [↑]

C'est assez simple en fait : Sur une session ouverte entre amis où il y a environ 10 personnes, on ne peut rien voir ! Comme je le disais, il suffit d'un appareil "floodeur" pour que tous les autres appareils (joueurs connectés) soient obligés de répondre et donc de monter leurs taux d'envoi de données. Ces personnes qui au départ volent avec des appareils "sains", peuvent hélas "sauter" (avec le message du genre "L'hôte a terminé la session") et si la personne avec l'appareil "floodeur" a une bonne voir une très bonne connexion, lui va tenir. C'est pour ça que chez PFS, nous déconnectons les appareils qui floodent. Encore une fois, le système mis en place chez nous est propre à PFS et il est assez complexe hélas pour être adapté à d'autres sessions. Cela dit, il ne faut pas perdre de vue que le problème vient des appareils et non des sessions.

C'est pour ça que je disais dans mon premier sujet que depuis les débuts d'FSX, ce souci tue littéralement la communauté GameSpy.

Dernière modification par JardY (05-10-2011 22:16:19)

Fro' · [↑]

Thor's Hammer a écrit :

... 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é...

JardY a écrit :

... 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'

Dernière modification par Fro' (05-10-2011 22:49:39)

Lagaffe · [↑]

Ce sujet est très interressant mais j'ai juste une petite remarque à faire sur la compréhension de celui-ci, beaucoup de simples utilisateurs comme moi ne comprendront pas tout dans ce message, peut-on résumer en disant que lorsque la session saute, ce n'est donc pas forcément de la faute de tel ou tel avion puiqu'en général, et je le redis , on ne sait pas forcément quel type de programme est utilisé pour certains avions. Est-que je peux dire en résumé a certaines personnes sur les sessions qui se permettent de nous dire:"c'est ton avion qui fait planter la session " sans savoir quelles types de gauges on a qu'ils ont en parti tort.
Merci beaucoup de la part d'un passioné qui prend juste du plaisir a voler avec des superbes appareils sans savoir tout sur le charabia utilisé pour creer ceux-ci.

Loin de moi l'idée que Loac56 veuille critiquer ce topic mais justement cet aspect technique TRES fouillé m'interesse au plus au point. Il est très rare d'avoir ce type de discussion sur ce forum ors la rubrique Création s'y prête particulièrement bien: même si le public intéressé est de moins de 20 personnes, je pense qu'il faut de temps en temps aborder ce type de problèmatique car c'est à la suite d'échanges de ce type que l'on peut hisser son niveau et ses connaissances.

En ce qui me concerne, je continue à suivre vos échanges avec délectation et envie: Merci.

JardY · [↑]

Dans tes précédents posts Fro' tu as mis l'accent sur une information supplémentaire : La "surcharge" le CPU donc la surcharge de travail demandé au simulateur lors de l'utilisation de code déclenché en boucle tel que mon exemple. Il ne faut pas oublier que ce que j'ai utilisé c'est un <Element> contenant un <Select>, c'est donc détourner l'utilisation de cette balise pour simplement effectuer un petit script car le développeur s'est rendu compte que ce code est "toujours" exécuté (quand je dis "toujours", c'est bien entendu lié au taux de rafraichissement de la gauge).

Pour en revenir au Rafale, il suffirait simplement de vérifier sur chaque configuration de volets que les flaps ne sont pas déjà dans la bonne position pour éviter de rappeler l'événement (K:FLAPS_SET).

Je copie / colle un bout du Rafale (je comprendrais que Rollus me demande de le supprimer de ce sujet évidemment)

(L:rafTankP, bool) 1 < (L:rafTankC, bool) 1 < &&
(A:PAYLOAD STATION WEIGHT:2,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:3,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:4,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:5,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:6,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:7,pounds) 0 > &&
(A:FLAPS HANDLE INDEX,number) ???? != &&
if{ 16383 (>K:FLAPS_SET) }

J'avais commencé à essayer de corriger le problème en ajoutant une ligne supplémentaire au IF (A:FLAPS HANDLE...) pour voir si les volets sont déjà dans la bonne position. Car si on ne fait pas cette vérification, tant que l'appareil est dans la configuration décrite dans le IF, il va flooder l'événement (K:FLAPS_SET).

Le problème ici c'est que c'est une valeur d'axe entre 0 et 16383 et que la variable "A:" (lecture seule) donne l'index de position des volets et non la valeur d'axe. De toutes façons la documentation est claire sur l'événement K:FLAPS_SET :

KEY_FLAPS_SET : Sets flap handle to closest increment (0 to 16383)

Il faut donc trouver la position de volets mise sur l'appareil pour 16383 (là c'est facile c'est la plus grande donc l'index 9, index visible dans les flaps.position du aircraft.cfg).

Mais d'autres configurations de volets indiquent des valeurs 4000 / 6000 / 8000 / 10000 / 12000.

Rollus pourra peut être nous en dire plus à ce sujet.

Le but évidemment étant de rendre le Rafale doux comme un agneau avec les sessions multijoueurs en terme d'envoi d'événements car je le répète encore, il n'est pas normal que le serveur multijoueur soit floodé.

Dernière modification par JardY (06-10-2011 09:09:35)

loac56 · [↑]

salut,
Tout a fait Lagaffe,merci de le souligner, loin de moi l'idée de critiquer des sujets aussi interressants surtout quand ceci explique cela, je voulais juste demander une confirmation. Mais je suis pour ces sujets qui peuvent des fois éviter les prises de becs comme je l'ai déjà vu sur des sessions parceque tel ou tel joueur fesait soit disant planter la session.Bref, continuer avec des sujets explcatifs c'est très interressant.
PS: Pensez juste un petit peu aux non initiés qui sont interressés par ces sujets mais qui ne comprennent pas grand chose au charabia de programmeur. lol

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'

JardY · [↑]

Merci de ta réponse !

Nous sommes d'accord, il faut passer entre 0 et 16383 à l'événement (K:FLAPS_SET).

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é.

(L:rafTankP, bool) 1 < (L:rafTankC, bool) 1 < &&
(A:PAYLOAD STATION WEIGHT:2,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:3,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:4,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:5,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:6,pounds) 0 > &&
(A:PAYLOAD STATION WEIGHT:7,pounds) 0 > &&
(A:FLAPS HANDLE INDEX,number) 9 != &&
if{ 16383 (>K:FLAPS_SET) }

Ici en rouge le complément de condition nécessaire pour stopper le flood du K:FLAPS_SET.

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.

Encore merci pour tes lumières :)

Dernière modification par JardY (07-10-2011 20:03:25)

Fro' · [↑]

JardY a écrit :

...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.

JardY a écrit :

...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?

JardY · [↑]

Encore merci pour tes lumières car à la base, je suis certes développeur mais pas de gauges :)

Je prends l'exemple du Rafale de Rollus car là c'est assez simple, il faut protéger les différentes configurations de volets (même si c'est un peu fastidieux car il y a en a plein). Lorsque dans les gauges, les événements sont protégés, l'appareil aussi complexe soit il génère autant de trafic réseau que le Cessna de base donc comme je le disais aucun rapport avec sa complexité. Je te montrerai à l'occasion si tu passes sur notre Mumble, car un beau dessin vaut mieux qu'un long discours.

Je n'en veux pas du tout à Rollus qui a produit un travail énorme pour un appareil de qualité, et ce problème (dont je lui ai parlé en privé) est comme on le disait très méconnu. Par contre, les pires des pires des pires, c'est les Nemeth Design, exemple avec le MD-900 :

<Element>
<Select>
<Value>(L:engine no1 off,bool) ! (L:engine no2 off,bool) ! || if{ (>K:MIXTURE_RICH) }</Value>
</Select>
</Element>

Ils fonctionnent qu'avec des variables locales (ce qui n'est pas si bête en soit) mais pour tout même des choses qu'ils pourraient vérifier avec des variables de simulation classiques. Quasiment la totalité de leur flotte d'hélicos sont des floodeurs en puissance.

J'aimerais d'ailleurs bien te montrer toi qui a développé les instruments de l'Etendard (si je me trompe pas) car l'Etendard IV est assez utilisé chez nous. Passe donc à l'occasion sur Mumble chez nous : http://www.praetorians-fs.com/index.php?page=nousrejoindre.php

JardY · [↑]

Désolé de relancer là dessus mais Rollus ne m'a pas encore répondu donc j'en profite pour essayer de peaufiner avant de lui en reparler.

Quand tu mets :

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

C'est pas plutôt : 7° de déflexion représente 16383 donc par exemple 4° = 16383*4/7 = 9361.71 = 9362 ?

Après pourquoi mettre à deux reprises : deux index identiques pour 5° et 6° ?

Dernière modification par JardY (10-10-2011 22:47:17)

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

JardY · [↑]

Pour mémoire : La version anglaise (merci Maman=8)

Open letter to aircraft developers but also to the pilots who want to understand why some aircrafts cannot stay connected to Gamespy sessions.

Hello everybody !

I) Introduction

It’s been some time now that I have felt like posting this quite serious topic. My purpose is not to criticize gauge developers whether they are payware or freeware crafts developers. I only want to explain once for all a phenomenon due to the default multiplayer by FSX which all designers should know about.

First of all, I introduce myself: My name’s JardY, I deal with all sorts of developments for the Praetorioans-Fs session which some of you already know. I know what some of you think of the default multiplayer by FSX (often referred to as GameSpy), but precisely this topic is totally linked to FSX sessions on GameSpy and it will make it possible to better understand the supposed unreliability of that network.
[---]
II) The problem

On forums or in technical supports, you’ve probably come across comments such as : "I get disconnected from a session with that craft", "I get the message - session closed down by host", "my computer rows more in multiplayer than in solo sessions".

The answers are often rather simple : "The server you fly with hasn’t got a good connection", "there’s a problem with your internet connection", "your config isn’t strong enough" or simply "GameSpy, it’s trash".

It’s high time people should know why some crafts don’t stay connected in multiplayer mode.
[---]
III) The origin of the problem

I’ll first try to simplify the problem, then I’ll go into the details. When you develop a gauge (a board instrument), you often use simulation variables and events. For example, for the transponder, you can use the event (K: XPNDR_SET). Events are always written (K: event_code). When you are connected as multiplayer on FSX, the use of an event automatically sends an information. In other words, the pilot sets a transponder code and the simulator sends the server information about the change of transponder code.

All "K:" events don’t send the FSX server information, but basic events do, such as the COMs, the transponder, the lights, the flaps, the landing gear, etc. When you use a "K:" event with a mouse click or a gauge button, there’s no problem, the event is sent once because it is linked with one pilot action. On the contrary, with an xml gauge, when you use a <element > command in the gauge root, the code gets executed all the time. More precisely at the rate of gauge refresh (that is about 16 times a second). If the code isn’t protected, a udp packet is sent each time the code is read, that is about 1000 times a minute, which is unfortunately 999 data too many.

And that’s really the problem.
[---]
IV) Conséquences sur une session FSX

What happens on a FSX session when a craft sends an event repeatedly ?

It then sends 50 times more data than normally. We could say that it’s not a problem if that had consequences only on the pilot sending an event endlessly, except that the other pilots have to answer these packets. Instead of once answering "transponder updated", all the other pilots of the session have to answer about 1000 times a minute "transponder updated". Of course, I oversimplify. In case of a small session with only a few pilots connected, it’s not really a problem, but it really is one with a 20-to-30 players session.
[---]
V) A concrete example

I’ve developed a rather simple and basic xml gauge to exemplify my words. Of course it’s only an example without any particular aeronautics interest, but one example of how a simulator event is wrongly used (let us remember that the event is written "K:").

Here is code number one (not protected) :

<?xml version="1.0" encoding="UTF-8"?>
<SimBase.Document Type="AceXML" version="1,0" id="ExempleEnvoiEvenement">
<Descr>AceXML Document</Descr>
<Filename>ExempleEnvoiEvenement.xml</Filename>
<SimGauge.Gauge id="ExempleEnvoiEvenement" ArtDirectory=".">
<FloatPosition>0.000,0.000</FloatPosition>
<Size>500,500</Size>
<Element id="eltNbEvents1">
<FloatPosition>25.000,150.000</FloatPosition>
<GaugeText id="ggtNbEvents1">
<BackgroundColor>red</BackgroundColor>
<Bold>True</Bold>
<FontColor>white</FontColor>
<FontHeight>16</FontHeight>
<GaugeString>%((L:COMPTEUR_EVENEMENTS_1,NUMBER))%!d!%</GaugeString>
<Size>100,50</Size>
<Transparent>True</Transparent>
</GaugeText>
</Element>
<Element id="eltFlood">
<FloatPosition>0.000,0.000</FloatPosition>
<Select id="sltSelect1">
<Expression id="expNonProtegee">
<Script>7777 s0 10 % l0 10 / int 10 % 16 * + l0 100 / int 10 % 256 * + l0 1000 / int 4096 * + (>K:XPNDR_SET) (L:COMPTEUR_EVENEMENTS_1,NUMBER) 1 + (>L:COMPTEUR_EVENEMENTS_1,NUMBER)</Script>
</Expression>
</Select>
</Element>
</SimGauge.Gauge>
</SimBase.Document>

This gauge operates 2 things: It displays a meter incremented as soon as the event is used (K:XPNDR_SET), and an "Element" area always assigning code 7777 to the transponder. The "Element" area includes one element and one expression. This is the usually used technique to make sure that the select code will always be executed and it is indeed. It is executed as many times as the gauge is updated (see above when I referred to the gauge refresh rate). In that code number 1, 7777 is simply applied to the transponder and as I said, if you are connected as multiplayer, you’ll send a packet/ network information each time the transponder is affected. In other words, you’ll flood the server.

I say it again, only the event variables of "K:" type are likely to automatically send a packet when in multiplayer sessions.

Now here is code number 2 (protected code) :

I won’t rewrite the whole gauge but only the "Element" command and its corresponding script. In this case, I want to protect my code in order not to trigger the transponder event if I don’t need it. How can I do it ? Simply by checking whether the transponder value isn’t already included in the value I want to give it :

<Element id="eltFlood">
<FloatPosition>0.000,0.000</FloatPosition>
<Select id="sltSelect1">
<Expression id="expNonProtegee">
<Script>(A:TRANSPONDER CODE:1,NUMBER) 7777 != if{ 7777 s0 10 % l0 10 / int 10 % 16 * + l0 100 / int 10 % 256 * + l0 1000 / int 4096 * + (>K:XPNDR_SET) (L:COMPTEUR_EVENEMENTS_1,NUMBER) 1 + (>L:COMPTEUR_EVENEMENTS_1,NUMBER) }</Script>
</Expression>
</Select>
</Element>

Again: It’s only an example as I say. "K:" type events should be used with great care to avoid them being loop used and thus make a plane on multiplayer mode unstable.
[---]
VII) Conclusion

As I first said, on forums, we often come across requests about "problems" in multiplayer mode. Of course, perhaps the server isn’t powerful enough, or perhaps the connection is hopeless, but most of the times the problems remain unsolved.

Well then, here is the solution, however complicated it may be, the adjustments to operate on crafts are rather minor. Now it requires time to check one’s code. To conclude, I offer to help all the aircrafts developers who would like to be informed and test their crafts. The topic has already been hinted at, if I remember well, for the Rollus Rafale, but also, and it’s quite topical, for the PMDG 737 NGX. So, we’ve got the general account for the problem.

This topic only wanted to inform crafts developers who care about their plane stability when in multiplayer mode. I’d like to add that the problem isn’t really well-known and it has wasted GameSpy sessions since the beginning of FSX without being clearly set out. That’s done ! Let’s hope we’ll be taken seriously because PMDG not only looked down on us but have never taken us into account since their 737 was released. And yet we will have tried !

As a conclusion, I would understand that this topic shouldn’t be of great interest for many people, but I considered it was important to deal with it.

Have a good day everybody !

Laurent Jardillier.
http://www.praetorians-fs.com

Dernière modification par JardY (16-04-2013 00:37:25)

#1 [↑][↓] 05-10-2011 14:28:41

[FSX] Lettre ouverte aux développeurs d'appareils

#2 [↑][↓] 05-10-2011 16:57:42

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#3 [↑][↓] 05-10-2011 19:43:16

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#4 [↑][↓] 05-10-2011 20:20:54

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#5 [↑][↓] 05-10-2011 21:00:56

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#6 [↑][↓] 05-10-2011 21:27:00

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#7 [↑][↓] 05-10-2011 21:53:29

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#8 [↑][↓] 05-10-2011 21:55:21

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#9 [↑][↓] 05-10-2011 22:05:33

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#10 [↑][↓] 05-10-2011 22:15:21

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#11 [↑][↓] 05-10-2011 22:36:35

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#12 [↑][↓] 05-10-2011 22:45:38

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#13 [↑][↓] 05-10-2011 23:03:08

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#14 [↑][↓] 06-10-2011 21:30:48

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#15 [↑][↓] 07-10-2011 18:20:18

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#16 [↑][↓] 07-10-2011 19:41:45

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#17 [↑][↓] 07-10-2011 22:15:52

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#18 [↑][↓] 07-10-2011 23:00:40

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#19 [↑][↓] 10-10-2011 22:46:41

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#20 [↑][↓] 11-10-2011 07:00:45

Re : [FSX] Lettre ouverte aux développeurs d'appareils

#21 [↑][↓] 23-10-2011 15:36:02

Re : [FSX] Lettre ouverte aux développeurs d'appareils

Pied de page des forums