Les challenges - work in progress

[tofitouf]

Gros retour sur le code ce soir. un peu dur de s'y remettre mais j'ai déjà un peu avancé.
j'espère avoir définitivement réglé les problèmes de connexions.
il me reste encore aps mal de pb nottament dans al phase d'installation-téléchargement.

Tout ce qu'avait signalé Mr Spock il y a quelques temps. Il faut donc revoir à la fois le site et le manager pour mieux les synchroniser et simplifier la phase d'installation.

Ensuite le site est aussi en chantier, beaucoup de choses à revoir.

mais bon c'est des petites choses, du fignolage tout cela. la base tourne bien et le lancement d'un défis, la sauvegarde automatique, etc tout cela fonctionne encore très bien. Donc du plaisir de tester et restester jusqu'à que tout soit nickel au niveau ergonomie. tout le reste roule et c'est du bonheur.

a+

[tofitouf]

Ca progresse tout doucement,
Le téléchargement des add-ons est maintenant fait via la page web ce qui permet plus de possibilité coté ihm.
Bien plus facile de trouver les fichiers manquant si on les déjà chez soit.

de petites choses mais qui rende l'utilisation plus claire et donc très important vu ce que je lis dans ce fil. Simplifier, toujours simplifier.

[tofitouf]

Hier j'ai clarifié et simplifié
* la création de la configuration d'orbiter
* l'installation des dossiers

tout se fait via les pages web. Il ne me reste donc plus qu'à nettoyer ces fameusement page
Prochaine étape, enfin la refonte du site

[MrSpock]

[tofitouf]

La mise en page progresse doucement mais surement.

épuration nettoyage, simplification.... y'a du boulot.

[tofitouf]

Pfff c'est long à faire le php....

[Fox-Terrier]

cool
tu t'y es remis !
bonne continuation !

(avec tous ces panneaux "j'ai arrêté de fumer tatata" on croirait que tous le monde ici seraient de gros fumeurs)

[tofitouf]

On est maintenant de monstrueux vapoteurs

merci pour ton ptit message. j'espère que tu aura le temps de tester comme le dernière fois, tes retours m'ont été bien utiles

[astazou]

Fox-Terrier a écrit:
avec tous ces panneaux "j'ai arrêté de fumer tatata" on croirait que tous le monde ici seraient de gros fumeurs

moi, j'ai arrêté avant de commencer

[tofitouf]

Debogage et mise en page de nouveau ce soir.... mais ca avance à petit pas.
J'en suis à l'envoi final de succès de mission.
quelques erreurs à corriger et pas mal de mise en page.

Il restera par la suite à regrouper les défis dans différents dossiers et ca sera presque montrable....

Ah oui et aussi comptabiliser des stats comme la distance totale, les points etc...
pfff c'est encore loin mais ca avance.



Message modifié ( 03-11-2010 00:33 )

[tofitouf]

coté stats c'est bon, les règles du jeu tiennent en quelques lignes de php une fois que tout le framework est en place.
Donc pour le faire évoluer vers d'autres type de jeux (carrière multijoueur), il n'y aura que quelques page de php à changer et le module interne d'orbiter. Le manager ne sert vraiment qu'aux transferts et à vérifier quelques points de cohérence.

j'ai encore quelques petites choses à régler du coté du module (calcul de la distance parcourue, et de la durée de vol, trois fois rien à priori.

juste une interrogation sur cette fameuse distance parcourue. si je la prends dans le répère global. même quand on ne bouge pas (sur une planete par exemple) la valaur change à cause justement de la rotation de la planète et de son mouvement autour du soleil.
docké à un satellite là aussi ca bouge beaucoup fatalement.

Est ce que je prends comme repère, pour chaque mission le point final d'arrivée ? la planète en cours de référence ? ou le global (c'est à dire toujours el soleil comme référence.
pour l'instant j'ai pris cette option, la plus simple à calculer.... à voir.

Coté affichage html, c'est encore largement perfectible mais ca progresse. je reviendrai dessus une fois la beta en cours. L'avantage de la solution web c'est justement que je peux changer plein de choses sans que l'utilisateur n'ai besoin de recharger quoi que ce soit.

