Author Topic: [C++] Gros bug (Read 16421 times)

picto · 16 September 2007, 23:53:54

Quand je lance un scenario avec le focus camera sur un MMU j'ai un crash ici ...
oapiTriggerPanelRedrawArea (0, AID_MFD1LEFTLIGHT);
Ca n'a rien à voir avec MMU.
Je n'ai pas le moindre début d'idée sur le pourquoi ni sur la façon d'y remédier ...

Ca viens d'un appel à un trigger que je fais au premier post step pour pouvoir lier une
lumière assignée aux MFDs que je fais avec un test sur l'état sauvegardé d'un MFD ...

Les appels de fonction dans le premier post step ...

ToggleMfd1PowerLight ();
ToggleMfd2PowerLight ();

Et la fonction ...

   int mode = oapiGetMFDMode(0);
   if (mode != MFD_NONE )
      bBottomLightMfd1Status = TRUE;
   else
      bBottomLightMfd1Status = FALSE;
   oapiTriggerPanelRedrawArea (0, AID_MFD1LEFTLIGHT);
   oapiTriggerPanelRedrawArea (0, AID_MFD1RIGHTLIGHT);

Rien de bien méchant, mais si je ne fais pas ça au premier post step, les lumières ne
sont pas accordées à l'allumage ou non d'un MFD et ça fait un peu naze ...

Et je ne vois vraiment pas ou faire ce test autrement

Message modifié ( 17-09-2007 00:08 )

DanSteph · Reply #1 - 17 September 2007, 00:45:53

Il m'est arrivé des truc bizarre aussi avec les oapi... comme si Orbiter essayait de rafraichir
alors qu'il n'avait pas le focus (pas de panel affiché=CTD)

Peut être y avait il une autre solution mais comme j'en avais marre
et je soupconnais une couille dans Orbiter J'ai résolu avec un "Truc"

Declare une nouvelle fonction :

oapiMyTriggerPanelRedrawArea()

Dans cette fonction tu teste si tu a le focus (getHandleFocus=GetHandle ou un truc comme ca)
et tu return si faux (pas de panel, fait rien)... sinon tu appel la fonction normale:
oapiTriggerPanelRedrawArea avec les params passé a "My"

Une fois fait et testé avec un trigger (et un pas a pas debug pour être sur) remplace (CTL+H) TOUT les oapiTriggerPanelRedrawArea normaux par oapiMyTriggerPanelRedrawArea (sauf
le seul qui doit rester dans la fonction elle meme)

Comme il n'a pas le focus de toute maniere quand on refais un focus un "triggerarea" est declenché...
donc pas de bug d'affichage a craindre.

A++

Dan

Message modifié ( 17-09-2007 00:48 )

picto · Reply #2 - 17 September 2007, 00:56:54

C'est ce que j'étais en train de me dire ... :grat: :grat:

Ca zappe le initpanel ... mais pourquoi Orbiter fait il
cette boucle alors qu'il n'a pas le focus sur Boulinium ?
Mystere et boulinium

Merci pour la soluce ... çà a l'air plutôt délicat à faire mais je vais tenter le coup .

PS : "T'es sûr que c'est pas une couille de UMMU ?

... "

Message modifié ( 17-09-2007 00:59 )

DanSteph · Reply #3 - 17 September 2007, 01:09:57

Quote

picto a écrit:
Merci pour la soluce ... çà a l'air plutôt délicat à faire mais je vais tenter le coup .

Délicat nan, 4 lignes un replace all et c'est baché...

Quote

picto a écrit:
Ca zappe le initpanel ... mais pourquoi Orbiter fait il

Martin est comme nous... des fois il n'a pas les bras en croix, ne multiplie
pas les petits pain et fais des grosses c... bulles.

Quote

picto a écrit:
PS : "T'es sûr que c'est pas une couille de UMMU ?

UMMU viendrait tripoter ton panel avec ses petits doigts musclé ?

Mais nan, quand j'ai eu ce bleme UMMU n'existait pas

Dan

picto · Reply #4 - 17 September 2007, 01:19:02

Nan, avec sa cou... gauche ... celle qui pend

