Tacview 0.91 et Falcon 4

[Buzzz]

[quote="Nayfe"]Oui pour des munitions c'est possible, par contre ça ne peut pas s'étendre pour les avions, car un avion qui ne bouge pas n'est pas forcément détruit ]

Bien sûr pour l'instant, ma remarque ne s'appliquait qu'aux munitions.
Sinon, tu n'as pas trouvé l'indicateur d'évennement dans l'acmi, qui pourrait correspondre à "avion touché" ou "avion détruit"?

[Couby]

Pour la conversion des coordonnées, je ne suis pas convaincu que chercher la fonction inverse de la projection de Closter donne le résultat escompté.
A mon avis cela va faire beaucoup de calculs pour un résultat final plutôt moyen compte tenu des approximations au départ.

J'aurai plutôt tendance à proposer une méthode plus basique et brutale ...
Faire le relevé d'un bon petit paquet de points couvrant les largeurs du théâtre (avec la carte dans TacEdit et les coordonnées X, Y Falcon d'un côté, et Google Earth de l'autre pour les coordonnées réelles correspondantes), et faire tout simplement une interpolation polynomiale (il y a des applets qui font ca tout seul, suffit de chercher un peu sur le net ).
Et roule ma poule, à mon avis le résultat sera "suffisant".

Après cela implique de chercher ces fonctions pour chaque théâtre, et de faire une sélection au moment de la conversion pour préciser dans quel théâtre a été pris l'ACMI.

Ca n'est certes pas rigoureusement super fantastique, mais à mon avis ca doit marcher. Et il n'y a pas besoin de trouver une bête en math pour faire ca, il suffit juste d'un petit peu de temps.

Bon après si vous trouvez votre mathématicien pour vous trouver des formules buques carrées... tant mieux.

[berkoutskaia]

C'est un peu ce à quoi je pensais. C'est brutal et peu élégant... mais dans u premier temps c'est le plus efficace.

Et ça n'empêche pas de travailler sur quelque chose de "propre" par ailleurs

[Buzzz]

c'est un peu ce que j'avais fait il y a un temps pour mon petit logiciel GPS pour falcon. J'utilisais Oziexplorer, et en fait, au début pout calibrer ma carte, j'avais donné plusieurs points remarquables au logiciel et il avait tenté de faire une interpolation.

[Nayfe]

J'ai préparé une archive avec une sortie debug du fichier binaire avec son acmi associé en attendant que je rajoute une ptite case pour switch entre le mode debug et le mode normal si ça interesse quelqu'un
http://ogm2000.free.fr/debug_example.tgz

---------------------------------------------------------------------------------------------------------

Sinon, tu n'as pas trouvé l'indicateur d'évennement dans l'acmi, qui pourrait correspondre à "avion touché" ou "avion détruit"?

Ya des flags que je n'ai pas réussi à déchiffré par faute de temps, et surement que certains correspondent à ça

---------------------------------------------------------------------------------------------------------
Moi je suis ouvert à toute proposition pour essayer de coller un peu plus à la réalité que ça soit de manière formelle et mathématique ou empirique avec la méthode décrite par Couby
Je n'ai pas le temps pour l'instant de faire des mesures pour cette méthode, mais
si ça tente quelqu'un ya pas de souçis pour implémenter par la suite une fonction de conversion
Sinon par pure curiosité je me demande ce que l'on peut considéré comme
repère géographie fiable pour ce genre de mesures ? (des grosses montagnes?,des îles?, des objets spécifiques?, la côte? ).

---------------------------------------------------------------------------------------------------------
pour rappel :
Vhs2txt (mode console) http://ogm2000.free.fr/ParseVhsToTxt-win32.7z
Vhs2txt (mode Gui) http://ogm2000.free.fr/vhs2txt-0.2.7z

[Buzzz]

je dirais que ça dépend du niveau de précision qu'on souhaite avoir

Nayfe, je viens d'ouvrir le fichier debug et c'est une vraie mine d'or. Je vais faire ma petite analyse, mais je pense qu'on peut récupérer des infos intéressantes.

[Electro]

Sinon par pure curiosité je me demande ce que l'on peut considéré comme
repère géographie fiable pour ce genre de mesures ? (des grosses montagnes?,des îles?, des objets spécifiques?, la côte? ).

Je pense que 1/ villes et 2/ aéroports sont plus fiables que jouer sur le reprérage de montagnes, etc... non ?

[Nayfe]

Pour un ptit exemple de ce que je sais déjà sur le débug et qui est utilisé :

Code : Tout sélectionner

