KaTZ-Pit V3000, Le KaTZ-Pit de DCS FC3

[Lynx]

C'est magnifique !!!

[Red Daron]

extreme le chat ! si ca marche sur tablette android ca sera top !

[KaTZe]

Petit Update de l'avancement des travaux.


J'ai reçu les fichiers de LeCreole, qui a effectué une liaison direct entre DCS (module export .lua) et une page web (script javascript) en créant un échange websocket.
Mon projet est différent puisque je veux intercaler SIOC , pour garder une compatibilité Hard-Cockpit, et pour profiter de ses possibilités de calcul (playtime, cap vers objectif etc etc ...).
Pour lier SIOC et la page Web j'ai créé un serveur web en Python (Le KaTZ-Link) qui communique d'un côté avec SIOC et de l'autre avec la page web via la technologie WebSocket.
Cela offre toutes les flexibilités (page Web multiples, Postes multiples géographiquement délocalisés etc etc ....).

Aujourd'hui ... tous ces liaisons fonctionnent dans les deux sens :
DCS <<-->> SIOC
SIOC <<-->> KaTZ-Link (début Septembre)
KaTZ-Link <<->> Page Web : le KaTZ-Pit (fin Septembre)

Un grand merci à LeCréole dont les fichiers m'ont permit de comprendre comment implémenter une websocket entre le KaTZ-Link et le KaTZ-Pit.
C'est un vrai bordel ces systèmes apparemment assez récents, et super mal documentés.
Idem pour javascript, quelle M..... ce language , le web a vraiment pas été concu pour afficher dynamiquement autre chose que du baratin (même le web est devenu pourri par les marketeurs/baratineurs/commerciaux ).

Maintenant, il me reste à tester et faire certains choix pour une transmission fluides des données.
J'essaye aussi d'avoir une structure claire, pour permettre une évolutivité du système à tous les module de DCS, et des données facilement manipulable par tous ceux qui voudrait se faire leur config perso.

Donc il reste à faire le travail un peu fastidieux des tableaux/listes de valeurs, etc etc, pour alimenter le KaTZ-Pit.
Après les affichages de valeurs, et les Switch de commande, on s'occupera de faire tourner les aiguilles, d'animer l'ILS etc etc ....

Si tous va bien ce soir, je devrait faire mon premier vol avec la version per-pre-pre-alpha



Ce message a été modifié par KaTZe - 29 Sep 2014, 10:28.

[gillesdrone]

si tu as besoin d'un testeur avec pit hard , je suis dispo ( retour de vacances )

