Tacview 0.93

[Nayfe]

Donc en fait les entités correspondent aux parents 516(GBU31 vs Chaff) et 270(FAP500 vs Flares) .
Falcon les détectent bien comme type 8 et 16 respectivement et donc correspondant bien à chaff et flares.
Reste à savoir si les entrées sont <<multiplexées>> ou pas :

Es-ce qu'il existe le même identifiant_type pour la GBU31 et les chaffs, et qu'il faut regarder le flag_falcon (8) pour différencier l'un ou l'autre,
ou es-ce que le nom du parent 516 est foireux et n'est pas associé à une GBU mais bel est bien a un chaff.

Dans le premier cas, il faut modifier le programme interne, dans l'autre cas, il suffit de modifier la base de données.

Pour le savoir, on pourrait imaginer que quelqu'un fasse un ACMI équipé de toutes les GBU31 possibles en lancant quelques chaffs, pour voir si les GBU31 correspondent à un autre parent ou si le parent n'est pas l'unique déterminant.

[Nayfe]

version 10/28/08-0

* ChangeLog :
- fixé : FAP500 et GBU31 au lieu de leurres

* TODO :
- revoir : gestion des THEATER.MAP
- revoir : répertoire par défaut
- revoir : vanish time

[Nayfe]

version 10/28/08-1

* ChangeLog :
- maj. : prise en compte de la DB à ce jour.

* TODO :
- revoir : gestion des THEATER.MAP
- revoir : répertoire par défaut
- revoir : objet parent (missiles)
- revoir : destructions des objets
- revoir : duplication des objets (bulle)
- revoir : sortie fichier de débug
- revoir : filtrage des batiments inutiles

[AlphaFox]

C'est un bel outil, bravo aux devs, il y a du boulot derrière.
Pendant que nous en sommes aux desiderata, serait-il possible d'afficher plusieurs vues en même temps en mode fenétré ? (Avoir simultanément la vue Cockpit, satellite, ... )

[Vyrtuoz]

Pour l'instant ce n'est pas prévu d'avoir plusieurs vues 3D.

Par contre je vais ajouter une vue tactique (en plus de la vue 3D) dans une prochaine version.
(style vue satellite avec les cercles, de belles icones et tout et tout)

C'est un bel outil, bravo aux devs, il y a du boulot derrière.
Pendant que nous en sommes aux desiderata, serait-il possible d'afficher plusieurs vues en même temps en mode fenétré ? (Avoir simultanément la vue Cockpit, satellite, ... )

[hatch]

Oui c'est un très bel outil, très fluide et intuitif, merci. Et puis c'est bien pratique de pouvoir visualiser les acmis sur le bureau

[Nayfe]

Buzz je me permets de répondre à ton mp sur le thread pour répondre aux interrogations récurrentes, si ça te gène je supprimerais.

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

1) Tir des missiles, bombes, roquettes, ... : En attendant une méthode plus fiable, lors de l'apparition d'une munition, le fait mettre un "?" pour la valeur [ParentObjectID] (format Tacview) permet dans 99% des cas de trouver l'appareil ayant tiré la munition.

=> Oui, il me semble qu'on en avait déjà parlé et c'était passé à la trappe, je le mets à la TODO list.

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

2) Bulle Falcon. Un des paramètres importants dans falcon est la player bubble. Tout objet entrant dans cette bulle autour du joueur (ou du host si partie multijoueur) apparaît dans le monde 3D et est enregistré dans l'acmi. Tout objet sortant de la bulle disparait du monde 3D et donc de l'acmi.
Actuellement, le convertisseur rencontre le problème suivant : Lorsque les objets sortent de la bulle, ils sont conservés dans l'acmi Tacview. Si le joueur fait demi-tour et que ces objets entrent à nouveau dans la bulle, ils sont créés une deuxième fois et surchargent Tacview. Une nouvelle occurence de chaque objet (avion, objet statique ou véhicule) est créée à chaque fois.
Solution temporaire : Lorsqu'un objet sort de la bulle, il cesse de donner ses coordonnées. Il faudrait tester les objets dont les coordonnées existaient à l'instant T et n'existent plus à T+1. Dans ce cas, il faudrait écrire pour cet objet une ligne d'event "! 28 , <ObjectID>" (voire même "! 20 , <ObjectID>").