Ce qui est délicat, c'est le remplacement des fonctions.
Si ça foire, j'en ai pour quelques heures à réparer ...

J'ai trouvé ça qui se rapproche de ce que tu décris.
OAPIFUNC OBJHANDLE oapiGetFocusObject ();
OAPIFUNC VESSEL *oapiGetFocusInterface ();

Les autres GetFocus de l'oapi n'ont rien à voir avec la choucroute.

DanSteph · Reply #5 - 17 September 2007, 01:20:49

Quote

picto a écrit:
Ce qui est délicat, c'est le remplacement des fonctions.
Si ça foire, j'en ai pour quelques heures à réparer ...

Ben euh.. non...

(toi aussi t'est en 1019 ?

)

si ca foire tu remplace all "oapiMyTriggerArea" par "oapiTriggerArea", retour a la case départ.

Dan

DanSteph · Reply #6 - 17 September 2007, 01:24:06

Un bidule dans le genre (faut regarder le prototype de oapiTriggerPanelRedrawArea

Code: [Select]

oapiMyTriggerPanelRedrawArea(int Panel,int Number)
{
     if(oapiGetFocusObject()!=GetHandle())
          return;
     oapiTriggerPanelRedrawArea(Panel,Number);
}

après juste ce gaffer qu'on "remplace all" pas celui dans "my"
(en bref le remettre comme avant le replace all)

Dan

Message modifié ( 17-09-2007 01:24 )

picto · Reply #7 - 17 September 2007, 01:27:13

Essaye ça sur le DGIV
Remplace 0 par 1 .... puis
1 par 0 ....
puis après .... répare !

DanSteph · Reply #8 - 17 September 2007, 01:28:32

Avec les replace all faut juste ce gaffer quand on mets des modifications au debut ou fin,
ou que le nom entier n'est pas hyper spécifique...

oapiTiggerReplaceArea_MY()

un "replace" de plus et tu a ca:

oapiTiggerReplaceArea_MY_MY()

Des fois ca donne des cas ou justement tu ne peux plus "revenir en arrière"

Le replace all c'est juste 5 secondes de terreurs pur quand on le fais
mais on a le temps de ce calmer pendant les deux mois qu'on passe
à tout récuperer...

Dan

Message modifié ( 17-09-2007 01:30 )

picto · Reply #9 - 17 September 2007, 01:37:33

Tu comprend pourquoi je bossais souvent sur Notepad au départ ...

Paske des doubles changements en faisant pas trop gaffe , j'en ai fait quelques uns ...

DanSteph · Reply #10 - 17 September 2007, 01:45:59

Quand on a chié un prog ou deux après on est hyper concentré
et ca passe... avec un backup oeuf normand

marre de la prog ? cliquez "replace all"

Dan

picto · Reply #11 - 17 September 2007, 02:03:20

Bon .... ça fonctionne mais c'est pas parfait au niveau des sauvegardes Orbiter.
Plusieurs cas ...

Si focus cockpit puis quitte ... relance nickel les MFDs sont retrouvés dans le même état avec les petites loupiotes.
Si focus Boulinium vue extérieure .... nickel aussi.
Si focus Cockpit virtuel .... nickel.
Par contre si focus MMU intérieur ou extérieur ... pas de sauvegarde de l'état des MFDs.
Si focus Panel du bas .... pas de sauvegarde des MFDs non plus.
Et je pense que c'est pareil si focus sur un autre vessel que MMU.

J'ai envie de faire les sauvegardes des MFDs moi même

Je sais pas si c'est pas dangereux ça ... Double emploi dans certains cas ?

Par contre, merci

plus de crash sur le trigger au premier post step

picto · Reply #12 - 17 September 2007, 02:06:36

C'est pas mal ta combine ...

C'est à se demander si on peut pas faire un addon encore
plus stable qu'Orbiter en mettant ce genre de fusible sur
la moindre fonction.

Message modifié ( 17-09-2007 02:07 )

DanSteph · Reply #13 - 17 September 2007, 02:07:38

Les MFD ca a toujours été un prob, leurs états quand on switch focus ou sauvegarde/restore
n'est pas garanti par orbiter... (switch dans un boulinium suivant le mfd dans l'autre
il a changé aussi)

