Résultat étrange

Bonsoir,

Comment expliquer dans un script telemetry que :

lcd.drawNumber(x , y, 3.5+3.45+3.5, MIDSIZE+INVERS+PREC2)

affiche 10,44 et non 10,45 ?

alors qu'un print(3.5+3.45+3.5) affiche bien 10,45.

Je confirme, j'ai testé et effectivement c'est un bug, la V2.1 affiche malheureusement 10.44 au lieu de 10.45.

Avec la 2.0, on n'avait pas ce problème car il fallait multiplier par 10 ou 100 en fonction de la précision pour afficher un nombre avec une ou deux décimales.

C'est chiant ce genre de changements, va falloir encore modifier les scripts pour les porter sous la 2.1, j'espère que cela va se stabiliser une fois pour toute rapidement.

Ouf moins seul donc...quelque gouttes de sueur...
Non je ne crois qu'il faille modifier quoique ce soit, je pense vraiment que c'est un bug, il y a peu être une info chez les développeurs.

Il semble qu'une demande ai été ouverte :
https://github.com/opentx/opentx/issues/3150

Effectivement, le problème que tu as trouvé sur GitHub est bien le problème que tu as rencontré.

Ce que je voulais dire, c'est qu'entre la V2.0 et la V2.1, le comportement de lcd.drawNumber a été changé ce qui impose de changer les scripts existant pour qu'ils fonctionnent correctement en 2.1

En attendant, tu peux utiliser une micro-fonction pour pallier au problème :

Code:

local function lcd_drawNumber(x, y, val, att)
  local prec = bit32.band(att, PREC2)
  lcd.drawNumber(x, y, val + 0.1 * (prec == PREC1 and 0.1 or (prec == PREC2 and 0.01 or 0)), att)
end

Merci

J'ai bien compris cela, nous allons suivre de près l'évolution de la fonction.

pointu a écrit:Il semble qu'une demande ai été ouverte :
https://github.com/opentx/opentx/issues/3150

La demande dans GitHub a été fermée.
La solution choisie est revenir à ce qu'il y avait en V2.0.17
Autrement dit, il est urgent d'attendre la sortie de la V2.1.7 pour ceux comme moi qui ont plusieurs scripts a migrer de la 2.0 vers la 2.1

Sacre100 a écrit:.../...La solution choisie est revenir à ce qu'il y avait en V2.0.17.../...

As-tu plus d'infos pour savoir dans quelle mesure ce retour en partie vers la 2.0.17 ?
S'agit-il du Lua dans son entièreté ou pas ? (Par exemple, la possibilité d'écrire des fichiers sur la SD serait-elle abandonnée dans le lot ?)

D'après les fichiers validés sur github que la fonction arrondi concernée.

Heisenberg a écrit:

Sacre100 a écrit:.../...La solution choisie est revenir à ce qu'il y avait en V2.0.17.../...

As-tu plus d'infos pour savoir dans quelle mesure ce retour en partie vers la 2.0.17 ?
S'agit-il du Lua dans son entièreté ou pas ? (Par exemple, la possibilité d'écrire des fichiers sur la SD serait-elle abandonnée dans le lot ?)

Mais non pas du tout, c'est limité au comportement de drawNumber, regarde l'issue dans GitHub :

en V2.0, la valeur devait toujours être un entier :
- 1234 sans précision donnait  -->> 1234
- 1234 avec la précision PREC1 -->> 123.4
- 1234 avec la précision PREC2 -->> 12.34

en V2.1, la valeur pouvait être un nombre décimal :
- 1234.56 sans précision donnait -->> 1234
- 1234.56 avec la précision PREC1 -->> 1234.5
- 1234.56 avec la précision PREC2 -->> 1234.56

Sauf que voilà, en V2.1, l'arrondi ne fonctionne pas bien :
- en PREC2, 1234.56 donne à l'affichage -->> 1234.55
- en PREC1, 1234.5 donne à l'affichage -->> 1234.4

Alors ils ont décidé de revenir en arrière uniquement pour cette fonction.

Au temps pour moi, j'avoue ne pas avoir été voir sur Github au moment où je postais ma question.
Comme tu indiquais qu'il était urgent d'attendre la 2.1.7 pour modifier tes scripts 2.0, j'en ai déduit qu'il y'avait d'autres changements.
La conversion des scripts reste donc la même, si seules les valeurs arrondies sont modifiées.