un "lacher de WP" un peu plus sioux surtout dans le cas où il y a un @WPH après

[paparazzia]

(d'après la Roadmap)

[spf]

On pourrait faire ceci:
Calculer le point le plus proche entre pos(avant) pos(apres) et le WP.
Si ce point est dans le segment (pos*), on calcule le temps mis a atteindre ce point.
Et on simule une vac de duree du temps restant en allant dans l'autre direction (apres @WPH).

[anonymous]

c'est dangereux ;) je vois déjà comment faire du raz cailloux optimum ;)

[paparazzia]

c'était moi :p

[spf]

Oui, mais bon ca parait plus logique, aussi :)
Ceci dit, on peut faire le "lacher" apres avoir franchi ce point.

(c'est facile a tester, il suffit que le ratio soit entre 0 et 1 dans un appel de fonction et on a bon ;) )

[paparazzia]

reporté à la 0.9

[paparazzia]

Plus j'y pense et plus ce ticket me semble n'être possible que si on implémente globalement une approche "continue" (à la seconde) pour Vlm, c'est à dire le calcul d'un ordre se ferait toujours au moment ou il est donné.

Le moteur le permet actuellement puisqu'une vac est bien calculé en fonction de l'heure de la vac précédente par bateau il me semble.

On finirait donc par avoir une vac générique de 1min ou 5min et un temps minimum en secondes entre 2 ordres (genre 10")

Avantage : ce ticket serait résolu automatiquement (on utiliserait l'heure programmée du pilototo pour calculer)
Inconvénient :
- il faut pouvoir donner un retour à l'utilisateur de sa "vraie" position (celle de la dernière vac + x% de la vac d'après
- ça révolutionnerai le razkyou