=> Petit souçis à ce niveau là. En fait, un objet, une fois qu'il est crée, s'il ne bouge pas, il n'y a plus aucune donnée <<position>> le concernant jusqu'à la fin,
donc on ne peut pas savoir s'il ne bouge pas ou s'il disparait. Il faudrait creuser un peu plus genre si deux objets de même type sont à la même position à epsilon pres, on les fusionne.
Mais bon reste tjrs le pb de détection de destruction.

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

3) Exception au cas précédent : la destruction d'un objet. Pour l'instant, je n'ai pas réussi à trouver le "code" de l'event falcon correspondant à un impact missile, un crash,... .
En attendant d'avoir trouvé on peut prendre pour hypothèse qu'un missile ou un avion ne met pas 0.1 seconde pour passer d'une vitesse élevée à une vitesse nulle et donc en étudiant la vitesse de ces objets (différentiel de position aux instants T et T+1) on peut déterminer facilement s'ils sont sortis de la bulle ou s'ils ont été détruits et donc créer une ligne "! 2C , <ObjectID>" au lieu de la ligne "! 28 , <ObjectID>".
Contrairement à la solution du point 1 pour le tir d'un missile, mettre "?" pour la valeur [HitObject] d'un ligne "! 2C , <ObjectID>, [HitObject]" ne permet pas de trouver à coup sûr la victime d'un missile (surtout si le missile n'a pas touché de cible). Le mieux est donc d'attendre d'avoir trouvé le code indiquant un impact missile dans l'acmi falcon.

=> Oui j'avais aussi pensé à ça, faudrait calculer le delta du vecteur vitesse à chaque instant de chaque objet qui bouge ...
Deux problemes possibles :
- grosse perte niveau perfo
- risque de fausses destructions nécessitant de nombreux ajustements.

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

4) Objets statiques : Eux-aussi sont soumis au problème du point N°2. Cependant, Dans Tacview les objets statique autres que la cible n'ont aucun intérêt réel. ce que je propose donc est de faire l'impasse sur ces objets et ne pas les créer ou enregistrer leur coordonnées dans les acmi convertis. Cela réduira la charge de tacview et limitera encore plus la taille des fichiers.

=> Le probleme ici c'est de savoir quelle est la cible j'suis pas sûr que ça soit faisable sans perte d'info interessante.
Genre le mec qui fait un TE et qui détruit un objet avec une bombe pour le trip, pas sûr que son objet soit visible.

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

5) Pour pouvoir aller plus loin : sur la dernière version du convertisseur, il n'y a plus de case à cocher de debug. ça serait intéressant de la retrouver. Par ailleurs, j'aurais un souhait concernant cette fonction. Serait-il possible d'écrire le debug à une étape plus avancée de la conversion : en l'occurence, après un classement chronologique. Cela faciliterait la recherche des events d'impact missile et de destruction ou autres trucs qu'on n'a toujours pas traduits.

=> La j'suis entièrement d'accord, c'est une fonctionnalité nécessaire, le problème c'est que j'ai fais mon prog un peu comme un connard, et que pour pouvoir activer cette fonctionnalité, faut que je revois pas mal de trucs. Ya des chances pour que je reprenne <<from scratch>> mon programme histoire de faire un truc super propre.

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

[Buzzz]

=> Petit souçis à ce niveau là. En fait, un objet, une fois qu'il est crée, s'il ne bouge pas, il n'y a plus aucune donnée <<position>> le concernant jusqu'à la fin,
donc on ne peut pas savoir s'il ne bouge pas ou s'il disparait. Il faudrait creuser un peu plus genre si deux objets de même type sont à la même position à epsilon pres, on les fusionne.
Mais bon reste tjrs le pb de détection de destruction.

Falcon sait faire la différence. Y a pas de raison qu'on n'y arrive pas. Il doit y avoir une variable quelque part qui lui dit quels objets ont vraiment disparu et lesquels sont seulement immobiles.

=> Oui j'avais aussi pensé à ça, faudrait calculer le delta du vecteur vitesse à chaque instant de chaque objet qui bouge ...
Deux problemes possibles :
- grosse perte niveau perfo
- risque de fausses destructions nécessitant de nombreux ajustements.

