Multijoueur -> Module Copilotage

[Bibi Uncle]

C'est pas pour l'incompatibilité des add-ons. C'est que certains MFDs ne fonctionnent pas (ex: DG en mode 2D) et tous les MFDs en mode cockpit de base (les MFDs verts) ne fonctionnent pas. Je n'ai toujours pas trouvé de solution.

[pilote334]

Pour le DG, j'ai le DGiV de Dan, il fonctionne très bien en 2D et 3D et celui d'origine aussi, mais je suis hors topic là....

[MrSpock]

Pas de panique les mecs .
J'avais testé la première version ( celle où il fallait lancer le serveur à la main ... ) sous Orbiter 2006 , et tout marchait nickel . Faut vérifier dans le sdk , Pilote334 , que les fonctions nouvelles que tu utilises sont disponibles avec le sdk de 2006.
Je pense notamment à la cruciale GetElement() et à sa fausse jumelle SetElement() .
Sinon , l'avenir c'est quand même 2010 . Faudra s'y faire !
Mais la communauté est assez forte ( quand elle est solidaire ) pour régler un à un tous les problèmes .




Message modifié ( 12-08-2010 22:07 )

[pilote334]

Euhhh ouais, je vais regarder, d'autant que je crois avoir trouvé mieux que setelements et getelements....mais faut que je vérifie avant d'en parler....

Yves

[pilote334]

Alors, après avoir regardé dans le SDK 2006, la réponse est oui, c'est compatible pour toutes les fonctions actuellement utilisées ou que j'envisage d'utiliser. Voilà pour la réponse, après recherche....

[yoann]

Excuser moi de débarquer comme ça a l'improviste sur le sujet... mais quel est l'intérêt d'un mode multijoueur , si on est genre 4 a piloter plusieurs vaisseaux ?

perso, si ya que ça, moi ça m'intéresse pas...

1 vaisseaux par joueur, tout le monde au a l'accélération temporel x1, et basta... si on veut rejoindre un autre gars dans le système solaire, on a qu'a aller dans le scénario editor, et paf " copy state vector" et on se retrouve au même endroit que l'autre vaisseau... pas réaliste, mais pratique pour les rendez vous...

la, être 3 gugusses sur un même vaisseaux.. pour moi, aucun intérêt

enfin bon, ca enleve rien a la performance de votre travail... mais en l'etat, moi ca ne m'interresse pas

ps: si j'ai mal comprit un truc, merci de m'expliquer patiement, je suis plutot long a la detente

[MrSpock]

je suis plutot long a la detente

Et moi , je suis Clint Eastwood !!

Bon , allez ...
Quand j'étais ... jeune ..., je ne comprenais pas l'intérêt des sciences mathématiques , qui étaient trop abstraites pour moi .
Il me manquait un terrain d'application pour comprendre que les mathématiques servent à fabriquer des outils d'un genre
nouveau , pour appréhender des réalités invisibles . Comment mesurer ce que l'on ne peut saisir ?

Pour ma part , je vois un intérêt dans ce mode de jeu , c'est la fonction d'écolage .
Pour l'instant , seuls 4 postes sont disponibles , ce sont des postes d'officiers . Yves parlait de 8 postes , j'imagine de mon
coté les 4 postes restant : Commandant en second , Aspirant Navigateur , Aspirateur ( r2d2) etc ...
Je veux dire que c'est l'occasion pour des néophytes d'apprendre sur le pont , et non plus sur le tas ...
Un système de récompense serait le fait de recevoir de la part de Pilote334 , la version Serveur quand on a atteint le rang
de Commandant , ce qui permet de créer son propre vaisseau sur le Net , et de recruter son personnel naviguant ...
Nous verrions alors la différence entre la coordination de 2 équipages !!
C'est le principe de la régate à la voile ...
C'est suffisant pour t'intérresser ? De toute façon , faut de tout pour faire un monde , et moi , je n'aime pas gaspiller ma salive . C'est quand même mal-poli de dire " J"aime pas " quand tu n'as pas goûté ...
Tu seras privé de dessert !




Message modifié ( 13-08-2010 14:09 )

[pilote334]

Pour ma part , je vois un intérêt dans ce mode de jeu , c'est la fonction d'écolage .

Et bing ! Spock a tapé dans le mille ! c'est le but premier de mon travail. D'autre part, il y aura la fonction d'accélération temporelle car la synchro ne pose plus de problème. Tout les membres d'équipages ont  les commandes du vaisseau. C'est donc un vrai travail d'organisation des rôles que le commandant de bord devra faire, car il est responsable de la bonne conduite du vaisseau, de sa sécurité et de celle des autres.