Pour résumer, il me reste :
- finir des calculs dans le module orbiter
- ajouter des scénarios de tests simples (tests unitaire pour chaque type d'objectif)
- organiser les Défis en chapitres

Et enfin je pourrait vous proposer une beta. J'ajouterai les excellent défis de nulentout au fur et à mesure mais une fois que la prochaine session de test sera passée.

[MrSpock]

Salut Tofitouf !

j'ai encore quelques petites choses à régler du coté du module (calcul de la distance parcourue, et de la durée de vol, trois fois rien à priori.

J'ai vu récemment qu'il est possible d'invoquer un interpréteur Lua dans le code C++ .
Ce serait possible de l'intégrer à ton module , ce qui permettrait d'avoir des configs modulaires ou fixes .
Lua donne accès à (quasi) toutes les fonctions du SDK , et le fait de coder un script pour une mission est + rapide une fois le langage acquis .

Est ce que je prends comme repère, pour chaque mission le point final d'arrivée ? la planète en cours de référence ? ou le global (c'est à dire toujours el soleil comme référence.
pour l'instant j'ai pris cette option, la plus simple à calculer.... à voir.

C'est tout là l'intêret de Lua : Tu testes des paramètres sans avoir à recompiler .
Tes fonctions sont changées à partir d'un bloc note , tu lances Orbiter et les changements sont faits .

Pour résumer, il me reste :
- finir des calculs dans le module orbiter
- ajouter des scénarios de tests simples (tests unitaire pour chaque type d'objectif)
- organiser les Défis en chapitres

C'est bien !
Une fois ton plan réalisé , tu seras plus libre d'imaginer de nouvelles solutions ( je ne veux pas me répèter et je comprends que tu doives achever ce que tu as commencé ... )
Bonne continuation .
J'apprends le langage Python en ce moment ...
BYYYYE !

[tofitouf]

Yep pour lua je te suis à fond. c'est une super alternative tout nouvelle à orbiter et qu'il faut exploiter.

Pour ma part ayant monté de mes ptites mains tout un framework pour MFD qu'on voit dans ma carte. J'en ait pas trop besoin. Mais c'est clair que c'est l'avenir, par la simplicité avec laquelle tu peux interagir sur le jeu.

Moi je n'aurais jamais le temps d'exploiter cette partie, je vais continuer comme j'ai commencé car je maitrise bien mes outils et je n'ai pas besoin de chercher plus loin pour l'instant.

Mais pour les autres projets que tu as en tête les évolutions à venir, ca pourrait complètement remplacer, dans mon architecture actuelle, le module Orbiter que j'installe dans le jeu. Plus simple et surement plus facile à maintenir.

Le tout pour garder un cap commun est qu'on se mette d'accord sur les format d'échange de fichiers et de données.
à priori tout peux se faire facilement avec le module lua (lecture de fichiers et ouverture de socket). En tout cas l'expérimentation veux le coup de fouiller dans ce sens.

Mais effectivement il me faut d'abord finir l'existant pour voir les évolutions. Je fonce donc vers visual pour corriger mon MFD ensuite, il faut que je change l'affichage des durées et distance coté php,
Le manager ne bouge plus trop ces temps ci, il sert de passerelle, entre le site et orbiter. j'essaie de limiter son implication pour le rendre plus facile à utiliser dans des contextes divers. Je l'ai tout de même corrigé un peu pour prendre en compte des spécificité de la nouvelle version d 'orbiter.
Le site lui intègre les règles du comptage de point et du classement des joueurs. j'ai encore la page de classement à écrire. Je vais faire un peu brute au début. je peaufinerai par la suite. veuillez m'en excuser

Voila en brut les pensées qui m'animent. Tout est facile, mais reste à faire. c'est du tout cuit coté codage je pense.

Par contre j'aurais bientôt bien besoin de testeurs. Et aussi si quelques bonnes volontés veulent proposer des scénario intéressants pour les premier tests, ils sont les bienvenus. Pour les premiers test j'ai besoin de choses jolies à voir juste avec la version nue d'orbiter. comme une jolie démo des meilleurs coins du système solaire.

Seule compétence technique requise : savoir créer un scénario dans orbiter et aimer le faire partager.
Vous pouvez m'envoyer vos propositions en MP.  

Par la suite j'ouvrirai les envois directs depuis le manager, c'est d'ailleurs déjà intégré.... il reste qu'à tester.

j'y retourne. zou

[MrSpock]

Super !
Comme je disais , bonne continuation .
Je n'ai pas la compétence pour créer un bon scénario ( dans orbiter et pour le moment ) , je t'aurais aidé sinon .
Mais je connais un paquet de candidats sur ce site ...
A+ tofitouf !




Message modifié ( 06-11-2010 23:12 )

[tofitouf]

encore tout plein de ptit détails réglés ce soir mais j'en trouve toujours encore et encore.

Je vais bientôt pouvoir multiplier les premiers micro défis de test. ce qui donnera un bon panel d'exemples pour en ajouter d'autres.

[tofitouf]

Tout roule, j'en suis à ajouter les premiers scenario de test. à vrai dire j'en ai ajouté un nouveau, juste un.

Mais c'est que j'en ait profité pour corriger tout ce qui clochait dans le manager au passage, et y'en avait....

Je pense que je vais bientot mettre  en ligne juste en l'état. avec mes quelques scenarios de test. ca vous permettra de voir un peu le fonctionnement.

Et puis j'ai hate de la montrer il est vrai, ca fait maintenant quelques semaines que je buche sur cette mise en ligne, ca commence à faire.

pour résumer :
Le site : assez fonctionnel, c'est pas encore parfait mais il ne manque qu'un ou deux liens et le tableau des emilleurs, qui ne sert à rien vu que y'a pas encore de joueurs.

Coté manager, il roule plutot bien pour lancer les jeux, coté création de nouveau monde, c'est plus que perfectible, je corrigerai au fur et à mesure que je crée les premiers univers, ca le rodera. en général c'est assez simple à faire mais trouver quel est l'enchainement de commande le plus intuitif est une autre affaire.

Coté MFD : il lui reste encore un type d'objectif à traiter : le dock. il sait détecter des atterissage, approches, et élements orbitaux. c'est déjà pas mal pour plein de scenarios imaginable. par la suite si on veux des interaction plus fine il faudra bien le faire grossir, je pense bien à UCGO qui dans son SDK (merci dan !!!!) propose tout plein de valeurs à tester des ctions possible faites par les humanoides, des bases à construire etc etc etc. C'est tellement vaste que ca en donne le vertige mais il va falloir relier tout ca entre eux.
c'est pas finit....

[MrSpock]

Coté MFD : il lui reste encore un type d'objectif à traiter : le dock. il sait détecter des atterissage, approches, et élements orbitaux. c'est déjà pas mal pour plein de scenarios imaginable. par la suite si on veux des interaction plus fine il faudra bien le faire grossir, je pense bien à UCGO qui dans son SDK (merci dan !!!!) propose tout plein de valeurs à tester des ctions possible faites par les humanoides, des bases à construire etc etc etc. C'est tellement vaste que ca en donne le vertige mais il va falloir relier tout ca entre eux.

Tiens , je l'avais oublié celui là !
J'avais bien essayé le " manager " , mais pas le Mfd .
En tenant compte de l'ergonomie de ton précédent chef-d'oeuvre , le " map3D " , je pense qu'au final l'utilisation sera très agréable .
Allez courage !
A+

[tofitouf]

Il est l'oins d'avoir le niveau de map 3D mais il en emprunte beaucoup de chose. affichage du texte (outliné, et positionnement) et des données interne (mon vaisseau est où ???). Mais pour le reste il est moche à souhait et il n'y a aucun interaction. C'est d'ailleur le but juste un panneau informatif sur la mission en cours mais intégré aux commandes du vaisseau.  

Par la suite j'utiliserai bien am carte pour afficher les checkpoints. je l'ai d'ailleur modifiée récemment en ajoutant les cibles dans ce but.

 Et pour en revenir à LUA, si tu expérimente de ce coté, ca pourrait complètement remplacer ce dernier MFD.

[MrSpock]

Non , je n'ai pas expérimenté cet aspect , j'avais commencé à étudier la faisabilité de la gestion d'un mode Mission -> carrière en me basant sur l'exemple de base de Martin . ( le script peut écrire dans des fichiers ... J'imagine bien le script ecrire la prochaine mission pendant que le joueur finit son roulage ou admire la vue après un docking réussi ).
Le script , c'est relativement simple : tu définis une condition , et tant qu'elle n'est pas atteinte , le script rend la main
au processus principal  Tu peux coder ainsi tout une mission , en gérant tous les params de vol + les animations .
 J'avais dans l'idée de mettre la main sur la caméra aussi , pour scripter des vues extérieures à des moments clés .
Et tout çà se fait à partir d'un notepad ! Etonnant ... En ce moment , je me remets au langage python .
J'imagine que revenir sur Lua sera plus facile .
Allez ,a+ .



Message modifié ( 09-11-2010 11:03 )

[MartySpaceLines]

Hello!

Yeah, ce projet a la classe!

Pour ton calcul de distances, tu voudrais pas prendre 2 mesures, une en absolu et une autre avec le point de départ (ou on a allumé les moteurs) comme réf??

Ces deux mesures seraient intéressantes à comparer!!

Exemple: dans ma tête, une mission lunaire c'est 400'000km x 2 = 800'000km. Alors que je suis sûr que c'est presque 10x +!!!!!!!!!!!!!!!!!!

[tofitouf]

@Spock : C'est clair que les possibilités sont énormes et sans trop se prendre la tête. Quand tu passera là dessus préviens moi je tenterai bien l'aventure avec toi.

@Marty, merci pour ton intérêt, ca fait bien plaisir

Effectivement les distances calculées actuellement sont énorme, même quand je ne bouge aps, mais ca reste interessant. j'avais dans l'idée calculer toujours en relatif par rapport au body de référence, ca qui fait que ca prendrait en compte la rotation de la planète .

Je voulais alors supprimer ce calcul total mais comme cela t'intéresse je le garde rien que pour toi.

Je vous tiendrait au courant si ce calcul est plus adapté.



Message modifié ( 09-11-2010 21:04 )

[MrSpock]

@Spock : C'est clair que les possibilités sont énormes et sans trop se prendre la tête. Quand tu passera là dessus préviens moi je tenterai bien l'aventure avec toi.

D'accord !
Je vais attendre toutefois que tu aies stabilisé OrbiterChallenge , et que donc tu sois bien disponible .
A ce moment là , une possibilité serait de transposer ton architecture relationnelle ( MFD->Manager<->Serveur Http )
en :

Fichier .Scn ( contient le nom du script en entete et l'exécute) ->Manager<->Serveur Http  

ou encore

Fichier .Scn ( contient le nom du script en entete et l'exécute) <->Serveur Http . ( le script peut ouvrir des sockets ...)

Dans ce cas le manager servirait aux uploads/downloads et création de missions sous forme de script ?
Mais c'est de la SF pour le moment ...
Stabilise OrbiterChallenge et nous aviserons ?
Longue vie et prospérité !

[tofitouf]

pas tant de la sf que ca, dans mon système actuel je réécrit le scénario à la volé à chaque fois, pour garantir pas de triche, je peux donc le faire aussi sur le fichier de script lua.

Je peux adapter le manager pour cette petite particularité. ca peux se faire très vite.

Pour la communication le manager doit par contre être central. pour des raisons de sécurité je ne maintiens qu'une seul session http à la fois coté serveur, celle avec laquelle le joueur s'est logué. Donc c'est lui qui envois les données de jeu au site.

On pourra toujours expérimenter sans le manager en recherchant coté sécurité http etc comme faire mais autant continuer le manager qui ne sert que de passerelle dans ce cas et permet en cas de besoin de bloquer des appels pirates. Et puis y'a toujours la question du mot de passe qu'il faudra de toute facons envoyer. etc...

Donc c'est vraiment aps de la science fiction ton plan, y'a qu'à ...

je finit donc cette version du manager avant de voir la suite.

ce soir j'ai ajouté 3 nouveaux petits test , approche de base, dock et pad.

ca avance bien même si je retrouve toujours des myriade de micro bug par ci par là, ca ralentis forcement puisque j'arrive pas à m'empêcher de les corriger immédiatement.

Je mettrai en ligne avant que tout soit impeccable. ca restera surement en travaux quelques semaines

[MrSpock]

On pourra toujours expérimenter sans le manager en recherchant coté sécurité http etc comme faire mais autant continuer le manager qui ne sert que de passerelle dans ce cas et permet en cas de besoin de bloquer des appels pirates. Et puis y'a toujours la question du mot de passe qu'il faudra de toute facons envoyer. etc...

Ok !
C'est non pour l'accès au serveur directement depuis le script pour des raisons de sécurité .
Je ne me rappelle plus comment le MFD communique les résultats au manager : sous forme de fichier ?
A ce moment , là , une optimisation serait les PIPES , le manager et le script étant sur le même pc local .
Les données passeraient en streaming ... Le PIPE , c'est facile à mettre en oeuvre pour toi je pense .
Bien que tu disposes surement déjà de fonctions de lectures et écritures dans un fichier . En fait , j'imagine que tes fonctions pourraient être compatibles . Mais bon , je chipotte là ...

Sinon quoi encore ?
AH oui , génial que tu écrives déjà des scénarios !
Tu rajoutes une ligne contenant le nom du script dans le .scn , et si tu disposes de blocs de texte en dur contenant
des fonctions Lua , tu dois pouvoir créer un script sur le tas .
DU genre via une fonction telle que :

bool DoScriptWaitAltitude ( char* script , float altitude )
{
// tu " concatenate " après conversion de float en char* à la bonne place dans le code préformaté ,
// et le tour est joué ... Une fonction fwrite(...) ou un équivalent et c'est bon . ENfin je suppose ...
}

Pourquoi en dur ?
Parce qu'ainsi , tu disposes d'un réservoir de missions qui ne sont pas éditables par l'utilisateur tant qu'il ne les a pas
débloquées ... D'où la notion implicite de mode carrière . Si cela pouvait fonctionner , ce serait même possible de créer
une campagne dynamique , en interprêtant les résultats ! J'imagine ..
Pour en être fixé , il faudrait que j'écrive un programme externe en c++ qui crée un script de base pour commencer.
Avec ouverture d'un.scn , écriture du nom du script , fermeture , écriture du script au bon endroit dans les tripes d'Orbiter 2010 . Et là je peux utiliser Borland ...
Le script Lua qui écrit un autre script me plait bien aussi , mais l'obstacle ce sont les données en dur ... elles ne seraient pas cachées . A moins de les structurer et les écrire dans un fichier au format binaire , mais cela complique
les fonctions de lecture ( gestion du seek du pointeur selon la taille des blocs de code ... ) .
Sinon , pour sombrer dans la folie , utiliser une base de donnée pour stocker des lignes de script , que ton manager
demande , traite , et en sortie il produit un script tout neuf . Bienvenue dans la 4eme dimension .

Sinon pour en revenir à la possibilité de coder un MFD avec Lua , c'est OK !
Je viens de vérifier dans la doc , et t'invite à y jeter un oeil en passant :Orbiter Help ( launchpad)> Script User's Guide > MFD scripts



Extrait :

MFD scripts provide a quick and easy way to create new multifunctional display modes for enhancing all Orbiter vessels. Unlike vessel DLL modules, they don't require the compilation of a C++ file, but just a text file containing the script.

avec un exemple concret :

An essential callback function is update which is called by Orbiter to redraw the MFD display. Its interface looks like this:

function update(skp)
  -- Draw the MFD display here
end
where skp is a Sketchpad object associated with the MFD surface. It contains methods for drawing text and geometric primitives, selecting pens, brushes and colours. For details see the Sketchpad class reference.

Bel avenir en perspective !
A+




Message modifié ( 10-11-2010 04:52 )

[tofitouf]

yo beaucoup de chose à commenter.

pour la communication MFD-Manager, aujourd'hui j'utilise des socket TCP/IP.
L'avantage c'est que ca ouvre la possibilité vers lua, qui en standard sait les traiter à moins que la version intégrée à orbiter soit bridée.
Pour les pipes ca serait pas faisable avec lua.
Je ne passe pas par des fichiers car la possibilité de tricherie est trop forte

avec des socket c'est toujours faisable de gruger mais c'est beaucoup plus dur, avec des pipes encore plus.


Sinon je n'ai aps tout suivit sur comment tu verrait l'intégration avec lua, ton idée de mission en dur etc.... je me suis perdu dans ta prose je doit dire.

Pour clarifier sur le fonctionnement actuel avec mon MFD dans orbiter :
- l'utilisateur clique sur démarrer la mission
- le manager récupère alors les données de mission en interrogeant le base de donnée.
- il écrit deux fichier : le scénario (.scn), et les données de défis (objectifs .cfg) qu'il récupère parmi ces données
- il lance alors orbiter
- la mission démarre automatiquement, on ne passe pas par le launcher orbiter standard
- quand un objectif est remplis le MFD envoie par socket des données (xml)
- le manager vérifie quelques points de cohérence et si c'est ok renvoie au site web
- ce dernier l'ajoute dans la BDD et calcule le score global de l'utilisateur. (c'est là que les règles du jeu globales interviennent : calcul des médaille, progression etc....)

Pour faire évoluer ceci vers l'utilisation de lua il suffirait de remplacer le fichier cfg lu par le MFD par tout simplement le script à lancer. Comme il est écrit à la volée le joueur ne peux le modifier avant de lancer la partie. Donc même si les règles y sont écrite en clair il ne pourra pas faire des correctifs.

Dans ce script on trouve donc des choses spécifique à cette mission, des choses scénaristiques (affichage à l'écran, changement de camera) et aussi le moyen de renvoyer des données au mfd par le même moyen qu'auparavant (socket).

 Le MFD actuel est alors inutile.

Voila c'est pas du tout de la SF, c'est presque prêt déjà dans l'état. juste quelques correctifs à faire coté BDD et coté site web pour ajouter de nouvelles règles de carrière.