En fait, il ne faudrait pas calculer ce delta pour tous les objets. Juste pour ceux qui disparraissent.
Pour l'ajustement, je ne pense pas qu'il y ai de problème. En faisant un test de valeur décélération inférieure à -200m/s² tu chopes 99.99% des avions abattus par missile ou canon ou crashés

=> Le probleme ici c'est de savoir quelle est la cible j'suis pas sûr que ça soit faisable sans perte d'info interessante.
Genre le mec qui fait un TE et qui détruit un objet avec une bombe pour le trip, pas sûr que son objet soit visible.

A l'heure actuelle, étant donné que les objets statique ne sont pas placés à la bonne altitude dans Tacview, je ne vois pas l'intérêt de conserver les objets statiques. Pour la cible, je pensais plutôt utiliser la fonction de Tacview pour créer un objet placé grâce au fichier XML d'objets personnalisés. Rien ne nous empêche de créer un petit outil pour générer ce fichier XML automatiquement à partir des coordonées et de l'altitude de la cible.

=> La j'suis entièrement d'accord, c'est une fonctionnalité nécessaire, le problème c'est que j'ai fais mon prog un peu comme un connard, et que pour pouvoir activer cette fonctionnalité, faut que je revois pas mal de trucs. Ya des chances pour que je reprenne <<from scratch>> mon programme histoire de faire un truc super propre.

Entre-temps, j'ai un peu réfléchi, et le format actuel de debug peut convenir. Je suis en train de faire une macro excel pour analyser le fichier debug.
Par contre, il faut absolument virer les objets statiques dans le debug, ça facilitera grandement la tâche d'analyse.

Merci pour ton travail et ton écoute.

[Nayfe]

Mise à jour des exigences :