En utilisant les clbkMFD et des variables de classes on doit pouvoir les faire nickel
et spécifique a un vessel mais attention au imfd et autres qui on des systèmes
spécifique.

Me suis jamais trop emm.. avec ca en fait.

Dan

picto · Reply #14 - 17 September 2007, 02:10:38

Pour les MFDs ...
Il y a ça ...
Ce pourrait être le minimum syndical à sauvegarder ...

#define MFD_NONE 0
#define MFD_ORBIT 1
#define MFD_SURFACE 2
#define MFD_MAP 3
#define MFD_HSI 4
#define MFD_LANDING 5
#define MFD_DOCKING 6
#define MFD_OPLANEALIGN 7
#define MFD_OSYNC 8
#define MFD_TRANSFER 9
#define MFD_COMMS 10
#define MFD_USERTYPE 64

On peut même conserver le usertype

DanSteph · Reply #15 - 17 September 2007, 02:13:22

Quote

picto a écrit:
C'est pas mal ta combine ...
C'est à se demander si on peut pas faire un addon encore
plus stable qu'Orbiter en mettant ce genre de fusible sur
la moindre fonction.

Normalement martin à bien protegé tout sauf sur certains truc,
si probs ouais c'est utile.

Ce qui m'etonne depuis 5 ans c'est les CTD a cause de meshes
ou textures absente... pourtant c'est des handles... NULL=return;

Quelque chose me fait penser que dans le code à Martin tout n'est
pas aussi clair et angélique... on à tous nos moments...

Alors maintenant que tu est bien introduit (aah) qu'en pense tu de
la prog: de l'art ou du cochon ?

Franchement comme créativité ca ce pose la , mais même le code
à ses beautés et ses zones d'ombres... ses coup de génie et ses
cafouillages laborieux...

Dan

DanSteph · Reply #16 - 17 September 2007, 02:14:47

Quote

picto a écrit:
Pour les MFDs ...
Il y a ça ...
Ce pourrait être le minimum syndical à sauvegarder ...

Me suis pas fait ch...
si a terre par defaut un surface un orbit si en l'air un orbit et un autre, je sais plus...

visiblement ca dérange personne... pas eu de retour.

Dan

picto · Reply #17 - 17 September 2007, 02:33:00

De l'Art ... sûrement dans le sens outil au service de la créativité.
Là, c'est indéniable ... je me rend compte qu'avec un certain niveau
de connaissance, la seule limite est l'imagination.
Pareil sur le regard qu'on porte sur ce qui nous entoure.
Chacun a sa vision des choses, et les mêmes moyens à disposition.
La seule façon de faire "autrement", "différent" est d'essayer de
donner à voir ... donc de faire voir le monde aux autres tel qu'on le voit.
Donc, comme en peinture ....

Sur les moyens ... je n'en suis pas encore là

J'en suis encore à faire du travail de singe je crois ...
Donc je ne peux pas encore vraiment me rendre compte.

Je vais prendre un exemple, ce sera plus simple.
Quand je repense à ce que tu as fait pour le modèle de vol SW.
Tu t'es posé un problème, tu as fouillé dans l'oapi pour voir ce qui t'était proposé
puis tu as créé une routine la plus simple et efficace possible ... donc belle.

Sur le cas d'un test de collision par exemple, je n'ai pas le moindre petit
début d'idée sur comment faire. Ou si, mais peut être est ce une mauvaise idée.
Si je te dis que je ne sais pas encore comment gérer des fichiers externes mais
pas globalement ... je veux dire les lire et les utiliser de l'intérieur comme on fait
avec les scenarios, vois tu ce que j'ai en tête ?

Enfin, tu vois quoi ... c'est laborieux et pas vraiment talentueux.

Mais je pense être sur la bonne voie ...
Ce qui me rassurre, c'est que comme en peinture, sans travail, le talent n'est rien.
Et le travail peut compenser un manque de talent ... le tout étant
d'accepter ses limites mais de faire au mieux à l'intérieur de celles ci.
Pour l'instant, je dirais que c'est un univers étrange et fascinant.

Et finalement,
Je suis content car ça rejoint petit à petit une idée qui me trotte dans la tête
depuis les Beaux Arts et qui, j'espère pourrait m'amener un jour aux demoscènes.