[color="Wheat"]--------------------------------- ---Reading Entity #0 (80)--- ---------------------------------[/color] [color="PaleGreen"]uniqueID: 1[/color] = numero de l'entité (connu & utilisé) [color="PaleGreen"]type: 2393[/color] = modèle de l'entité (F16,M2K,TOWER,...) [color="Wheat"]count: 1[/color] = nombre d'entité de ce type (connu & pas utilisé) [color="PaleGreen"]flags: 4[/color] = type de l'entité (avion,objet,missile,chaff,flare..) [color="Plum"]leadIndex: 8030024[/color] = ?? [color="Plum"]slot: 0[/color] = ?? [color="Plum"]specialFlags: 219464508[/color] = ?? [color="PaleGreen"]firstPositionDataOffset: 35504[/color] = offset (connu & utilisé) [color="PaleGreen"]firstEventDataOffset: 2688737[/color] = offset (connu & utilisé)

Code : Tout sélectionner

[color="PaleGreen"]--------------------------------- --Reading Entity Pos (35545)-- ---------------------------------[/color] [color="PaleGreen"]time: 51944,441406[/color] = temps en seconde de la frame (connu & utilisé) [color="PaleGreen"]type: 0[/color] = 0=entitypos, 1=switchpos, 2=DOFpos [color="PaleGreen"]x: 2572946,750000[/color] :) [color="PaleGreen"]y: 631123,687500[/color] :) [color="PaleGreen"]z: -1421,000000[/color] :) [color="PaleGreen"]pitch: 0,000000[/color] :) [color="PaleGreen"]roll: 0,000000[/color] :) [color="PaleGreen"]yaw: 0,000000[/color] :) [color="Wheat"]radarTarget: -1[/color] = numero de l'entité pointé (tacview interpole) [color="PaleGreen"]nextPosUpdateOffset: 43376[/color] [color="PaleGreen"]prevPosUpdateOffset: 0[/color]

Code : Tout sélectionner

[color="Plum"]-[Switches non gérés par tacview]- --------------------------------- --Reading Entity Pos (12673590)-- ---------------------------------[/color] [color="Wheat"]time: 52385,464844[/color] [color="Wheat"]type: 1[/color] = switch [color="Wheat"]switchNum: 7[/color] = cf lodeditor [color="Wheat"]switchVal: 1[/color] [color="Wheat"]prevSwitchVal: 0[/color] [color="Wheat"]nextPosUpdateOffset: 12675230[/color] [color="Wheat"]prevPosUpdateOffset: 12673549[/color]

Code : Tout sélectionner

[color="Plum"]-[DOF non gérés par tacview]- --------------------------------- --Reading Entity Pos (12672688)-- ---------------------------------[/color] [color="Wheat"]time: 52385,464844[/color] [color="Wheat"]type: 2[/color] = DOF [color="Wheat"]DOFNum: 31[/color] = cf lodeditor [color="Wheat"]DOFVal: 0,505739[/color] [color="Wheat"]prevDOFVal: 2,600194[/color] [color="Wheat"]nextPosUpdateOffset: 12672729[/color] [color="Wheat"]prevPosUpdateOffset: 12672647[/color]

Code : Tout sélectionner

