[Projet Exploreur] Le vaisseau d'exploration ultime

[korben62]

DES jours tu veut dire
J'ai tourné et retourné le truc des heures entiéres sans y arriver, Je suis a peu pres sur qu'il manque un truc dans
mon SDK, mais quoi windows.h ?

[laserpithium]

C'est un grand moment !

Messieurs,
Ce qui est très probablement une première dans l'histoire d'Orbiter a eu lieu il y a quelques minutes à Mariupol (Ukraine).
En effet, ce qui est très certainement la première réparation spatiale lors d'une EVA a eu lieu avec succès !

L'opération a porté le nom de code "AE-35", en l'honneur d'Arthur C. Clark.
L'antenne du vaisseau Exploreur connu en effet une défaillance critique. Un membre de l'équipage a alors effectué une sortie
extra véhiculaire, et a entouré d'une sphère rouge la zone de la défaillance. Il s'est ensuite rendu sur place et à effectuer
la réparation, d'une durée de 10s.
Il est ensuite retourné sain et sauf dans l'appareil.

A noté que suite à des ennuis dans l'équilibrage des RCS de son scaphandre, il n'a pas réussi à s'approcher à moins de 2m de
l'antenne, mais ce fut suffisant pour effectuer la réparation.

Le département Engineering de la Ring's Corporation va probablement s'ouvrir une bouteille de vodka dans sa chambre d'hôtel
pour fêter cette première historique.

[Pagir]

Bravo!

Reste plus qu'à faire gaffe à HAL, maintenant...

Pagir

[yoann]

laserpithium a écrit:
A noté ... ... des ennuis dans l'équilibrage des RCS de son scaphandre

une autre panne pandant une panne !!! ah c'est la tuile !!!! pas de chance !!!  

[brainstorm]

J'ai hâte de voir les photos de tout ça !!

[laserpithium]

A la faveur des vacances de noël, ça avance pas trop mal.

Je vais bientôt franchir le cap de 5000 lignes de code. Et quand je vois tout ce qu'il reste à faire, je me dis que ça va
finir par être plus long que l'oeuvre complète de Balzac...

