aircockpit.com

Non, toute la logique est interne à l'add-on mais il faut pour le relier au cockpit par une interface.

Pour pouvoir activer les switchs, lire les LED/display.
Pour pouvoir le relier aux carte SIOC il faut soit que l'add-on utilise des offsets FSUIPC réservé (comme PM)
ou qu'il utiliser un serveur IOCP.

C'est les 2 seuls moyens de communiquer avec le SIOC.

BOB

Pour continuer à développer ma pensée:

Si le contact passe bien avec eux, le top du top d'est de proposer une interface API.( Pour les non programmeurs,il s'agit d' un système où le logiciel,ici l'addon, utilise des fichiers externes appelés DLL. Ces fichiers DLL sont en fait des petits programmes réutilisables par d'autres programmes.) Une fois l'interface API crée, ils en profitent pour faire la DLL de base qui relie leur soft à FSUIPC, puis ils laissent le soin aux autres développeurs de créer des interfaces plus spécifiques (SIOC notamment), en ouvrant la doc d'accès à cet API.

JL

Jackpilot a écrit:Suis pas sur de comprendre , mais la logique de l'avion n'est pas dans la carte d'interface!!? ni dans sa programmation.
Si l'avion est bien concu, notamment pour la formation, tout est deja dans le "modele " de vol et la logique interne..non?
Je ne pense pas que tes interlocuteurs aient besoin des possibilités de SIOC pour recréer une logique qu'ils ont deja programmé
Je me trompe?
Jack

Au risque de dire une annerie Je pense qu'il n'y a que 2 interfaces de dialogue avec FS:
FSUIPC
IOCP ( regardez offset explorer dans vos programmes iocp)
+ bien sur les attributions directes FS

Donc a mon avis l’idéal c'est un avion qui utilise au max les attributions directes de FS
ce qui permet une programmation très simple des entrées via une interface joystick standard ( bodnar,pokey ect ...)

pour les systèmes non standards et les sorties : FSUIPC ou IOCP ( ce qu'a fait L4SC)
L'important c'est que l'éditeur rende les offsets publics.

Après il peuvent créer des applis dédiées pour simplifier la programmation,
mais a mon avis pas d'issue sans FSUIPC ou IOCP.

Alain

Ce que je veux dire c'est qu'a partir du moment ou il faut une interface dédiée ( PM,flightdecksoft,jehell)

on est un peu dans une logique pro puisqu'il faut utiliser obligatoirement ladite l'interface.

Après c'est un question d'argent.
PM hors de prix
flightdecksoft abordable
Jehell gratuit ( ce qui au passage est grand et généreux vu le boulot qu'il abat )

Si un éditeur veux créer un avion grand public y'a pas plus simple que de publier ses offsets.
(767 Level D, Beech B200 Aeroworks)

Alain

Jackpilot a écrit:Si l'avion est bien concu, notamment pour la formation, tout est deja dans le "modele " de vol et la logique interne..non?

Tout à fait! c'est là tout l'intérêt de pouvoir utiliser un add-on qui est déjà de grande qualité au niveau logique/modèle de vol, qu'il ne reste plus qu'à interfacer.
On ne doit rien avoir à bidouiller, juste faire de "l'assignation" de fonction de l'add-on à une entrée/sortie de notre hard.

Jackpilot a écrit:Je ne pense pas que tes interlocuteurs aient besoin des possibilités de SIOC pour recréer une logique qu'ils ont deja programmé

Bien sûre qu'ils n'ont pas besoin de SIOC pour recréer une logique qu'ils ont déjà dans leur modèle de vol.
Mais nous, on a besoin d'une interface pour assigner leur logique à notre hardware. Et les offset FSUIPC est une possibilité.
Dans ce cas SIOC ne servirait pas à programmer quoi que ce soit (comme tu dis, tout est déjà dans l'add-on), là on servirait juste de SIOC pour attribuer nos entrées/sortie de hard. "telle entrée agit sur tel offset"
Dans le cas des cartes OC, il faut le "déclarer" avec SIOC. (Comme ce que tu fais avec tes cartes FDS lorsque tu attribues une fonction à une entrée).
Pas de programmation, juste de l'attribution.

JeeHell a écrit:Pour continuer à développer ma pensée:

Si le contact passe bien avec eux, le top du top d'est de proposer une interface API.( Pour les non programmeurs,il s'agit d' un système où le logiciel,ici l'addon, utilise des fichiers externes appelés DLL. Ces fichiers DLL sont en fait des petits programmes réutilisables par d'autres programmes.) Une fois l'interface API crée, ils en profitent pour faire la DLL de base qui relie leur soft à FSUIPC, puis ils laissent le soin aux autres développeurs de créer des interfaces plus spécifiques (SIOC notamment), en ouvrant la doc d'accès à cet API.

JL

Au fait, il m'a dit ceci: "We were using our own boards which we have developed (UDP based) to interface with the cockpit."
Je n'ai aucune idée de ce qu'est ce protocole UDP, peut être (sûrement même) qu'à toi cela évoque quelque chose?

Oui oui UDP c'est User Datagram Protocol, c'est très semblable au TCP et utilise les mêmes couches matérielles sur IP (je rentrerais pas plus dans le détail pour les puristes). S'ils sont OK pour ouvrir ce protocole et en permettre l'utilisation c'est tout bonnard car après suffit de rebalancer sur IOCP ou FSUIPC. Mais je pense qu'on peut shunter cette couche IP et légèrement gagner en performances.
Mais je suis pas sûr qu'ils veuillent bien ouvrir un protocole utilisé dans des applications/matériels de grade professionel ($$$$).

JL

OK, merci! J'ai déjà pas mal de renseignements, je vais leur faire un petit mail.
Qui ne tente rien n'a rien...

FiX a écrit:OK, merci! J'ai déjà pas mal de renseignements, je vais leur faire un petit mail.
Qui ne tente rien n'a rien...

C'est ce que j'allais te proposer
mets leur un lien vers ce fil, ça les aidera surement à mieux comprendre nos attentes.

Alain

Voilà, c'est fait...
Bon par contre pour notre fil, en Français, je ne sais pas s'ils vont chercher à traduire...

Par contre, Jeehell, si jamais ils avaient l'intention de se pencher un peu plus sur le sujet (on ne sait jamais), es-ce que tu accepterais que je te mette en contact avec eux pour répondre, beaucoup mieux que moi, à des questions un peu techniques?