Salut
le if then else n’a rien d’anormal, par contre la variable testée si!
Le problème est ici:
Lua:
local hdgmanager = "AirbusFBW/HDGdashed"
Tu déclares la variable Lua hdgmanager et tu lui affectes une chaîne de caractères de texte.
Et cette variable n’est plus modifiée par la suite dans ton code.
Moralité ta variable hdgmanager dans ton test n’a JAMAIS la valeur 0 attendue et donc branche direct sur le else et affiche en permanence — .
Il ne faut pas confondre dataref et variable Lua, ce n’est pas en faisant comme cela qu’il faut s’y prendre.
Le seul moyen d’accéder en lecture à un dataref c’est d’utiliser un xpl_dataref_subscribe() comme tu as fait pour la valeur de cap.
Le plugin Air Manager ausculte en permanence les Datarefs déclarés et dès que ceux-ci changent, il transmet la valeur modifiée à AM qui a son tour appelle la fonction concernée. Un dataref (ou variable pour FSX)subscribe() est toujours associé à une fonction qui va traiter la valeur reçue(*).
Il faut donc créer un nouveau dataref subscribe et sa fonction associée pour gérer
ta variable qui sera utilisée par
ailleurs.
Lua:
display_chr_HDG1 = hw_chr_display_add("affichage vitesse", "MAX7219", 1)
local hdgmanager=0.0 -- déclaration initiale de la variable lua (un float )
-- ici la variable Lua hdgmanager est mise à jour suivant l’évolution du dataref
function hdg_mode(hdgmode)
hdgmanager = hdgmode
end
xpl_dataref_subscribe("AirbusFBW/HDGdashed", "FLOAT",hdg_mode)
-- verifie sile mode est manager (1) ou selecter (0)
function CAP(HDG1)
if hdgmanager == 0.0 then -- si on est en mode selecter
hw_chr_display_set_text(display_chr_HDG1, 0, 0, string.format("%03.0f", HDG1 ) )
else -- si on est en mode manager
hw_chr_display_set_text(display_chr_HDG1, 0, 0, "---") -- affichage des ---
end
end
xpl_dataref_subscribe("sim/cockpit/autopilot/heading_mag", "FLOAT", CAP)
Encore mieux, comme l’évolution des deux Datarefs est liée et qu’ils sont utilisés en même temps, l’idéal est de regrouper tout ça en un seul xpl_dataref_subscribe() qui peut surveiller plusieurs variables en même temps (pas de limites connues).
Du coup plus besoin de variable Lua intermédiaire.
Lua:
display_chr_HDG1 = hw_chr_display_add("affichage vitesse", "MAX7219", 1)
-- verifie sile mode est manager (1) ou selecter (0)
function affiche_cap(HDG1,hdgmode) -- La fonction récupère les valeurs des deux Datarefs dans l’ordre de leur déclaration dans le subscribe
if hdgmode== 0.0 then -- si on est en mode selecter
hw_chr_display_set_text(display_chr_HDG1, 0, 0, string.format("%03.0f", HDG1 ) )
else -- si on est en mode manager
hw_chr_display_set_text(display_chr_HDG1, 0, 0, "---") -- affichage des ---
end
end
xpl_dataref_subscribe("sim/cockpit/autopilot/heading_mag", "FLOAT",
"AirbusFBW/HDGdashed", "FLOAT",
affiche_cap)
Et voilà, une fois que tu as compris le principe, tu peux ajouter d’autres Datarefs qui peuvent être utiles dans ce cas, par exemple le fait que le FCU soit alimenté ou pas, ce qui permettra de ne rien afficher en cold en dark…
Bien évidemment il vaut mieux limiter les Datarefs suivis dans un seul subscribe seulement à ceux qui sont pertinents, pour éviter d’avoir des centaines de tests inutiles qui peuvent éventuellement ralentir le code Lua.
A noter qu’on peut tout à fait avoir le même dataref dans plusieurs subscribe() différents, ça ne pose aucun problème.
Dernier conseil, pour progresser, rien ne vaut l’analyse du code Lua d’instruments déjà existants.
Jacques
(*): La fonction appelée par un subscribe() doit toujours être déclarée dans le code AVANT le subscribe() en lui même, sinon le compilateur Lua renvoie une erreur.