Tout le monde sait piloter, rien de plus facile. Savoir analyser une situation à un moment donné et prendre la bonne décision en un court labs de temps, voilà la vraie fonction du pilote commandant de bord. Et je peux en parler en connaissance de cause puisque je suis moi-même pilote avion dans la vie réelle, pilote et instructeur ULM. Donc, la formation, je connais...un peu...

Yves

[MrSpock]

Tout les membres d'équipages ont les commandes du vaisseau.

Ah bon ?
Je pense qu'il y a des choses à inventer au niveau du gameplay .
Le SDK nous permet de faire beaucoup de choses , et un Panel2D par poste serait une belle innovation .
Nous pouvons créer des MFD personnalisés , disposant de fonctions uniques , spécifiques au poste dans le vaisseau .
C'est sûr qu'en conservant les Vessels tels quels , il est difficile de trouver un intérêt .
Par contre , si chaque Vessel est décomposé en sous-systèmes qui doivent être synchronisés , la bonne marche du
bâtiment dépend de l'organisation et du travail d'équipe de l'équipage .
 Je pense que la technique de connectivité ne suffit pas à créer de l'intérêt , Orbiter se suffisant à lui-même .
  D'ailleurs , si vous recherchiez la nouveauté dans la version 2010 , vous verriez ce que Martin envisage pour l'avenir .
Notamment de permettre dés maintenant la création d'un système de rendu Graphique " Indy ", chose qui commence à
me titiller ( dreling dreling ...) l'Esprit . Je pense à des moteurs 3d Gratuits comme OGRE et compagnie ...
Extrait de GraphicsApi dans le SDK 2010 d'Orbiter ...

Code: [Select]

// ======================================================================
// class GraphicsClient
// ======================================================================
/**
 * \brief Base class for external graphics client modules.
 *
 * This class defines the interface between the graphics-less version of
 * the Orbiter core and any external plugins providing a rendering
 * environment for the orbiter-generated scene.
 * The GraphicsClient base class is defined in terms of generic graphics
 * objects (meshes, textures, etc.) Derived classes can then adapt these
 * into specific rendering objects for a given 3-D rendering engine
 * (DX, OGL, etc.)
 */
Le moteur Physique d'Orbiter est à la pointe de la technologie , son moteur de rendu non !
Il est temps d'imaginer l'Avenir , et de ne pas avoir peur de colorier à l'extérieur des traits ...
La version 2010 représente une mutation : Il pourrait exister DES ORBITERS , et non plus un ORBITER .
Nous parlerions alors de "mods" , en plus de " addons " .
Le point commun étant dans les gènes : le moteur physique de Martin .
Il n'y a pas un " modèle type " d'utilisateur ou de joueur , chacun peut dés à présent inventer son gamePlay .
Le mien me plait beaucoup , mais je ne l'imposerai à personne . qui m'aime me suive !




Message modifié ( 13-08-2010 15:21 )

[pilote334]

Mon travail, ici, n'est pas d'inventer un gameplay, mais un outil qui pourra éventuellement servir à des gameplays.

Maintenant la question de "tous peuvent avoir les commandes" :

Imaginons le navigateur trouvant une solution de TLI grâce à IMFD 5.4 (oui, elle est sortie) et que le pilote n'aie que la 5.1.

Je n'ai pas prévu, pour le moment en tout cas, de synchronisation des MFDs (trop lourd à gérer et trop diversifiés). Le fait que le navigateur ait les commandes permet à celui-ci de lancer l'auto-burn à partir de son IMFD.

Autre exemple : dans une session d'instruction, il peut être intéressant de faire pouvoir faire passer les commandes à tour de rôle...

Voilà....

Yves

[MrSpock]

Mon travail, ici, n'est pas d'inventer un gameplay, mais un outil qui pourra éventuellement servir à des gameplays.

Exellent ! Je l'entendais bien ainsi !
Ce que j'aime , c'est l'évolutivité d'un projet .
Pour qu'Orbiter évolue , Martin a dissocié la partie " Moteur3D" pour permettre son remplacement .
Tu crées un module multiplayer dans le but qu'il soit utilisé dans l'Avenir .
Comme je suis intérréssé par ce projet , je te soumets mes idées , en sorte que ton code soit assez souple pour permettre de les réaliser . Ce n'est bien sûr pas à toi de les coder dans l'immédiat . Mais tu pourrais par la suite t'investir
dans une sorte de gameplay .

Autre exemple : dans une session d'instruction, il peut être intéressant de faire pouvoir faire passer les commandes à tour de rôle...

Oui , mais tu peux déjà réfléchir aux rôles : Le navigateur passant la main à l'aspirant navigateur , le pilote à l'aspirant pilote etc ... Il " suffit " de placer un filtre selon le type de poste occupé .
L'intérêt étant de passer , comme dans une entreprise , du " bas de l'échelle " jusqu'à la " Passerelle " , en ayant appris
sur tous les ponts . Enfin, c'est ce que moi j'imagine .