* TODO :
- revoir : gestion des THEATER.MAP : (Meilleure recherche du fichier THEATER.MAP dans l'arborescence de F4) //Y a t'il des problèmes au niveau des théatres "exotiques" sur AF et OF?
- revoir : répertoire par défaut : (création d'un fichier qui conserve le chemin d'acces du répertoire de falcon4)
- revoir : objet parent : (ajout de "?" pour les missiles et bombes)
- revoir : destructions des objets : (calculer le delta du vecteur vitesse)
- revoir : duplication des objets : (si un objet sort d'une bulle et y revient, ne pas le dupliquer)
- revoir : sortie fichier de débug : (rajouter la fonctionnalité permettant d'afficher toutes les variables contenues dans l'acmi)
- revoir : filtrage des batiments inutiles : (ne pas afficher les villes et tout autre objet ne servant à rien par rapport à l'ACMI)

[Nayfe]

Falcon sait faire la différence. Y a pas de raison qu'on n'y arrive pas. Il doit y avoir une variable quelque part qui lui dit quels objets ont vraiment disparu et lesquels sont seulement immobiles.

C'est pas sûr, ya ptetre un mécanisme à la con interne a F4 qu'il faudra reproduire,
mais bon faut espérer

En fait, il ne faudrait pas calculer ce delta pour tous les objets. Juste pour ceux qui disparraissent.

Le truc c'est que les objets ne disparaissent pas ils arretent juste d'être rafraichi s'il ne bougent plus

A l'heure actuelle, étant donné que les objets statique ne sont pas placés à la bonne altitude dans Tacview, je ne vois pas l'intérêt de conserver les objets statiques. Pour la cible, je pensais plutôt utiliser la fonction de Tacview pour créer un objet placé grâce au fichier XML d'objets personnalisés. Rien ne nous empêche de créer un petit outil pour générer ce fichier XML automatiquement à partir des coordonées et de l'altitude de la cible.

Oui ok, faudra voir avec les autres ce qu'ils en pensent; mais la mise en place d'un filtre permettant de générer ou non les objets statique est faisable.

Entre-temps, j'ai un peu réfléchi, et le format actuel de debug peut convenir. Je suis en train de faire une macro excel pour analyser le fichier debug.

Le seul probleme c'est que l'ancien prog en C ne prend pas en compte toutes les améliorations faites sur la version en Java, et que dans l'absolu, une version unique est plus facilement gérable

Par contre, il faut absolument virer les objets statiques dans le debug, ça facilitera grandement la tâche d'analyse.

Ouép moi j'utilise Vim et en fait en cherchant via les offset, c'est assez facile de naviger dans l'ancien format du fichier de debug.

Merci pour ton travail et ton écoute.

pas de souci

[Buzzz]

C'est pas sûr, ya ptetre un mécanisme à la con interne a F4 qu'il faudra reproduire,
mais bon faut espérer

Moi j'en suis sûr à 99% (Hé ouais, encore)

Le truc c'est que les objets ne disparaissent pas ils arretent juste d'être rafraichi s'il ne bougent plus

Comme pour au-dessus : Falcon arrive à faire la différence entre un objet qui ne bouge pas et un autre qui a disparu. ça ne se fait pas tout seul. Il y a une variable quelque part. Il faut trouver laquelle.
Je vais reprendre mon travail d'analyse sur des acmis minimalistes pris dans des zones maritimes (comme ça, pas de batiments pour saturer l'acmi inutilement)

Oui ok, faudra voir avec les autres ce qu'ils en pensent; mais la mise en place d'un filtre permettant de générer ou non les objets statique est faisable.

Tout ce que je peux te dire, c'est que sur un acmi un peu chargé, la charge supplémentaire représentée par les objets statiques est énorme.

Le seul probleme c'est que l'ancien prog en C ne prend pas en compte toutes les améliorations faites sur la version en Java, et que dans l'absolu, une version unique est plus facilement gérable

J'ai jamais dit que je ne souhaitais pas de debug sur le nouveau prog. Juste qu'il n'y a pas forcément besoin de faire évoluer le debug par rapport à avant.

[Buzzz]

Mise à jour des exigences :

* TODO :
- revoir : gestion des THEATER.MAP : (Meilleure recherche du fichier THEATER.MAP dans l'arborescence de F4) //Y a t'il des problèmes au niveau des théatres "exotiques" sur AF et OF?
- revoir : répertoire par défaut : (création d'un fichier qui conserve le chemin d'acces du répertoire de falcon4)
- revoir : objet parent : (ajout de "?" pour les missiles et bombes)
- revoir : destructions des objets : (calculer le delta du vecteur vitesse)
- revoir : duplication des objets : (si un objet sort d'une bulle et y revient, ne pas le dupliquer)
- revoir : sortie fichier de débug : (rajouter la fonctionnalité permettant d'afficher toutes les variables contenues dans l'acmi)
- revoir : filtrage des batiments inutiles : (ne pas afficher les villes et tout autre objet ne servant à rien par rapport à l'ACMI)

Pour info, la dernière version ne reconnaît pas le théatre Balkans installé sur mon falcon.
De plus, un truc intéressant serait que le répertoire d'origine pour la recherche de l'acmi soit le répertoire falcon choisi avant, ou mieux, le répertoire acmibin.

[Nayfe]

Pour l'histoire des objets détruits, j'ai ptetre une piste, en fait les flags qu'on arrive pas a analyser sont probablement des tableaux de bits sans représentation à vérifier en binaire ... je regarderais un peu plus le SP3 AcmiTape.cpp

Pour l'histoire des objets statiques, j'suis d'accord, mais ça dépend ce que l'on recherche, je préfère donner l'option à l'utilisateur de les integrer ou non

Pour l'histoire du théatre balkan non reconnu, il ya de tres fortes chances que ça soit parceque les fichiers theatre.lst et les tdf et les répertoires ne sont pas cohérents à 100% (majuscules etc)..

Enfin, c'est bien ce que je pensais de proposer par défault le répertoire acmibin une fois la sélection du répertoire racine, cette derniere se faisant semi-automatiquement :p
Le plus efficace serait de se pencher sur la lecture de la base de registre en Java/JNI, mais j'avoue ne pas avoir bcp de temps depuis mon embauche :D

[Couby]

Pour ma part s'agissant des objets statiques, je serai preneur de la solution proposée par Buzzz :
- les virer pour le moment de la tape convertie
- voir après avec le fichier xml pour les replacer correctement

[Serpentaire]

Nayfe pourrais tu remettre l'interface de l'ancien convertisseur, là je ne comprend pas ce qu'il faut faire pour convertir un ACMI

directory FALCON ? lead pursuit , battlefield operation , acmi bin?

Je ne comprends pas tout très bien


Serpentaire

[Nayfe]

heu ben rien n'a changé pour l'instant,
premier champ = répertoire racine de falcon
deuxieme champ = l'acmi a convertir

la j'suis en train de voir pour refaire mon programme bien propre et bien structurée ... ça va me prendre un peu de temps, mais c'est nessaire en cas de nouvelles évolutions...

[AlphaFox]

Vhs2txt ne fonctionne pas pour 3 ACMI AF théatre Blakan 2010, poids de chaque fichier : 25 Mo.

C'est un ACMI d'une mission en campagne, il y a donc de nombreux objets ...

Quand il fonctionne, Tacview plante, même théatre, meme poids de fichier.
En l'état actuel du dev, normal ou pas ?

[Buzzz]

même si c'est en campagne, 25Mo c'est relativement petit.
J'ai déjà converti des acmi de 200Mo sans problème. La cause du plantage n'est peut-être pas la taille

[Nayfe]

Vhs2txt ne fonctionne pas pour 3 ACMI AF théatre Blakan 2010, poids de chaque fichier : 25 Mo.

C'est un ACMI d'une mission en campagne, il y a donc de nombreux objets ...

Quand il fonctionne, Tacview plante, même théatre, meme poids de fichier.
En l'état actuel du dev, normal ou pas ?

Heu oui, ya un souçis au niveau du théatre Balkan apparement ...

En fait, le programme lit le theater.lst, tous les .tdf dans le répertoire en question, et suis les chemins décrits pour chercher les THEATER.MAP et j'ai l'impression que ces fichiers theater.lst et *.tdf ne sont pas à jour ou ne décrivent pas correctement les chemins d'acces (majuscules non respectés?).

Le probleme c'est que j'ai pas AF d'installer et sur mon OF, j'ai pas les Balkans.

[AlphaFox]

Bien, on se contentera de l'ACMI d'AF .... Faute de grives , etc ...

[Nayfe]

Bien, on se contentera de l'ACMI d'AF .... Faute de grives , etc ...

T'inquiètes pas, ça va marcher un jour ...

La j'ai juste un gros souçis au niveau conception ... Mon truc est devenu assez dur à maintenir car à base de patches successifs sans trop réfléchir ...

Ya des chances pour que je reprenne mon truc à zero tant que je peux le faire ... la j'suis en plein dans les diagrammes UML & co ... Après dès que j'ai une structure solide, je repars dans le developpement ...

Ah la jeunesse ... on part sans réfléchir et on se retrouve coinçé

[AlphaFox]

T'inquiètes pas, ça va marcher un jour ...

La j'ai juste un gros souçis au niveau conception ... Mon truc est devenu assez dur à maintenir car à base de patches successifs sans trop réfléchir ...

Ya des chances pour que je reprenne mon truc à zero tant que je peux le faire ... la j'suis en plein dans les diagrammes UML & co ... Après dès que j'ai une structure solide, je repars dans le developpement ...

Ah la jeunesse ... on part sans réfléchir et on se retrouve coinçé

T'inquiète je connais : on part pour développer une applet et l'on se retrouve avec une usine à gaz qui, en plus, fait le café. Si la structure n'est pas blindée dès le départ, effectivement il y a un moment où il faut le faire ...
Bon courage ...

[Serpentaire]

Nayfe fait il continuer à remplir la base de données ?

Serpentaire

[Nayfe]

Oui bien sûr, ça c'est un truc qui sera tjrs nécessaire

[Nayfe]

version 11/03/08-3

* ChangeLog :
- maj. : prise en compte de la DB à ce jour.
- maj : gestion des THEATER.MAP (dites si ça marche mieux pour les Balkans plz ?)
- maj : répertoire par défault des acmis : répertoire trouvé automatiquement.
- maj : objet parent : (ajout de "?" pour les missiles et bombes)
- maj : filtrage des batiments inutiles

* TODO :
- revoir : destructions des objets : (calculer le delta du vecteur vitesse)
- revoir : duplication des objets : (si un objet sort d'une bulle et y revient, ne pas le dupliquer)
- revoir : sortie fichier de débug : (rajouter la fonctionnalité permettant d'afficher toutes les variables contenues dans l'acmi)
- revoir : répertoire par défaut de F4
- revoir : "?" au début