Message modifié ( 17-09-2007 02:42 )

picto · Reply #18 - 17 September 2007, 02:34:16

Quote

ca dérange personne... pas eu de retour.

Si

Mais je pensais qu'on avait pas le choix

DanSteph · Reply #19 - 17 September 2007, 02:45:08

Après il y a la maitrise de l'outil, débutant en peinture je n'ai aucune liberté
à part faire des splatch et des splotch (bon mauvais exemple, certains font
des splotch et vendent ca très cher)

Mais en prog quand tu commence a maitriser la il y a vraiment la "patte"
outre l'effet final...

Collision il faut deja arrivé à controller un mesh en "local", après
a mon avis la piste standard des jeux est mauvaise (tree), après tout
on ne teste qu'une centaine de poly toujours les mêmes, donc on fait
une "boite virtuel" un poil plus complexe et on test avec ca... beaucoup
plus optimisé. C'est mon idée en tout cas faudra que je test le concept.

Quote

Si je te dis que je ne sais pas encore comment gérer des fichiers externes mais
pas globalement ... je veux dire les lire et les utiliser de l'intérieur comme on fait
avec les scenarios, vois tu ce que j'ai en tête ?

non ? un fichier config externe ? une liste de passager ?
moi je reste avec le bon vieux fopen, apres ca dépend des données...
on peut lire un fichier config "humains" (lisible) ou un simple fichier
de donnée bien "packée" comme en interne... le deuxieme cas prend
une ligne et une structure. le premier c'est plus complexe.

Dan

picto · Reply #20 - 17 September 2007, 03:15:16

Ah, ben si, c'était presque ça mon idée ...

Aller lire les fichiers meshs (la difficulté étant de trier les bonnes
infos) et de se fabriquer un "faux Dummy" interne pour gérer les collisions ...

Message modifié ( 17-09-2007 03:15 )

DanSteph · Reply #21 - 17 September 2007, 03:19:52

moi je le ferais même methode que toi mais sur
un mesh grossier tracé dans 3dmax et exporté à part.

Mais je ferais ce genre de truc quand j'aurais 6 mois
de libre... c'est pas demains

Dan

picto · Reply #22 - 17 September 2007, 03:22:01

Quote

quand j'aurais 6 mois de libre

D'accord ... je vais oublier alors

Il me faudrait 20 ans pour y arriver donc !:lol:

picto · Message modifié ( 17-09-2007 04:07 )

Message modifié ( 17-09-2007 04:07 )

picto · Reply #24 - 21 September 2007, 14:37:39

Hors de la classe
enum
{
   DOCK_0_PANELSTATUS,
   DOCK_1_PANELSTATUS,
   DOCK_2_PANELSTATUS,
   FIN_DOCK_PANELSTATUS,
};

typedef struct{
   int iInnerDoor;
   int iOuterDoor;
   int iChamber;
   double dPressure;
   bool bFlagPourFaireChuterLaPression;
   bool bFlagPourFaireMonterLaPression;
}DOCKSTATUS;

Dans la classe
DOCKSTATUS PanelDockStatus[FIN_DOCK_PANELSTATUS];

initialisation
void Irridium::clbkSetClassCaps (FILEHANDLE cfg)
{
   for (int merde=0;merde>=2;merde++)
   {
   PanelDockStatus[merde].iOuterDoor=CLOSED;
   PanelDockStatus[merde].iChamber=CLOSED;
   PanelDockStatus[merde].iInnerDoor=CLOSED;
   PanelDockStatus[merde].bFlagPourFaireChuterLaPression=FALSE;
   PanelDockStatus[merde].bFlagPourFaireMonterLaPression=FALSE;
   PanelDockStatus[merde].dPressure=100.00f;
   }

DansPoststep
sprintf(oapiDebugString(),"PRESSION %i",int(PanelDockStatus[1].dPressure));

Et j'obtiens ça .... sans avoir tripoté ces fuckeries de variables ...

Deux jours que c'est la panne complète ...

Et la preuve que je ne la tripote pas avant de faire l'affichage !!!

Message modifié ( 21-09-2007 17:03 )