je n'ai pas prévu, pour le moment en tout cas, de synchronisation des MFDs

Ben là , il te suffit de décider que ce sont les addons du Serveur qui priment , les clients doivent s'adapter , sinon pas de
connection .
Au niveau du scénario , c'est même trés interressant puisque tel vaisseau pourrait être ancien , équipé d'anciens systèmes , d'autres plus modernes , avec les nouveaux systèmes . Et c'est le serveur qui décide du vaisseau et de ses systèmes . C'est une offre d'emploi suplémentaire pour les créateurs de Vessels ...  
Voilà ...



Message modifié ( 13-08-2010 16:28 )

[MrSpock]

Encore moi ...

Separation of the graphics and rendering subsystem from the simulation core. The Orbiter code base has been revised to isolate the rendering module from the physics simulation. This allows to plug in external graphics clients for improved visual appearance, or to run Orbiter without graphics support in server mode.

Extrait de la page " NEWS " du site officiel d'Orbiter2010 .
Etrangement , Martin a rassemblé ces deux aspects ( Graphisme , Network ) sur un même " chapitre " .
Je ne pense donc pas être Hors-sujet , mais plutôt dans l'anticipation . Et encore ... Si j'arrivais à savoir ce que Martin
imagine , je comprendrais mieux COMMENT utiliser son SDK .
Donc , l'avenir pour moi c'est le " modding " associé au " Networking " , justifiés par un nouveau gameplay .
Pilote334 s'occupant du NETWORKING , je peux me concentrer sur le MODDING .
Chouette !

[pilote334]

Si j'arrive à savoir comment on fait pour qu'un autre développeur puisse accéder à certaine fonction d emon module, j'essaierai de produire alors un SDK, mais on en est pas là pour le moment...

[MrSpock]

Tu sais , je veux bien participer à la mise en forme du sdk , la doc , etc ...
C'est une bonne expérience pour moi , et l'échange de points de vue est enrichissant .

Pour ce qui est du futut SDK , tu as plusieurs Options :

_Tu fais comme Martin S , tu publies une Dll qui exporte ses fonctions ( tu choisis lesquelles ) , tu fournis la lib ( compilation des fichiers .h et .cpp et .obj ) et le ou les fichiers .h qui contiennent les définitions de tes fonctions .
Ceux qui utiliseront ton SDK le feront en dialoguant avec ta dll ( ton module ) .
Sous borland , j'utilisais Implib , un utilitaire en ligne de commande qui prend en paramètre d'entrée le nom de ta dll ,
et en param de sortie le nom de ta lib . Et voilà ... Ton sdk est constitué de fichiers .h , d'un fichier lib  , et de ta dll .
Avec vs2005 ou supérieur , c'est possible que l' outil de création de lib soit intégrè à l'IDE .

_Tu publies tel quel ton projet , bien annoté , en y incluant des informations de license , d'utilisation etc ...

Le sdk OrbiterSound est un très bon exemple de mise à disposition du code .
La manière de DAN pour présenter les choses est très claire , bien organisée .
Son code est commenté , en donnant des exemples d'utilisation précise de ses fonctions .
S'en inspirer est de bon aloi . ( marrant ce mot ?) .

Spoiler  :

"De bon aloi" est un dérivé du verbe "aloier", forme ancienne de "allier". L’expression, certifiée dès le XIIIe siècle, désignerait la proportion légale d’or à utiliser pour fabriquer l’alliage de ce métal précieux et de l’argent.

Idem pour celui de Martin , mais il est plus long à intégrer ...

Spoiler  :

A propos de Martin ... son pseudo sur SourceForge , c'est apogee ... Il est possible dés à présent de suivre la direction
que prend le SDK (Orbiter Visualisation Project), j'ai vu des fonctions qui ne sont pas encore publiées , le code source d'Orbiter , Ogla , la version Client Dx9 ... Hallucinant . Une leçon de programmation .

A+



Message modifié ( 14-08-2010 04:29 )

[pilote334]

ouais, va falloir que je regarde tout ça...

[pilote334]

Bon, une petite info que j'avais pas retracée concernant les tests du module :

Grâce à l'aide d'un collègue de ma VA, j'ai pu tester le débit de la partie client du module. Voici comment cela s'est passé :

Contexte :

Mon débit : 6 Mb/s
Débit du collègue : 1 Mb/s

Applications réseau en fonction chez moi : TeamViewer, MSN, TeamSpeak.
Applications réseau chez le collègue : TeamViewer, MSN, TeamSpeak.

Machine relativement ancienne chez le collègue (Processeur mono coeur 2GHz, 2MB de RAM DDR1)

Incidence des applications tournant en réseau sur la bande passante et sur le processeur :

TeamViewer est un serveur/client qui permet de prendre la main sur un ordinateur distant. La partie visualisation est gourmande en bande passante comme sur toutes les applications de ce type.