et merci pour ton travail ( je sais un merci n'étanche pas la soif )

[KaTZe]

si tu as besoin d'un testeur avec pit hard , je suis dispo ( retour de vacances )

et merci pour ton travail ( je sais un merci n'étanche pas la soif )

Merci Gilles,

En fait, ce qu'il faudrait, c'est que je sache quelle plage de données dans SIOC vous n'utilisez pas.
Perso. j'utilise les offset de DCS, puis j'effectue dans SIOC un certain nombre de calculs, et j'alimente une plage d'export qui est envoyé au KaTZ-Link.

Dans cette plage se trouve
> des données déjà exportée de DCS que je recopie (exemple : IAS, TAS etc etc ...)
> des données calculées depuis les données DCS (exemple: conversion m/ft, durée de vol, status armement ...)
> des flags "voyants" ou "équipement" (exemple engine-fire, position verrière ...)

Pour la clarté du programme c'est plus simple, si je pouvais avoir une plage de 500 positions réservées pour les calculs (exemple 500-1000), et 1000 positions réservées pour les export vers le KaTZ-Pit, (exemple 1000-2000).

Off course il faudrait que çà soit des positions non utilisées par les sim-pitteurs, pour pouvoir juste ajouter les codes dans vos .ssi, sans avoir à décaler vos positions.

Je sais pas si je suis clair

Pour le moment j'utilise toujours mon vieux ".ssi" mais comme je vais devoir profondément le réviser avec FC3, autant partir sur des plages dédiées

Ce message a été modifié par KaTZe - 29 Sep 2014, 11:56.

[gillesdrone]

pour ce soir je te mets un dossier avec mes exports et SSI Kamov

[Lecreole]

Salut,

KATZ à quoi sert ton 'KaTZ-Link' ?
Pourquoi ne pas utiliser LUA DCS pour la liaison entre SIOC et Page web?

LUA <------> SIOC
|<------> Page web

Moi j'utilise le svg pour le coté graphique un example l'interface est créée dynamiquement et pilotable par javascript :

// Création
g_alt_1 = panel.gauge(20,60,1.4,altGaugeOptions);
g_alt_2 = panel.gauge(20,400,1.4,altGaugeOptions);
g_rpm_1 = panel.gauge(340,127,1,rpmGaugeOptions);
g_rpm_2 = panel.gauge(520,127,1,rpmGaugeOptions);
g_rpm_ru = panel.gauge(400,400,1,rpmRUGaugeOptions);
l_led1 = panel.led(700,450,10,"green","off");
l_led2 = panel.led(800,450,10,"red","on");
l_led3 = panel.led(900,450,10,"green",1);
l_led4 = panel.led(1000,450,10,"red",0);
// interactivité
l_led1.setValue(1) // pour allumer la led 1
g_alt_1.setValue(4260); // pour afficher l'odometre et rotation de l'aiguille.
g_rpm_ru.setValue([57,69]); // pour afficher valeur rpm left et right.

L'avantage la même qualités d'affichage pour toutes les résolutions .
Je continue à travailler sur mes prochains instruments, ADI, HSI, VSD.

[gillesdrone]

pour Katz

si tu veux j'ai mis dans /public/Gillesdrone/EXPORT_DIVERS
un zip export
il contient tous ce qui cons=cerne export et Sioc SSI
tu pourras voir ains les plages utilisées au moins par Bad , Oeil de faucon,et moi

[KaTZe]

@Gilles : Merci je vais pouvoir utiliser des plages libres afin de ne pas chevaucher avec vos plages de commandes de pit.
Je pense que je reviendrai vers toi, because j'ai vu que certain export ont changé depuis FC2, plutôt que de perdre mon temps, je regarderai ton script d'export DCS

@LeCréole : Encore merci pour tes info. WS
Je garde SIOC dans la boucle y compris pour le Pit, because je préfère ne pas exporter directement depuis DCS vers le pit.

- J'ai pas mal de calculs intermédiaires effectués par SIOC (consommation moyenne, armement panel, conversion metrique/imperiale, chrono, durée de misson ....)
Bien sur je pourrais effectuer ces calcul en lua dans l'export DCS, mais ils ne sont pas tous utile à chaque 200ms, çà surcharge DCS, et surtout côté debug, c'est un enfer (alors que sous SIOC il suffit de regarder le résultat dans le numéro de plage.
En plus tous ces calculs sont déjà fait, donc je préfère me brancher dessus plutot que de tout reecrire dans DCS.

- Le KaTZ-Link me permet aussi d'effectuer quelques conversions, et surtout de charger un fichier .ini avec les correspondances SIOC/KaTZ-Pit
C'est un fichier texte (.csv), donc facilement consultable/editable

C'est vrai que çà morcelle la chaine, mais çà la rend transparente, et permet de debugger chaque étape, ainsi que de l'adapter ainsi facilement à tous les (futurs) avions DCS.

C'est ce que je reproche à tous les outils que l'on a vu naitre depuis quelques années (gaugecomposer, helios etc etc ...) c'est qu'il y a toujours une part propriétaire ou custom made qui rend l'évolutivité ou l'adaptation compliquée. Dans mon système, les jauges ne sont pas recréés avec un logiciel type perfectwidgets etc etc, mais c'est une image (.gif) du cadran tel qu'il est dans DCS, affichée maintenant par la page web, avec juste une image d'aiguille en rotation. Idem pour les voyants, c'est ceux du jeu allumés ou éteints, via jquery.


- Finalement dans la perspective d'un écolage (ou vol DC) à distance, la gestion websocket entre un serveur Python et le Client Web, me parait plus simple à gérer que de d'avoir le serveur WS directement dans DCS.


Ceci dit j’admets bien volontiers, que çà n'est peut être pas optimal (je suis un amateur complet en programmation), mais c'est à ma portée , et donc à celle de tout gars qui voudra customiser, en investissant un minimum de temps



Ce message a été modifié par KaTZe - 30 Sep 2014, 07:50.

[KaTZe]

@Gilles,

Bon j'ai testé et réfléchi
Notre échange m'a donné une idée.

Dèjà, j'utilisais le KaTZ-Link pour convertir les numéro d'offset de SIOC en étiquettes clairement compréhensibles pour le KaTZ-Pit.

En fait, j'ai créé un fichier de configuration texte (.csv), dans lequel se trouve la correspondance offSet/étiquette/Gain. Je charge ce fichier au démarrage du KaTZ-Link, ce lui permet :

1> de faire la déclaration à SIOC :Arn.Vivo des offset qui seront écoutés
2> de transformer les messages de SIOC avec une étiquette intelligible vers KaTZ-Pit
3> d'effectuer les conversions d'unité avec les valeurs gains, ce qui fait que le Pit recoit directement les bonnes valeurs prêtes à être affichées sans faire de calcul en javascript (qui est une vrai m.... comparé à Python).
4> d'effectuer des transformations plus complètes : par exemple pour l'heure/le temps de vol/ de mission, où la donnée secondes est converti directement en hh:mm:ss et envoyé telle qu'elle au KaTZ-Pit.

Ainsi, quand on adaptera d'un pit à l'autre au besoin, il suffira de mettre à jour des offset et les gains dans le fichier texte utilisé par Python