[En Dev]Le KaTZ-Pit du Mi-8, La Version MI-8 du KATZ-Pit

[gillesdrone]

Bravo le Chat

[KaTZe]

Finalement plutôt que de répondre en mp, je préfère en discuter en clair (si certains ont des idées).

dans le moyen de récupérer de la vitesse de transmission

ceci valable pour mon utilisation , passer tout en rapide et augmenter la vitesse de lecture

où intègres tu la notion de vitesse lente et vitesse rapide ?

(je voisbien dans les commentaires que tu parle de 200 ms , mais après je ne vois pas dans les fonctions )

autres idées
, comme je n'utilise que des boutons on/off ou poussoir , je vais supprimer tous les autres types de boutons

ainsi que les panels que je n'utilise pas à savoir que je n'utilise que les cadrans analogiques , le mod de vol ( gauge puissance ) et le panel des températures huile et moteur .

déja je devrais gagner en vitesse si c'est faisable

fj'étudie cela cet aprem ....

Bon WE

Gilles

.cc etcher

Mmmmm, à mon avis il ne faut pas mélanger les problèmes et faire un audit méthodique de la chaine.
Derrière "la vitesse de transmission" se cache une chaine DCS/SIOC/KaTZ-Link/KaTZ-Pit

Chaque élément tourne avec sa fréquence, et la stabilité de l'ensemble passe par la nécessité d'éviter les bottleneck. Pour le moment, c'est totalement stable pendant des heures de mission.

Dans cette chaine, SIOC est probablement le maillon fort. Etant en language compilé, il est très rapide et çà n'est pas les 30-40 variables qui passent qui le charge (les FSX piteurs utilisent des centaines de variables).
Par contre je ne connais pas la partie connection électronique (hard), mais je suppose qu'elle est tout aussi efficace.

Pour le KaTZ-Link, on a clairement un bottleneck.
Il est constitué de deux threads qui tournent en synchro.
L'un récupère les données de SIOC, l'autre gère la websocket et communique avec le KaTZ-Pit html.
Pour le moment, une boucle complète :
> Reception variables de SIOC / Envoi à Pit / Reception Ordre Pit / Envoi à SIOC
a un timing de 200ms (100ms pour chaque demi boucle).

Clairement, de temps en temps il y a des valeurs dans le sens SIOC>Pit qui passent à l'as
Je le vois bien avec le nouvel Altirad du Huey, où dans des descentes rapides on a des "sauts de données".

Il y aura un travail d'optimisation à faire (le top aurait été de programmer le bousin (KaTZ-Link) en C++ mais là ... je pars de zero.

Pour le KaTZ-Pit, la partie html/Javascript : du moins sur une machine type PC, je ne pense pas qu'il y ai beaucoup de lag. C'est d'ailleurs la grosse différence avec GaugeComposer, qui accumulait les lags jusqu'à atteindre 2-3sec après 15-20mn de vol.

Dans tous les cas dans la V5008, tous les scripts concernant les panels non affichés sont stoppés. Donc seul l'affichage Analogique (cadran) consomme de la ressource.
De plus les données de ces panels sont maintenant regroupées par grappe (variables regroupant de 2 à 8 valeurs).
Donc il ne sert à rien de les supprimer tu ne gagneras rien.

Mais ......

Dans ton cas je pense que tu parles du lag entre un switch dans ton pit (SIOC) et son affichage dans le jeu.
Donc la chaine KaTZ-Link-KaTZ-Pit est hors sujet.

Il reste donc, la reception des ordres par le programme d'export.lua