Résultat du test :

Orbiter est lancé avec le module copilotage en mode client chez le collègue. Un serveur de test est en fonction chez moi. Le serveur de test émet de manière cyclique aussi vite que le processeur le permet des données de la taille de 256 octets à travers le réseau que le client reçoit. Celui-ci emet aussi une réponse que le serveur reçoit.

Compte tenu du contexte, les résultats sont plus que satisfaisant avec un échange de données supérieur à 10 emissions/réception par seconde. Sans Teamviewer en fonctionnement ces performances devrait grimper (en extrapolant) à un taux compris entre 25 et 50 émission/réception par seconde, peut-être même plus...

Pour comparaison ce taux était de l'ordre de 100 en réseau local (deux ordinateur différents sur le même LAN).

Ces tests démontre qu'une synchro de position temps réel est viable. Le projet peut donc continuer sereinement...

Fin de compte-rendu.

Yves

[MrSpock]

salut !
Ben c'est bien , mais la vitesse , ce sera vite vu pendant qu'on joue , non ?
Je veux dire : Donc , tes données traversent un NAT , et le client les reçoit ?
Hé ! Mais c'est super çà ! Le client est déjà en état de se repositionner dans l'espace ?
Parce que le vrai test , il est là !
Cool , c'est pour bientôt !

[pilote334]

Salut Spock,

Le client est déjà en état de se repositionner dans l'espace ?

Hélas, non, pas encore. Le client reçoit bien les données mais ne les traite pas pour le moment. Mais je vais très bientôt attaquer cette partie du codage (en fait deamin ou après-demain). C'est à ce moment là que le beta testeurs vont être le bienvenue.

D'ailleurs puisque nous en parlons, il va être créé sur mon serveur (le permanent, le gros, l'hébergeur quoi) un serveur TeamSpeak (www.teamspeak.com) dédié au béta-testeur du module copilotage. Il permettra d'effectuer les tests grandeur nature. Il faudra être dûment enregistré (autrement dit, accrédité par moi) pour pouvoir se servir dudit serveur teamspeak. Et avoir un micro-casque correctement configuré, évidemment...

Les volontaires sont bienvenus et peuvent se faire connaître ici-même. La période des premiers tests in situ va approcher à grand pas maintenant.

Yves

[MrSpock]

YES SIR ! NO SIR !
Teamspeak3 ?
Ouais , cela permettrait les comms pour le personnel naviguant .
Va falloir ouvrir un faq : comment je fais pour créer un raccourci clavier etc ....
T'as une secrétaire ?

 Moi j'avais pensé l'inclure , la radio , à travers le système
de NAV d'Orbiter , en rajoutant par exemple une ou plusieurs fréquences et en créant un VoiceOverIP .
Mais c'est encore un truc balèze . Mais ... Je sais utiliser les blocs audios ... et oui ...

[pilote334]

Mais ... Je sais utiliser les blocs audios ... et oui ...

Moi pas !

Alors, la bonne idée serait de créer un vrai serveur/client VOIP pour Orbiter avec une gestion MFD.
Tu te sens capable de faire ça, tu as envie de le faire ?

Si oui, tu crées un nouveau topic pour nous tenir au courant de ce projet. J'avoue que ce type d'appli, ce serait top. Un conseil (si je puis me permettre...) : préfère un protocole asynchrone (UDP - SOCK_DGRAM) pour les communications VOIP sur le réseau...c'est plus rapide et moins gourmand...

Mais...j'avoue que TS avec son paramétrage est particulièrement léger et fiable, ce qui est de loin un gage de sérénité.

Utilise plutôt le RC2 pour le client TeamSpeak, il est plus stable...

Yves

[pilote334]

Autre chose :

Lorsque le module sera en version béta avec toutes les fonctions opérationnelle, je créerai un site où les gens pourront trouver un tas d'infos en rapport avec le module copilotage...et son téléchargement bien sûr...

Yves

[MrSpock]

Je disais que je sais maitriser des blocs audio ... utiliser les sockets , pour l'instant c'est ta partie .
Je suppose qu'avec les PIPES , en réseau local , je n'aurais pas de mal .
Je pense de toute façon coder de l'audio ( en utilisant OrbiterSound pour me faire la main dans Orbiter) et ma propre lib pour divers projets ( dont le VoIp ... ) .
Mais pour l'immédiat , TS ira trés bien en attendant ! C'est cool .

[MrSpock]

Ben ...

Lorsque le module sera en version béta avec toutes les fonctions opérationnelle, je créerai un site où les gens pourront trouver un tas d'infos en rapport avec le module copilotage...et son téléchargement bien sûr...

Parles en à Tofitouf ?

[pilote334]

Le moment venu, ce sera fait ....

[MrSpock]

Bien ... ce fil !