je pense qu'avec fc2, il va être possible de faire la gestion radar et le tews!!!

une petite partie de l'export.lua montre que cela doit être exportable, enfin je pense :

LoGetTargetInformation()
LoGetLockedTargetInformation()
LoGetF15_TWS_Contacts()

les trois principales qui parraissent importantes pour cela???

Je suis dedans en ce moment même

Ils ont changé le protocole de connexion donc pour le moment je galère un peu (je suis loin d'être un expert comme Dart ), mais en trifouillant, je vais bien arriver à connecter SIOC, et là çà sera vers l'infinie et au delà

Je te tiens au courant
Miaou

J'ai regardé rapidement, il faut changer le dofile("lua.lua") par 2 lignes (path...) qui sont dans l'exemple de l'export. Pour le reste, j'ai pas encore détaillé, mais il ne doit pas y avoir de monstrueux changements, bon espoir pour tous nos outils...

yep ils ont même intégré les infos pour les cadrans fuel flow, t° moteur, noz pos etc... moi qui les avait fait fonctionner juste avec les rpm... ils seront indépendant maintenant

enfin de compte il y a beaucoup plus de données qui sont exportées, les flaps aussi si j'ai bien vu etc...

Affirmatif

Ca y est

"Allo Houston", ici "eagle" the SIOC is connected

Bon maintenant faut tout refaire
Parceque en effet y'a tellement de trucs exportables, que si on pet tout dans un serveur comme celui de LeCreole on va vite être paumé, et la maintenance va être galère.

Donc je vais adopter l'approche des gars qui ont commencé sur DCS (Oakes) en créant des modules lua indépendant pour chaque module du pit.
Ceci dit les exports du KA50 semblent très développés pas sur qu'il en soit ainsi pour tous les appareils.

Miaou

katze tu as modifier les fichiers???
un download sur le site???

2eme victoire

Ca y est non seulement je me connecte mais j'arrive à exporter des valeurs dans SIOC
Donc j'ai tout le protocole sous contrôle.

Maintenant va falloir que je réfléchisse à la meilleure structure pour pouvoir facilement "maintenir" le programme.

PS @Dart : Tu as déjà réfléchi à une structure pour tes exports vers LoPlug ?
Qu'est ce que tu me conseilles (le top serait un module SIOC pour Loplug

Pour le moment, je peux rapidement essayer de recréer un serveur type loiocp_serveur, avec les anciens exports (ce qui me permettrait de brancher le KaTZ-Pit sans devoir réécrire mes ssi) idem pour tout ceux qui ont aujourd'hui un pit sur SIOC.

Mais à terme, va falloir libérer des offset pour pouvoir profiter des nouvelles valeurs.


Miaou

ben je vois pas pourquoi libérer des offset il y en a tout plein de vide non?

par contre est ce que tu arrive a mettre LOVP avec ?

@Vippen,

En fait sous FC1.12 on utilisait les 200 premiers.
Mais là avec la multiplication des exports il faudrait probablement réserver les 500 premiers offset.

Je vais voir si je décale les offsets calculés pour pouvoir garder les offset groupés par type d'info.

@Gilles, je vais voir pour LOVP ... mais là on manque cruellement d'info. sur le format des exports ... j'arriverai peut être à récupérer le module dans le serveur de LeCreole.

Je vais essayer de pondre qqchose pour le WE prochain.

Miaou

katze quels sont les fichier que tu as modifie pour faire fonctionner l'export lua vers le sioc???

Oui nous avons déjà une structure avancée pour LoPlug, en fait, contrairement à losioc qui envoit toutes les données à chaque trame, nous avons un système de programmation du lua. Le client (le module lockon de LoPlug) paramètre le lua pour chaque valeur qu'il veut selon une période différente (ex: altitude toutes les 200ms et le fuel toutes les 5 secondes). Cela évite trop de traitement dans le lua et allège LockOn de ce poids. C'est complexe mais marche très bien. Pour le sioc, je suis pas contre, au contraire, reste à savoir si c'est faisable. Je sais que Tolteque a déjà regardé, mais l'interface avec SIOC est pas le plus facile d'accès, à revoir...

En fait Losioc, n'envoie une donnée que si elle a changé (comparaison avec une valeur archive) et envoie que si elle est différente.

D'autre part, il me semble que la fréquence d'envoi n'est pas à chaque frame mais actuellement réglé sur 0.05s.

Je pensais non pas utiliser l'export lors du "LuaExportAfterNextFrame()" mais utiliser "LuaExportActivityNextEvent(t)" pour effectivement espacer les exports (Le KaTZ-Pit fonctionne en 200ms).

Ce que je ne comprend pas c'est pourquoi LeCreole au lieu d'utiliser l'export direct vers SIOC, avait créé un serveur TCP (dans loisioc-serveur) , pouvant accueillir plusieurs clients. Ca complique beaucoup le code.
Dans un premier temps, je compte séparer :
- Les paramêtres de config de la connection SIOC
- Une table de correspondance (valeur LO / offset SIOC)
- Le serveur d'export en temps que tel.

Pour l'envoi vers SIOC, c'est finalement pas trop compliqué :
Par exemple pour envoyer la valeur temps sur l'offset 10




Mais si tu as une doc sur votre structure, çà pourrait m'intéresser.
Je vous tiendrai au courant des progrès

Miaou

Lecreole avait créé losiocserveur, pour pouvoir envoyer les données a plusieurs clients , même s'ils ont les même adresses de port , du moins c'est pourquoi je l'utilise car LOVP ne peut être changer de port et impossibilité a l'époque d'utiliser SIOC et LOVP en même temps

deuxio, il permettait aussi un gain en Fps car , c'est le serveur qui envoyait les données au client et non LOFC ( je veux dire directement )

En lisant le code, je comprend l'objectif du multiclient, cependant en principe il aurait du gérer les connection/deconnection à chaud, hors si on allume SIOC après le début de mission il ne fonctionne pas, et même pire (avant la dernière modif que j'avais faite) il freezait LO, alors que çà ne devait pas être le cas. Bref, y'a un truc qui ne fonctionnait pas exactement comme prévu.