Comme je l'expliquais , il y a deux horloges qui ne déclenchent les exports qu'à une fréquence donnée (conseil de l'équipe de DCS). J'ai mis le script de réception dans la boucle rapide.

Les données de vol : IAS, Vz, Alti ... sont dans la boucle rapide
Les données des panels : Power, Fuel, Nav ... sont dans la boucle lente

Pour le KaTZ-Pit, le timing des boucles est réglé à 200ms et 1 seconde.
Les instructions se trouvent dans le module séquenceur de tâche qui commence ligne 730.
Il suffit de changer les valeurs de SamplingPeriod_1 (fast) et SamplingPeriod_2 (slow) (valeur en seconde).

Ca fait parti des tests que je dois faire pour la phase d'optimisation.

A l'extrème, tu peux mettre le module recetion dans la partie "KD_AfterNextFrame=function(self)", ce qui écoutera à chaque image ...

Attention quand même à ne pas faire écroules les fps, en chargeant le script d'export.

Là aussi, il faudrait comparer les fps, avec le jeu sans export et avec export ... depuis la v5008, j'ai allégé le flux de donnée en aval en regroupant les données dans des valeurs transférées, mais çà charge l'encodage/décodage à chaque bout de la chaine.
Je ne sais pas donc s'il vaut mieux travailler avec beaucoup de valeurs transitant (non regroupées), ou peu de valeurs groupieert . Pour le moment, j'ai choisit l'option type "multiplexage temporel".

Si tu testes, idéalement il faudrait mettre mon code du fts-logger dans le script d'export et analyser les moyennes sur un vol pour voir si le script fait ramer la machine ...

Sachant que dans le principe c'est sensé tourner sur deux machines, pour justement garder la puissance de la machine n°1 pour le jeu

Miaou

Ce message a été modifié par KaTZe - 17 Jan 2015, 09:40.

[gillesdrone]

Merci pour ta réponse je regarde cela lundi dans la journee

[KaTZe]

Juste pour info. mais vous le verrez au prochain démarrage de EKPI, j'ai repris le pit du MI-8 sous toshop et modifié les textures des panels (on est très proche du pit anthracite).

J'ai ajouté aussi l'horloge de vol, avec chrono et chrono de vol fonctionnel.
Par contre, je pense modifier le chrono de vol , pour le rendre automatique (sur RPM > 80% ?)
Je ne suis pas sur que grand monde le déclanche avec le bouton rouge surtout qu'on ne peut pas l'utiliser en temps intermédiaire (relancer après arrêt).

Pour info. d'ailleurs le chrono est aussi ajouté sur le Kamov.

Demain je pense le mettre sur les pits FC3 Russes (fonctionnel avec la fonction temps de vol, et stopwatch, réalisé dans le pit, même si elle n'est pas dans le jeu )

Miaou

[KaTZe]

Mise à jour, du travail nocturne ce matin ... j'ai intégré l'indicateur de commandes de vol dans les pit du Mi-8 et du Huey

[etcher]

J'ai loupé la discussion du dessus, donc avec un peu de retard:

J'ai profilé le KatzeLink pendant son développement, la latence qui lui est imputable est de l'ordre, au maximum et dans le pire des cas, de 2 millisecondes, je ne pense pas que le problème vienne de lui (au passage, la latence du websocket en local est également de l'ordre des 2 millisecondes, ce qui nous amène à 5 en arrondissant bien large. Il n'y a que Postal et ses 2500 fps qui arriverait à s'en apercevoir. Ce qui est bien sûr est une blague).

A mon avis, le point faible de la chaîne se trouve dans les calculs effectués par le javascript, qui est lui même un sous processus du browser, qui travaille dans un environnement innaccessible.

A titre de test, pour peu que le vario du Huey soit effectivement un exemple représentatif, je te propose d'extraire les calculs y afférant et de les déplacer directement dans la Link, puis d'effectuer un test comparatif.

Mon avis d'amateur non-éclairé est qu'à partir du moment ou cette grosse bouse de Javascript ne reçoit plus que des inputs bruts et n'a plus aucune forme de calcul, boucle ou quelque shenanigan que ce soit à effecteur en dehors de déplacer les aiguilles, la latence, même artificielle, ne devrait plus être qu'un mauvais souvenir.

[KaTZe]

Well ...

La discussion avec Gilles remonte d'avant l'Etcher-Link , aujourd'hui la micro latence restante n'a aucun effet sur le pilotage ... je dirais même plus, entre :

> un gars qui baisse les yeux sur un KaTZ-Pit rigoureusement immobile et ou chaque cadran est toujours au même endroit de l'écran ...

> un gars qui baisse la tête avec son track IR cherche le cadran, et immobilise ses muscles cervicaux pour figer l'image, et arriver à lire correctement le cadran ... en admettant qu'il n'a pas besoin de zoomer/dezoomer

il n'y a pas photo ... on est loin d'un éventuel 5ms de délai .


Par ailleurs, 99% du taf de javascript consiste à appeler des objets (ID), et à y fourrer une valeur ou à les faire tourner.
C'est encore plus vrai avec les produits Belsimtek, puisque c'est le %age de rotation/déplacement qui est exporté en non plus la vrai valeur. Sur FC3 et KA, la vrai valeur est exportée, et effectivement le javascript va délinéariser la valeur pour faire tourner les aiguilles correctement.

Le gros avantage du système actuel, est que le SIOC+Link est totalement commun à tous les pits.
Donc développer un nouveau pit va très vite.
Si je commence à déporter les calculs dans le Link, on va se retrouver avec des spécificités pour chaque appareil, et la maintenance dans qq années avec la multiplication des addon va s’avérer monstrueuse.

Sincèrement, quand je vois la vitesse de réaction de la partie javascript/html, çà dépasse largement les besoins de n'importe quel pilote ici (c'est même trop rapide avec un déplacement un peu saccadé des aiguilles) , j'ajoute en outre qu'irl, un baro, un vario, un pitot vu les technologies "pneumatiques" utilisées (mesure de pression/delta pression) , on est loin de 5ms de réaction
Idem quand Gilles parlait de 100ms pour le basculement d'un interrupteur (qui est "instantané" dans sa boucle SIOC), il oubliait les 500ms qu'il lui a fallu pour lever le bras et activer son interro dans son pit ... le bottelneck, n'était surement pas le KaTZ-Link



Puisqu'on parle du Mi-8, je me suis attaqué au panel Armement.

Etant donné que c'est un helico DC, que l'on pilote seul, pour cet aspect, j'ai pris le parti de ne pas reproduire l'ergonomie catastrophique du cockpit en combat.
Je ne vais pas faire un panel pour le master arm, un panel pour les selection s'emport, un panel mix GUV, Rocket, un panel etc etc ....

Donc il y aura :
> un master panel armement (regroupant MasterArm, Main Switch, selection d'emport, jettison
> Un panel control Rocket + UPK
> Un panel control GUV
> Un panel control Bombes

Miaou

Ce message a été modifié par KaTZe - 2 Mar 2015, 14:52.

[etcher]

Solid copy !

[KaTZe]

Voilà le premier des 4 panneaux



On retrouve donc :
> Le safety switch (1er master Arm), qui se trouve près du dome Rouge derrière le pilote
> Le 2eme switch (Main Switch) localisé au dessus de la tète du pilote près des voyants d'armement
> Les 6 voyants de présence sur le pylone
> Les jettison soit de bomb only (panel bomb du copilote) , soit Bomb + Pod (devant le pilote)

> La table au centre est clickable et va commander le bouton de selection de payload qui se trouve sur le bomb panel du copi.
Quand on click sur une configuration, elle s'affiche (quand le bouton tourne dans le pitDCS), en dessous des pylones.
Ca n'est donc pas un retour de l'emport réel (qu'on a pas dans le Mi-8), mais bien la selection que vous avez choisit.

-------------

J'essayerai de finaliser avant le train de Mercredi (auquel hélas je ne pourrai pas participer ... invité à diner chez des voisins)

Le panel Rocket, permettre de voir le voyant d'armement des rocket, et les selecteurs UPK/RS, Riffel Qty, Firing Pods

Le Panel GUV, permettra de voir le voyent d'armement, les selecteurs 800/624/622 cutoff et durée de salve

Le Panel bomb, permettre de voir le switch on, et le voyant d'armement, ainsi que le selecteur de largage

Avec çà on aura une logique beaucoup plus facile à mettre en oeuvre.

Miaou

[KaTZe]

Voila le travail de la nuit dernière

J'ai regroupé tir rocket et programmation des GUV dans un même panneau



Du coup, j'arrive (presque ) à comprendre la logique du système
Je up çà si j'ai le temps en fin d'aprem

Miaou