[color="Plum"]-[pas pris en compte pour l'instant]- --------------------------------- --Reading Event Header #0 (12693065)-- ---------------------------------[/color] [color="Wheat"]eventType: 6[/color] //5=objet statique, 6=objet qui bouge, 0-4&7-14 connus cf src/gEH.c [color="Wheat"]index: 0[/color] = numero de l'objet [color="Wheat"]time: 51945,019531[/color] = date en secondes [color="Wheat"]timeEnd: 51945,019531[/color] = date de fin de l'evenement [color="Plum"]type: 92[/color] = ?? [color="Plum"]user: -1[/color] = ?? [color="Plum"]flags: 1[/color] = ?? [color="Plum"]scale: 34,500000[/color] = echelle de l'objet(??) [color="Wheat"]x: 2546708,000000[/color] = position de l'objet [color="Wheat"]y: 605946,687500[/color] = position de l'objet [color="Wheat"]z: -1653,891968[/color] = position de l'objet [color="Wheat"]dx: 26,694483[/color] = déplacement (non présent si type=5) [color="Wheat"]dy: 12,249288[/color] = deplacement (non présent si type=5) [color="Wheat"]dz: -80,000000[/color] = deplacement (non présent si type=5) //Représente des objets non gérés par IA je pense, genre des radars en rotation, ...

Code : Tout sélectionner

[color="Plum"]-[pas pris en compte pour l'instant]- --------------------------------- --Reading Event Trailer #0 (12701190)-- ---------------------------------[/color] [color="Wheat"]timeEnd: 51950,019531[/color] [color="Wheat"]index: 0[/color] = numero de l'event (connu & non utilisé) //Index qui me semble inutile ;)

Code : Tout sélectionner

[color="Plum"]-[pas pris en compte pour l'instant]- --------------------------------- --Reading Feat Event #0 (12702190)-- ---------------------------------[/color] [color="Wheat"]time: 51944,441406[/color] [color="Wheat"]index: 0[/color] = numero de la feature event [color="Plum"]newStatus: 0[/color] = ???? [color="Plum"]prevStatus: 0[/color] = ???? //nextStatus et prevStatus toujours égaux à 0, à quoi ça sert ...

Code : Tout sélectionner

[color="Plum"]-[pas pris en compte pour l'instant]- --------------------------------- --Reading Text Event #0 (12704894)-- ---------------------------------[/color] [color="Wheat"]intTime: 50100219[/color] = temps en secondes [color="Wheat"]indexStr: 55:00[/color] = affiché dans l'acmi intégré [color="Wheat"]msgStr: Amraam joined as Falcon11 at 13:55:00[/color] affiché dans l'acmi intégré

Code : Tout sélectionner

[color="PaleGreen"] --------------------------------- --Reading Callsign #1 (12707522)-- ---------------------------------[/color] [color="PaleGreen"]label: Amraam[/color] = callsign (connu & utilisé) [color="PaleGreen"]teamColor: 6[/color] = nom de la team (c & u)

[Buzzz]

A propos des secondes, il semble qu'il y a un problème de traduction, car l'heure indiquée dans tacview ne correspond pas à l'heure de l'acmi.

Concernant les types d'events, l'acmi que tu utilises n'est malheureusement pas le plus adapté car il n'y a pas d'appareil détruit par missile.
Je pense qu'il faudrait faire différents acmi avec peu d'infos dans chacun pour avoir plus facile à décortiquer.
Genre, il faudrait limiter le nombre d'objets. limiter la durée à quelques secondes en se concentrant sur des évennements précis (tir d'un missile, hit d'un missile, explosion d'un appareil,...)
Qu'en penses-tu? Si tu es OK sur le principe, on doit pouvoir vite obtenir de tels acmis.

[Nayfe]

Oui c'est possible que ça déconne l'heure, en effet, j'avais tenté de faire un système pour que la de la mission concorde avec la date de l'enregistrement, et c'est possible que ça chie, surtout que j'avais développé ça sous unix et aussi sous windows il me sort pas les mêmes valeurs pour les mêmes fonctions
je regarderais ça plus en détail

Pour ton idée, c'est comme cela que j'avais procédé pour l'analyse de plusieurs champs mais je n'ai plus ces ACMI <<sample>>.
Le plus simple pour la communauté, c'est que je rajoute une case pour que chacun puisse obtenir les infos de debug sans avoir à recompiler le projet, ça ira plus vite que de m'envoyer des acmi pour que je sorte le debug et que je le publie

[Nayfe]

Wala qui est fait, je retourne sous windows compiler avec le bouton debug ...

( pense qu'il va pas tarder à installer un windows virtuel sous son linux :D )

Et voilà (avec la date corrigée):
http://ogm2000.free.fr/vhs2txt-0.2.7z

[Nayfe]

Bon en fait, je repère bien la date, mais en fait comme mes frames ne commencent pas à 0, ben ça rajoute 2 fois la date ...

Un hotfix corrige ça

[Buzzz]

Je continue mes investigations et lance une nouvelle idée. Pour l'explosion d'un avion ou son crash dans le décor, il y a une grosse différence avec un aterro : la décélération. Dans le cas d'un aterro, tu as un ralentissement progressif, alors que pour une explosion, tu as une chute de vitesse très très importante. Lorsque tu détecte une vitesse nulle sur un avion, il faudrait remonter le temps d'une frame pour voir la vitesse précédente et se fixer un différentiel maxi au delà du quel on considère que l'avion a été détruit.

[Nayfe]

Pas con comme idée

[Buzzz]

Rien n'empêche de laisser l'avion encore quelques secondes dans l'acmi après la détection de vitesse nulle. Si la vitesse reste nulle après x secondes, l'avion est considéré comme détruit, sinon on met ça sur le compte d'un freeze.

[Nayfe]

En fait, ça pose pas de problème ce que j'ai dis précédemment, car en fait,
ce qui nous interesse c'est les deux ou trois dernières frames de chaque entité, car tant qu'une entité ne bouge pas, elle ne génère pas de nouvelles entrées.

Par contre je sais pas si quelqu'un a testé l'exe 0.2, mais moi ça met super longtemps à se lancer gtk sous windows ... c'est étrange

[berkoutskaia]

Ca me le fait pas

En même temps j'utilise pidgin, donc GTK est déjà chargé (à noter que même avec pigin fermé, c'est toujours très rapide )

[Nayfe]

tant mieux :D

[Couby]

Je pense que 1/ villes et 2/ aéroports sont plus fiables que jouer sur le reprérage de montagnes, etc... non ?

Pas vraiment Electro , les objets dans Falcon n'ont pas vraiment toujours des positions fiables, surtout les aéroports d'ailleurs.

Le mieux ce sont les côtes. Elles sont très bien retracées dans Falcon, et on peut très aisément identifier ainsi des points communs entre la carte Falcon et l'image satellite sur Google Earth.

Le défaut de la méthode que je propose je pense est surtout au niveau de la conversion des X. Pour les Y comme on est sur les grands cercles l'approximation va être correcte.
En revanche au niveau des X il devrait y avoir un facteur lié à quelque chose du genre cos Ly. Ceci dit on peut évaluer ce que ca donne et voir si vraiment le résultat nécessite une meilleure précision.

Si personne n'a le temps d'y jeter un oeil, j'essairai de voir ca lundi.

[Buzzz]

En fait, ça pose pas de problème ce que j'ai dis précédemment, car en fait,
ce qui nous interesse c'est les deux ou trois dernières frames de chaque entité, car tant qu'une entité ne bouge pas, elle ne génère pas de nouvelles entrées.

Par contre je sais pas si quelqu'un a testé l'exe 0.2, mais moi ça met super longtemps à se lancer gtk sous windows ... c'est étrange

Je n'ai pas ce problème.
Par contre, sur un acmi particulier, la conversion a été particulièrement longue (plus de 15 minutes) alors que l'acmi n'était vraiment pas gros.

[Nayfe]

Mes algos sont assez pourris niveau complexité, ya des chances pour que ça prenne du temps dans le cas où les entités sont mal triés à l'origine

mais un jour je reprendrais tout from scratch mais pour l'instant je peux pas

[Nayfe]

Bon bon bon, quelques jours ont passé, j'ai pas fais grand chose,
juste un ptit changement d'implémentation de liste.

Pour rentrer dans les détails, anciennement j'utilisais un GList (liste doublement chaînée issue de la Glib) et quand je rajoutais un élément dans la liste, l'algo utilisé parcourait chaque fois toute la liste ... si liste de taille N et M ajout on tappe le O(N*M), pas top .

J'suis donc passé à une GQueue, qui a l'avantage de faire un ajout d'element en O(1) et donc si j'ajoute M element dans une GQueue de taill N, ça reste lineaire O(N).

Chez moi, les perfs se ressentent vraiment et voici la nouvelle version :
(Je laisse l'ancienne version si ça vous tente de tester ce qui marche le mieux)
http://ogm2000.free.fr/vhs2txt-0.3.7z (nouvelle version)
http://ogm2000.free.fr/vhs2txt-0.2.7z (ancienne version)

[berkoutskaia]

\o/

Rien de nouveau de mon coté pour les coordonées. Vu qu'on a trop peu d'infos sur la projection utilisées pour les théatres Corée et Balkans, la solution de Couby me semble la plus efficace.

Va donc falloir faire des relevés de coords dans F4 et GoogleEarth

[Nayfe]

J'pensais à un autre truc à l'instant, les coordonnées dans les acmis sont sous la forme de (X,Y) et sont convertis pour un affichage sous forme de (latitude/longitude). C'est ptetre plus simple d'analyser directement les X,Y que les trucs déjà converti ?

Code : Tout sélectionner

#define FT_TO_METERS 0.30488F #define FT_PER_DEGREE FT_PER_MINUTE * 60.0F #define FT_PER_MINUTE 6087.03141F #define EARTH_RADIUS_FT 2.09257E7F #define DTR 0.01745329F #define RTD 57.2957795F #define DEG_TO_MIN 60 #define LAT_ORIGIN 33.843750 #define LONG_ORIGIN 123.00 latitude = (((LAT_ORIGIN * FT_PER_DEGREE + x) / EARTH_RADIUS_FT) * RTD) - LAT_ORIGIN; longitude = ((((LONG_ORIGIN * DTR * EARTH_RADIUS_FT * cos(latitude)) + y) / (EARTH_RADIUS_FT * cos(latitude))) * RTD) - LONG_ORIGIN;

Mon code est bien sûr calqué sur SP3.

[berkoutskaia]

Ce sera effectivement plus simple à "injecter" dans le code, mais pour se recaler sur les coordonées Google Earth, il faudrait savoir comment on passe de {lat. ; longi.} de Falcon à {x;y} du .vhs