AM : A propos de fsx_variable_subscribe

[PapaLima]

Bonsoir

Question pour les pros des gauges AM :

Je me pose la question suivante : Vaut-il mieux avoir :
1 fsx_variable_subscribe avec 10 paramètres d'abonnement ou bien 10 fsx_variable_subscribe avec 1 paramètre d'abonnement ?

En d'autres termes (extrait de la gauge clock Seneca V)

Ici on s'abonne sur 9 variables et on appelle la fonction PT_clock

Code: Tout sélectionner

fsx_variable_subscribe("ELECTRICAL AVIONICS BUS VOLTAGE", "Volts",
                  "ELECTRICAL BATTERY BUS VOLTAGE", "Volts",
                  "ELECTRICAL MAIN BUS VOLTAGE","Volts",
                  "AMBIENT TEMPERATURE", "Celsius",
                  "AMBIENT TEMPERATURE", "Fahrenheit",
                  "ZULU TIME", "Hours",
                  "TIME ZONE OFFSET", "Hours",
                  "L:HoursTime","Number",
                  "L:MinutesTime","Number",
                  PT_clock)


Ne serait-il pas plus efficace (en terme de perf) de faire plusieurs souscriptions par groupe par exemple:

Code: Tout sélectionner

fsx_variable_subscribe("ELECTRICAL AVIONICS BUS VOLTAGE", "Volts",
                  "ELECTRICAL BATTERY BUS VOLTAGE", "Volts",
                  "ELECTRICAL MAIN BUS VOLTAGE","Volts",
                  PT_clock_elec)

fsx_variable_subscribe(     "AMBIENT TEMPERATURE", "Celsius",
                  "AMBIENT TEMPERATURE", "Fahrenheit",
                  PT_clock_temp)

fsx_variable_subscribe(    "ZULU TIME", "Hours",
                  "TIME ZONE OFFSET", "Hours",
                  "L:HoursTime","Number",
                  "L:MinutesTime","Number",
                  PT_clock_time)


Je dis peut être une bêtise. Mais il n'y a pas de question idiote hein ?

@+

[JacquesZ]

Ce n'est pas une question bête, mais j'ai pas vraiment la réponse!

Le soucis avec des variables_subscribes décomposés dans plusieurs fonctions différentes qui sont appelées, est que cela peut poser des problèmes des synchronisation quand plusieurs tâches doivent s'enchainer.

Si elles sont dans des fonctions séparées, comme on ne maîtrise pas l'appel à la fonction qui est géré parle plugin d' AM chaque fois qu'une variable change dans FSX/P3D/XPlane, l'enchaînement des séquences peut être compliqué, ou alors il faut prévoir des "flags" de partout.

Si dans le cas de l'horloge du Seneca, température et Zulu time sont complètement indépendants, pourquoi pas...
Mais toutes ces fonctions dépendent AUSSI de l'état de la batterie (c'est une montre électrique), ce qui veut dire qu'il faudra souscrire pour chaque fonction à l'état de la batterie,OU ALORS AVOIR UNE VARIABLE GLOBALE POUR STOCKER L'état de la batterie, donc ce sera de toutes façons redondant! Pas sûr qu'on y gagne au final...

Code: Tout sélectionner

fsx_variable_subscribe("ELECTRICAL AVIONICS BUS VOLTAGE", "Volts",
                  "ELECTRICAL BATTERY BUS VOLTAGE", "Volts",
                  "ELECTRICAL MAIN BUS VOLTAGE","Volts",
                  PT_clock_elec)

fsx_variable_subscribe(ELECTRICAL AVIONICS BUS VOLTAGE", "Volts",
                  "ELECTRICAL BATTERY BUS VOLTAGE", "Volts",
                   "AMBIENT TEMPERATURE", "Celsius",
                  "AMBIENT TEMPERATURE", "Fahrenheit",
                  PT_clock_temp)

fsx_variable_subscribe(ELECTRICAL AVIONICS BUS VOLTAGE", "Volts",
                  "ELECTRICAL BATTERY BUS VOLTAGE", "Volts",
                   "ZULU TIME", "Hours",
                  "TIME ZONE OFFSET", "Hours",
                  "L:HoursTime","Number",
                  "L:MinutesTime","Number",
                  PT_clock_time)

Mais Corjan (le developpeur d'AM) pourra sûrement t'en dire plus sur le forum SimInnovations, je vois que tu le fréquentes (le forum)!

Jacques

[PapaLima]

Merci Jacques

Le forum AM était "sous l'eau" hier soir...difficilement accessible et puis on a pas mal d'amis qui nous ont fait de belles gauges ici aussi. Et comme je débute tout juste maintenant à écrire deux lignes...

Je viens de poster chez sur le forum AM. Je transmettrais leurs recommandations si il en a.

Mon idée étant de savoir si il y a une utilisation recommandée de cette fonction importante car il me semble que le Raspberry PI 2 auquel je soumets le code se retrouve vite dans les choux après plusieurs clics sur les boutons du timer.... Je pense qu'il est un peu débordé de mon panel instruments "captain" ... Je n'ai pas encore essayé avec un PI 3. D'où ma question pour optimiser l'utilisation de ces petits CPUs des Framboises des bois

A+
Philippe

[PapaLima]

Voilà j'ai eu une réponse sur le forum AM : Ralph un des pontes chez eux

En général cela importe peu à moins d'avoir une très grosse fonction callback. Ce qui arrive lorsqu'on a beaucoup de variables souscrites sur une fonction callback, c'est qu'à chaque petit changement, l'intégralité du script est parcourue.... Mais la plupart des scripts ne sont pas très longs, cela n'impacte pas.

Lorsque je construis des instruments complexes je découpe en plusieurs parties. Ainsi on a une callback par section. Cela aide aussi à organiser le code et de garder une bonne visibilité dessus.

Je retiens donc de faire un souscription de variables par section logiques de l'instrument programmé.
Plutôt qu'un appel avec 3km de variables...

A+

[arcc]

On peu donc aussi retenir que si nos jauges ne sont pas très compliquées (je pense que c'est vrai pour notre Twin) cela n'a pas trop d'importance.
En tout cas je ne mettais pas posé la question.

Impeccable
Christian

[PapaLima]

On peu donc aussi retenir que si nos jauges ne sont pas très compliquées (je pense que c'est vrai pour notre Twin) cela n'a pas trop d'importance.
En tout cas je ne mettais pas posé la question.

Impeccable
Christian

Si je n'avais pas eu un Raspberry Pi 2 qui me semble avoir un peu de mal à gérer la partie gauche "instruments de pilotage", je ne me serais pas posé la question non plus !

Cà n'a pas vraiment d'importance pour la plupart des gauges comme l'on précisés les mentors chez AM.
On souscrit par petits groupes de variables pour organiser logiquement le code et on évite les variables globales car elles tendent à le compliquer.

60% du temps CPU va dans l'affichage et LUA est très rapide à l'exécution. Pas d'inquiétude à avoir.