Pour ce qui est de la charge de LockOn, on l'augmente avec les requètes d'export de donnée (LO vers LOSIOC).
La transmission (LOSIOC>SIOC) via serveur TCP, si elle permettaait la gestion multiclient, ne changeait rien quand à l'envoie les données à SIOC.

Comme mentionné par Dart, l'approche intelligente va consister à faire des requètes de donnée à LockOn avec des fréquences adaptées (pas la peine de lui demander un status armement sur un pylone à chaque frame), par contre des données comme le cap, le vario vont nécéssiter une fréquence de rafraichissement plus élevée.

Donc je vais essayer la structure suivante :

LO>> LOSIOC_Serveur : fréquence adapté aux données
- en utilisant LuaExportActivityNextEvent(t)
- en utilisant les tables de coroutine

LOSIOC_Serveur >> SIOC :
- tri des données : uniquement celles ayant changées depuis le rafraichissement n-1
- transmission (éventuellement via serveur TCP multiclient si j'arrive à m'en sortir).

Dans un premier temps, je vais réutiliser la même structure SIOC que celle de LeCreole (même Offset), pour vous permettre rapidement de faire re-fonctionner vos Pits sous LO200
Par la suite, il faudra changer la table des offset pour faire de la place aux nouveaux.
Ca sera aussi l'occasion de combiner LOSIOC_serveur avec le système LoPlug de Dart et Tolteque.

Miaou

Finalement, je vais séparer le LOSIOC serveur en deux programmes distincts.

- Un module d'extraction des données de LockOn (avec fréquence adaptée au données) vers une table
- Un serveur d'export vers SIOC (qui prend les données dans la table, les traites, expédie les nouvelles vers SIOC à fréquence constante).

D'où deux petites questions à Dart-Toltèque :

Q1> Avec Loplug, créez vous un module d'extraction qui va populer une table, sur laquelle vient se brancher les modules spécifiques ?

Q2> Si oui avez vous déjà créé cette table (données, arguments ?)

Merci
Miaou

En fait on a ce schéma:



Chaque module est connecté à LoPlug routeur. Chacun possède sa propre base de données selon ce qu'il a besoin. Par exemple, le cockpit a une base de données qui contient toutes les valeurs à affichée (liste des canaux TS, valeurs LUA...). Cette base de données est géré par le framework qui se charge d'aller demander les valeurs aux modules correspondant (liste des canaux au TS, les valeurs lua au module LO).

Donc en fait, cette base de donnée est du code Python objet et contient des objets complexes permettant de gérer des structures complexes comme des images, des payloads, des valeurs... Donc on va bien plus loin que le LUA. En fait, LoPlug n'est pas LO dépendant, LO n'est qu'une source de données comme une autre. En fait, on peut insérer un module FSX, Call Of Duty ou sudoku si on veut...

Pour le SIOC, il faudrait prévoir un module qui se connecte sur le bus LoPlug. Si on peut attaquer le SIOC avec une socket, je pense qu'on peut faire un module pas compliqué qui connecte LoPlug et le SIOC. Cela permettrait aussi de récupérer des données autres que Lockon dans les cockpits (gestion TS par exemple...).

Faut voir la faisabilité, mais ça peut être sympa et pratique avec l'arrivée de la L16 ensuite ^^

En effet çà me parait la solution la plus élégante plutôt que de développer un export spécifique pour SIOC.

En fait SIOC fonctionne en socket (via FSUIPC pour FSX) ou n'importe quel client IOCP via un réseau TCP/IP.
Dans le cas du serveur losioc Lecreole l'interfaçait en créant un serveur TCP (pour pouvoir connecter plusieurs appli sur LO), mais ce week end j'ai pu l'interfacer grace au LuaSocket (socket.try(c:send(string.format("Arn.Resp:%s=%.0f:\n",10,t))) , en envoyant simplement le numéro de l'offset de SIOC (ici le 10) et la valeur (t).

L'avantage de SIOC étant qu'il est supporté par la communauté des piteurs de FSX, et de la boite qui vend du hardware pour pit. Il est donc bien documenté et continue d'être développé (contrairement à GaugeComposer, ou LOVP)

Voici la présentation du système SIOC .ppt présentation

Si tu veux je peux regarder comment l'interfacer en Python ?
Ou commencer par un serveur TCP en lua

En effet comme tu le mentionnes, si l'on peut récupérer dans SIOC des data du bus Loplug comme TS, çà permettrait de faire ce que j'ai fait pour le changement de fréquence TS, mais directement, et non via une émulation des commandes clavier.

En tout cas je suis partant pour vous filer un coup de main sur ce module (dans la mesure de mes modestes compétences)

Miaou

Salut à tous


Pour la simple raison que si l'on ne posséde pas de pit et de IoCard on pouvait connecter GaugeComposer ou autres clients utilisant le protocole IOCP directement à lockon sans avoir recours à d'autres logiciels.
Le module SIOC à été ajouter sur demande des piteurs, c'est pourquoi elle est activable ou pas dans le fichier.



SIOC, n'est pas un client de Loiocpserveur, car SIOC est un serveur d'ou des ports différents, c'est pour cela qu'il ne connecte pas aprés que Loiocpserveur soit lancé, c'est Loiocpserveur qui se connecte à sioc, mais pour ne pas compliqué le code je l'ajoute dans la liste des clients.

voila, bonne continuation à vous tous.

Lecreole.

Salut LeCreole

Arf je comprend mieux la question de Gillesdrone relative à LOVP alors

En fait, initialement je n'avais pas compris qu'on pouvait directement se connecter depuis GC vers Loiocpserveur. Mais c'est vrai que passer par SIOC même si on a pas de pit, est super utile pour le traitement de certaine valeur (c'est là que j'ai réalisé mes calculs de consommation, bullseye etc etc ...)
Même si je suppose que çà aurait été plus flexible de le faire en amont via une routine Lua, et de stocker les valeurs finies dans SIOC.

Merci encore pour tes éclaircissements

En fait, initialement, Lecréole avait commencé un traitement de données via le LUA, mais étant donné l'utilisation déjà chargée du fichier, il est apparu qu'il était préférable de laisser un autre thread s'en charger, d'autant que des programmes externes comme LoVP utilisent des données brutes du LUA.