Dan's Orbiter page
Orbiter Francophone => Création Orbiter Francophone => Topic started by: picto on 03 October 2007, 23:38:19
-
J'ai un problème de sauvegardes.
Je tourne en rond pour essayer de mettre au point un système qui permette
de travailler les constantes du vaisseau pour les moteurs, réservoirs et ISP ...
temporairement.
Un peu à la manière de Boulicraft, mais par lecture scenario pour faire vite.
Vu que ce sont des const double j'ai essayé d'en faire des variables doubles de classe
mais visiblement Orbiter n'aime pas trop ...
Et je n'ai aucune idée sur comment détourner le truc pour faire cette mise au point.
Scn.SavedVariable("MAIN_THRUST", &MAX_MAIN_THRUST);
Scn.SavedVariable("IONIC_THRUST", &MAX_IONIC_THRUST);
Scn.SavedVariable("RCS_THRUST", &MAX_RCS_THRUST);
Scn.SavedVariable("MAX_TANK1", &MAX_TANK1_CAPACITY);
Scn.SavedVariable("MAX_TANK2", &MAX_TANK2_CAPACITY);
Scn.SavedVariable("MAX_RCS_FUEL", &MAX_RCS_FUEL_CAPACITY);
Scn.SavedVariable("EMPTY_MASS", &EMPTY_MASS);
Message modifié ( 03-10-2007 23:42 )
-
Ben pas bsoin de constante, tu fait des variables normale de classe:
double MAX_MAIN_THRUST;
Dans clascap tu les initialise a une valeur par defaut au début:
MAX_MAIN_THRUST=20000;
Et tu cree tes moteurs avec....
Au chargement du scenario tu redefini tes moteurs après le chargement des variables éventuellement changée.
Une constante c'est une variable tout a fait comme les autres, tu *promet* juste au programme que tu ne les
changera jamais, ca lui permet de faire quelques optimisations dessus.
Oublie pas après chargement et avant definition des moteurs de les proteger contre les ecritures
foireuse des scn avec des minimum et maximum.
Ca, ca force la valeur a etre plus grande que 10000 et plus petite que 30000:
MAX_MAIN_THRUST=min(30000,max(MAX_MAIN_THRUST,10000));
Tant qu'on lui passe un truc "dans les clous" c'est bon, si on passe en dehor c'est forcé..ie:
si tu passe 5000 ce sera forcé a 10000 si tu passe 100'000 ce sera forcé à 30000
A++
Dan
Message modifié ( 04-10-2007 00:38 )
-
OK, je ne savais pas dans quel ordre Orbiter faisait le boulot entre la création
des moteurs et le save restore.
J'avais décidé de ne pas faire d'initialisation dans classcap pour être sûr
que les valeurs utilisées seraent bien celles définies dans le scenario. :sick:
Visiblement, c'était une boulette :badsmile:
Je pensais vraiment que la position dans class cap du save restore et l'écriture
du premier scenario serait suffisante pour que ce ne soit pas foireux.
Je vais essayer et je prend aussi le coup du min max .... c'est très bien.
Même si ce n'est destiné qu'à la mise au point des moteurs de boulinium,
ça vaut le coup de prévoir les bêtises pour gagner du temps sur les tests.
Il y aura aussi moyen de régler le ROT DRAG pour certains grincheux qui se reconnaitront surement ! :badsmile:
Ce ne sera pas une feature par la suite par contre .... A moins de le faire d'une
façon classe comme le DGIV avec un programme de configuration bien fait :)
Message modifié ( 04-10-2007 01:00 )
-
:wall:
Ca ne fonctionne pas mon idée !
Même en mettant ça dans le scenario:
ISP_AIR 0.00
ISP_VACCUM 0.00
MAIN_THRUST 0.00
IONIC_THRUST 0.00
RCS_THRUST 0.00
MAX_TANK1 0.00
MAX_TANK2 0.00
MAX_RCS_FUEL 0.00
EMPTY_MASS 130000.00
Et en faisant dans cet ordre là dans class cap , j'ai des moteurs qui fonctionnent, visiblement selon les valeurs
intialisées .... :doubt:
void Irridium::clbkSetClassCaps (FILEHANDLE cfg)
{
MAX_MAIN_THRUST = 1064360.0;
MAX_HOVER_THRUST = 744975.0;
MAX_RCS_THRUST = 4500.0;
MAX_TANK1_CAPACITY = 35250.0;
MAX_TANK2_CAPACITY = 35250.0;
MAX_RCS_FUEL_CAPACITY = 2700.0;
EMPTY_MASS = 13000.0;
ISP = 3.3e4;
ISP_P0 = 3e4;
Scn.SavedVariable("ISP_AIR", &ISP);
Scn.SavedVariable("ISP_VACCUM", &ISP_P0);
Scn.SavedVariable("MAIN_THRUST", &MAX_MAIN_THRUST);
Scn.SavedVariable("IONIC_THRUST", &MAX_HOVER_THRUST);
Scn.SavedVariable("RCS_THRUST", &MAX_RCS_THRUST);
Scn.SavedVariable("MAX_TANK1", &MAX_TANK1_CAPACITY);
Scn.SavedVariable("MAX_TANK2", &MAX_TANK2_CAPACITY);
Scn.SavedVariable("MAX_RCS_FUEL", &MAX_RCS_FUEL_CAPACITY);
Scn.SavedVariable("EMPTY_MASS", &EMPTY_MASS);
ph_main = CreatePropellantResource (MAX_TANK1_CAPACITY + MAX_TANK2_CAPACITY);
etc ... etc ...
Et je suis sûr de mon coup car quand je met ça dans classcap au moment de la première initialisation,
je n'ai effectivemment ni moteurs ni réservoirs.
void Irridium::clbkSetClassCaps (FILEHANDLE cfg)
{
MAX_MAIN_THRUST = 0.0;
MAX_HOVER_THRUST = 0.0;
MAX_RCS_THRUST = 0.0;
MAX_TANK1_CAPACITY = 0.0;
MAX_TANK2_CAPACITY = 0.0;
MAX_RCS_FUEL_CAPACITY = 0.0;
EMPTY_MASS = 130000.0;
ISP = 0;
ISP_P0 = 0;
Le scénario est donc superbement ignoré !
-
DanSteph a écrit:
Au chargement du scenario tu redefini tes moteurs après le chargement des
variables éventuellement changée.
Donc dans clbkRestoreBidule ;)
Y a des fonctions pour ajuster les moteurs les tank sans devoir tout detruire/recreer.
picto a écrit:
Le scénario est donc superbement ignoré !
Ben non,les variables sont bien chargée mais les moteurs vont pas changer comme par miracles ;)
double MaxThrust=10000;
SetMaxThrust(MaxThrust)
Si tu met MaxThrust maintenant à 10000000 le moteur va pas broncher... c'est juste une variable.
Faut refaire un SetMaxThrust(MaxThrust)
Dan
Message modifié ( 04-10-2007 02:02 )
-
Tu veux dire dans cette fonction ?
Je suis un peu largué sur ce coup là :sick:
C'est comme si ces variables ne suivaient pas le même chemin que n'importe quelle autre.
Ce qui m'embrouille le plus, c'est que quand je suis le code, je me retrouve bien avec une
variable lue sur le scenario juste avant de créer thrusters et autres bidules ... :wonder:
// --------------------------------------------------------------
// Read status from scenario file
// --------------------------------------------------------------
void Irridium::clbkLoadStateEx (FILEHANDLE scn, void *vs)
{
char *line;
while (oapiReadScenario_nextline (scn, line))
{
if(Scn.LoadScenario(line)==TRUE||Crew.LoadAllMembersFromOrbiterScenario(line)==TRUE)
continue;
ParseScenarioLineEx (line, vs); // unrecognised option
}
}
Message modifié ( 04-10-2007 02:35 )
-
clbkSetClassCap est executée AVANT clbkLoadStateEx
clbkLoadStateEx n'est appellée QUE si on lis un scenario (donc pas en cas de création par scn editor)
void Irridium::clbkLoadStateEx (FILEHANDLE scn, void *vs)
{
char *line;
while (oapiReadScenario_nextline (scn, line))
{
if(Scn.LoadScenario(line)==TRUE||Crew.LoadAllMembersFromOrbiterScenario(line)==TRUE)
continue;
ParseScenarioLineEx (line, vs); // unrecognised option
}
[color=green]// a partir d'ici toutes tes variables on été lue depuis le scenario[/color]
[color=green]// C'est le moment de proceder aux initialisations qui dépendent des scn[/color]
[color=green]// Par exemple (pseudo code)[/color]
MAX_MAIN_THRUST=min(30000,max(MAX_MAIN_THRUST,10000)); [color=green]// limitation caca du scn[/color]
SetMaxThrust(MAX_MAIN_THRUST); [color=green]// reglage moteur , tank etc etc[/color]
}
Message modifié ( 04-10-2007 02:50 )
-
Oki ....
Je viens de comprendre.
Comme quoi .... quelquefois on fait des trucs qui fonctionnent mais en ayant eu un mauvais raisonnement.
Et ben, je crois que je vais avoir encore un sérieux ménage à faire dans le code! :sick:
Par exemple pour le panel, je fais un init dans class cap
InitialiseDiodeAA(DIODE_ELECTRICAL_PANO_SOLAIRE_AA,235, 335, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
Puis un save variable toujours dans class cap
Scn.SavedVariable(id, &DiodeAA[id - FIN_DIODE_SIMPLE - FIN_DIODE_A ].Etat);
Et pouf, je retrouve ma diode allumée si j'ai quitté Orbiter avec cette diode allumée.
Mais l'analyse que j'avais fait était que c'était parce que c'était en dessous dans class cap.
Ce qui est faux donc .... le coup de bol que j'ai eu c'est que InitPanel se fait après Load scenario :sick:
Mais j'ai pris cette manie de penser que de faire la sauvegarde SOUS l'initialisation suffisait.
Message modifié ( 04-10-2007 03:05 )
-
Je viens de comprendre pourquoi j'étais obligé de faire certaines initialisations
à la première image de post step aussi du coup :pfff:
C'est assez chouette toutes ces fonction spéciales qui sont mises à notre disposition sur les moteurs aussi.
Dans le genre void IncThrusterLevel (THRUSTER_HANDLE th, double dlevel) const; (single time step )
Je comprend aussi pourquoi tu dis que Martin à pensé à faire une SDK riche .... il est vrai qu'en fouillant un
peu c'est hallucinant de voir la quantité de possibilités qui nous sont offertes.
Message modifié ( 04-10-2007 13:29 )
-
attention quand même, après clbkLoadStateEx le status des modèles d'orbiter *pour certains* rare
truc n'est pas fini d'initialiser. Par exemple impossible d'obtenir un handle vers un autre vessel depuis
clbkLoadStateEx c'est pour ca que le first_step_init est utile. Sinon pour les animations,moteurs,
fuel et tout ca peut etre fait à la fin de clbkLoadStateEx
A++
Dan
-
Ouais .... ben c'est pas gagné ces histoires de moteurs ... :sick:
C'est n'importe quoi pour le moment !
Je ne comprend rien à toutes ces fonctions différentes ...
Elles ont presque le même nom ... certaines sont sans effet ou redondantes ...
Comme rien ne fonctionne après lecture du scénario, j'ai bien envie de tout
recopier bêtement à partir de class cap pour ce qui concerne la création des
ressources moteurs fuel ISP
Bref ... c'est pas très intéressant et en plus ça mââârche pââââ !
Je m'appelle pas Von Braun quoi! :pfff:
-
Crunch Crunch Crunch *machonne le boulot*
Pris du frelonIX code fait a l'arrache, vite fait... si ca peu te donner quelques idée.
A la fin de clbkLoadStateEx :
PB_ISP_LOADED=max(500,min(800000,PB_ISP_LOADED));
if(PB_ISP_LOADED!=(int)PB_ISP)
{
DWORD ThrusterNbr=GetThrusterCount();
DWORD i;
for(i=0;i<ThrusterNbr;i++)
{
THRUSTER_HANDLE hThrust=GetThrusterHandleByIndex(i);
SetThrusterIsp(hThrust,PB_ISP_LOADED,PB_ISP_LOADED);
}
}
PB_MAXMAINTH_LOADED=max(10000,min(200000,PB_MAXMAINTH_LOADED));
if(PB_MAXMAINTH_LOADED!=(int)PB_MAXMAINTH)
{
SetThrusterMax0 (th_main,PB_MAXMAINTH_LOADED);
SetThrusterMax0 (th_hover,PB_MAXMAINTH_LOADED);
}
A++
Dan
-
Note que le seul avantage de faire tout ca externe c'est si tu veux qu'un "beta testeur" (Pagir ? :) )
te "mette au point" les bonnes valeurs de poussée et autre... comme cela il a pas besoin de
toucher le code et peu faire ses essais lui-même.
Sinon ca sert a rien, personne tripote jamais ces valeurs pratiquement
(ou quelques types seulement)
Donc pour 1.0 perte de temps à part le gag du la "mise au point externe"
A++
Dan
-
"mise au point externe""beta testeur" (Pagir ? ):)
Vi ... c'est pour ça ... mais pour l'instant le gain de temps .... ben :badsmile:
Vi ... pi JLuc .... pi Sirius aussi ....
Comme ça, on va pouvoir faire des tableaux .... :pfff:
Remarque, avec des pilotes c'est plutôt intéressant ...
Thanks pour l'indication ...
Je crains de n'avoir pas tout compris vu ce que je faisais .... :lol:
Avec ça sur le scenario
ISP 30000.00
MAIN_THRUST 2128720.00
IONIC_THRUST 1489950.00
MAX_FUEL 71500.00
EMPTY_MASS 130000.00
Et ça dans le loadstateex
ISP_P0 = ISP;
MAX_TANK1_CAPACITY=MAX_TANK2_CAPACITY=(MAX_FUEL-MAX_RCS_FUEL_CAPACITY)/2;
SetEmptyMass (EMPTY_MASS);
SetMaxFuelMass (MAX_FUEL);
SetISP (ISP);
SetMaxThrust (ENGINE_MAIN, MAX_MAIN_THRUST);
SetMaxThrust (ENGINE_HOVER, MAX_HOVER_THRUST);
ph_main = CreatePropellantResource (MAX_TANK1_CAPACITY + MAX_TANK2_CAPACITY);
ph_rcs = CreatePropellantResource (MAX_RCS_FUEL_CAPACITY);
Data.dFuelMass=GetPropellantMass(ph_main);
Message modifié ( 04-10-2007 16:14 )
-
Mais quand même c'est pas facile de s'y retrouver.
En y repensant, ce n'était pas complètement débile ce que je faisais !
SetMaxThrust
comparé à
SetThrusterMax0
SetISP
comparé à
SetThrusterIsp
Quand je dis que c'est redondant ... c'est plutôt confusant en fait :pfff:
Pourquoi toute ces fonctions qui ont l'air de faire la même chose ?
Message modifié ( 04-10-2007 16:33 )
-
C'est la zone :sad:
Un scenario que je lance ...
ACTIVE_PROBE 0
ISP 30000.00
MAIN_THRUST 2128720.00
IONIC_THRUST 1489950.00
MAX_FUEL 71500.00
EMPTY_MASS 130000.00
Class Cap
Scn.SavedVariable("ACTIVE_PROBE", &iActiveProbe);
Scn.SavedVariable("ISP", &LOADED_ISP);
Scn.SavedVariable("MAIN_THRUST", &MAX_MAIN_THRUST);
Scn.SavedVariable("IONIC_THRUST", &MAX_HOVER_THRUST);
Scn.SavedVariable("MAX_FUEL", &MAX_FUEL);
Scn.SavedVariable("EMPTY_MASS", &EMPTY_MASS);
Le Current State après avoir quitté Orbiter
ACTIVE_PROBE 0
MAIN_THRUST 2128720.00
IONIC_THRUST 1489950.00
MAX_FUEL 71500.00
EMPTY_MASS 130000.00
Elle est passée ou la ligne ISP ? :doubt:
Et pourtant, la variable existe ... de toutes façons, sinon ça ne compilerait pas ...
-
picto a écrit:
Pourquoi toute ces fonctions qui ont l'air de faire la même chose ?
Ptete la doc pourrais donner une explication ? :)
pour l'ISP c'est bien une variable de classe double ?
Je sais pas...
Dan
-
Oui c'est bien une double pourtant.
Je suis un peu naze ... on va se ressaisir ;)
Message modifié ( 04-10-2007 19:41 )
-
Je crois avoir identifié la source de mes problèmes de lecture.
Mais pas d'écriture sur le scenario par contre...
Dans ClassCap, sur le modèle du ShuttleA, tous les thrusters sont liés à une unique ISP.
Et je vois que dans LoadStateExt tu redemandes un Handle juste avant d'y intégrer l'IsP loaded.
C'est bizarre d'ailleurs ... pourquoi un handle créé dans class cap n'est il pas dispo ensuite
n'importe ou dans le code ?
Si j'ai ça dans le header de classe pourquoi faut il en redemander un dans LoadStateExt ?
PROPELLANT_HANDLE ph_main, ph_rcs;
Comme ceci ...
DWORD ThrusterNbr=GetThrusterCount();
DWORD i;
for(i=0;i<ThrusterNbr;i++)
{
THRUSTER_HANDLE hThrust=GetThrusterHandleByIndex(i);
SetThrusterIsp(hThrust,PB_ISP_LOADED,PB_ISP_LOADED);
}
L'avantage, je le vois, c'est qu'en cinq lignes je redéfinis TOUS les thrusters y compris les RCS
mais sinon ?
-
picto a écrit:
C'est bizarre d'ailleurs ... pourquoi un handle créé dans class cap n'est il pas dispo ensuite
n'importe ou dans le code ?
Si j'ai ça dans le header de classe pourquoi faut il en redemander un dans LoadStateExt ?
Bien revoir le scope des variables... variable declarée dans fonction=non dispo ailleurs,
j'avais deux solutions pour ce cas:
1-rendre les handle des thruster comme variable de classe. (accessible partout)
2-rechoper les handles des thruster par un autre moyen.
Dan
-
Picto,
Tu sais, je ne sais pas que piloter des vaisseaux de la mort qui tue! Si je pouvais modifier quelquechose dans un
config.cfg, c'est à ma portée. Mais, .... ça va te faire du boulot!
JLuc
-
Je me doute bien vu comment tu maitrises cet aspect des
engins Orbiter .... mais as tu regardé le config d'Irridium ?
C'est plutôt basique .... tout est dans la DLL. :sick:
C'est pour ça que je suis bien embêté sur ce coup là.
Je pensais vraiment gagner du temps en en passant par une
lecture scenario, et puis, j'imagine qu'une lecture de config par
la DLL nécessite autant de boulot non ?
Mais je vois ou tu veux en venir. Pour les tests tu voudrais faire passer
irridium en SP3, PPPPPfffff .... franchement, ça ne m'emballe pas ...
Autre problème, j'ai vraiment besoin de ces variables pour faire d'autres
choses dans le code.Affichages displays, manettes des gazs et compagnie.
Message modifié ( 05-10-2007 20:49 )
-
Peu de méthode .... beaucoup de mémoire :badsmile:
Il me semblait bien avoir lu un truc sur les fichiers configs dans les tutos de Dan :)
Ceci pourrait il être une solution pour se créer un fichier de config type SP3 utilisable
par une équipe de beta testeurs en mettant toutes les variables dans une structure ?
Peut être en rajoutant une instruction dans la fonction pour ajouter une ID devant ou
un nom clair comme sur les fichiers scenarios d'Orbiter ... :wonder:
Sauve la structure config:
FILE * stream;
stream = fopen( "Sound\\DeltaGliderIV\\config.cfg", "wb" );
{
fwrite( &Cfg, sizeof( Cfg ), 1, stream );
fclose( stream );
}
ouvre le fichier et charge la structure config:
FILE * stream;
stream = fopen( "Sound\\DeltaGliderIV\\config.cfg", "rb" );
if(stream)
{
fread( &Cfg, sizeof( Cfg ), 1, stream );
fclose( stream );
}
-
Pas vraiment, la structure requiere d'avoir les données alignées au byte pres sinon ca merde.
En claire si tu laisse quelqu'un ecrire a la mano dans ton fichier et qu'il mets même un espace
en plus c'est foupoudav.
pour un fichier "humain" il faut un décodage & controle fin des données du fichier.
La structure c'est utile en "private", ie: TU sauve,TU charge et personne tripote. ;)
A++
Dan
-
Bref .... c'est pas ma période :sad:
Idées foireuses sur idées foireuses ! :badsmile:
Message modifié ( 06-10-2007 01:07 )
-
Les idées sont bonnes, c'est juste un manque de connaissance sur les détails.
Et en prog les détails.... y a que ca ! :badsmile:
Dan
-
pour éviter la merde de quoi qu'on causait tout a l'heure (en mp pour ceux qui espionnent ;) )
Change LogError comme suis:
/////////////////////////////////////////////////////////////////
// LogError
/////////////////////////////////////////////////////////////////
void SaveRestoreScenario::LogError(char* Valeur)
{
[color=blue]#ifdef[/color] _DEBUG
MessageBox(NULL,Valeur, "LogError SaveRestore",MB_OK);
[color=blue]#endif[/color]
}
quoi que t'est ce ?
les directive qui commence par "#" sont des directives de compilation, si tu regarde dans tes propriétés d'irridium
tu verra qu'en debug il défine ce mot clé: "_DEBUG"
Ces lignes vont dire au compilateur:
#ifdef _DEBUG
MessageBox(NULL,Valeur, "LogError SaveRestore",MB_OK);
#endif
"Compile la ligne entre if/endif QUE si le mot clé _DEBUG est présent.
En bref la fameuse ligne t'envoie une messagebox d'erreur si il y a une merde avec saverestore
a l'execution (le fameux ISP l'aurait declenché)
pourquoi on ne la met QUE en debug cette messagebox ?
Pasque'une messagebox en fullscreen c'est blocage et redemarrage de l'ordi si le gars a pas l'idée
de faire ALT tab et cliquez ok a l'aveuglette. Donc que pour toi pour eviter les erreurs genre "ISP"
ou autre et pas en release pour les testeur ou utilisateurs.
Ca reste du controle d'erreur basique... j'ai pas poussé vu que saverestore a été ecrite en deux heure...
A++
Dan
-
J'ai toujours su que j'aurais dû être chef!
Je sais pas de quoi :lol: mais chef :badsmile:
Le chef :"Fais ci .... fais ça ... "
L'autre:"Comment ? "
Le chef :"Démerde toi !"
L'autre:"T'es sûr que c'est une bonne idée ?"
Le chef :"Oui !!!"
-
Essaie après modif de remettre "ISP" tu verra mieux de quoi qu'on cause.
Dan
-
J'ai regardé sur MSVC ce qu'est une MessageBox.
Je tombe sur un define de winuser.h, j'en déduis donc que c'est
une macro qui permet d'ouvrir une nouvelle fenêtre windows.
Quand au Debugging sur MSVC, j'ai encore énormément de mal
à savoir QUOI regarder quand j'ai une erreur. Face à l'afflux d'infos,
si ce n'est pas clairement identifiable et en rapport avec l'idée que je
me suis fait au préalable de la source possible d'erreur, je n'y arrive pas.
-
Faut toujours revenir au source du probleme...
1-J'ai une erreur... un code que j'ai ecrit ne fait pas ce qu'il doit...
2-quel est ce code ?
Voila LA question...
Pas de poussée, c'est soit le define des moteurs, soit le carburant, donc on check en premier les fonctions et les
parametres passé a ces fonctions en debug "break"... tient ? zéro ? ah ben voila....
3-pourquoi la valeur est à zéro?... et hop la pelote...dévide toussa
"1-J'ai une erreur 2-quel code devrait faire marcher ce truc correctement? 3-controle du code en question"
1-Pas de save de la valeur ISP
2-Quel code ? le saverestore !
3-Trace du saverestore de l'ISP.
Scn.SavedVariable("ISP", &Loaded_ISP);
Dan
Message modifié ( 06-10-2007 01:56 )
-
Encore un truc ou j'ai du mal tiens .... :doubt:
C'est quand je lis un synopsis comme celui ci, j'ai encore du
mal à voir que le compilo me réclame une écriture de ce type ...
MessageBox(
HWND hWnd,
LPCTSTR lpText,
LPCTSTR lpCaption,
UINT uType
)
MessageBox(NULL,Valeur, "LogError SaveRestore",MB_OK);
-
picto a écrit:
MessageBox(
HWND hWnd,
LPCTSTR lpText,
LPCTSTR lpCaption,
UINT uType
)
Chierie de doc MS, pas toujours évident c'est vrais... pour pas te faire ch...
tu cherche dans les news groupes (usenet)...
"MessageBox win32" (le win32 c'est pour éliminer les autres plateform comme linux et autre des fois je
rajoute "C++" pour eviter d'autre language suivant les résultats)
En bref ca donne ca:
http://groups.google.fr/groups?hl=fr&q=MessageBox%20win32&oe=UTF-8&um=1&ie=UTF-8&sa=N&tab=wg
Deuxieme réponse tu à un exemple pratique:
MessageBox(NULL, "wnd message loop", "caption", MB_OK);
Après on sait mieux de quoi on parle, la doc devient plus claire, on peut raffiner la recherche ou trouver
d'autres exemples plus explicites...
Dan
-
Oki, toujours le même truc quoi :)
Tu n'as pas la science infuse .... mais la bonne méthode.
Il faut que ça devienne un automatisme.
Bah .... ça va bien finir par venir .... avec de la persévérance.
J'ai fait quelques petits progrès, en lisant des synopsis de l'oapi je
parviens à remplir des appels de fonctions qui compilent .... ça se
termine souvent par des CTD finalement mais c'est toujours mieux que rien :badsmile:
-
Après rien ne vaut l'experience personelle, je vois pas mal de truc que tu fait faux
ou j'avais pourtant dis comment faire. Le prob c'est que ca rentre jamais aussi bien
que quand on est confronté au probleme et rame pour une solution.
Si on pouvait apprendre a conduire en lisant des posts d'un forum ca ce saurait ;)
Dan
-
Sur quel genre de trucs je fais de grosses boulettes ? :sad:
Message modifié ( 06-10-2007 03:15 )
-
Exemple: Les SavedVariable éparpillés un peux partout dans SetClassCap.... pas glop, bordélique... risque d'erreurs.
Visiblement ca vient de la confusion et de la non-compréhension de comment le save restore marche exactement.
Sur le moment les SavedVariable ne font.... rien, ni save, ni load ni quoi que ce soit, ca enregistre seulement
que "cette variable sera a sauver/recharger" ... mais plus tard, après le clbkSetClassCap.
Comme t'en a des chiées qui "polluent" la lisibilité de ton clbkSetClassCap, je les mettrais
carrement toutes dans une fonction séparée qui serait appellée au début de SetClassCap.
Comme c'est tout a fait à propos je mettrais cette fonction dans le cpp "SavRestore.cpp"
Donc au début de saverestore.cpp
void DeclareVariableASauver()
{
Scn.InitClass(); //Toutes les sauvegardes de variables
// compressed variable
for(int id=DIODE_CHECK_ELEC;id < FIN_DIODE_SIMPLE;id++)
Scn.SavedVariable(id, &Diode[id].Etat);
..... TOUT les "Scn.SavedVariable" ICI
}
Et au début de clbkSetClassCap()
DeclareVariableASauver();
Tu me dira que c'est pas grave, il y a deux problèmes toutefois:
1-la lisibilité, risque de déclarer deux fois la même (et combat au restore vu qu'elle ce feron ch.. l'une l'autre)
2-Le fait que cette ecriture demontre que tu n'a pas pigé/integré vraiment le principe de "SavedVariable"
ce qui peux t'amener à de faux raisonnements et a ramer comme une bete car tu crois que ca marche
d'une certaine maniere alors que non.
Et c'est pas très beau en plus question organisations... ;)
Dan
-
Sinon j'ai pas tellement regardé, juste vu quelques indentations mal faite (je supporte pas ca personellement)
mais j'ai pas poussé plus loins... me suis juste occupé du "CG problem" et "variable"
Dan
Message modifié ( 06-10-2007 03:22 )
-
Ah oui ... ça ... je m'en suis rendu compte .
Je n'avais rien compris sur le save restore.
Je pensais vraiment que le RESTORE se faisait sur la ligne :sick:
Donc oui, je vais faire du ménage ... je l'ai dit hier ou avant hier.
C'est même sur ce thread d'ailleurs ( au milieu de la page 1 )
Message modifié ( 06-10-2007 03:28 )
-
reposte:
Et plus haut ce n'est pas une critique hein...
Juste une constatation, comme je disais à pagir hier la prog c'est comme l'anglais,
on le parle très vite mais pour le maitriser totalement faut du temps... ;)
faut du temps, et pas mal de conneries et d'erreurs... :badsmile:
Dan
Message modifié ( 06-10-2007 03:29 )
-
Et plus haut ce n'est pas une critique hein...
Ben oui, je sais bien ... je n'ai pas la prétention de penser qu'en trois mois
on peut maitriser un tel truc.
J'aime bien l'image de l'Anglais ... vu comment je le baragouine :badsmile:
Ca le travaille le Pagir, cette histoire de prog ! :)
reposte:
??? :wonder: ???
Message modifié ( 06-10-2007 03:32 )
-
picto a écrit:
reposte:
:wonder: ???
posté en même temps, j'ai reposté nouveau pour etre sur que tu vois... ;)
Dan
-
Petite question sur les initialisations.
Malgré le initOK sur les fonctions d'initialisation des boutons,
est ce qu'un petit memset sur les structures pourrait sécuriser encore le bidule ?
Je veux pas dire une mise à zéro sur CHAQUE VARIABLE hein :badsmile: sinon, chuis pas rendu ... mais sur la structure, ou bien est ce totalement inutile ?
BOUTON Bascule[FIN_BOUTON_BASCULE];
BOUTON Selecteur[FIN_BOUTON_SELECTEUR];
BOUTON Poussoir[FIN_BOUTON_POUSSOIR];
BOUTON DiodeA[FIN_DIODE_A];
BOUTON DiodeAA[FIN_DIODE_AA];
BOUTON Diode[FIN_DIODE_SIMPLE];
BOUTON Display[FIN_DISPLAY];
BOUTON RedrawNever[FIN_BOUTON_REDRAW_NEVER];
J'oublie les init par tableaux aussi ... ce n'est pas suffisamment lisible.
J'imagine au bout de quelques mois quand on veut ajouter une
nouvelle couche à un addon.
Alors que des trucs comme ça restent lisibles même au bout de quelques mois je pense.
memset(&Probe[FUELPROBE1],0,sizeof(PROBESTATE));
memset(&Probe[FUELPROBE2],0,sizeof(PROBESTATE));
memset(&Probe[FUELPROBE3],0,sizeof(PROBESTATE));
memset(&Probe[FUELPROBE4],0,sizeof(PROBESTATE));
Message modifié ( 13-10-2007 04:13 )
-
Mémoire de poisson rouge ? :lol:
static int ResetOk=0; // initialise tout le tableau si premier appel à cette fonction pour cette instance
if(ResetOk!=(int)this)
{
int I;
for(I=0;I<FIN_DIODE_SIMPLE;I++)
memset(&Diode[I],0,sizeof(BOUTON));
ResetOk=(int)this;
}
Nan je rigole, tout ce qu'on n'a pas "pensé/reflechi/créé" sois-même est dur à retenir, c'est pour
ca que les aides "code-fourni" sont à double tranchant, sans elles tu n'y arriverais pas ou
difficilement mais du coup tu n'apprend/ne retient pas vraiment.
En bref si tu a deja ca sur toutes les fonctions "Initialise" c'est bon, remise à zero des structures
au début. (au premier "Initialise*****")
pour répondre à ta question: OUI une remise à zero des structures est essentielle avant utilisation,
sinon impossible de "proteger" le code.
Dan
-
PS: pour que cette fonction de remise a zéro des structures marche correctement il est impératif que tout les
initialise*** soient appellés dans clbkSetClassCap (ou dans une fonction appellée par clbkSetClassCap)
Dan
-
:sad: Personne ne m'avais jamais traité de poisson rouge :sad: :blop: :bulles: :blop: Ouais, bon ... c'est fait donc ...
Faut dire que le commentaire n'est pas super clair non plus ! On sait pas trop ce que fait cette ligne du coup !
// initialise tout le tableau si premier appel à cette fonction pour cette instance :lol:
Dernière question sur ces initialisations ( pour voir si j'ai bien compris )
Même si je fais ça dans ClassCap
Portes.dPorte_status = CLOSED;
Portes.dAnimPorte_proc = 0.0;
Portes.dPorte_CLOSED = CLOSED;
Portes.dPorte_OPEN = OPEN;
Portes.dPorte_CLOSING = CLOSING;
Portes.dPorte_OPENING = OPENING;
Il est important que j'ai fait un memset là dessus avant ?
PORTE Portes[FIN_PORTES];
Porte par porte ... autant de fois qu'il y a de portes dans le enum.
Comme ça quoi ...
(http://img01.picoodle.com/img/img01/9/10/12/f_007Jupiterm_4fb44a0.jpg)
Message modifié ( 13-10-2007 04:47 )
-
picto a écrit:
J'oublie les init par tableaux aussi ... ce n'est pas suffisamment lisible.
J'imagine au bout de quelques mois quand on veut ajouter une
nouvelle couche à un addon.
Tu veux parler d'initialise par boucle for/next plutôt ?
for(int id=DIODE_CHECK_ELEC;id < FIN_DIODE_SIMPLE;id++)
Scn.SavedVariable(id, &Diode[id].Etat);
Pourtant c'est pratique et plus lisible que 123 lignes de code à peu près pareil. Dur de voir une erreur avec la dernier
methode. Faut juste etre TRES stricte avec les boucle FOR/NEXT !
IMMENSEMENT STRICTE !!!!
Si tu n'est pas sur d'y arriver vaut mieux faire une ligne par variable effectivement au prix d'avoir des centaines de
lignes. Envore une fois a mon avis l'erreur c'est de ne pas avoir fait en série, tu a commencé par faire tout les boutons
du panel avec une sauvegarde monstrueuse alors que tout ces boutons ne servent encore a rien et changent
constamment au fur et a mesure que tu avance dans les systemes. Boutons desactivés, inutiles, qui changent,
rajouté= foutoir dans les save des variables.
Dan
-
Euh oui les for next ... désolé pour le vocabulaire ...
Je les ai virés ...
Ca marchait sur les boutons parce que j'avais fait ça super concentré,
mais tant pis, je préfère voir au premier coup d'oeil ou j'en suis de l'utilisation
des Id pour éviter d'avoir de nouveaux chevauchements.
J'avais un id utilisé trois fois :badsmile:
Là j'ai 257 lignes pareilles à peu près, mais aucun trou dans les Ids et surtout
je sais au premier coup d'oeil que j'en suis à 257.
Et surtout, comme parfois je manque de concentration, il m'est arrivé d'ajouter
un nouveau bouton dans le enum .... MAIS sur une position stratégique pour
la lecture des boucles ... J't'explique pas le bordel que ça avait foutu et le temps
que j'avais mis à réparer :sick:
Message modifié ( 13-10-2007 04:57 )
-
Tu peux me renvoyer les derniers sources que je jette un oeil voir si je peux te conseiller ?
Dan
Message modifié ( 13-10-2007 04:58 )
-
Mais je comprend tout de travers ... :wall: J'étais sûr de mon coup sur les memsets.
Ce ne sont pas des variables boutons mais des variables pour les
affichages de trucs dynamiques sur les displays genre la pression
qui monte ou qui descend ... ce genre de trucs.
-
Mais franchement, ce que je t'avais deja dis: A ta place je commencerais par enlever TOUT les boutons qui ne
servent pas encore. Tu ne garde QUE ceux qui te servent/sont deja en fonction.
Tu vire TOUTES tes variables qui ne servent pas encore !!!
Par exemple:
enum
{
CREW_MANAGEMENT_PERFORM_EVA ,
[color=red] LIFE_SUPPORT_POWER_AIR_FILTER,
LIFE_SUPPORT_POWER_AIR_TEMPERATURE,
LIFE_SUPPORT_POWER_CLIMATISATION,
LIFE_SUPPORT_POWER_RADIATOR ,
LIFE_SUPPORT_POWER_POMPE_AIR,
LIFE_SUPPORT_POWER_WATER_FILTER ,
LIFE_SUPPORT_POWER_WATER_ANALYSE,
LIFE_SUPPORT_AJOUTE_HUMIDITE,
LIFE_SUPPORT_RESCUE_POWER_AIR_FILTER,
LIFE_SUPPORT_RESCUE_POWER_AIR_TEMPERATURE ,
LIFE_SUPPORT_RESCUE_POWER_CLIMATISATION ,
LIFE_SUPPORT_DEPLOY_RADIATOR,
LIFE_SUPPORT_POWER_POMPE_WATER ,
LIFE_SUPPORT_DUMP_WATER ,
LIFE_SUPPORT_ENLEVE_HUMIDITE,[/color] PROBES_RELEASEBUTTON,
BOTTOM_DOCK ,
FIN_BOUTON_POUSSOIR,
};
en:
enum
{
CREW_MANAGEMENT_PERFORM_EVA ,
BOTTOM_DOCK ,
FIN_BOUTON_POUSSOIR,
};
Tu va te retrouver avec 15-20 "Initialise" et 15/20 saverestore. Facile et lisible. Tu repart avec un code clean ou tu ne
bossera PLUS qu'en série.
Je rajoute une bouton "fuel dump" ?
1-declaration dans le tableau
2-intitialisebouton
3-saverestore
4-gestion systeme,poststep
en bref quand tu a fini les "fuel dump" dois marcher completement depuis un spawn par scn vide jusqu'au restore,
dock, en vol etc etc.
Avec tes 257 boutons dont 20 servent a quelques chose plus toutes tes variables inutile meme pour un pro ce serait
casse gueule.
Dan
Message modifié ( 13-10-2007 05:10 )
-
Ouais :sad:
Je comprend bien cette histoire de série .... je suis un peu têtu.
Je m'étais dit que je passerais au tout en série une fois tout ce qui a été
entamé en parallèlle serait mis à jour, mais je n'avais pas imaginé que
cette remise à niveau doive se faire tout de suite selon tes conseils.
Je pensais gagner du temps en faisant comme ça ... mais ça fait tellement
de trucs à penser en même temps que souvent ... oui ... c'est un problème ...
Donc le temps gagné ... effectivement :siffle:
-
Je pense a un truc, la tu maintien DEUX liste une pour les initialise, une pour les saverestore, risque d'inconsistance
entre les deux, double boulot, pourquoi ne pas faire d'une pierre deux coup ?
Tu fous les save restore DANS les initialises, et dans les initialises tu rajoute en premier parametre le no de la
variable pour sauvegarde...
Exemple:
InitialiseDiode([color=red]001[/color],DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode([color=red]002[/color],DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode([color=red]003[/color],DIODE_CHECK_HYDRO,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode([color=red]004[/color],DIODE_CHECK_TEMP,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
En rouge ce que j'ai rajouté: (attention j'ai coupé les lignes trop longue, copie/colle pas comme ca)
void Irridium::InitialiseDiode([color=red]int SaveRestoreNbr[/color],int MotCle....
{
if([color=red]SaveRestoreNbr<0||SaveRestoreNbr>999[/color]||MotCle<DIODE_CHECK_ELEC......
{
return; //fait rien
}
static int ResetOk=0;
if(ResetOk!=(int)this)
{
int I;
for(I=0;I<FIN_DIODE_SIMPLE;I++)
memset(&Diode[I],0,sizeof(BOUTON));
ResetOk=(int)this;
}
Diode[MotCle].InitOK=INITBOUTONOK; // fin initialisation
Diode[MotCle].Etat=EtatInitial;
Diode[MotCle].iBmpPosX=SourceBitmapX;
Diode[MotCle].iBmpPosY=SourceBitmapY;
Diode[MotCle].AidPosZoneX=PositionPanelX;
Diode[MotCle].AidPosZoneY=PositionPanelY;
Diode[MotCle].Panel=Panelo;
[color=red]Scn.SavedVariable(SaveRestoreNbr,&Diode[MotCle].Etat);[/color]
}
ATTENTION A BIEN APPELLE LE SCN.INITCLASS AU TOUT DEBUT DE clbkSetClassCAP AVANT TOUT INITIALISE !
Message modifié ( 13-10-2007 05:26 )
-
Avec le code en dessus, tes boutons sont initialisé ET sauvé automatiquement et les structure remise a zéro automatiquement . La liste n'est plus double, le code est plus court et si un bouton est declaré il sera sauvé... gain sur tout les tableaux.
Dan
Message modifié ( 13-10-2007 05:29 )
-
Ah oui pas bête ... bravo encore!
Je pense pas encore instinctivement à faire ce genre de trucs, appeller
d'autres fonctions à partir d'une fonction déjà appellée depuis une autre.
Sinon, pour certains boutons, j'ai été obligé de créer des "mémoires" temporaires
quand un bouton a des états différents automatisés par un sélecteur par exemple.
D'ou ces boutonneries supplémentaires qui te paraissaient bizarres ;)
Trois chambres .... trois boutons ... neuf variables "mémoire"
int iOuterDoorButtonState;
int iChamberButtonState;
int iInnerDoorButtonState;
Ps .... j'ai bien vu ça ... sinon CTD direct de toutes façons non ?
ATTENTION A BIEN APPELLE LE SCN.INITCLASS AU TOUT DEBUT DE clbkSetClassCAP AVANT TOUT INITIALISE !
Message modifié ( 13-10-2007 05:35 )
-
picto a écrit:
Donc le temps gagné ... effectivement :siffle:
Si tu regarde le nombre de fois ou tu reprend reecris tout, effectivement hein... ;)
par contre pour la desactivation commente dans un premier temps avec des /* et */:
enum
{
CREW_MANAGEMENT_PERFORM_EVA ,
[color=green]/*
LIFE_SUPPORT_POWER_AIR_FILTER,
LIFE_SUPPORT_POWER_AIR_TEMPERATURE,
LIFE_SUPPORT_POWER_CLIMATISATION,
LIFE_SUPPORT_POWER_RADIATOR ,
LIFE_SUPPORT_POWER_POMPE_AIR,
LIFE_SUPPORT_POWER_WATER_FILTER ,
LIFE_SUPPORT_POWER_WATER_ANALYSE,
LIFE_SUPPORT_AJOUTE_HUMIDITE,
LIFE_SUPPORT_RESCUE_POWER_AIR_FILTER,
LIFE_SUPPORT_RESCUE_POWER_AIR_TEMPERATURE ,
LIFE_SUPPORT_RESCUE_POWER_CLIMATISATION ,
LIFE_SUPPORT_DEPLOY_RADIATOR,
LIFE_SUPPORT_POWER_POMPE_WATER ,
LIFE_SUPPORT_DUMP_WATER ,
LIFE_SUPPORT_ENLEVE_HUMIDITE,
*/[/color]
BOTTOM_DOCK ,
FIN_BOUTON_POUSSOIR,
};
Comme ca si t'en enleve a tort... bonjour l'angoisse si tu les avait supprimé carrement.
Dan
-
Je te rapelle en passant de laisser de la place dans les numéros de saverestore pour pouvoir rajouter des truc, c'est
juste une question de lisibilité...
si tu fait tout +1 (imagine une grosse liste)
[color=green]// diodes[/color]
InitialiseDiode(001,DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(002,DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=green]//boutons[/color]
InitialiseBouton(003,BOUTON_PROUT,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(004,BOUTON_CACA,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
Quand tu voudra rajouer une diode tu n'aura pas le choix que la mettre a la fin de liste:
[color=green]// diodes[/color]
InitialiseDiode(001,DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(002,DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=green]//boutons[/color]
InitialiseBouton(003,BOUTON_PROUT,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(004,BOUTON_CACA,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=green]// Ah euh... diodes encore[/color]
[color=blue]InitialiseDiode(233,ENCORE_DIODE,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1); [/color]
[color=green]// Ah tient ouais encore une bouton... c'est le foutoir la fin de liste[/color]
[color=blue]InitialiseBouton(234,ENCORE_BOUTON,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1); [/color]
Tandis que si tu laisse de la place dans la numérotation:
[color=green]// diodes[/color]
InitialiseDiode(001,DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(002,DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=green]//boutons[/color]
InitialiseBouton([color=blue]050[/color],BOUTON_PROUT,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton([color=blue]051[/color],BOUTON_CACA,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
Tu peu rajouter dans la même section:
[color=green]// diodes[/color]
InitialiseDiode(001,DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(002,DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=blue]InitialiseDiode(003,ENCORE_DIODE,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1); [/color]
[color=green]//boutons[/color]
InitialiseBouton(050,BOUTON_PROUT,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(051,BOUTON_CACA,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=blue]InitialiseBouton(051,ENCORE_BOUTON,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1); [/color]
Des ID tu en a de dispo de 0 a 999... les vides eventuel dans la numérotation sont pas grave...
Message modifié ( 13-10-2007 05:48 )
-
Ouais ... je crois que je vais me décider enfin ... :sick:
Mais le panel sera moins joli pour les testeurs :sad:
Sinon,
Je crois que j'ai compris la boulette sur le memset ...
memset(&PanelDockStatus[REAR_DOCK],0,sizeof(DOCKSTATUS));
dans PanelDockStatus, j'ai 17 variables donc il faut que je fasse un for next comme ça ...
int I;
for(I=0;I<17;I++)
memset(&PanelDockStatus,0,sizeof(DOCKSTATUS));
Message modifié ( 13-10-2007 06:04 )
-
picto a écrit:
Ps .... j'ai bien vu ça ... sinon CTD direct de toutes façons non ?
ATTENTION A BIEN APPELLE LE SCN.INITCLASS AU TOUT DEBUT DE clbkSetClassCAP AVANT TOUT INITIALISE !
Pas forcement, ca peut etre plus vicieux que ca, bug bizarre, CTD que dans certains cas et...
arrachage du peu de cheveux qui te reste après boulinium :badsmile:
Dan
-
picto a écrit:
Ouais ... je crois que je vais me décider enfin ... :sick:
Mais le panel sera moins joli pour les testeurs :sad:
Fais le fameux masque "désactivé" sous photoshop... 2mn...
En tant que testeur je trouve plus boulifiant d'avoir des centaines de boutons sans savoir
lequels marchent/sont a tester... un layer noir transparent avec des trous... tout con
(http://orbiter.dansteph.com/screenshot/dansteph/picto5mnpourtrouver5.jpg)
Dan
Message modifié ( 13-10-2007 05:57 )
-
Je te rapelle en passant de laisser de la place dans les numéros de saverestore
pour pouvoir rajouter des truc, c'est juste une question de lisibilité...
C'était un peu pour ça que je ne parvenais pas à me décider d'en virer.
Je me disais que je n'avais pas à prnser à conserver de la place en faisant tout d'un coup.
Mais vu ce qui se passe sur chaque système ... :sick:
Genre un sélecteur qui deviens un poussoir ou inversement.
A chaque fois je me retape toutes les listes d'ENUM pour être sûr de pas faire une connerie.
Tout ceci selon l'adage :"Pourquoi faire simple quand on peut faire compliqué ! " :badsmile:
-
picto a écrit:
Je te rapelle en passant de laisser de la place dans les numéros de saverestore
pour pouvoir rajouter des truc, c'est juste une question de lisibilité...
C'était un peu pour ça que je ne parvenais pas à me décider d'en virer.
Je me disais que je n'avais pas à prnser à conserver de la place en faisant tout d'un coup.
Mais vu ce qui se passe sur chaque système ... :sick:
Je te rapelle en passant de ne PAS bosser sur les scenarios maintenant, ca ca vient en dernier.
Meme en laissant des trous avec les changements qui vont intervenir dans le code
(enlever un bouton, modifier) tu va te retrouver avec une numérotation plutot dans le genre a la fin:
[color=green]// diodes[/color]
InitialiseDiode(001,DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(005,DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(009,ENCORE_DIODE,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=green]//boutons[/color]
InitialiseBouton(050,BOUTON_PROUT,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(054,BOUTON_CACA,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(056,ENCORE_BOUTON,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
Comme la numérotation ne pose probleme que avec d'ancien scenario, juste avant la release tu renumerote tout:
[color=green]// diodes[/color]
InitialiseDiode(001,DIODE_CHECK_ELEC,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(002,DIODE_CHECK_ATMO,171, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseDiode(003,ENCORE_DIODE,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
[color=green]//boutons[/color]
InitialiseBouton(050,BOUTON_PROUT,210, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(051,BOUTON_CACA,249, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
InitialiseBouton(052,ENCORE_BOUTON,132, 26, XdiodeBmp, YdiodeBmp,Eteint, Panel1);
Tu fait tes scenarios ensuite et tu part super clean avec nickelium 1.0... du code et des scn clean pret
pour nickellium 1.5.
Pour 1.5 tu pourra plus faire ce cleanage a moins de faire que les scenarios ne soient plus
du tout compatible avec 1.0. C'est possible, les SCN "DGIII et DGIV ne sont pas dans le meme repertoire.
(meme si les III marchent avec le IV quand meme... 20 ans de metier ;) )
Dan
Message modifié ( 13-10-2007 06:09 )
-
Euh ... oui ... j'en suis pas là.
J'essaye de cleaner Class Cap pour le moment et d'être sûr que
je bosse bien avec des variables pas dangereuses.
As tu vu le post sur memset ?
Je reposte ...
Sinon,
Je crois que j'ai compris la boulette sur le memset ...
memset(&PanelDockStatus[REAR_DOCK],0,sizeof(DOCKSTATUS));
dans PanelDockStatus, j'ai 17 variables donc il faut que je fasse un for next comme ça ...
int I;
for(I=0;I<17;I++)
memset(&PanelDockStatus,0,sizeof(DOCKSTATUS));
Message modifié ( 13-10-2007 06:18 )
-
Mais non ... c'est pas bon mon histoire ...
Trois tableaux de 17 variables ... :wall:
Si je fais ça, j'initialise un seul tableau
int I;
for(I=0;I<17;I++)
memset(&PanelDockStatus,0,sizeof(DOCKSTATUS));
memset(&PanelDockStatus[REAR_DOCK] ,0,sizeof(DOCKSTATUS));
memset(&PanelDockStatus[CORRIDOR_AIRLOCK] ,0,sizeof(DOCKSTATUS));
memset(&PanelDockStatus[FRONT_DOCK] ,0,sizeof(DOCKSTATUS));
-
picto a écrit:
As tu vu le post sur memset ?
Bon ben t'a tes devoirs pour ce week-end. :badsmile:
1-enlever tout ce qui ne marche pas
2-rajouter les saverestore dans les initialise
A la fin de ca faudra des beta teste et testes poussé pour etre sur que tu part clean
(je veux bien revoir ton code a ce moment, deux pairs de zieux valent mieux qu'une)
si c'est ok tu part super clean et après tu rajoute tes brique les une après les autres.
Un mur c'est très dur à monter d'un coup, mais en faisant une brique après l'autre même
un freluquet serais capable de monter la muraille de chine...
SERIE !!!!
Dan
Message modifié ( 13-10-2007 06:25 )
-
C'est l'heure ou je suis moins étanche :badsmile:
Tout deviens confus ..... d'Oie :)
Je reverrais tout ça après un petit dodo. ;)
-
Désolé , j'ai pas bien regardé... 'ffectivement c'est pas bon
Ca serait plus juste ???
int I;
for(I=0;I<FIN_DOCK_PANELSTATUS;I++)
memset(&PanelDockStatus[I],0,sizeof(DOCKSTATUS));
Message modifié ( 13-10-2007 06:32 )
-
Ca y est j'ai compris !!!
Le sizeof vide toute la structure ( donc 17 variables en un coup).
typedef struct{
int iDockingStatus;
... 14 lignes virées
int iChamberButtonState;
int iInnerDoorButtonState;
}DOCKSTATUS;
Mais il faut que je lui dise comment s'appellent les trois tableaux.
Vu qu'ils s'appellent comme ça ...
DOCKSTATUS PanelDockStatus[FIN_DOCK_PANELSTATUS];
et qu'ils sont listés comme ça ...
enum
{
REAR_DOCK,
CORRIDOR_AIRLOCK,
FRONT_DOCK,
FIN_DOCK_PANELSTATUS,
};
il faut lui dire fais trois fois le vidage de cette structure dont voici les noms de tableaux ...
Donc ....
int I;
for(I=0;I<FIN_DOCK_PANELSTATUS;I++)
memset(&PanelDockStatus,0,sizeof(DOCKSTATUS));
C'est bon ?
-
Ah ben :sad:...
Le temps de faire mon post ... il y a une réponse .
Mais il vaut mieux que j'ai compris moi même que d'avoir encore du tout prémâché ;)
Message modifié ( 13-10-2007 06:38 )
-
picto a écrit:
Mais il vaut mieux que j'ai compris moi même que d'avoir encore du tout prémâché ;)
Exact et :applause: pour avoir trouvé tout seul.
Ca marche dans l'autre sens aussi: Quand je post du code essaie de bien le comprendre
et pose des question sinon...
A++
Dan
-
J'essaye toujours de comprendre ...
D'abord dans les grandes lignes ...
Par exemple sur les fonctions d'initialisation .
Puis sur les détails ... comme le initBoutonOk avec le memset
qui faisait partie de cette fonction.
Mais chacun sa vitesse. :sick:
Le principal étant que ça rentre petit à petit.
Et surtout que je ne comprenne pas de travers.
Ca c'est plus grave parce que ça fait faire des conneries. Ca fait deux trucs
importants sur lesquels je m'aperçois en deux jours que je n'avais rien compris. :sad:
Reste ce :fu: This que je ne comprend toujours pas ;)
Mais ça viendra en temps voulu, je sais ce que c'est, instance et tout le
tremblement mais je ne comprend pas encore comment et pourquoi ça fonctionne.
-
Et en fait, c'est ce que j'avais fait !!! :lol:
Mais il vaut mieux être sûr !
(http://img01.picoodle.com/img/img01/9/10/12/f_007Jupiterm_4fb44a0.jpg)
-
picto a écrit:
Reste ce :fu: This que je ne comprend toujours pas ;)
Mais ça viendra en temps voulu, je sais ce que c'est, instance et tout le
tremblement mais je ne comprend pas encore comment et pourquoi ça fonctionne.
this c'est le handle de l'instance de la classe ou est le this.
La classe irridium est instanciée par orbiter pour chaque MO dans le scenario,
Orbiter fait probablement un truc dans le genre:
VESSEL hVessel[Nbr]=new Irririum();
Avec deux vessel dans le scenario tu aura donc deux handle (adresse mémoire) par exemple:
MO1: hVessel[0]=0x4567890
MO2: hVessel[1]=0x7435689
"This" c'est ce chiffre la, le handle...
Donc dans le MO1 this donnera par exemple: 0x4567890 et dans MO2 this donnera 0x7435689
comme notre variable "static int ResetOk" est static au contraire des autres elle va retenir
sa valeurs pour toutes les instances.
Dans l'orde d'execution ca ce passera comme cela pour chaque Initialise():
Orbiter charge instancie et execute le clbkSetClassCap de MO1
MO1 Initialise(1): InitOK!=0x4567890 donc remet à zero la structure de MO1 et donne la valeur InitOK=0x4567890
MO1 Initialise(2): InitOK==0x4567890, saute la remise a zero de la stucture
MO1 Initialise(3): InitOK==0x4567890, saute la remise a zero de la stucture
MO1 Initialise(4): InitOK==0x4567890, saute la remise a zero de la stucture
MO1 Initialise(5): InitOK==0x4567890, saute la remise a zero de la stucture
Orbiter charge instancie et execute le clbkSetClassCap de MO2
InitOK est toujours egal a 0x4567890 vu qu'il a gardé la valeur précédente (static)
MO2 Initialise(1): InitOK!=0x7435689 donc remet à zero la structure de MO2 et donne la valeur InitOK=0x7435689
MO2 Initialise(2): InitOK==0x7435689, saute la remise a zero de la stucture
MO2 Initialise(3): InitOK==0x7435689, saute la remise a zero de la stucture
MO2 Initialise(4): InitOK==0x7435689, saute la remise a zero de la stucture
MO2 Initialise(5): InitOK==0x7435689, saute la remise a zero de la stucture
C'était un moyen un peu tordu je l'avoue de faire une remise a zero des structure automatique
sans faire appel a une autre fonction genre IniButtonReset() ou un memset ou une variable qu'on aurais
du initialiser avant (donc autant de risque d'oubli que IniButtonReset() ou memset)
En bref on aurrais pu faire ca:
Memset(&bouton,0,sizeof(BOUTTON);
Initialise(1);
Initialise(2);
ou ca:
IniButtonReset()) // memset dedans
Initialise(1);
Initialise(2);
ou ca si on avait mis le memset dans la fonction initialise:
bBoutonResetDone=FALSE;
Initialise(1); //remise a zero structure et bBoutonResetDone=TRUE
Initialise(2);
Avec le "this" on fait que ca et c'est tout automatique, au premier appel la structure et remise a zéro.
aucun risque d'oubli.
Initialise(1); // memset de la structure de l'instance
Initialise(2);
Initialise(3);
Initialise(4);
Tordu hein ? :badsmile:
Dan
Message modifié ( 13-10-2007 07:42 )
-
A relire à tête reposée mais je comprend le principe.
Lire un truc que tu sais être unique et l'utiliser comme test pour faire juste une fois.
Ok, c'est le même pricipe que le FIRST_STEP_INIT_DONE dans post step sur le principe.
Mais ce que je trouvais étrange, c'est que ce This "contient" toutes les autres variables quand je
regardais dans la fenêtre du bas en debugging sur MSVC. Ca apparaissait donc plus compliqué au
premier abord que ce simple handle d'une case mémoire comme tu expliques plus haut. Donc juste
une valeur.
Faudrait que je teste un scenario avec deux Irridium en debug avec MSVC et
basculer de l'un à l'autre pour mieux voir ce This et voir ce qui se passe dans l'un
et l'autre quand je bascule.
Message modifié ( 13-10-2007 13:50 )
-
Pas besoin de bascule... Attention le clbkSetClassCap n'est pas executé quand tu bascule (F3)
mais à l'instanciation du vessel, en bref 1X pour chaque vessel quand le scenario démarre
c'est tout. C'est la toute premiere chose qui est executée de ta classe suivi par clbkLoadStateEx
si lancé depuis un scenario. (au lieu d'avec ScN editor) et chacun est executé le nombre de fois
qu'il y a de vessel.
Pour voir InitOK=this en action: deux scenarios, F9 sur "InitOK" et tu regarde... comme
tu a 523 InitBouton tu devra faire 523 F10 avant de voir le InitOK et this changer pour
le deuxieme vessel mais le principe est la.
A++
Dan
Message modifié ( 13-10-2007 14:33 )
-
picto a écrit:
Mais ce que je trouvais étrange, c'est que ce This "contient" toutes les autres variables
Ah oui, comme this est le handle la "poignée" de la classe il "contient***" toute ta classe.
tu pourrais faire ca: this->MaFonction(); ca revient strictement au même que de faire
MaFonction(); dans ce cas.
Le MSVC est gentil de t'indiquer le contenant (sur quoi pointe) this mais sa valeur en
tant que variable est une adresse mémoire.
*** c'est un pointeur of course, il ne "contient" pas mais pointe sur l'adresse mémoire de ta classe.
this est surtout utile pour des fonctions win32 qui demandent l'instance en entrée
exemple foireux: GetParam(this,hWnd);
Dan
Message modifié ( 13-10-2007 14:44 )
-
Attention le clbkSetClassCap n'est pas executé quand tu bascule (F3)
Oui, je suis bête, c'est évident en fait, sinon, on retrouverait le
vaisseau dans l'état initial à chaque fois qu'on utilise F3.
C'est dingue cette architecture d'orbiter.
Quand on pense à tout ce qui se passe en mémoire de l'ordi
quand il y a dix vessels sur un scenario,plus les planètes etc ...