Je viens de finir la gestion des alarmes. Il y a plusieurs alarmes d'implémentées (températures trop hautes, trop basses...),
et il y a des jolies sonneries pour signaler tout ça ainsi que des voyants qui clignotent. (ça m'a d'ailleurs pris 2h pour
arriver à synchroniser les clignotements, les variables static en C++ c'est vraiment une horreur par rapport à java).

Le dernier gros morceau qu'il reste est la programmation des pannes. La réparation est déjà codée, mais pas encore l'IA qui
va déclencher les pannes.
Pour l'aspect purement visuel, attendez-vous au strict minimum. Non seulement je ne m'y connais rien, mais en plus ça ne
m'intéresse pas.

J'espère sortir une première béta (sans la navette de descente et sans les sondes atmosphériques) d'ici 1 ou 2 semaines.

[DanSteph]

laserpithium a écrit:
et il y a des jolies sonneries pour signaler tout ça ainsi que des voyants qui clignotent. (ça m'a d'ailleurs pris 2h pour
arriver à synchroniser les clignotements, les variables static en C++ c'est vraiment une horreur par rapport à java).

Fait très gaffe aux statiques et evite les comme la peste. Si tu a plusieur vaisseau dans le meme scenario
les statiques sont partagée entre tous et alors la bonjour la prise de tete...

Je te conseille aussi de grabber toutes les variable dont tu a besoin au debut de timestep
et de les mettre dans une structure.

Declaration au debut du h:

typedef struct{
double Altitude;
double VitesseVerticale;
int ClignotementVoyant;
etc etc...
}MESDATA;


Dans la classe vessel dans le H:

MESDATA MyData;

Au debut de timestep dans le cpp:

MyData.Altitude=GetAltitude();
MyData.VitesseVerticale=GetVertSpeed();

L'immense avantage c'est qu'au lieu de faire 320 appel a GetAltitude(); tu ne le fait qu'une fois
et l'altitude est dispo partout apres=gain de performance, gain de clarté.

Pour faire clignoter un truc tu peut faire:

if(fmod (oapiGetSimTime(), 0.5) < 0.3)
   CaClignote();

Tu peut le mettre dans Data aussi:

MyData.CligneRapide=fmod (oapiGetSimTime(), 0.5);

Et y acceder partout pour synchronisation.

If(MyData.CligneRapide<0.3)


En dernier dans le panel gaffe au refresh des instrument chaque image... une fois ton panel bien remplis
ca va ramer. un voyant on/off par exemple ne doit etre rafraichi que manuellement:

Pas PANEL_REDRAW_ALWAYS mais PANEL_REDRAW_USER et quand tu veut rafraichir le voyant
tu call oapiTriggerPanelRedrawArea

A++

Dan

[laserpithium]

DanSteph a écrit:

laserpithium a écrit:
et il y a des jolies sonneries pour signaler tout ça ainsi que des voyants qui clignotent. (ça m'a d'ailleurs pris 2h pour
arriver à synchroniser les clignotements, les variables static en C++ c'est vraiment une horreur par rapport à java).

En dernier dans le panel gaffe au refresh des instrument chaque image... une fois ton panel bien remplis
ca va ramer. un voyant on/off par exemple ne doit etre rafraichi que manuellement:

Pas PANEL_REDRAW_ALWAYS mais PANEL_REDRAW_USER et quand tu veut rafraichir le voyant
tu call oapiTriggerPanelRedrawArea

J'ai mis des REDRAW_ALWAYS uniquement pour la position de la manette des gaz et l'affichage des températures. Tout le reste
est en USER ou MOUSE.

A noté que le refresh des voyants m'a donné mon lot de CTD...
Lorsque tu fais un oapiTriggerPanelRedrawArea(), si le panel affiché au moment de l'appel n'est pas celui sur lequel doit
avoir lieu le redraw, ça CTD (contrairement à ce qu'indique la SDK).
Plus vicieux : lorsqu'il y a un TriggerRedraw de demandé au moment où tu changes le focus du vessel : CTD, pareil.
A noté que cela se résout bêtement en utilsant clbkGetFocus, mais quand même, c'est bien vicieux...

A noté que j'ai enregistré la voix de ma soeur pour l'IA de bord. Lorsque les moteurs entrent en surchauffe, on entend un
charmant "Warning, engine temperature too high !"
Le sol truc, c'est que pour le moment ça fait très son-enregistré-a-l'arrache-avec-mon-petit-micro.
Est-ce que quelqu'un connait un petit logiciel SIMPLE qui permet de retraiter les sons ? (à destination d'un novice complet
en la matière) ? En particulier les "t" font de mini-explosions...

Merci !

[DanSteph]

Pour les voix j'utilise ca: http://www.research.att.com/~ttsweb/tts/demo.php en general mieu que la petit soeur

Pour les oapiTriggerPanelRedrawArea y a une couille dans ton code, j'en ai exactement 491 dans le code
du DGIV et pas un seul CTD. Qu'import le panel affiché, ca marche sans soucis. Compare avec le clbkLoadPanel
du stock DG pour voir....

Pour les REDRAW_ALWAYS oublie pas qu'un affichage declenche un tas de ligne de code que tu ne peu meme pas
imaginer...donc un redraw de la manette des gaz chaque image c'est le camion 24 essieus pour transporter un verre d'eau...

Pour eviter ca en debut de timestep:

MyData.MainThrustLevel=GetThrustLevel(THRUST_MAIN);

plus loin dans timestep:
If(MyData.MainThrustLevel!=MyData.OldMainThrustLevel)
oapiTriggerPanelRedrawArea(MANETTEGAZ);

Et en fin de timestep:
MyData.OldMainThrustLevel=MyData.MainThrustLevel;

C'est une technique que j'utilise beaucoup pour diverse chose.
En debut de timestep tu a toujours la nouvelle valeur
si elle a changée l'ancienne (old...) n'est pas egale. Avec un simple
test if Ca garanti un refresh seulement quand la position a changée
et crois moi ca sauve des milliers de lignes de code et un temp fou.
Ca marche meme pour des floats si elle ne changent pas souvent.

Oublie pas d'initialiser les valeur dans le clbkSetClassCap
pour qu'elle ne soit pas egale comme ca tu un refresh a la premier iteration au moins.
MyData.OldMainThrustLevel=-1;
MyData.MainThrustLevel=0;

De maniere générale: TOUTE variable de ta classe DOIT etre initialisée
sur une valeur valide dans le clbksetclasscap. Cette regle t'evitera
une chiee de CTD et de problemes.

Si tu utilise des structures tu peut faire des
memset(&MyData,0,sizeof(MyData));

Les structures c'est le pied.

Et évite les statics comme la peste, c'est une source d'ennui.

Pour finir toi t'aime pas ca mais y a de bon modeleur voir d'excellents et qui on pas de programmeur...
pourquoi pas un module pour le CTV de well et Nomatter un jour ? ou pour un autre modeleur avec
pleins de fonctions avancée, un truc qui arrache !? C'est dommage d'avoir un code génial avec
un model moche et dommage d'avoir tout ces superbes model avec les fonctions basique de spacecraft.dll

A++

Dan



Message modifié ( 01-01-2007 23:12 )

[laserpithium]

DanSteph a écrit:
Pour les voix j'utilise ca: http://www.research.att.com/~ttsweb/tts/demo.php en general mieu que la petit soeur

Je viens de regarder, effectivement, ça rend plutôt bien ! Je crois que je vais garder l'adresse !

Pour les oapiTriggerPanelRedrawArea y a une couille dans ton code, j'en ai exactement 491 dans le code
du DGIV et pas un seul CTD.

Ah ben merde.
Bon ben... y' as plus qu'à.

Pour les REDRAW_ALWAYS oublie pas qu'un affichage declenche un tas de ligne de code que tu ne peu meme pas
imaginer...donc un redraw de la manette des gaz est superflu...

Pour eviter ca en debut de timestep:

MyData.MainThrustLevel=GetThrustLevel(THRUST_MAIN);

If(MyData.MainThrustLevel!=MyData.OldMainThrustLevel)
oapiTriggerPanelRedrawArea(MANETTEGAZ);

Et en fin de timestep:
MyData.OldMainThrustLevel=MyData.MainThrustLevel;

Je retiens l'idée, je pensais pas que ça coûtait si cher un redraw

Si tu utilise des structures tu peut faire des
memset(&MyData,0,sizeof(MyData));

Effectivement, j'utilise plein de structure, ça rend le code plus propre. Par contre, le coup du memset, c'est vraiment
impératif ?



Message modifié ( 01-01-2007 23:14 )

[DanSteph]

Effectivement, j'utilise plein de structure, ça rend le code plus propre. Par contre, le coup du memset, c'est vraiment
impératif ?

En general on les veut a zero les valeurs a part quelques cas rare (OldThrustLevel !?) quand tes structures
commencent à faire 50 lignes comme celle du DGIV c'est presque impossible de ne jamais oublier une variable. (j'ai eu le cas dernierement, ca datait du DGIII) avec un memset t'est sur de ton coup quitte a re-initialiser quelques variables un peut plus bas pour les valeurs spéciale... au moins elle seront pas indefinie (moche d'avoir un -123324243235 la ou ton code attend du 0 a 10 )

Et hyper Gaffos: en debug ta mémoire est remise a zéro, pas en release. Debug ca marche, t'est content tu passe en release pour sortir ton addon et c'est la cata, la caca, la ...? oui catastrophe... (merci pour ceux qui suivent dans le fond )

Au sortire de clbkSetClassCap il ne doit y avoir aucune valeur non initialisée...

Je retiens l'idée, je pensais pas que ça coûtait si cher un redraw

Pour l'affichage c'est parce que tu n'a jamais fait une SDK de sprite... un pixel= 1 a 3 lignes de code
donc image de 21x21 = 441 a plus de 2000 lignes (dépend de la SDK dans directX7 une lignes par pixel
mais y a la preparation du blit en plus) donc on a deux lignes plus un if (donc rien) contre 441 au moins
chaque image juste pour un petit carré de 21x21. Ca fait 30'870 lignes de code inutile par seconde a 70 FPS.
Ca vaut le coup a moins de prévoir un panel avec 5 boutons seulement ou la on s'en fout un peut.
(mais ca reste des methodes de goret)

A++

Dan



Message modifié ( 02-01-2007 02:01 )

[naphtaline]

hum j'ai lu tous les post et j'ai qu'une envi : etre commandant de ton vaisseau après tout une fois qu'on "maitrise un peu le
vol spatial" le plaisir est de faire encore plus réaliste mais a ce sujet :

-Concernant la gestion des pannes tu as un petit soucis : tu dis le compteur par a 0 et en fonction du temps on a plus de
chance d'avoir une panne.

=> cela ne correspond pas à la réalité, le moteur n'aura pas plus de chance de casser parce que le temps passe mais parce que
la DUREE d'UTILISATION a été plus grande. Ainsi même si quelqu'un fait une sortie de 2 jours avec les moteurs qui marche 70%
du tps => (si le carburant est suffisant) le moteur aura plus de chance de casser que durant un voyage d'une semaine ou on
aligne des plans peu distants et on rejoins un satellite.

Donc voila je ne sais pas si tu sras le codé moi non ^^ donc on peu pas t'en vouloir ^^ mais sa serait bien de retravaillé ca
dans se sens.

[Profil supprimé]

quand ton vaisseaux sera un peu plus aboutie, ou avec texture, si tu le veux bien j emettrai une photo sur ma
page "projet en cours". actuellement la seule photo posté n'est pas assez avancé pour être percutante.
Bonne continuation et poste nous des images régulièrement.

[laserpithium]

naphtaline a écrit:
ion des pannes tu as un petit soucis : tu dis le compteur par a 0 et en fonction du temps on a plus de
chance d'avoir une panne.

=&gt cela ne correspond pas à la réalité, le moteur n'aura pas plus de chance de casser parce que le temps passe mais
parce que
la DUREE d'UTILISATION a été plus grande. Ainsi même si quelqu'un fait une sortie de 2 jours avec les moteurs qui marche 70%
du tps =&gt (si le carburant est suffisant) le moteur aura plus de chance de casser que durant un voyage d'une semaine ou on
aligne des plans peu distants et on rejoins un satellite.

Parfaitement d'accord !

C'est codé de la manière suivante:
- La probabilité de panne est aléatoire et inversement proportionnelle a la durée de vie du système.
- Lorsque le moteur n'est pas utilisé, la probabilité de panne est calculé sur une durée moyenne de vie longue (de l'ordre de
1 an).
- Lorsqu'il fonctionne, cette proba est calculée sur une durée de vie beaucoup plus courte (et d'autant plus courte que le
moteur fonctionne a une puissance plus élevé).
- De plus, lorsque le moteur est utilisé dans des conditions non correctes (températures trop élevées, séquence de
préchauffage non effectuée...), la durée de vie est réduite peu à peu (et ne peut être rétablie à sa valeur initial que lors
d'une réparation).

A noté qu'il ny'a pas en fait une probabilité de panne mais 2 :
- Un premier compteur, à durée de vie longue.
- Lorsque ce compteur génère une panne, le moteur fonctionne toujours, mais un voyant "Engine malfunction" s'allume et la
proba de panne est calculée sur un compteur avec une durée de vie beaucoup plus faible. Lorsque ce second compteur génère une
panne, le moteur s'arrête.
La réparation répare les 2 pannes simultanément (la réelle et la virtuelle).

++

Laserpithium

[yoann]

huuuaaaaa, quel imaginatiooonn. bravo pour cette superbe idée, je la trouve géniale !!!

[brainstorm]

Ca promet d'être intéressant ! J'ai hâte de voir ce que ça va donner !;)