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 20:44:25)

bonsoir fro

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

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 23:05:01)

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

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 23:49:39)

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 &lt; (L:rafTankC, bool) 1 &lt; &amp;&amp;
(A:PAYLOAD STATION WEIGHT:2,pounds) 0 &gt; &amp;&amp;
(A:PAYLOAD STATION WEIGHT:3,pounds) 0 &gt; &amp;&amp;
(A:PAYLOAD STATION WEIGHT:4,pounds) 0 &gt; &amp;&amp;
(A:PAYLOAD STATION WEIGHT:5,pounds) 0 &gt; &amp;&amp;
(A:PAYLOAD STATION WEIGHT:6,pounds) 0 &gt; &amp;&amp; 
(A:PAYLOAD STATION WEIGHT:7,pounds) 0 &gt; &amp;&amp;
(A:FLAPS HANDLE INDEX,number) ???? != &amp;&amp;
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 10:09:35)

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

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 23:47:17)

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 * + (&gt;K:XPNDR_SET) (L:COMPTEUR_EVENEMENTS_1,NUMBER) 1 + (&gt;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 * + (&gt;K:XPNDR_SET) (L:COMPTEUR_EVENEMENTS_1,NUMBER) 1 + (&gt;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 01:37:25)