-
Bonjour à tous,
C'est un projet qui va prendre du temps, mais je me suis lancé dans un module logiciel externe qui permettra le multijoueur (2 dans un premier temps). Les essais des premières routines sont en cours, mais les eccueils sont nombreux. J'avais tenté de le faire à l'intérieur d'un MFD, mais la fonction recv est bloquante lorsqu'elle attend des données. Donc ce sera un programme externe qui récuperera les données d'Orbiter...
Je vous tiens au courant pour la suite...et l'évolution des choses....
Yves
Message modifié ( 14-08-2010 15:53 )
-
wahoooo, mais y'a déjà un projet en cours sur le site anglophone. mais je ne sais pas s'il est bon
-
Super pilote334. Tu entres en force sur le fofo :beer:. Laisse-nous des messages sur tes avancements dans ce projet :)
-
et tu vas faire comment pour appliquer les mêmes univers à tout le monde ? dès que quelqu'un créé un vaisseau ou l'enlève, il devra apparaître chez tout le monde ou disparaitre
orbiter ne retient pas la valeur des mdf pour chaque vaisseau, il affiche toujours les mêmes, même quand on change de vaisseau
ça va être chiant, mais si tu réussi à finir ce projet de multi-joueur, bravo !
et bienvenue :beer:
-
En fait la situation de départ devra être commune aux joueurs qui veulent se connecter ensemble (comme dans fs9 ou FSX). L'ajout du vaisseau sur Orbiter n'est pas un problème (scenario editor fait ça très bien), mais comme dans FS9 ou FSX, pour que tout le monde voie le vaisseau d'un joueur, tout le monde doit posséder ce vaisseau. Non, le problème, effectivement c'est la configuration de l'univers et la synchronisation temporelle. Lors de l'initialisation de la session multijoueur, une situation temporelle est choisie (ex. le 1ier juin 2025 à 10:53:22). En fait le joueur qui propose la session sert de référence, c'est lui qui décide donc de la situation. Les autres joueurs en se connectant subissent cette situation et se synchronisent à elle. La position de chaque vaisseau sera celle au moment de la connexion. Voilà pourquoi il va falloir faire attention à la situation de départ (comme dans FS).
Voilà les grandes lignes...les difficultés tiennent, pour le moment plus au protocole de com, que je souhaite rapide et fluide comme sur le réseau DAFSIM, par exemple...(voir www.dafsim.com) que j'utilise régulièrement dans ma compagnie aérienne virtuelle (www.atlantic-sky.fr).
-
pour la synchronisation d'univers je peux te filer un bon coup de main, mon manager d'add-on sert à ca et le multi-joueur était une des cible de cet outil.
il permet de configurer automatiquement une série d'add-on et donc de démarrer tous dans les mêmes conditions, pour la suite, là c'est assez chaud mais largement faisable, faut juste une bonne dose d'acharnement.
tu epux me contacter en MP si tu veux des détails et des ptits coups de pouces
bon courage
-
Merci tofitouf....
J'en suis pas là pour le moment, mais....je te promets de me mettre en relation avec toi quand il sera temps...
-
commence en utilisant juste l'install d'orbiter par défaut y'a déjà de quoi faire.
dès que tu veux ajouter un nouveau vaisseau pour une partie je t'aide. mon manager télécharge l'addon manquant et l'installe de manière transparente (sans opération pour l'utilisateur)
may the schwartz be with you
-
Ok, je vous tiens au courant donc :
Le module serveur fonctionne avec un client, il reçoit les données d'Orbiteur via un stream. Le client est inclus dans un MFD qui retrace les infos de connexion et affiche certains messages du serveur. Pour le moment, je ne travaille qu'avec deux données d'orbiter : le GetFocusObject() et le CountVessel(), mais c'est surtout les liaisons client1<->serveur<->client2 qui m'intéressent pour le moment, c'est la partie la plus tendue...
C'est un début.....mais loin d'être la fin !
-
ambitieux en tout cas, bon courage
-
oui, bon courage !
-
Salut à tous !
Nouveau sur le forum et sur orbiter ( je suivais l'affaire par épisode ).
Je cherchais sur divers forums des propositions de mode multijoueur sur Orbiter, et j'ai le bonheur de l'avoir trouvée ici .
Je programme en c++ , ( borlandC++Builder5 de préférence) , et j'aimerais participer à l'élaboration de ce projet ambitieux.
J'ai déjà étudié les principes de fonctionnement de protocoles UDP et TCP , et la mécanique de traitement des données .
Ma plus grosse expérience dans le traitement de données concerne surtout le son ( bibliothèque fmod) et les signaux videos ( SDK win32 Multimédia ) .Egalement musicien et compositeur amateur , graphiste 3d etc ... niveau "amateur éclairé" . Pour finir avec légèreté , j'ai aussi les oreilles pointues !:zen:
Donc , si l'idée d'une collaboration te (vous) plait , n'hésitez pas à me déranger !:merci:
En espérant vous ( te ...) rejoindre dans ce beau projet , bons vols !
-
une nouvelle recrue pour nos labos !!!!
yes bienvenue Mr spock
-
Yes ... Mon petit doigt de vulcain me dit que nous allons bien fusionner ...
Merci pour l'acceuil , j'ai le nez dans le sdk , je regarde ce qui est proposé et j'exposerais mon point de vue plus tard ...
J'ai survolé les tips de Dan , bien efficaces ... respect !
Spock...
-
Oui, Dan, Papyref, Momo et les autres ont fait un super travail de documentation, qui nous est bien utile, à nous qui tentons de développer...avec nos maigres connaissances...
-
Bon, quelques nouvelles au sujet du multijoueur. Ayant réussi à faire du multiconnect suffisamment rapide (en fait dépendant du taux de rafraichissement des MFDs). J'en suis à l'étape stratégique de la réflexion. En gros, voici les questions auxquelles je suis confronté :
1 - Il est inutile de synchroniser le multijoueur (de créer les vaisseaux) tant qu'ils ne sont pas visibles d'au moins un autre joueur.
2 - Comment gérer la synchro lorqu'un des joueurs utilise l'accélération temporelle d'où la question suivante
3 - est-il utile de synchroniser la date et l'heure (mais dans ce cas, quid des positions des planètes) ?
4 - doit-il y avoir un module "co-pilotage" au sein du multijoueur, si oui, doit-il accepter l'accélération temporelle ?
Quoiqu'ayant quelques éléments de réponse, je n'ai pas la solution complète à ces problèmes, et j'ai n'ai donc, pour le moment, pas de stratégie de travail là-dessus.
Peut-être vos propre réflexion me permettront-elles d'y voir plus clair....
Yves
-
Pour gérer l'accélération temporelle, tu pourrais faire en sorte que lorsque quelqu'un en démarre une, Orbiter demande à chaque joueur d'appuyer sur une touche pour confirmer que tout le monde veut vraiment faire une accélération temporelle.
Reste juste à programmer tout ça :badsmile:
-
Il y a peut-être plus simple : Un joueur ne peut se synchroniser aux autres que si et seulement si il se trouve en orbite d'un corps. Ainsi quelque soit le temps absolu et la position du corps en question, il se trouve à proximité de ce corps. La position du vaisseau est prise relativement (en fait Apa, Pea, inc, Lon et Lat) quelque soit la date à laquelle il se trouve. Lors de la connexion, les dates sont synchronisées avec le reste de la session, le corps autour duquel il tourne aura bougé (La Terre aura avancé sur son orbite solaire et elle aura tourné sur elle-même) mais le vaisseau aura conservé sa position relative. Le pilote risque juste de se retrouvé en nuit alors qu'il étant en jour avant de se connecter, ou vice versa...
Bon, je réfléchis encore un peu là-dessus avant de commencer à coder comme un malade...
Yves
-
ca a toujours été un sujet difficile cette histoire d'accélération, la proposition de bibi était la même que moi.
de toute facons la multijoueur n'as de sens que lorsqu'on est tout près les uns des autres. donc ton idée d'être dans la même sphère d'influence est assez bonne mais risuqe de nous empécher de faire des courses spatiales en direct.
-
Ben ouais, c'est juste pour les courses spatiales. Après il y a cette possibilité pour ce genre d'épreuve :
Ici, il ne faut plus parler de position mais d'évènement ce qui inclut la prise en compte de la quatrième dimension qu'est le temps, et c'est assez inhabituel pour le commun des mortels de parler d'espace-temps, ça a toujours un parfum de SF. Et pourtant....
Préalable à une course :
- Choisir un même espace-temps (date unique et positions proche ou confondues) de départ.
- L'arrivée de la course doit se situer dans le même espace mais pas forcément dans le même temps.
- Le serveur enregistre la position de vaisseaux à des intervalles réguliers considérant que le temps est invariant sur toute la durée de la course.
- Les vaisseaux ne peuvent se voir mutuellement que si et seulement si ils sont dans des espace-temps proches.
- Si un vaisseau arrive avant l'autre, le premier, lors de la synchro avec le serveur, devra attendre l'arrivée de l'autre.
- Si le vaisseau qui est arrivé le premier se déconnecte avant l'arrivée du deuxième, ce dernier ne verra jamais le premier vaiseau.
Tout cela paraît, après tout assez conventionnel mais en prenant en compte la possibilité d'accélérer le temps dans le simulateur, cela prend toute son importance.
-
Woaww ... Je ne m'attendais pas à une telle problématique interne à Orbiter !
C'est vrai que les distances parcourues sont extra-Ordinaires ...
Pour ce qui est de :
- Choisir un même espace-temps (date unique et positions proche ou confondues) de départ.
Ne suffit-il pas de se servir de l'horloge système , en temps Universel ?
Une simple lecture getTimeDate() ? Ah oui mais non ...Car 2 gars connectés en même temps , un en France et un aux
Strates ou à la Réunion etc ... , n'auront pas la même heure .
A PART SI UN TRAVAIL DE CONVERSION EST FAIT EN AMONT : L'heure locale est celle du Serveur Hôte , les autres sont converties .
Je ne vois pas l'intêret de ma projeter en l'an 3010 , à part bien sûr pour profiter d'un EVENEMENT CELESTE particulier .
C'est d'ailleurs une idée plausible de challenge : Arriver en lieu et en heure à temps pour admirer un phénomène éphémère . C'est plus un challenge genre Trecking ou rallye dans ce cas qu'une course de vitesse .
Dans le simulateur Condor , certaines TASKS demandent à ce que les participants prennent une photo d'un élément du
décor . Ce système me plait , et l'idée de prendre en photo une éclipse ou un alignement de Planètes-Lunes original aussi.
Je commence à y voir plus clair gràce aux anciens posts de dan concernant l'utilisation des dll , et les moments de déclaration des VESSELS (meshs) .
- Trés bon départ de réflexion sur les filtres à appliquer concernant la visibilité des joueurs entre eux ( la distance qui
les sépare - sans parler du temps , je laisse çà à doc ... :prof: ) .
Cela est indispensable au niveau de la fluidité en cas de connections massives ( on ne sait JAMAIS ...) , j'imagine que
des groupes et sous-groupes de connection devront être établis et mis à jour .
Ce que je sais , c'est qu'une telle architecture est possible , c'est décrit dans le SDK socket WIn32 ... Faut que j'y aille
me rafraichir la mémoire .
L'ACCELERATION TEMPORELLE :
Pas trés réaliste , à part en simulation de Vitesse-Lumière et autre ...
Quel controle avons-nous sur l'Acceleration temporelle ? J'ai lu que parmi les callbacks à notre disposition , une concerne le buffer des actions clavier du joueur : Donc possible de limiter delta ( facteur acceleration) suivant nos propres critères -> De là création de types de vaisseaux , ou classes , qui ont droit ( ou non ) à " l'hyper espace' ?
L'idée d'acheter chez papyBar le foutu module de calcul sans lequel je n'atteindrai jamais alpha du centaure avant les
autres ...
Trop noob sur Orbiter , j'imagine quand même qu'il est difficile de se passer de cette accélération alors je pense encore à ceci : LE PIMENT DU COMPTE A REBOURS . ** Accélération imposée **
Du genre , plus que 3 minutes , 2 minutes ,30 secondes , et mes doigts moites qui glissent sur ce fichu clavier de MFD ,
si je n'entre pas mes coordonées vite fait , je vais me retrouver dans le coeur d'uranus ( et non pas dans le c... de pluton :lol:
Cet aspect là me plait beaucoup aussi , l'aspect URGENCE ( Vous imaginez la sirène des 10 dernières secondes ...)
Et cela donne un aspect STRATEGIQUE certain .
De derniere minute : Un systeme de quota , en secondes d'utilisation de l'accélération ...
Message modifié ( 18-07-2010 08:48 )
-
Bonjour à tous ( si c'est possible ... )
Bon , une parenthèse pour DanSteph et " le doc " ( il se reconnaitra ) , plus je découvre ce que vous faites ( portail francophone et autres ... ) plus je suis admiratif . Je n'en finis pas :- Tiens , il a réalisé çà aussi ? :trucdeouf:
Chapeau les gars , et aussi les autres , les anciens ... 3 jours que je parcours le forum et les autres , et votre activité
est étonnante ! Bon, c'est fait .
Réalité ?
Ben je me disais que si créer un mode multijoueur était " facile " , DanStef l'aurait déjà fait .
Donc , investigations pour trouver où çà coince , quelles sont les incompatibilités ( propre aux routines d'Orbiter ) ,
comment les contourner ou faire avec .
Et surtout , trouver ces fameux projets que les plus anciens parmi vous ont en mémoire mais qu'un blue byte comme moi
ignore .
Parmi les projets " utilisables " , j'ai trouvé :
_HAMAC ( ptit nom sympa ..)->Hamac (http://www.aibs.org.uk/hamac/)
_OrbConnect . ( upgrade de OUIPC , cousin de FSUIPC en sorte ... ).->OrbConnect (http://sourceforge.net/projects/orbconnect/)
Le premier , HAMAC , a une approche intéressante (?...) qui propose de dévier les calculs d'orbite via leur module ,
et d'utiliser ORBITER comme moteur de rendu ( en lui laissant aussi les déplacements des objets dans leur espace de référence ) . Limitation : Pas de mode sol ...
*********************************************************************************************
What all this means is that Orbits runs on a central server and users of Hamac.dll in Orbiter
connect to it. At present Orbits only works in orbit landing is not supported as Orbiter
would interfere with the central physics server too much. Equally only orbits around The Moon
are simulated. Orbits has the capacity for simulating the solar system, but as a technology
demonstrator, this was not required.
*********************************************************************************************
Les développeurs ont rencontré des difficultés , notamment celles là :
I can't land! No. This simulates orbiting. Ground multiplayer didn't need testing and Orbiter intervenes in ground actions too strongly.
I can't dock to two buddies - they jump around! This is an Orbiter limitation, once two vessels are docked, you can't update other vessels at the same time. Maximum of two vessels may dock at any time. This is not a Project Hamac bug.
I can't transfer to Solar or Earth orbit! No. Orbits only simulates the Moon at present, as further complexity, whilst planned for, wasn't required.
I can't change time acceleration! You can, but it'll mess things up. Orbits runs at a set accelerated time to make things happen quicker. You have enough dV in a DG that you shouldn't care.
My orbit deteriorates badly after a long spell Orbits is an unmodified RK4 integrator. Any production version will use the Kosmos engine.
Ces deux projets disposent d'executables à tester ainsi que leurs sources , que je vais m'empresser d'éplucher .
Histoire d'au moins connaitre mon sujet ... A+
J'ai ressorti mon vieux apache ...
Spock
-
@ Spock :
Oui, je sais que de tels projets ont existé, mais de façon embryonnaire (notamment pour OrbConnect que j'ai testé...sans réel succès dans le cadre que je souhaitais.). De plus, je voulais quelque chose qui soit proche de ce que je connais déjà un peu sur d'autres logiciels (FS9 et FSX entre autres) avec un mode de fonctionnement similaire.
Un certain nombre de choses qui n'étaient pas possible sur O2006, le deviennent sur O2010 (au vu des SDKs). Il était donc, à mes yeux, intéressant de revoir le concept...
Mais...s'il y a mieux...je suis preneur....
Yves
-
pilote 334 :
Salut !
Attends ... Je ne remets pas en question ta démarche , qui semble déjà donner quelques résultats !
Non non, c'est juste moi qui ai besoin de renforcer mes connaissances , et m'initier au SDK d'Orbiter .
Je ne veux pas polluer ton post , mais comme il est probable que tous ceux qui aimeraient qu'un multijoueur devienne
stable le liront , j'en profite pour partager avec toi et eux , l' état des lieux en quelque sorte .
Je suis allé voir le lien que tu proposais en exemple , jusqu'au : " Je sais que tu aimerais que je te donne le code source , comme je sais qu'en 5 minutes tu le détruirais ... ( en gros c'était çà ) .
:lol:
Pas faux ... :badsmile:
Sinon j'ai l'expérience de VATFrance , squawkbox , squawkbox X ....
IBNET aussi , super bien écrit .
Tout çà pour dire que c'est passionnant comme sujet , et ils sont nombreux à s'y être interressé avant nous .
Nous devrions en tirer quelque chose ...
Spock .
-
et ne négligez pas les choses toutes faites coté serveur comme smartfox. je l'utilise pour un de mes projets pro.
toute la partie echange de données est faite et ca tiens des centaines de joueurs simultatnés. y'a plus qu'à lui envoyer ou recevoir des paramètres (position, vitesse etc...)
-
Oui, effectivement, Ibnet est très bien écrit, Ivap (IVAO) n'est pas mal non plus, et donc Dafsim (j'ai pas trouvé plus rapide sur FS9 à l'époque mais il faudrait que Ben l'adapte un peu mieux pour FSX, il est moins fluide sur ce simulateur). Tu parlais de Squawkbox, il a justement été remplacé par Ivap sur Ivao (pour info 350 000 utilisateurs dans le monde, au recensement 2008 pour le salon de la simu du Bourget...dont j'étais, en tant que contrôleur aérien).
Je ne connais pas smartfox, à voir donc...
Yves
-
vu votre niveau de connaissances sur le sujet, ne perds pas ton temps, smartfox je l'utilise sur un de mes projet et le proposais à tout hasard. il a ses défauts mais reste très modulaire, et est capable de bien encaisser.
il est surtout utilisé pour les jeux en ligne sous flash.
mais tes serveurs ont l'air bien plus adaptés aux simulateurs, je m'incline donc
-
@Tofitouf :
Ne crois pas que je sois un "cador" en matière de programmation, juste un bidouilleur, tout au plus, surtout en C++. Mon expérience dans d'autres langages m'aide mais ne me transformera pas en expert pour ça. Et dans un domaine aussi complexe que celui-là, toute idée est bonne à examiner avant de l'accepter...ou de l'écarter.
Je suis quelqu'un d'ouvert par nature, et accepte volontiers l'échange d'expérience....
@MrSpock :
Ne t'inquiètes pas, tu ne critiquais pas ma démarche, tu essayais juste d'y voir plus clair dans peut-être un nième projet de multijoueur. Il n'y a aucune malice à se documenter et je trouve ta démarche on ne peut plus saine. Donc, n'hésites pas, continues...
Yves
-
Merci Yves !
Je ne connais pas non plus SmartFox , je vais faire un petit détour .
J'ai éssayé de compiler le SDK d'Orbiter avec le compilateur Borland , mais j'ai un code d'erreur " Probably COFF file " au niveau final du linK.
Encore cette vieille histoire dans les fichiers libs de VC ....
Avec DEVC++ , il suffisait parfois d'aller à la fin du fichier LIB , de faire un retour arrière , et le fichier était guéri (DX88) !
Mais là , si je veux utiliser Borland , faudrait que j'aie les .Cpp du SDK , ou juste la version dll , j'ai les outils pour reconstruire des .LIBS .
Je me disais que ce serait bien d'offrir une alternative à VsC++ ...
LA BONNE VIELLE METHODE DE DANSTEPH EST PLUS QUE JAMAIS D'ACTUALITE .
c'est d'ailleurs la seule qui marche , il me semble, le wiki en anglais dit la même chose ...
Je réfléchis aussi au GAMEPLAY ou à l' EXPERIENCE d'ORBITER , et il me semble que proposer des modes de COLLABORATION serait plus passionnant pour les "joueurs" que des compétitions . Ou alors mette en compétition deux équipes qui s'affrontent sur un même objectif ( bip ...bip...bip...bip ...)
Le monde du software est rempli de jeux de courses , de combat , etc , mais j'en connais peu qui permettent aux "joueurs"
de collaborer sur une mission vers Mars , construction d'une base sur la lune et autre pirouette de l'Esprit !
Orbiter est un simulateur Unique , et ce serait bien si le Mode MultiJoueur prolongeait cet aspect .
Le module challenge de TOFITOUF permettra déjà de réfléchir à des scénarios , tant historiques que fictifs .
Et là , ils sont nombreux les auteurs ici à être " plus que doués " .
Voilà où j'en suis .
SpOck !
Message modifié ( 19-07-2010 22:49 )
-
Bon vieux doc !
En suivant la piste SmartFox , j'ai trouvé un lien vers Unity3D .
Intrigué , j'vais voir ... Trouve ce rapport :
Photon est un sdk permettant d’installer un serveur pour des jeux multijoueurs. Il est gratuit pour une utilisation limitée à 50 joueurs, au-delà il est payant suivant le nombre de connexions.
Sur le site de Photon, vous pouvez télécharger un serveur Unity déjà préconfiguré et des vidéos vous explique l’installation d’une simplicité assez déconcertante.
50 joueurs , pour des béta-testeurs, c'est pluton pas mal ! ( UDP et TCP mentionnés ... )
Si on ouvrait le capot pour voir cqu'y a dindans ?:diable:
Je n'ai pas téléchargé encore le sdk , je vais le faire ce soir , pour voir ...
Un lien pour pilote334: Video de demo avec Unity , codage en c++ ? (http://www.unity3d-france.com/unity/?p=1502)
Un autre , les sdk Clients/seveurs :SDK (http://shop.exitgames.com/)
L'inconvenient à court terme , c'est la dépendance à une technologie qui ne nous appartient pas .
Maintenant faut voir ce que l'avenir nous réserve en matière de consommation de bande Passante ,
le temps que nous passerons à élaborer une solution et les moyens de déploiement .
Orbiter est gratuit , et le moteur de la communauté c'est la passion .
Encore un choix à faire : Une ouverture " Grand Public " , qui conduit Orbiter sur " le marché ..stable ...du moment qu'tu paies cash" , ou un cercle ( que j'espère grandissant , de passionnés qui trouvent sans cesse des solutions alternatives , à ... rebondissement" .
Est-ce que je paierais une cotisation pour participer à une aventure multijoueur sur Orbiter ?
Sais pas ... Mais les membres d'aéroclubs en " vrai " paient une cotisation .
Well , Well ... Spock.
Message modifié ( 19-07-2010 22:48 )
-
Oui, Spock, tu as mis le doigt sur la vraie problématique. Voici mon opinion là-dessus qui est aussi une question de respect, tu vas comprendre...
FSX est payant (cher). Une communauté crée des add-ons gratuits et des pros créent des payants. Payant pour un jeu payant...bon, on admet....
Orbiter est le fruit d'un travail mis a disposition gratuitement. En ce qui me concerne, je me refuse à faire du fric sur un produit mis gracieusement à disposition, ce serait dévoyer l'esprit même de la conception d'Orbiter et les intentions de son auteur. Donc, de mon point de vue, tout ce qui touche à Orbiter doit demeurer gratuit (ce qui ne veut pas dire forcément open, mais redistribuable gratuitement par la communauté dans le respect des droits d'auteur), ceci indépendamment de la qualité de l'add-on produit (imagine que Dan fasse payer ses add-ons pour Orbiter, alors qu'il le fait - et encore modestement - pour FS9/X).
Voilà, c'est peut-être discutable, mais c'est une philosophie à laquelle je tiens...
Tout travail mérite salaire, soit. Sauf que c'est pas mon boulot....et qu'Orbiter n'est pas un boulot...du moins pas encore...
Amicalement,
Yves
-
Bien sûr que je suis d'accord avec toi !
Mais en parler , c'est déjà clarifier .
Je me demandais même jusqu'où nous pouvions aller dans la modification d'Orbiter , sans avoir le feu vert du Dr Martin .
Car même si dans le SDK , une partie est consacrée aux plugins ( ma partie ...) , et aborde succintement ( suggestion ? )
le multiplayer , les modalités d'utilisation d'Orbiter concernant la mise en réseau deviennent ' litigieuses " dans le cadre
d'une cotisation . A part peut-être sous le statut d'Association Loi 1901 , avec Orbiter reconnu d'utilité publique !:applause:
Sinon , un clin d'oeil à DANSTEPH , pour lui dire que ses " vieux conseils " marchent toujours !
Sur ma machine :
------ Build started: Project: ShuttlePB, Configuration: Debug Win32 ------
Linking...
Creating library .\Debug/ShuttlePB.lib and object .\Debug/ShuttlePB.exp
Embedding manifest...
Build log was saved at "file://h:\STUDIO\Program files\ORBITER\Orbitersdk\samples\ShuttlePB\Debug\BuildLog.htm"
ShuttlePB - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Merci Dan !
Les choses " sérieuses " vont pouvoir commencer !
Ah oui, j'ai donc les sources Serveur/Client de photon , il y a de la doc en HTML Help et pdf .
Faut s'enregistrer pour le download ...
Si tu veux y jeter un coup d'oeil , je pourrais t'envoyer une copie en fichier joint .
Rapidement :
Client sdk en C++ , Serveur en C# .
Va savoir pourquoi .
Tout çà à tester avec VC bien sûr , des démos sont fournies , ainsi que les exe compilés .
Le forum de leur site est actif , pas mal de questions soulevées , mais en ANglais ...
Un commentaire d'utilisateur : ( retranscrit ..)
Je vous remercie pour cette offre gratuite limitée à 50 connections , car pour un indépendant comme moi c'est l'idéal
pour tester pleinement mes stratégies de transfert ...
Bonne nuit ,
Spock !
-
le projet sur lequel j'ai bossé est sous unity3D :) le monde est petit.
si vous avez facebook : http://apps.facebook.com/dolphinalpha/
c'est un outil magique unity mais on s'égare.
le serveur n'existait pas à l'époque, d'où smartfox qui a très bien joué son role.
En tout cas je suis parfaitement d'accord avec votre remarque sur le gratuit. il faut que cela reste gratuit à tout prix et qu'on continuer à n'utiliser que des softs gratuits pour compiler pour qu'un autre reprenne le flambeau sans avoir à payer une quelconque licence.
-
Un petit post pour demander où tu en es de tes éssais ...
A+,
Spock !
-
Je suis sur l'interface graphique du serveur...et ce sera un module copilotage plus qu'un mltijoueur. On pourra travailler en collaboration jusqu'à huit dans un même vaisseau....
Yves
-
EXELLENT !
Cela faisait partie de mon projet , quand je me demandais où était l'interet d'un mode multi ...
Ben tu l'as trouvé , hé hé !!
SUper !
Si tu m'invites dans ton starship , j'pourrais faire le cuistôt ? ( oh oh ...).
Tiens-nous au courant !
Spock !
-
ouais, ça va pas être facile de le réaliser, mais bon...
Donc patience...
-
Salut , Pilote334 et les amis du mode multi-Joueur .
En tenant compte des suggestions de Dan , j'arrive à synthétiser ce genre de projet .
_ Ne plus envisager un module externe à Orbiter , mais un plugin qui est invoqué par un type de vessel particulier .
_ Ce module peut être configuré comme Serveur ou client , recevant et envoyant des données .
_ Le mode le plus intéressant pour commencer semble être le double commande , et la classe Shuttle de base serait
pas mal pour débuter , tant par la programmation que par l'initiation au pilotage.
Dans ce modèle , c'est le client qui se connecte au serveur , qui doit être activé sur le réseau .
Une procédure pourrait faire en sorte que le client (copilote) ne puisse démarrer le SImulateur tant que le Serveur
n'est pas prêt . Un bouton On/Off permettrait d'arrêter le mode Double Commande et permettre au copilote de prendre les commandes en cas d'absence de serveur .
_ Ce module devra intégrer un système de commande de connection intégré dans un MFD .
_ Devront être présent aussi un système de communication de style chat et Audio .
Au niveau Technique ,un des problèmes IMPORTANTS reste l ' interpolation des données de Position/rotation/translation
liés aux temps de latence entre PC . Vous imaginez bien que au temp t=0 , si j'envoie une position p(x,y,z) , que ce message est transmis au 2eme PC qui le reçoit au temp t=t+0.1 , p(x,y,z) ne sera plus valable , et les collisions imprévisibles ...
Autre situation : QUe faire quand une connection est interrompue ?
Dans le cadre d'un Double Cockpit ?
Dans le cadre d'un mode multi ?
Quand un vaisseau ne " répond plus ", une méthode " réaliste " serait de le laisser filer ( donc le prendre en charge sur chaque Pc ) et recalculer sa position selon les derniers params valides reçus .
D'autres idées ?
Mr SPock.
-
Alors oui, c'est bien le principe que j'envisageais...Je m'explique...
1 - On part avec le même scénario type (qui peut être customisé par les deux parties si besoin)
2 - Chacune des partie doit avoir le vaisseau de l'autre sinon...refus de connexion
3 - Le poste occupé (8 possibilités) ne doit pas être pris pas une autre partie...sinon : GET OUT !!! :blbl:
4 - Tout le monde démarre orbiter en pause. C'est le serveur qui dit "Ok, je suis prêt" et enlève la pause.
Déroulement chronologique d'une connexion tel que je le vois :
1 - un joueur lance Orbiter et un scénario en pause.
2 - Ctrl-F4 puis activation du plugin en mode serveur avec choix de la fonction à bord (c'est lui qui propose la session donc il a toutes les possibilités.
----- Opération terminée pour celui qui propose la session (on dit qui héberge la session) ---------
3 - un autre joueur lance Orbiter avec le même scénario en pause aussi
4 - Ctrl-F4 pour activer le plugin en mode client en entrant l'adresse IP du serveur (de l'hôte de la session)
5 - le client en lisant la session récupère la liste des postes vacants à bord
6 - le joueur choisit sa fonction à bord dans la liste proposée.
7 - Une demande est transmise à l'hôte qui l'accepte ou la refuse (non,, je veux pas jouer avec toi).
8 - si acceptée le client mets en place les éléments du scénario du serveur en les comparant avec les siens.
---- Début de partie -------------------------------------------------
Si et seulement si tout le monde prévu est à bord :
9 - L'hôte donne son accord pour lancer la partie.
---- Partie en cours -----
10 - l'hôte envoie les données de position, d'attitude, d'état des commandes (pas toutes) du vaisseau devenu commun en temps réel. La quantité de données envoyées ne devrait pas pénaliser la synchro.
---- Fin de partie ----
C'est l'hôte qui décide de la fin de partie mais....
Toute connexion perdue volontairement par un client est définitive pour la session en cours, le client ne peut revenir sur une perte de connexion. (à étudier la possibilité de se reconnecter, le serveur se mettant en pause le temps de la reconnexion).
Voilà voilà, c'est comme ça que j'envisageais les choses, comme dans FSX par exemple....
Yves
-
4 - Tout le monde démarre orbiter en pause. C'est le serveur qui dit "Ok, je suis prêt" et enlève la pause.
Bien vu çà ,utiliser la pause !
5 - le client en lisant la session récupère la liste des postes vacants à bord
6 - le joueur choisit sa fonction à bord dans la liste proposée.
Bien !!
10 - l'hôte envoie les données de position, d'attitude, d'état des commandes (pas toutes) du vaisseau devenu commun en temps réel. La quantité de données envoyées ne devrait pas pénaliser la synchro.
Sur ce point , tu n'evoques pas l'envoi des commandes client vers le Serveur .
Super important puisque si j'ai bien compris ton voeu c'est par exemple de créer un poste de barreur ,d'officier radar ,
d'officier de pont ( amarrage ) , officier de survie ( gestion oxygène , systèmes electrique, etc ..) , de scaphandrier ( pourquoi pas ?) etc ...
J'ai ma petite idée la dessus , mais huit d'un coup , tu fais fort !!
Vite fait , je dirais qu'un client ( le radar) passe une commande au serveur ( "ISS en terminale ...") et que le serveur (commandant de bord a la voix pleine d'assurance) donne son ordre à l'officier en question , tout en mettant à jour l'état
des clients restant . Huit ? :)
Ton histoire a de la gueule !!
MrSpock.
Message modifié ( 29-07-2010 23:01 )
-
Bon, des nouvelles de l'avancement du projet :
J'ai réussi à intégrer mon client dans Orbiter de façon non bloquante, même en l'absence de serveur. J'ai galéré un peu mais la façon dont je l'ai fait en fait un client extrêmement rapide !
Pour le côté serveur, je galère encore mais ça va venir. J'ai un serveur de test mais il est externe à orbiter, il me sert juste à vérifier que le client se connecte bien...
Voilà pour les nouvelles....
-
J'ai réussi à intégrer mon client dans Orbiter de façon non bloquante, même en l'absence de serveur
Tu veux dire que ton client utilise une fonction qui ouvre un port et attend de trouver un Serveur , tout en n'empéchant
pas la boucle d'Orbiter de tourner ? Bien !!
J'ai un serveur de test mais il est externe à orbiter, il me sert juste à vérifier que le client se connecte bien...
çà , c'est un détail , une broutille , une chimère ,une ...
Bon , ben t'y es presque ?
On connait déjà le sexe ?:)
Quel sera son prénom ?:)
Les contractions vont se rapprocher , courage !!:damn:
:applause:
Mr SPock !
-
Ouais, le truc pour le client est que je ne voulais pas bloquer Orbiter suite à un serveur introuvable. En fait, s'il ne le trouve pas, la boucle continue, mais sans serveur. Il faut donc se déconnecter et tenter une reconnexion si il y a eu échec. Mais c'est un détail quand on le sait, et l'application notifiera si la connexion est réalisée ou non, donc pas de souci là-dessus.
Bon à savoir, le fait que le client soit connecté n'a pas (pour le moment en tout cas) d'incidence apparente sur le framerate.
Chouette !!!
Le problème du serveur se heurte à la fonction "accept" qui est bloquante et dont j'ai besoin pour accepter plusieurs clients. Mais je vais me pencher dessus et je vais trouver une solution...
Yves
-
Le problème du serveur se heurte à la fonction "accept" qui est bloquante et dont j'ai besoin pour accepter plusieurs clients. Mais je vais me pencher dessus et je vais trouver une solution...
En cas de contraction trop forte , la respiration type " petit chien " fonctionne bien !:lol:
Pour préparer une longue apnée , c'est de l'Hyper-ventilation ...:badsmile:
Good luck PILOT !
MrSpock
REEDIT :
Tu parlais d'utiliser le mode "PAUSE" .
Si la connection en mode Serveur est Bloquante pendant la PAUSE , ya pas d'probleme ?
Et si tu utilisais un timeOUT ?
Message modifié ( 01-08-2010 19:01 )
-
Je veux rester indépendant du mode "pause", ne serait-ce que par principe. Le plugin ne doit en aucun cas modifier de manière parasite le comportement d'Orbiter, c'est ma règle. S'il le modifie, c'est en rapport uniquement avec les données que le client (ou serveur suivant le mode en cours) reçoit.
D'où la difficulté, mais c'est le prix à payer pour avoir un protocole de communication rapide.
Yves
-
Je comprends ...
Peut-être en rajoutant des options dans le " Launchpad" alors ?
Je n'ai pas regardé encore les possibilités du SDK à ce sujet , mais il me semble que ce serait un bon endroit pour
lancer un serveur .
MrSpock .
-
En fait t'es pas loin, Spock !
Il n'est pas dans le lauchpad proprement dit, mais dans les options custom (comme le scenario editor). Ainsi il peut tourner en tâche de fond ce qui est de loin préférable et voulu. C'est comme si tu avais un programme externe que tu lances et paramètres depuis Orbiter et ensuite...tu l'oublies, il fait son boulot et communique avec Orbiter et (le plus important) l'extérieur....
Voilà où j'en suis. Le client fait son boulot mais pas le serveur...
Yves
-
Woaw !!
dans les options custom (comme le scenario editor)
Interressant ton plan !
Je vais étudier çà de plus près , mais j'imagine que tu as déjà bien pesé le pour et le contre ...
Merci pour l'info !
MrSpock.
-
Salut Pilote334 !
Un petit mot pour te rapporter mon évolution :
AJout d'une option Multijoueur dans les 2 MFD standard .
Affichage sur la première page de l'IP Hôte .
Je vais coder dans le MFD en utilisant les PIPES ...
A Faire :
Boutons Connect/Deconnect .
Bouton Chat ----> en rapport avec IP ??
Bouton voice ----> en rapport avec frequences ??
Data en background .
Le launchPad me semble parfait pour éditer des params de session . ( switch client-serveur , maxclient etc..)
// ==============================================================
// ORBITER MODULE: LaunchpadParamTemplate
// Part of the ORBITER SDK
// Copyright (C) 2006 Martin Schweiger
// All rights reserved
//
// LParam.cpp
//
// This module demonstrates the ability to add custom interfaces
// for module-specific global parameter settings into the "Extra"
// tab of the Orbiter Launchpad startup dialog.
// This particular example doesn't do anything useful, but can
// be used as a starting point for real applications.
// ==============================================================
A+MrSpock .
Message modifié ( 02-08-2010 02:48 )
-
Bonjour Mr Spock,
En fait le paramétrage se fait à l'intérieur du module : deux choix, soit il y a une adresse IP auquel cas on est en mode client, soit il n'y a pas d'adresse IP et on est en mode serveur (variable ADDR-ANY). C'est le plus simple....et le plus efficace.
En même temps c'est le plus facile à coder.
Tiens, voilà à quoi ça ressemble...
D'abord le module à activer dans Orbiter :
(www.simusic.fr/img/launchpad1.jpg)
On le retrouve dans le menu "Custom" d'Orbiter une fois lancé le scénario.
(www.simusic.fr/img/custom1.jpg)
Enfin, on retrouve son activation et paramétrage...ultra-simple !!!
(www.simusic.fr/img/plugin1.jpg)
Il manque la partie où le serveur/client indique son statut (connecté, non connecté, en erreur...etc...) que je n'ai pas encore réalisé, mais ça, c'est de la broutille....
Yves
Message modifié ( 02-08-2010 15:25 )
-
Ça avance bien ici ! Pour l'adresse de connexion, c'est l'adresse IP ? Ce serait sympa qu'il détecte automatiquement l'IP du PC qu'on utilise. ;)
-
Non, en fait l'adresse IP de ton PC, il s'en fout, c'est sur le même PC que tourne Orbiter donc on la connait, on la code en dur. C'est l'adresse IP du serveur distant (le collègue qui hénèrge la session, quoi) que l'on met...
Voilà, voili...
Yves
-
Impressionnant et bien pensé !
Félicitation , cher collègue !
:applause:
-
Bonjour,
Des bonnes nouvelles : ça y est, ça fonctionne enfin !!! Le client et le serveur dans le même module !
la solution a été le recours au thread (ben voyons !) pour éviter le blocage de "connect()" mais, j'y suis arrivé et une fois qu'on a compris, c'est pas si compliqué (en apparence) que ça. Le tout est de faire attention à la gestion des threads.
Fonctionnement des deux modes : à l'emplacement de l'adresse IP, si on met "serveur" puis "connexion", on se retrouve en mode serveur. Si on met autre chose, on est client. Voilà, c'est hyper simple !
Etape suivante : choix d'une structure de données à transmettre-recevoir...
Des nouvelles ici bientôt !
Yves
-
AAAH !
Enfin des nouvelles !
la solution a été le recours au thread (ben voyons !)
:top:
Fonctionnement des deux modes : à l'emplacement de l'adresse IP, si on met "serveur" puis "connexion", on se retrouve en mode serveur. Si on met autre chose, on est client. Voilà, c'est hyper simple !
:top:
Etape suivante : choix d'une structure de données à transmettre-recevoir...
Au point où tu en es , tu pourrais faire comme Jimmy Hendrix !
Tu codes ta structure avec le clavier derrière la tête ( trop facile sinon ... ).
Pis quand t'a fini , tu branches ta webcam , tu l'arroses de kérosène et tu nous fait un de ces petits clips qui vont bien ?
Aouuuuuuuuuh ! Aouuuuuuuuuh ! Aouuuuuuuuuh !
:applause:
-
Re...
En réfléchissant voici l'idée pour les datas :
Le serveur (celui qui héberge la session) envoie à chaque requête d'un client deux groupe de données en une trame (o verra si le socket l'accepte...) : un groupe variables de statut/position/attitude du vaisseau et un groupe de variables d'action simples (mode rcs, prograde/retrograde/normal+/normal-, puissance en cours pour chaque moteur principal et rcs). Le client les traite, les actualise sur sa propre session et ne renvoie au serveur que la partie action (au cas où il y ait des changements).
Voilà le principe général mais...suivant la fonction occupée à bord certaines données ne seront pas renvoyée au serveur. Un exemple est le navigateur qui aurait une action sur la manette des gaz. Celle-ci ne serait pas transmise au serveur et à la prochaine actualisation, le client se retrouvera dans l'état ou est le serveur, donc l'action est annulée par l'actualisation suivante (au frame suivant en fait, au pire 8 frame plus tard (à cause des 8 fonctions à bord = une fonction par frame dans le pire des cas...)).
Bon, reste à coder tout ça et à faire une interface sympa...
Yves
-
deux groupe de données en une trame
Du genre " structure imbriquée " ?
Tu devrais pouvoir passer en référence de ta fonction d'écriture un pointeur sur une classe CMSG par exemple.
Cette classe contiendrait deux structures , initialisées dans la classe et lisible normalement à travers readfile().
Par contre , un pointeurA contenant un pointeurB , je crois que B est inutilable plus loin en lecture ( en passant par le mode BYTE ).
-
Non, je pensais à qqchose de plus simple : deux structures de variables différentes passées à "send()" en tant qu'objet (surcharge de type)...
Yves
-
Oooops
Non, je pensais à qqchose de plus simple : deux structures de variables différentes passées à "send()" en tant qu'objet (surcharge de type)...
Send() accepte + d'un paramètre ? Comprends pas ...
A moins que tu veuilles dire : j'envoie un message puis un autre ?
(surcharge de type)
tu déclares
MASTRUCT msg ;
dans SEND(param,(void *) &msg,param,...) ??
Message modifié ( 04-08-2010 21:49 )
-
Cool ! Moi qui ne savais pas comment faire pour mon épisoe ... 2 F-35 qui escorte le DG4 en montée vers l'orbite ... vers Mars ! Mais seulement, comment piloter tout le monde ? J'ai eu l'idée de passer par FSX, mais tout ce qui est cone, airlocks, Playload bay et trappes de turbo-pacs ne serais pas animées ... puis une fois dans l'espace, tu ne peut plus rien faire ! Dernièrement, le passage brutaled'une qualité de 1 pixel = 1 mètre à un 1 pixel = 0.6 kilomètre me semble tout gacher pour l'expérience que j'en ai. J'attend vivement le nouveau-né, félicitations au parents ! euh je m'égare
-
HEY !! YVES !! UN CLIENT !!
:hot:
-
Bonjour,
Il m'est venu une idée : via un port particulier, le serveur (ou le client) communiquera avec un MFD dédié qui permettra de connaitre le statut et où passera certaines infos utiles pour l'équipage. C'est le serveur qui communiquera ces infos...Le MFD est déjà prêt, je n'ai qu'à le modifier...
Ca s'étoffe, ça s'étoffe....
Yves
-
Bien ...
C'était étonnant que tu n'utilises pas les mfd !
Enfin , chaque chose en son temps , hein ?
A+ , MrSPock .
-
Bon voilà la suite :
Je suis en train de programmer le MFD. Son rôle est double. En fait, lorsqu'on passe en mode client sur TeamServer (c'est comme ça que s'appelle le module principal), on ne peut pas choisir sa fonction à bord. Une fois la connexion établie avec l'hôte de la session, le client récupère les fonctions disponibles à bord et donne le choix à l'utilisateur via TeamMFD (le MFD relié à TeamServer). TeamServer récupère le choix de l'utilisateur via TeamMFD et l'envoie sur le réseau (vers l'hôte en fait qui le redistribue aux autres clients).
Enfin, le MFD permettra de donner aux utilisateurs des infos en broadcast en provennance de l'hôte de la session et /ou du cdt de bord du vaissseau.
Voilà....
Suite au prochain numéro...
Yves
-
SUper ...
Je me demandais si tu pensais aussi intégrer des changements graphiques , comme par exemple des PANELS2D
spécifiques aux " postes " clients ? Par exemple , le gars qui remplit la chaudière de charbon , aurait moins l'occasion
de rêver devant les étoiles que le Navigateur ? L'immersion serait super ...
-
Non, pas pour le moment en tout cas. Mais tu sais, un programme, ça évolue, alors qui sait....
-
J'ai éssayé une seconde de me mettre à ta place ...
Il y a beaucoup de paramètres à considérer .
Seul , je ne sais pas comment tu fais !
Mais bon , en procédant par étapes cela évite de se perdre .
Bon courage !
A+
-
Bon, ça avance, le MFD communique avec le plugin, tout ça rassemblé dans une seule dll. Pas commode, mais bon...
Voilà un screen en l'honneur de Mr Spock....
(www.simusic.fr/img/pluginmfd1.jpg)
La suite pour bientôt : prochaine étape, les données d'Orbiter...là, ça devient sérieux...
Yves
-
YEAAH !
Merci pour l'avant-première !
Cela semble simple et efficace !
Reste plus qu'à essayer 2,3 clients ?
C'est bien parti ...
Good work !:top:
-
Re bonsoir...
En fait, les données échangées peuvent se classer en trois catégories :
- Données de gestion de la session co-pilotage (fonctions à bord, connexions, déconnexions...etc...)
- Les données de situation et de statut du vaisseau (fournies à tous les clients, le serveur les ayant déjà). Elles assurent la synchronisation de tous les protagonistes par rapport au serveur.
- Les données d'action (appui sur un bouton, applicationn d'une poussée...etc...) fournies par les clients ou le serveur en fonction de la position à bord tenue par l'utilisateur.
Voilà pour le principe...
Yves
-
Re
Petite précision, la programmation de ce truc là, je m'en suis vu car il a fallu mélanger de type de plugin : le plugin général et le plugin du MFD. Cela a tendance à produire de la programmation spaghetti (j'aime pas trop !). Bonjour la maintenance sur ce type de prog. Mais bon, j'ai pas trop eu le choix...pour le moment. J'essaierai d'organiser le source un peu mieux, mais une fois terminé le projet.
Yves
Message modifié ( 09-08-2010 00:06 )
-
C'est marrant ... j'étais justement entrain d'y penser , aux types de données , et surtout au circuit de l'information .
Tu parlais de broadcasting , faut que je révise un peu mais ... c'est l'information à la demande ou l'envoi de paquets à
tous les connectés ? Non, çà c'est le multicast je crois ...
sinon :
1- Les données de situation et de statut du vaisseau (fournies à tous les clients, le serveur les ayant déjà). Elles assurent la synchronisation de tous les protagonistes par rapport au serveur.
2- Les données d'action (appui sur un bouton, applicationn d'une poussée...etc...) fournies par les clients ou le serveur en fonction de la position à bord tenue par l'utilisateur.
Il existe un lien interressant entre ces deux types de message .
Le plus évident est la dépendance de 1 à 2 :
Ex:
Si 2 ne lance pas l'ignition , 1 ( le Vessel) ne bouge pas ! ( Donc bypass de message de UPDATEPOS(...) ).
Si 2 ne change pas de cap , 1 conserve le même cap ! ( Donc bypass de message de UPDATEROT(...) ).
Cela est certes bien complexe à mettre en place , mais économique en taux de transferts .
La difficulté pour moi c'est de bien cibler les interdépendances ( et donc connaitre avec précision le rôle de chacun dans le sim ) .
Un truc au delà ... Ton TeamServeur communiquant avec un autre TeamServeur via le OrbiterChallenge de Tofitouf !
8+8+8+8+8+8+8+.....
:)
-
Alors, je précise :
Les message en broadcast sont destinées à tout le monde, c'est presque un synonyme de multicast mais il y a une différence, ce sont les messages envoyés qui sont d'un intérêt général (des messages système en l'occurence).
il existe un lien interressant entre ces deux types de message .
Le plus évident est la dépendance de 1 à 2 :
Oui et non. La situation du vaisseau étant mise à jour très rapidement, l'influence des messages d'action est limitée, sachant que les message de situation comprennent les vecteurs force (donc le mouvement).
Les messages d'action disent simplement à quel moment on applique ces forces et qui est à l'origine. C'est suffisant pour Orbiter.
La difficulté pour moi c'est de bien cibler les interdépendances ( et donc connaitre avec précision le rôle de chacun dans le sim ) .
Oui, je suis d'accord avec toi. Chaque rôle (poste au sein du vaisseau) détermine qui peut faire quoi. C'est essentiel pour éviter les conflits d'action. Un jeu de priorité est donc établi.
Yves
-
Salut !
Un autre truc que je me demandais , un client calcule bien sa propre position ?
Ou tu la calcules d'aprés les messages que tu envoies ?
Je dis cela parce que je viens de me frotter à la mécanique interne d'Orbiter concernant justement les positions
( à la surface d'une planète , certes ...) des vessels , et ce n'est pas simple !!
Ou alors j'ai raté un train ? :badsmile:
Moi , je laisserais Orbiter client faire le boulot à ma place ... tout compte fait !
A+ , merci pour les explications ! ;)
-
En fait, c'est pas le client qui le fait mais le serveur (l'hôte de la session si tu préfères). C'est lui qui le transmet aux autres. C'est une simple recopie à l'instant T, donc très peu de calculs...
Yves
-
Ahh... d'accord ...
C'est vrai que j'ai fait l'expérience de demander la position à Orbiter , mais pas de lui donner .
Tu feras les tests bientôt ?
Je pense essayer de mon coté un de ces jours avec mon système de Pipes , rudimentaire mais pour faire des tests ...
Bonne Journée !
-
Ooooops ! pas d'affolement. Pour la transmission des données, faut tout transformer en ASCII. Pas simple pour moi car pas familier avec ce type de procédure donc, doc, doc et re-doc ! ça prend du temps. Mais...j'ai commencé par les messages de broadcast. Et ça marche côté codage et côté transmission, l'envoi d'une trame se présente avec quelque chose comme ça :
trame envoyée : "BCST DanSteph 1 0 ....etc...."
Dans l'ordre :
BCST = message de broadcast (les 3 type de message : BCST, STAT, ACT)
DanSteph = Callsign ou pseudo de l'utilisateur
1 = mode de connexion (0 = non connecté, 1 = mode serveur, 2 = mode client)
0 = Fonction occupée à bord (0 = cdt de bord, 1 = pilote, 2 = copilote, 3 = navigateur)
Voilà où j'en suis...ça avance....doucement mais ça avance....
-
eh ca prends forme tout cela, excellent.
-
Pas simple pour moi car pas familier avec ce type de procédure donc, doc, doc et re-doc ! ça prend du temps.
A qui le dis-tu ?
Cela fait deux jours que je bouffe du AnsiiString pour mon projet d'éditeur de fichier .cfg !
Mais l'enjeu en vaut la chandelle ... de mon coté , je sais déjà instantanément combien j'ai d'Objets de décor dans
le fichier .cfg que j'édite via mon programme .
_ QUi rajoute des blocs à la demande ( mesh , block, runway ...)
_ QUi filtre les objets à l'édition selon leur type .
_Qui scannera le dossier "Config" à la recherche de petites erreurs ...
_ ...
T'as l'air de bien te marrer toi aussi ( strcat,strlen,strcpy.....)
Donc , tu télégraphies des données !:badsmile:
APrés le FAR WEST , le FAR SPACE !!
-
Parti d'un projet impossible au dires de certains, je vais sur un projet possible qui deviendra, je l'espère probable....pour finir un jour peut-être par être une réalité....
-
pilote334 a écrit:
Parti d'un projet impossible au dires de certains, je vais sur un projet possible qui deviendra, je l'espère probable....pour finir un jour peut-être par être une réalité....
À date, c'est très probable vu les avancements déjà fait.
Un petit remontant :drink: :badsmile:
-
moi je me tiens pret à vous acceuillir sur mon site pour le lancement des parties.
je prépare ca dès maintenant, des pages multijoueurs qui attendent un certain nombre de participant pour lancer le scennario. avec aussi un champ pour l'adresse ip du serveur.
cher pilote334, est ce que tu peux prévoir un fichier de configuration au format cfg, dans lequel je pourrais écrire les paramètres (IP par exemple et d'autres choses dont tu as besoin).
-
Je n'en suis pas là, mais l'idée est bonne, je la retiens. Je te fournirai la liste des variables nécessaire qu'il faudra mettre dans le fichier .cfg.
Yves
-
CHampagne !!
:friend:
-
Bonjour,
J'ai failli tomber sur un (très) gros os !!! Le projet a failli s'arrêter là ! J'explique :
On peut récupérer en lecture à peu près toutes les données d'un vaisseau, jusque là, pas de souci. Mais beaucoup d'entre-elles ne sont accessible qu'en lecture et pas en écriture (fonction GetQuelquechose mais pas de SetQuelquechose en face). C'est le cas, notamment pour la position du vaisseau. Je pouvais donc transmettre les données de position de mon vaisseau, mais le client ne pouvais pas actualiser sa propre position, juste la comparer avec la sienne. C'était à côté du but ! :wall:
Je me suis alors rappelé que tout objet dans l'espace décrit une orbite. Or je me suis rappelé aussi qu'on pouvais lire et écrire les éléments de l'orbite du corps choisi par rapport à un corps de référence. BINGO !!! j'ai ma solution pour contourner le problème....:trucdeouf:
OUUUFFF ! sur ce coup là, je reviens de loin.... :siffle:
Yves
-
Ouaip !
C'est ce que j'essayais de te dire , te préparer au ... choc .
Ceci dit , pour vérifier , j'ai fouiné dans le SDK ( on tourne autour du pot ...) et il me semble avoir vu une fonction de position dans la classe Vessel . Je vais essayer de la retrouver ...
Parce que si tu veux entrer dans les circuits d'Orbite ... tu vas manger du wiki !!
par rapport à un corps de référence
Cette fonction renvoie des valeurs calculées sur la frame écliptique de l'astre en question , à une date fixée ...
Moi aussi je me frottais les mains ... j'ai failli m'arracher les cheveux !
Mais ton idée peut en effet fonctionner sans calcul , du moins en théorie .
Ceci dit , j'ai appris en 4 jours " à cause d'Orbiter " plus de choses sur la géométrie , trigonométrie , topographie et astronomie qu'en toute une vie .
EN CAS DE GROS PEPIN , il reste la chirurgie ( LA GROSSE BOUCHERIE...) : faire comme FSUIPC , un FILEMAP de la région
mémoire d'orbiter qui concerne les variables du VESSEL , récupérer l'emplacement mémoire, et écrire directement dedans .
Faudra juste sangler ORBITER pour qu'il ne bouge pas trop , lui mettre une ceinture en cuir entre les dents , et pratiquer
une ouverture dans son lobe frontal pour en extraire 1cm3 .
J'espère qu'on aura pas à aller jusque là ...
Message modifié ( 11-08-2010 06:26 )
-
Hey !
Je viens d'avoir une idée :
Si tu crées un vessel dans ton plugin - appellons le TeamVessel - , tu as un pointeur sur ce vaisseau .
Si tu passes ce pointeur au client , ne partageront-ils pas la MEME INSTANCE ?
En fait non, mais le client sera actualisé ( par copie) par le serveur .
Si je ne suis pas assez clair , je développerais plus tard .
Mais je crois qu'il y a un truc à faire de ce coté ... vu que tu cherches à recopier des données , le pointeur , c'est le PIED !!
REEDIT :
Ah oui ... mais non... enfin... si !
Le problème du pointeur , c'est qu'il représente l'état du Vessel serveur au moment (t) . C'est comme un cliché instantané.
Il faut donc prendre ces "clichés" et les envoyer périodiquement au client ( ou que le client le demande au serveur , via une
question :
QuelleEstMaPositionStp(VESSEL* takaprendrecellela) ) .Et là , tu envoies une requête au serveur sous format texte si tu veux , mais il devra renvoyer un pointeur de lui-même.
Reste à définir la taille du pointeur : DWORD taille=sizeof(takaprendrecellela) et voir si tu peux l'expédier en 1 seul colis
par chronopost .
Mais cela change ta stratégie , enfin , pas tant que çà : tu conserves tes anciens messages , tu en crée un nouveau .
Qu'en penses-tu ?
Message modifié ( 11-08-2010 06:30 )
-
Zut ! Je crains aprés réflexion que le pointeur ne passe pas au travers des sockets ... Je m'explique :
Le VESSEL * pointe sur un emplacement mémoire sur le processus Orbiter du PC A .
Un pointeur sur une structure passerait , car c'est le contenu de la structure qui est envoyé .
Dans le cas d'un pointeur sur classe , ce n'est pas le contenu , mais l'adresse dans la pile de mémoire du processus Orbiter (de PC A ) qui est passée en paramètre à PC B .
Le PC B va rechercher l'adresse dans sa pile , ne la trouvera pas , et la fonction échouera .
Au mieux , il trouve sa propre adresse , si c'est la même dll qui tourne sur A et B .
C'est théorique hein , j'espère me tromper .
Faut essayer ...
La solution serait d'envoyer un VESSEL** , qui serait alors le contenu du pointeur mais ... les fonctions de base des Sockets ne sont pas faites pour çà . Il me semble quand même avoir vu un RAW SOCKET DATA quelque part dans le WSK2 SDK ..
Avec une note informant les programmeurs qu'ils pouvaient utiliser le format raw , non documenté pour faire ce qu'ils voulaient . Quelle aventure ... inventer une extension de protocole ?
AU CAS Où :
BINGO !!! j'ai ma solution pour contourner le problème....:trucdeouf:
ne fonctionnait pas dans la pratique ... Si cela fonctionne aprés des tests , annonce le STP !
Bon courage ,
Message modifié ( 11-08-2010 06:35 )
-
Alors en fait si, ça fonctionne (d'après le sdk en tout cas): je récupère les données via "getelements" de la classe "VESSEL" dans leur forme la plus simple. C'est du temps réel, on ne fait aucun calcul, le décalage se résumant au délai de la liaison réseau (négligeable). Comme on part à la base avec le même scénario de tous les côtés, le mjd ne pose pas trop de problème, les clients et le serveur sont synchro à quelque chose près. Une réactualisation du mjd de temps en temps est envisageable (notamment lors du premier message).
La fonction "GetElements" donnent les paramètres de l'orbite par rapport à un corps de référence...que je récupère aussi grâce à "GetGravityRef". Donc pas de souci de côté là. C'est testé en récupération, ça marche.
Je précise qu'on réactualise aussi vite que possible (indépendant du framerate c'est un processus thread à part d'Orbiter quoique commandé par le plugin...Méga rapide !!! j'ai été moi-même bluffé).
Enfin, je récupère l'attitude du vaisseau (x,y, et z) en Global Frame Ecliptique pour assurer que celui-ci pointe dans la bonne direction. Et le tour est joué.
Pour le moment je code la lecture des données pour pouvoir les envoyer, et ça avance bien grâce aux fonctions de base du C. Je vérifie à chaque fois que ce sont les bonnes et que je les transforme au bon format pour pouvoir faire l'opération inverse dans de bonnes conditions.
Si action d'un joueur il y a, celle-ci n'a pas d'influence sur le client mais sur le serveur (poussée, orientation...etc...) qui retransmet sa modification de position aux clients. Toujours pas de calcul, c'est l'Orbiter du serveur qui s'en occupe (c'est ça la véritable astuce pour éviter les prises de tête) et qui le retransmet aux autres (toujours le même principe, ça évite les dérives).
Quant à me lancer dans un lifting de winsock me parait l'équivalent d'utiliser un bélier pour enfoncer une porte ouverte !
Et de plus, je n'en ai pas les compétences...Je me suis déjà assez em.....é avec SOCK_STREAM pour ne plus y toucher dans la mesure où ça fonctionne plutôt bien et avec un contrôle de flux en plus (ce que ne fait pas SOCK_DGRAM, ni SOCK_RAW).
Je continue donc...on verra bien....
Merci pour les idées en tout cas...
P.S. : Si je peux me passer d'un système comme fsuipc qui marche ou ne marche pas, je préfèrerais...Dans le genre, simconnect (FSX) est bien mieux fait par Microsoft (pour une fois....).
Yves
-
Si je peux me passer d'un système comme fsuipc
Sûr ! La boucherie en dernier recours ! :badsmile:
Quant à me lancer dans un lifting de winsock me parait l'équivalent d'utiliser un bélier pour enfoncer une porte ouverte !
Ouverte , oui , mais étroite ... Comment passer avec c'te fichue armoire ??
Enfin, je récupère l'attitude du vaisseau (x,y, et z) en Global Frame Ecliptique pour assurer que celui-ci pointe dans la bonne direction. Et le tour est joué.
Par comparaison ? Et si par malheur il ne pointait pas... ouais bof, ya pas d'raison !
Ben çà m'a l'air d'être " carré " !
C'est testé en récupération, ça marche.
Ouaip , mais tu dis pas comment !
SetElements ( OBJHANDLE hRef, const ELEMENTS & el, ORBITPARAM * prm = 0, double mjd_ref = 0, int frame =FRAME_ECL )
Est-ce que Orbiter fait ses calculs à partir des membres de cette structure ?
Qu'est ce qui expliquerait l'absence de fonctions SET..() alors ? Martin n'a pas voulu que l'on puisse forcer la position du
vaisseau en ignorant les calculs ? Si c'est le cas , t'es un vrai filou d'avoir réussi à lui faire avaler quand même !
Je vais jeter un coup d'oeil à GetElement(...) , j'l'avais vite survolée .
Merci pour les détails qui sont trés instructifs !
A+
Message modifié ( 11-08-2010 12:32 )
-
Par comparaison ? Et si par malheur il ne pointait pas... ouais bof, ya pas d'raison !
Ben çà m'a l'air d'être " carré " !
Non, ça on peut l'écrire (Set je ne plus quoi...).
Est-ce que Orbiter fait ses calculs à partir des membres de cette structure ?
Qu'est ce qui expliquerait l'absence de fonctions SET..() alors ? Martin n'a pas voulu que l'on puisse forcer la position du
vaisseau en ignorant les calculs ? Si c'est le cas , t'es un vrai filou d'avoir réussi à lui faire avaler quand même !
Je vais jeter un coup d'oeil à GetElement(...) , j'l'avais vite survolée .
Merci pour les détails qui sont trés instructifs !
Ben les calculs, c'est l'Orbiter du serveur qui les fait...
Yves
-
moi je viens d'avoir une idée, pourquoi avoir besoin d'échanger des données concernant la position ?
il suffirait de creer le vaisseau au bon endroit avec la bonne oriantation avant le départ, puis seul les données concernant les RCS, la propulsion et le panneau 2D-3D ont besoin d'être échanger, ce sont les orbiter de chacun des utillisateur qui calcule les trajectoire, l'orientation et les animation
:???:
exemple un utilisateur demarre un scenario avec le DG-IV, il invite un autre joueur avec lui
ensuite la mission commence, et la :hot: un des joueurs appuit sur la touche K de son clavier ce qui a pour
effet d'ouvrir le cone de nez, puis, après avors traversé un labyrinthe de code, ça appuis sur K chez l'autre joueur, a la fin, on obtient le même effet chez les deux joueurs !!!
si j'ai fait une boullette dites le moi :doubt:
-
Edit :
En ce qui concerne la position ta méthode ne permet pas d'assurer la cohérence de position et d'attitude, voilà pourquoi le serveur la transmet aussi souvent que posible (supérieur au framerate). La transmission des vecteur forces n'est là que pour pallier un éventuel défaut de transmission...
Pour les actions, les clients les envoie au serveur qui les retrace à son tour aux autres clients. J'entends par action les sorties de train, les cones, les portes, mais aussi toutes les commandes de vol et de poussée.
Yves
Message modifié ( 11-08-2010 18:32 )
-
Bon, voilà où j'en suis maintenant :
En ce qui concerne l'émission des données, je suis presque arrivé au bout. J'ai toutes les données nécessaire pour définir la position et l'orientation du vaisseau dans l'espace, par rapport à un corps de référence (qui peut-être le Soleil lui-même, je vous le rappelle). C'est données sont celles transmises en temps réel aussi souvent que possible. Les clients connectés à l'hôte les reçoivent, les traitent (pour les remettre dans leur format initial) et actualisent la position et l'orientation de leur propre vaisseau en fonction des données reçues. La synchro est donc respectée.
En fait, avec les éléments orbitaux essentiels, je n'ai besoin de rien d'autre, le vecteur vitesse étant défini par les caractéristiques de l'orbite à l'instant T (vous vous souvenez ? à chaque orbite correspond une vitesse dans une direction donnée).
Gros morceau de fait ! avant de m'attaquer à la partie client, je vais produire les message initiaux de connexion nécessaires aux clients qui se connectent (du style : places disponible à bord, type de vaisseau utilisé....ce qui définit une situation de départ quoi). Ces messages d'initialisation permettront à un client de se connecter n'importe quand au cours d'une session déjà ouverte, sous réserve qu'il reste des places disponibles à bord...
Quand cette partie sera faite, on aura fait exactement la moitié du chemin pour arriver à la réalisation finale.
@tofitouf : je n'oublie pas ton fichier de config. Les paramètres à rentrer seront les caractéristique de l'orbite tels que décrit dans le SDK + le mjd, le nom du joueur et sa fonction à bord. Enfin tu devra ajouter le mode (hôte ou invité).
@tous : je suis arrivé jusque là aussi grâce à vous, à vos remarques et à vos idées, merci pour cela...et continuez de poster sur ce fil, ça m'encourage à continuer. Quand je galère, ça fait du bien....
Yves
-
(qui peut-être le Soleil lui-même, je vous le rappelle).
Tu pensais à qui quand tu écrivais çà ? :wonder: :)
La période de béta-test arrive bientôt ?
Tu pourrais envoyer des faire-part ?
Cela pourrait coincider peut-être avec la refonte d'Orbiter challenge ?
C'est super cette évolution ! Bravo pour ton " terrassement " et les fondations .
Plus qu'à poser les murs ... vu que l'évacuation est faite et les passages de cables réservés .
A+
-
'jour ! ;)
Pilote334 m'ayant fait l'honneur d'essayer son TeamServeur en tant que testeur bêta ( :fou: ) , je viens faire ici mon
rapport . Autant le dire tout de suite , j'ai cherché la faute ! :)
( je suis allé jusqu'à voir si en fermant orbiter, il ne restait pas un petit processus qui traine ... mais non !)
Oui , mais il n'y en a pas !
Test sous Orbiter 2010 .
Alors , la procédure d'installation est classique , déposer les fichiers contenus dans le dossier Module du release ,
dans le dossier Module d'Orbiter . Le module serveur étant au chaud dans son propre dossier TEAMSERVEUR , à la racine
d'Orbiter. --> 100 % Done !
Charger le module TeamServer dans le LaunchPad : ---> 100 % Done !
Je lance un scénario , ctrl+f4 , ModuledeCopilotage apparait dans la liste .
Je tape mon pseudo , j'entre serveur à la place de l'IP , j'ai alors le choix entre 4 postes .
Je choisis COmmandant ...:)
Je clique sur Connecter et .. ben je suis connecté ! --->100 % Done !
Dans le MFD , une nouvelle Option Team MFD .
Je clique dessus , j'obtiens une page d'information concernant l'Etat de la session : ( Connecté ou pas , pseudo ).
Le MFD propose des options via des boutons qui ne sont pas encore programmés , mais qui seront trés utiles par la suite .
Par exemple , la possibilité de se connecter, déconnecter , créer une session ou la rejoindre , sans passer par ctrl+F4 ?
De ce coté là , je dirais --> 50 % Done .
La ligne d'information des données de position gêne l'accés aux boutons du bas du MFD , mais ceci est accessoire puisque vraisemblablement elle n'apparaitra pas dans la version finale .
UN POINT CRITIQUE :
J'avais dans ma liste de modules , un module à moi qui consiste , comme pour TEAMSERVEUR , à rajouter un bouton
sur le MFD d'origine . J'ai du enlever mon module pour que celui de TeamServeur apparaisse !
Ceci est une problématique que tous les créateurs de MFD doivent connaitre .
Peut-être qu'un MFD dédié serait préférable pour pallier à ce problème ?
La question est valable pour mes propres productions .
En résumé :
Interface Intuitive , en cours de finalisation , qui est dés à présent bien prometteuse !!
Reste à tester le programme entre différents Pc sur le Net , c'est une autre histoire que je vous raconterais plus tard !
Bravo donc Pilote334 , pour cette belle avancée dans la conquête du Mode Multijoueur !
:applause:
Message modifié ( 12-08-2010 12:34 )
-
Et bien, que de bonnes nouvelles !!! :hot:
Ça va être super de pouvoir faire des petites courses entre amis autour de KSC ! ;) avec les anneaux de CSLevine, on aurait un parcours à la redbull air race ! ;)
MrSpock a écrit:
Reste à tester le programme entre différents Pc sur le Net , c'est une autre histoire que je vous raconterais plus tard !
Bravo donc Pilote334 , pour cette belle avancée dans la conquête du Mode Multijoueur !
:applause:
Ça pue le NAT ça, non ?
Dans l avenir pilote334, comment comptes-tu régler ce "souci" ? Ça m'intéresse !! :)
-
Bonjour Jim,
Alors oui, NAT il y aura. Un port (et un seul) à ouvrir sur la box et dans vos firewall. Ce sera le 13000. C'est tout mais c'est la seule contrainte de façon à avoir une connexion rapide....
D'autres jeux réclame ces ouvertures de port, rien de compliqué, en fait...
Le résultat vaut, je crois, cette toute petite contrainte....
Yves
-
Ça l'avance super bien ! :applause:
Ça va marcher fonctionner sur Orbiter 2006 ? Je tourne toujours avec lui.
-
J'ai pas fait les tests su O2006, mais a priori, ça devrait marcher (sous toute réserve...). Mais tu va pouvoir bientôt passer à O2010 tant les add-ons sont de plus en plus mis à jour pour cette version...
-
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.
-
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à....
-
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 )
-
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
-
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....
-
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 :)
-
je suis plutot long a la detente :)
Et moi , je suis Clint Eastwood !! :diable:
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 )
-
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
-
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 ...
// ======================================================================
// 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 )
-
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
-
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 )
-
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 !
;)
-
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...
-
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 ?) .
"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 ...
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 )
-
ouais, va falloir que je regarde tout ça...
-
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
-
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 !
;)
-
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
-
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 .... :badsmile:
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 ...
;)
-
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
-
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
-
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 .
;)
-
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 ?
;)
-
Le moment venu, ce sera fait ....
-
Bien ... ce fil !
;)
-
Bon, pour ceux qui prennent ce fil en cours et qui n'ont pas envie de lire tout ce qui précède, voici un résumé des évènements :
Devant une demande croissante sur plusieurs forums d'un mode multijoueur pour Orbiter, je tente l'aventure en étudiant la faisabilité d'un module.
Très vite, je me rends compte qu'un module multi-joueur sur Orbiter est inutile à cause des distances énormes et l'utilisation de l'accélération temporelle. Je me rabats donc sur un module co-pilotage qui a l'avantage de s'affranchir du problème distance, puisque tout le monde est dans le même vaisseau.
Mon premier objectif est de créer un module simple intégré à Orbiter. Partant d'un MFD au départ, je m'aperçois vite que celui-ci n'est rafraichi qu'en fonction d'un paramétrage dans le launchpad. Je cherche donc une autre solution.
Je tente de l'intégrer comme un module général (comme scenario editor par exemple), ça marche. Il me faut m'attaquer aux protocoles réseau. Après quelques déboires (notamment pour la partie serveur), j'arrive à me dépatouiller du protocole bi-directionnel (client/serveur) et je m'attaque aux données d'Orbiter.
Soucis là encore. On peut récupérer les données de position en lecture, mais on ne peut pas les écrire. Toutefois dans le SDK, je trouve deux fonctions qui me permettent de le faire. Les essais de connexions sur deux PC distant commencent parallelement. Et jusque là, les performances se montrent à la hauteur de mes attentes. En même temps, des essais partiels de compatibilité entre les deux versions d'Orbiter sont faits, là aussi avec succès.
J'en suis donc au stade où je dois traiter les différents type de message envoyés par la partie serveur du module, mais aussi par la partie client (notamment la demande de raccordement à la session).
Voilà pour ce petit résumé des faits...
Yves
-
petit reaction apres mon premier post, qui n'etait a avis critique, cela n'enleve rien a votre performance, personne sur ce forum, ou presque, arrive a comprendre ce fil ^^
pilote334 a écrit:
Très vite, je me rends compte qu'un module multi-joueur sur Orbiter est inutile à cause des distances énormes et l'utilisation de l'accélération temporelle. Je me rabats donc sur un module co-pilotage qui a l'avantage de s'affranchir du problème distance, puisque tout le monde est dans le même vaisseau.
Et bien justement, pour moi , cela va a l'inverse du multijoueur "pure", ca ressemblerai plus a un mode cooperatif selon mon avis.
et de plus, je confirme qu'un "vrai" mode mlultijoueur serai utile, il y a deja eu des tentatives, ( ya des fils sur le forum, que je retrouve plus) ou cerrtain s'amusai a docker 2 DG ensemble, , c'etait super ^^
enfin bon, ce que vous faites est tres bien, mais je dirai que le terme choisi n'est pas le bon ^^ je verai ca plus comme un mode coop que multi (dans le sens ou ont est tous dans 1 vaisseaux, et pas 1 personne / 1 vaisseaux )
bonne continuation sinon ^^
-
Oui, Yoan, tu as raison. Je ne dis pas que je n'irai pas vers un vrai multi-joueur, mais pour le moment, je dirais que ce n'est pas à l'ordre du jour. Après, si j'arrive au bout de ce projet-ci, il me sera plus facile d'envisager le vrai multijoueur avec des restriction, bien entendu, concernant la visibilité d'un vaisseau d'un autre...
Espérant avoir répondu à ta question...
-
Perso, j'ai toujours préféré le multijoueur en coopération. Un peu à la Splinter Cell ou à la Batalion Wars 2 où on s'entraîde pour passer un niveau.
Un autre petit remontant pour vous encourager :drink: :badsmile:
-
Il sera vite commandant c'lui là !!
:)
-
Mort de rire !!!
Yves
-
enfin bon, ce que vous faites est tres bien, mais je dirai que le terme choisi n'est pas le bon ^^ je verai ca plus comme un mode coop que multi (dans le sens ou ont est tous dans 1 vaisseaux, et pas 1 personne / 1 vaisseaux )
Ben moi je rêve d'un truc genre :
BiBi uncle , Alexandre , CsLevine , Tofitouf , Pilote334 et moi , on vous prend tous à la course à bord de notre vaisseau " maison " ,
via OrbiterChallenge et TeamServeur ! Ok ?
:siffle:
-
Ah, ça me plait bien ça, style Terre-Jupiter le plus rapidement possible en DGIV-2 ! avec le sling-shot autour de Jupiter en plus ! Yeah....et à 4 par vaisseau ! stratégie...stratégie....
Yves
-
moi ce qui me tenterai le plus c'est une mission apollo a trois avec timspeak pour communiquer ensemble ;)
Message modifié ( 14-08-2010 20:54 )
-
moi ce qui me tenterai le plus c'est une mission apollo a trois avec timspeak pour communiquer ensemble
Ben voilà ! ;)
Un scénario qui tombe du ciel !
:top:
-
on vous prend tous à la course à bord de notre vaisseau " maison " ,
çà me donne une idée , un mode " tous les coups sont permis " :
A chaque équipage de se créer le vaisseau le plus performant .
Les meilleurs seront ceux qui connaissent les bons addons ...
Cool non ?
-
MrSpock a écrit:
on vous prend tous à la course à bord de notre vaisseau " maison " ,
çà me donne une idée , un mode " tous les coups sont permis " :
A chaque équipage de se créer le vaisseau le plus performant .
Les meilleurs seront ceux qui connaissent les bons addons ...
Cool non ?
Z'avez tous plein d'idée ! Sa promets ! ;)
-
Quoi ? T'en as pas toi ?
:ptdr:
Ouf ! c'est bon de rire un peu ...
Message modifié ( 14-08-2010 21:14 )
-
eh bien moi je parie que je bas tout vos score avec le shuttle pb
il suffit de booster les moteurs dans son fichier de conf
-
TOFITOUF ! RHHHOOoô !
Traître !
Mille sabords !
Mon ingénieur à moi ?
SAPERLIPOPETTE !
Ils t'ont promis quoi ?
Je SAIS : Tu es à la solde de " Chaussures de sport and co " !
rhhhhoooô ... les bidouilles , garde les pour nous !
:diable:
-
Mille milliard de mille sabords ! il nous ont (encore) piqué Tournesol !!!
Message modifié ( 14-08-2010 21:50 )
-
Tof' ? on t'a trouvé un nouveau pseudo : Tryphon ....
:ptdr:
-
Bon, ça y est, j'ai commencé : je traite les premiers messages du client (sa demande de connexion au serveur, en l'occurrence).
Ce type de message commence par "DEMCON" suivi du nom du joueur. Le serveur lui renvoie les fonctions disponibles à bord....
Yves
-
Sa a l'air bientôt fini tout ca, quand Martin va voir ca...
-
Avec tous les idées que vous avez donné, j'ai trop hâte que ça sorte !!!
PS : On lance à Cape Canaveral pour notre voyage. C'est juste 2 heures en avion de chez nous :badsmile:
-
Du calme, on y est pas encore, et le obstacles sont encore nombreux...
Je suis sur les messages reçus/envoyés du client....
Yves
-
Salut Yves !
SetElements(...) client fonctionne ?
:wonder:
-
Pas testé encore mais j'ai mieux : "VESSEL::DefSetStateEx(const VESSELSTATUS * status) const"...
Je te donne le résultat dès que j'ai testé...
Yves
-
Pas testé encore mais j'ai mieux : "VESSEL::DefSetStateEx(const VESSELSTATUS * status) const"...
Je te donne le résultat dès que j'ai testé...
Chouette ! C'est déjà l'heure de l'apéro ?
:beer:
Je vais voir ce que c'est ta dernière trouvaille ..
A tout'
-
Au fait Spock,
Trois petites fonctions qui peuvent t'intéresser...
void GetDataBCST(void)
{
VESSEL *vessel=oapiGetFocusInterface();
spcft.Vessel = vessel;
spcft.Obj = vessel->GetHandle();
spcft.VName = vessel->GetName();
spcft.Gref = vessel->GetGravityRef();
char gref[255]={""};
oapiGetObjectName(spcft.Gref, spcft.BodyRef, 18 ) ;
vessel->GetGlobalOrientation(spcft.Orient);//SetGlobalOrientation existe donc ok
vectochar(spcft.Orient, spcft.Attitude);
vessel->GetElements(spcft.Gref, spcft.elem, spcft.prm = 0, mjd_ref, frame);
eltochar(spcft.elem, spcft.OrbitElem);
}
void vectochar(VECTOR3 vdata, char* datachar)
{
char datax[20]={""};
char datay[20]={""};
char dataz[20]={""};
sprintf(datax,"%f",vdata.x);
sprintf(datay,"%f",vdata.y);
sprintf(dataz,"%f",vdata.z);
strcpy(datachar,datax);
strcat(datachar," ");
strcat(datachar,datay);
strcat(datachar," ");
strcat(datachar,dataz);
strcat(datachar," ");
}
void eltochar(ELEMENTS& elem, char* datachar)
{
char sma[20]={""}, ecc[20]={""}, inc[20]={""};
char lan[20]={""}, omb[20]={""}, mle[20]={""};
sprintf(sma,"%f ",elem.a);sprintf(ecc,"%f ",elem.e);
sprintf(inc,"%f ",elem.i);sprintf(lan,"%f ",elem.theta);
sprintf(omb,"%f ",elem.omegab);sprintf(mle,"%f ",elem.L);
strcpy(datachar,sma);strcat(datachar,ecc);strcat(datachar,inc);
strcat(datachar,lan);strcat(datachar,omb);strcat(datachar,mle);
}
Bonne utilisation....
Yves
Message modifié ( 15-08-2010 19:49 )
-
C'est intéressant , puisque c'est une solution sortie de tes méninges .
Mais ( il y aura toujours un mais ... ;) ) Orbiter fournit des fonctions pour écrire directement dans un flux .
Que ce soit un fichier d'origine ou un stream , le résultat est le même .
Tes fonctions sont utiles dans certains cas :
Si j'avais besoin de convertir du numérique en Ascii , c'est clair que j'utiliserais tes fonctions .
Je les mets dans mon tiroir !
J'utilise moi :
OAPIFUNC void oapiWriteScenario_string ( FILEHANDLE scn,
char * item,
char * string
)
Writes a string-valued item to a scenario file.
pour ecrire dans mon stream ou file du texte .
Si j'ai besoin d'écrire des float , j'utilise oapiWriteScenario_float , c'est pratique puisque tu peux même
écrire le contenu d'un vecteur ! (void oapiWriteScenario_vec ) .
Aprés , tout dépend du genre de flux utilisé .
En tout cas , merci pour le partage !
Si je l'utilise , tu seras crédité! ( Tu vois , ce genre de plan , c'est ton futur SDK !)
:friend:
-
Ouais, ben, justement, il va falloir que tu m'explique comment je fais une dll pour exporter mes fonctions (style, les attributs, les particularités pour que quelqu'un d'autre puisse les utiliser...).
Yves
-
Le mieux , quand tu auras atteint le stade qui te satisfait , c'est de m'envoyer ton projet ( le mieux ç'aurait été à DAN ) ,
je regarderais son fonctionnement et serais à même de te donner un avis , même d'essayer de sortir une lib , pourquoi pas .Je te renverrais ensuite le projet avec les explications du " comment " , les commentaires , la lib ? et un embryon de pdf ?
Ce serait comme un exemple , tu pourrais le remanier à ta sauce aprés ... mijotage !
A voir ...
Là je me déguste du calamar à l'américaine ....
A+
-
Pour être franc, le c++, je découvre, et je n'utilise les classes que quand j'y suis obligé, ne sachant pas bien les manipuler. Donc je travaille beaucoup avec les fonctions, et si possible celles que je crée, car je les comprends et je sais pourquoi je les crée. Je t'ai dit: je suis un bidouilleur, débrouillard, certes, mais un bidouilleur quand même...
Yves
-
Un petit avant goût :
Tu m'as fait l'honneur de me montrer le contenu de ton code .
La manière de résoudre un problème , c'est précieux .
Tu as passé du temps à créer ces fonctions , et d'un simple copier/coller quelqu'un serait à même de l'utiliser ,
et pourrait se vanter en suite : REGARDEZ CE QUE MOI SEUL J'AI FAIT !
Injuste ... A part si tu décides d'offrir ce code au domaine public .
Pour éviter cette injustice , tu devras fournir les déclarations de tes fonctions dans un fichier .h , tout en cachant
ce qu'elles font ( le contenu que tu m'as envoyé ) en le compilant dans un fichier .lib qui contient ces définitions .
Quand un utilisateur mettra un :
#include "TeamServeur.h" dans son propre code , et qu'il voudra utiliser :
void vectochar(VECTOR3 vdata, char* datachar)il recevra un message d'erreur du compilateur qui lui dira qu'il manque la définition de cette fonction pour qu"elle
soit éxecutée .
Il faudra donc qu'il rajoute dans ses options de projet :
TeamServeur.libà coté des autres libs , dont Orbiter . La classe non ?
J'étais content , moi , de trouver sur SourceForge les .cpp me permettant de comprendre ce qui est caché dans les libs
d'Orbiter !
Si ton projet est de l'ordre de l'éducatif , mieux vaut laisser visible les .cpp , au risque toutefois qu'ils soient modifiés !
Pour finir , si tu veux faire de l'éducatif ET protéger ton code, tu suis l'exemple de Mr Martin S ...
A+
-
Pour être franc, le c++, je découvre, et je n'utilise les classes que quand j'y suis obligé, ne sachant pas bien les manipuler. Donc je travaille beaucoup avec les fonctions, et si possible celles que je crée, car je les comprends et je sais pourquoi je les crée. Je t'ai dit: je suis un bidouilleur, débrouillard, certes, mais un bidouilleur quand même...
Il n'y a pas de souci .
Ta démarche est logique , je la comprends trés bien .
Les classes en c++ ont de trés gros avantages , faire de petits exercices à coté de ton gros projet pourrait le servir ,
même avant la fin de celui-ci . Tu as plein de tutos sur le Net, je suppose , qui te permettraient de t'amuser .
Programmer doit rester amusant , donc dés fois , laisse reposer le plat , et fais de petites expériences à coté .
Attends , je ne parle pas de demoiselles , hein ? :)
Non , juste de petits exercices , fun pour toi .
A+ , amuse toi bien !
( de mon coté, bibi uncle est entrain de m'apprendre à utiliser et créer des .bat ... )
-
Pas testé encore mais j'ai mieux : "VESSEL::DefSetStateEx(const VESSELSTATUS * status) const"...
Si j'ai bien compris , tu préfères utiliser VESSELSTATUS2 que VESSELSTATUS .
Quand on sait l'évolution que cela représente , on dit : Trés bon choix !
Puisque maintenant tu devrais disposer en plus de la position, rotation etc les informations de fuel , docking et thruster .
SUPER INFO !
T'étais déjà une belle débroussailleuse , tu deviens un BULLDOZER !
:top:
-
Quand je lis ce qui précède, je me rends compte que j'ai encore bcp de choses à apprendre... :damn:
Quand je serai à la retraite (dans 11 ans) je ne m'ennuierai pas :)
-
Quand je serai à la retraite (dans 11 ans) je ne m'ennuierai pas
Ouaip !
Mais d'ici là , tout ce que tu comprends est à toi !
Prépare toi une bonne retraite !
Ah ouais , il ya une chanson des rolling stones , qui fait comme çà :
" Ti_ i _i_ ime , is on my__ si_i_de " !! :diable:
:beer:
-
Les classes en c++ ont de trés gros avantages , faire de petits exercices à coté de ton gros projet pourrait le servir ,
même avant la fin de celui-ci .
C'est juste que je manque un peu se temps pour ça, donc, je vais au plus simple, pour le moment. D'un autre côté, m'attaquer à ce projet m'a permis d'apprendre déjà énormément...
Yves
-
JellyFish F-SPK , " je manque un peu de temps pour ça ", copié !
( faudra que je révise ma phraséo ,moi ...)
:badsmile:
Message modifié ( 16-08-2010 18:55 )
-
Moi non plus je n'ai pas encore saisie la notion des classes pour une raison toute simple, je n'ai jamais programmée C++ autre chose qu'une DLL pour Orbiter. Et là, une seule classe est nécessaire. Avant, j'ai appris le C et c'est avec le C que j'ai le plus programmé.
Le C, c'est très puissant aussi, mais ce n'est pas destiné au même chose que le C++.
-
Ok ... t'as qu'à remonter le fil :
Mes questions sur vc++2005 , non ?
:siffle:
-
Mon post était en réponse à :
Pour être franc, le c++, je découvre, et je n'utilise les classes que quand j'y suis obligé, ne sachant pas bien les manipuler. Donc je travaille beaucoup avec les fonctions, et si possible celles que je crée, car je les comprends et je sais pourquoi je les crée. Je t'ai dit: je suis un bidouilleur, débrouillard, certes, mais un bidouilleur quand même...
-
C, C++ c'est vraiment la même chose,
Le C++ c'est juste une manière d'organiser différemment ton code en regroupant données et fonctions, et c'est tout.
ca a un coté pratique pour s'y retrouver quand ton projet commence à prendre de l'ampleur. mais pour les ptits projets tout simple c'est inutile
-
Il n'y a pas de problème , l'oncle .
Je l'aimais bien ton fil moi !
;)
-
MrSpock a écrit:
Il n'y a pas de problème , l'oncle.
Je l'aimais bien ton fil moi !
;)
:lol: L'oncle. Pas Oncle Sam quand même.
Moi aussi je l'aimais bien mais pour l'instant, je n'ai pas de questions. Quand j'en aurai, je le ressortirai. ;)
-
T'inquiete pas, t'y arrivera a t'en sortir avec succes en c++
bas oui, Uncle Ben's, c'est toujours un succès! :badsmile:
oui oui, pas tapper (http://i35.servimg.com/u/f35/12/05/36/23/chair10.gif) ,si vous me chercher je suis deja dehors...
-
:ptdr: :ptdr: :ptdr:
mmmmwwwaaaah
-
http://www.youtube.com/watch?v=n9LXc874aOg&feature=related
Une publicité qui passe trop souvent à la télé (ceci est la version anglophone mais il y a une version en français. Je ne l'ai pas trouvé sur YouTube).
-
Ready before you are !
Exellent !!
Faudra quand même le vérifier sur OrbiterChallenge , hein ??
:ptdr: :ptdr: :ptdr:
-
Bon, des nouvelles :
1°) La partie client avance bien. J'explique : le client fait une demande de connexion à l'hôte qui répond en lui envoyant les fonctions disponibles à bord, l'utilisateur client choisit l'une des fonctions disponibles et l'info et renvoyée au serveur.
2°) Le MFD est opérationnel, toute la procédure de connexion/déconnexion peut se faire à partir de celui-ci.
Voilà, ça avance...
Yves
-
2°) Le MFD est opérationnel, toute la procédure de connexion/déconnexion peut se faire à partir de celui-ci.
:applause: :applause: :applause:
Salut Pilote !
Ben je commençais à m'inquiéter ? J'imaginais un crack boursier sur ta banque Virtuelle ... :wonder:
çà me casse les bourses !!
Félicitation !
:beer:
Message modifié ( 18-08-2010 21:04 )
-
sa a l'air bientot près tout sa :diable:
-
Oh Un ami !
:diable:
-
Tiens, au fait, une idée m'est venue tout à coup :
Le problème d'un multijoueur (et je ne parle pas de copilotage) c'est le temps et l'accélération, n'est-ce pas ?
Ceci pourrait être résolu avec RWARP MFD qui nous balade à plus de 5 fois la vitesse de la lumière, je crois...
Bon, ok, adieu le réalisme mais cela nous affranchit de l'accélération temporelle...pas si mal non ?
Qu'est-ce que vous en pensez ? dois-je intégrer quelque chose à mon module pour réaliser cela ?
Yves
-
vraiment excellent les progrès rapide de ce module, j'ai super hâte de voir ca.
pour l'accélération temporaire, moi je trouve que ce n'est pas un vrai problème et sans se servir des Wrap MFD.
imaginons une partie à plusieurs (coopératif ou non)
un premier joueur demande une accélération.
Il ne se passe rien mais chacun des autres joueurs est notifié sur son écran.
quand les autres joueurs passent tous en accélération temporaire alors celle ci est exécutée chez chacun en même temps (prendre les MJD comme temps de référence pour le commencement de cette accélération)
enfin pour remettre au temps normal, même méthode. ca marche pour toute modification.
autre solution : dès que y'a un joueur qui passe en accélération alors tout le monde y passe. ce mode est ad-hoc uniquement pour les parties coopérative, on est alors dans le même vaisseau et c'est pas génant. si on est dans des vaisseaux différent il faut vraiment attendre que les autres joueurs soient prets.
donc finalement je n'ai jamais trouvé que c'était vraiment un problème. le tout est qu'il faut la démarrer exactement au même temps de simulation (MJD de référence) et donc il faut transmettre dans la communication un temps de démarrage dans le futur proche (genre une seconde après que le dernier joueur ai appuyé sur accélération)
j'imagine pilote334 que tu as vu comment recevoir els commande d'accélération et comment les bloquer.
-
Oui, ça, pas de soucis. L'idée pour le module coopératif est déjà prévu en terme d'accéleration temporelle. Le problème se posait plus sur le mode multijoueurs (plusieurs vaisseau). Mais ta solution est possible, mais n'est pas souhaitable car pénalisant les autres joueurs (j'ose pas imaginer les temps d'attente lorsqu'un des joueurs est train de calculer une trajectoire aux petits oignons...). Warp MFD contourne le problème, puisqu'il accélère le vaisseau, mais ne touche pas au temps devenu constant (irréaliste vu que seule la vitesse de la lumière est invariante, mais bon...la fin justifie parfois les moyens...) pour tous les joueurs, mais également pour tout le système dans lequel on se trouve (position des planètes).
C'est donc, il me semble, la meilleure solution....mais il peut y en avoir d'autres, j'attends vos réactions, elles vont conditionner une partie de mon travail présent et futur...
Yves
-
la solution de tofitouf est bien pour le lancement mais le soucis serai plutôt lors du retour au temps normal.
1. pas tout les joueur auront besoin de la même durée en accélération temporelle. Ex : Le joueur 1 fais terre-lune donc une longue période en accélération puis retour à la normal pour faire une correction puis re accélération. en même temps le joueur 2 lui fais un rdv avec iss et veux accélérer jusqu'à la révolution de rdv avec iss donc la la période en accélération sera plus courte. Et on reviens au soucis de pénaliser certain joueur comme le dis Pilote.
2. Le soucis au point 1. n'est pas très grave je vous l'accorde. par contre pour sortir de l'accélération sa vas créer des décalages de temps forcément. Je m'explique. Si on reprend l'exemple d'avant, le joueur 2 sors de l'accélération car il arrive près du point de croisement entre son orbite et celle d'iss. Les réseaux sont rapide je vous l'accorde mais pas instantané.... Donc le temps que l'info circule entre le serveurs et les différent clients, personne ne sortira de l'accélération au même moment d'ou les décalages temporel... et faire une demande comme pour le lancement de l'accélération est un truc a finir avec 3 orbites de trop pour notre pauvre joueur 2 lol
a mon avis s'est un vrai soucis si on veux garder une cohérence temporel entre les différents client...
et le même décalage aura lieu lors de la mise en route de l'accélération le temps que l'info circule
Pour moi se module est surtout intéressant pour être tous dans le même vaisseaux réalisant tous en ensemble une même mission. Le multi avec chacun son engin la par contre j'y crois pas trop et on perd le coté réaliste dans 95% des cas (les 5% restant pourrai être des mission style arrimage soyous-apollo, iss-autre engin(en supposant que des joueur sont a bord de l'iss), ou une missions apollo qui se pose sur la lune,... enfin se genre de mission)
Pour les missions à plusieurs avec le même objectif(pas chacun se promène dans son coin), se module ouvre de belles perspectives je trouve.
Message modifié ( 19-08-2010 13:46 )
-
Apofis, je suis partiellement d'accord avec toi. Comme écrit plus haut dans ce fil, il suffirait de définir une sphère de visibilité pour contourner au moins une partie du problème. Mais, oui, le problème de l'arrivée à la suite d'une accélération temporelle individuelle est insoluble, donc : le multijoueur (je ne l'appellerai plus comme ça d'ailleurs, mais le multivaisseaux coopératif) n'est intéressant qu'avec des vaisseaux proches, voire, très proches les uns des autres. Sans ça, disons-le clairement, bof !!!
Là où c'est beaucoup plus intéressant, c'est en cas d'EVA. Un UMMU, c'est un vaisseau à la base ! Donc là, ça se justifierait pleinement. Même réponse, bien sûr en cas d'amarrage entre deux vaisseaux tenus par deux équipages différents !
Là aussi, quels sont vos réactions par rapport à ça ?
Yves
-
Salut les génies !
Oullala ... vous êtes bien affutés aujourd'hui !
Je pense que je vais relire 2 ou 3 fois , histoire de ne rien rater .
Je ne vais donc pas mettre les pieds dans le plat , je rappellerai juste qu'un de ces jours sortira OrbiterChallenge ,
qui permettra je l'espère de mélanger COOP ( tous dans la même galère ) et MULTI ( tous dans le même Univers , mais chacun en son temps ) . Donc , pour l'instant , l' accélération temporelle ou la gestion de mfd spécialisés pourraient être cantonnés au Mode COOP . Je pense qu'avec l'expérience de ce Mode , d'autres idées verront le jour .
Là où c'est beaucoup plus intéressant, c'est en cas d'EVA. Un UMMU, c'est un vaisseau à la base ! Donc là, ça se justifierait pleinement. Même réponse, bien sûr en cas d'amarrage entre deux vaisseaux tenus par deux équipages différents !
Ben moi j'avais imaginé qu'une partie de l'équipage pourrait tenir le rôle de scaphandrier , dans le but d'éxécuter des actions spécifiques ( qui restent à déterminer ) . En mode coop .
Selon moi , le MULTIPLAYER est la seconde marche du projet ( bien que ce soit ton intention première ..) .
Je pense qu'il y a une recherche à faire au niveau des vaisseaux de type COOP .
En plus des vaisseaux conventionnels , nous pourrions imaginer des choses inédites , réalisées par d'autres membres de la communauté , s'ils étaient (intériorisés EDIT : Ooops ...erreur du CORRECTEUR)intéressés . C'est encore une fois les PANELS2D por commencer ...
C'est super la tournure que cela prend !
:top:
Message modifié ( 19-08-2010 18:21 )
-
Je fais une simple statistique qui me motive : le fil a été vu 1871 fois et il y a 462 réponses, c'est suffisant pour moi pour continuer ce travail...
Yves
-
:music:
"Go ! Go Johnny go , go ! " . C'était qui déjà ?
-
Eh spock, regarde tes mails plutôt que de faire de l'esprit ! :ptdr: :ptdr: :ptdr:
Yves
-
Beuh ... Touché ... coulé !
:ptdr: :ptdr: :ptdr:
-
Bon ... J'ai bien rigolé ... faudrait bosser un peu !
Donc , la version TeamServer 0.0.1c vient de sortir du four :
J'ai une bonne , et une mauvaise nouvelle ...
J'commence par quoi ?
J'attends une demi-heure et puis j'envoie .
Générique !
J'ai toujours révé d'être Thierry Ardisson ... Les joies du Direct !
-
vas-y, dis nous...
-
Ah ... Un public ....
Tiens , vous là , le monsieur , dans le public .
Oui vous ! Comment vous appellez -vous ?
_ YVES ! .
Super ! Vous savez-quoi Yves ?
Eh YVES, regarde tes mails plutôt que de faire de l'esprit ! Mmwah ah ah ah ...
Hum ... cà fait déjà une demi-Heure ?
:wonder:
AAAAH non !
Faut remplir la salle !
La prochaine fois , j'invite une vedette ( DAN , tu m'as pardonné hein ? :ptdr: ) , j'suis sûr de vendre tous les billets ...
Bon , une page de pub et c'est parti !
Message modifié ( 19-08-2010 23:47 )
-
j'ai lu mes mails et répondu !!! pas touché, et donc pas coulé, juste plouf! à l'eau !
-
Ok ,j'y vais ... j'ai dix minutes à ... tuer !
:music:
Là , il faudrait un comique pour chauffer la salle !
Je reviens ... PUBLICITE !
Pour avoir la foforme , visite notre forum !
-
Bonsoir et Bienvenue !
Orbiter Mag , l'Emission , est fière de vous retrouver en ligne !
Les enfants sont couchés ? On peut y aller !
Au sommaire de cette Emission , le module TeamServeur de Pilote334 , membre de ce forum des créateurs francophones
D'Orbiter , sous le patronat de DANSTEPH , généralissime inventeur de Modules .
Nous aurons peut-être la joie d'avoir la visite de nos modérateurs ( accompagnés par les flics en ce qui me concerne ,
tapage Nocturne ... :badsmile:
Donc , voici la nouvelle version de TeamServeur , testée sous Orbiter 2006 et 2010 .
J'avais une mauvaise nouvelle , je commence par là .
Déballage du paquet TeamServeur :
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-2-1.jpg)
D'abord , lancement du serveur :
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-1-1.jpg)
Jusque là , tout va bien , même s'il faut encore lancer le serveur à la main .
Un petit " shellexecute(bla bla...) permettrait peut-être d'automatiser le serveur .
Bref , je lance Orbiter 2006 , j'ouvre la page de modules ...
TeamServeur apparait bien dans la liste , je l'ajoute et ... Badaboum ! ( Tsouin tsouin )
Boite d'erreur :
Titre : Orbiter Launchpad:Orbiter.exe-Point d'entrée introuvable .
Message : Le point d'entrée de procédure ?oapiRegisterMFDMode@@YAHAAUMFDMODESPECEX@@@Z est introuvable dans la bibliothèque de liaisons dynamique Orbiter.exe
Etant juste Vulcanologue ( normal pour un vulcain :diable: ) , je ne saurais trop dire les raisons de cette erreur .
A première vue , une fonction du MFD SDK2010 qui serait incompatible avec 2006 ? Je n'ai pas insisté , étant trop
impatient d'essayer sur la Version 2010 , qui est quand même , SIGNALONS LE , la version stable de TeamServeur
depuis le début du processus . AH , j'entends déjà bibi pleurer à chaudes larmes , mais rassure toi ,nous ne te laisserons pas tomber !
Ainsi s'achève la première partie de notre émission , et nous enchainons tout de suite aprés la pub !
PUBLICITE :
TeamServeur , volez en équipe , vous n'aurez plus peur !
Message modifié ( 20-08-2010 00:53 )
-
Le serveur n'est là que pour les tests, le vrai serveur et déjà intégré au module...
-
Le serveur n'est là que pour les tests, le vrai serveur et déjà intégré au module...
( reprenant le micro ..)
:)
Eh bien , c'est noté cher Pilote334 !
Passons maintenant aux bonnes nouvelles !
;)
Vous allez voir qu'avec Orbiter 2010 , c'est bien différent , çà glisse !
Quelques images ...
Le chargement avec les autres modules : OK
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-0.jpg)
Je pense que le coeur de Pilote334 peut dés à présent se rasséréner !
Image suivante : Le MFD ouvert sur la page principale , avant démarrage .
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-3.jpg)
Un détail : Un ctrlF4 ouvre un panneau de configuration
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-7.jpg)
Mais ce n'est pas ce qui nous interresse dans ce TEamserveur 0.1c
La nouveauté , c'est la connection via le MFD .
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-4.jpg)
Le bouton IP ouvre une boite de dialogue d'adresse Ip tandis que le bouton "nom" ...
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-8.jpg)
Ah ! Un nouveau spectateur dans la salle ? Assieds toi bibi ... ;)
J'en étais où ? Ah oui ...
Donc , on entre l'ip , le nom , on appuye sur CON ( pas trop fort ...)
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-9.jpg)
Et on est connectés !
Remarquez les boutons apparus lors de la connection :
Ils représentent la fonction que vous désirez tenir à bord !
Vous me connaissez un peu , j'ai appuyé partout ...
Un screen des messages du Serveur pour démontrer le tout :
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-10.jpg)
Voilà , je n'ai pas testé le module sur mon réseau local , je le ferais certainement bientôt .
Cette émission s'achève , je rends le micro et vous dit :
BAnZAIIIIIII !!
Bravo à Pilote334 pour son acharnement et les progrès notoires de son module !
:applause: :applause: :applause:
Message modifié ( 20-08-2010 00:42 )
-
MrSpock a écrit:
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-0.jpg)
Windows Classic... :love: Toi aussi t'es toujours sur XP ?
AH , j'entends déjà bibi pleurer à chaudes larmes , mais rassure toi ,nous ne te lausserons pas tomber !
:cry: Mon pauvre Orbiter 2006... Pourquoi ces foutus MFDs ne fonctionnent pas dans 2010 :grrr:
Ça avance toujours très bien. Continuez les gars ! :friend:
Message modifié ( 20-08-2010 00:29 )
-
vi moi aussi, XP Pro !
-
A propos du screen du serveur de test :
On voit ici deux type de message envoyés par le client, "DEMCON" et "FN" (1ier mot du message). DEMCON initie la connexion et FN donne la fonction choisie par le client au serveur.
Le message envoyé par le serveur de test est juste une reponse à DEMCON et donne au client la liste des fonctions disponibles à bord ( le nombre 7 signifie que les fonctions pilote, copilote et navigateur sont libres).
Voilà...
Yves
-
Pour Orbiter 2006, je crois avoir identifié le souci, y plus qu'à tester (Spoooooock !!!!! regarde tes mails !)...
-
Bon, un truc de plus qui n'est pas le module mais qui y est lié : le serveur teamspeak est actif. L'adresse est
spacemusic.selfip.org:8778
vous pouvez vous y connecter en "anonymous" sans mot de passe. Le nombre d'utilisateur est limité à 10. Vous pourrez ainsi tester votre configuration teamspeak.
Pour trouver le client teamspeak : www.teamspeak.com et lisez la doc !
Yves
-
Salut !
Vite fait :
La modif que vient de faire Pilote334 sur son code est magique !
J'ai juste chargé le module pour Orbiter 2006, il est passé .
BIBI UNCLE ? :beer:
+ de tests + tard ...
Bisoubeko !
:top:
Message modifié ( 20-08-2010 13:54 )
-
Ok ...
Je viens de lancer Teamserveur 1.0.1c avec Orbiter 2006 .
Toute la procédure fonctionne ( Saisie IP , Nom , connection ) .
Un hic : Les boutons de droite ( Pilote, Copilote,Nav) n'apparaissent pas .
J'imagine que c'est un détail ?
A+
EDITH : Pour trouver le client teamspeak : www.teamspeak.com et lisez la doc !
:merci:
Message modifié ( 20-08-2010 14:04 )
-
Oui, normal si t'as pas lancé le serveur de test, le client attend une réponse...qui n'arrive pas !
Yves
-
Euh ... le serveur était lancé , msieur !
Bon ok, j'y retourne ...
Message modifié ( 20-08-2010 14:13 )
-
PROBLEME RESOLU !
Ben ouais , c'était un bug du ... testeur .
J'avais donné comme nom : "Mr_spock" , il attendait "Mr_Spock" .
Autant pour moi ...
:siffle:
faudrait que tu songes à recruter des testeurs ... professionnels ? :badsmile:
-
Chapeau les gars, ca avance bien votre projet et c'est très agréable de voir votre progression dans le forum !
surtout avec l'humour du vulcain et sa présentation télévisuelle.
je suis au aguets en attendant la prochaine émission. Quelle belle aventure en direct
Message modifié ( 20-08-2010 14:30 )
-
OK ... Fais gaffe ... Tu pourrais être la prochaine VEDETTE !
:merci:
HS
EDITH : " Youpiie , je viens de recevoir tes cd sammy !! " .
/HS
Une autre vedette sur ma liste ...
Message modifié ( 20-08-2010 14:33 )
-
MrSpock wrote:
OK ... Fais gaffe ... Tu pourrais être la prochaine VEDETTE !
:merci:
HS
EDITH : " Youpiie , je viens de recevoir tes cd sammy !! " .
/HS
Une autre vedette sur ma liste ...
Yeessss !
va fallloir renommer le jeu en FireOrbiter, si ça continue à chauffer comme ça, tous ces développements !
euh question :
c'est quoi ce module MeshBuilder dans le launchpad (page précédente) ?
moi pas avoir trouvé de Meshbuilder. Elle est où cette déellèle ?
-
euh question :
c'est quoi ce module MeshBuilder dans le launchpad (page précédente) ?
moi pas avoir trouvé de Meshbuilder. Elle est où cette déellèle ?
RAaaah ... rien ne t'échappe ! :applause:
C'est bon , c'était le premier nom de MESHPOSER , by CSLevine and MrSpock ...
Et vice et Versa ...
Mais comme c'est en préparation , j'ai pas fait le changement de nom ...
Avec ta complicité Pilote334 ?
[ Mode " Les Inconnus " :]
http://video.google.com/videoplay?docid=-8440679445946376108#
Pour ceux qui cherchent du sens aprés çà :
ANACHORETE : Religieux qui se retire dans le désert pour se consacrer à la prière et à des exercices de pénitence.
DERELICTION : Sentiment d’abandon, de solitude.
T'inquiètes , comme dirait l'autre ... ( Simone de Beauvoir arrive en courant .... :ptdr: ) .
En plus , le nom peut encore changer ... rien n'est perdu mais tout est transformé .
[ Mode " Les Inconnus " :]
Mais ceci ne nous regarde pas !
BanzaiIiIiiii !
Message modifié ( 21-08-2010 02:48 )
-
Là, je t'ai perdu MrSpock. :???:
-
Salut bibi !
Comme le disait Tofitouf , ce projet est une aventure , " technologique " et " Humaine " .
Nous rencontrons parfois ( souvent ) des obstacles dans une aventure , ils sont parfois techniques , d'autres fois Humains. Pilote334 m'a demandé hier mon véritable prénom , car cela le gêne de m'appeler Spock .
Je lui ai répondu que Spock c'est moi ! Mon identité , c'est l'esprit qui est en moi , c'est un ami aussi .
Comme Pilote334 n'a pas répondu à mon dernier Email , j'ai voulu le dérider un peu , avec l'aide d'une tierce ( un trio)
personne . Celui qui a de nobles projets passe par dessus l'offense . :wonder:
" ... et tout deviendra clair ."
En attendant le retour de Pilote334 ,
;)
-
Je te rassure Spock, il n'y a aucun souci pour moi ! Ce sont tes choix, et je me retrouverais bien prétentieux de ne pas les respecter. Je continue mon projet, et j'espère que tu es d'accord pour continuer à être mon bêta-testeur ! ;)
Yves
-
YES YEs YES !
Mais t'es gonflé quand même !:badsmile:
Un " ami " répond quand on l'appelle ? Enfin quand il peut ...
Super , merci de respecter mon choix ! +1 .
C'est reparti mon kiki !
Go pour la version 1.0.1d !
( c'est vrai qu'il m'arrive d'être con ... :bebe: ) .
A+++ ... Spock ! :ptdr:
-
Un " ami " répond quand on l'appelle ? Enfin quand il peut ...
Oui, c'est vrai et j'en suis désolé, mais étant, moi aussi, musicien, j'étais en plein mastering pour deux titre qui vont sortir très bientôt (pour le 1/09/2010 pour être précis...).
Yves
-
Trop fort ... J' adore les surprises , surtout quand elles sont bonnes !
Euh , Pilote334 , tu as combien de bras ?
EDITH : Euh , pardon , cela ne se demande pas ...
mm.m..mmm.mw...
:ptdr: :ptdr: :ptdr:
-
Tu savais pas qu'on m'appelait "Krishna" ? :ptdr:
Yves
-
Krishna :
Pour les membres du vaishnava Chaitanya, il représente la divinité suprême à l'origine de toutes les autres, l'instructeur universel
Ah , je comprends mieux ... Excuse K , moi j'viens juste d'arriver !
:bebe:
+A+
-
[Mode JDG] Et on dit merci wikipédia ! =P
Sinon Bravo continue comme cela ! Sa à l'air génial comme projet ! Surtout pour être a plusieur dans le même vaisseau <3
Par contre il y aura possiblité de faire notre propre serveur ou bien tout ceci sera uniquement sur un serveur de ton choix ? En tout cas, très bon travail !
-
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...
Le bon client pour TeamSpeak est là : www.teamspeak.com/?page=downloads&archive=1 .
-
Pour Vergil :
Le serveur fait partie intégrante du module, donc chacun le possèdera, c'est juste une histoire de mode de fonctionnement. Soit tu es l'hôte de la session et ton module tourne en mode serveur, soit tu client d'une session et ton module tourne en mode client. En fait tout dépend de ce que tu rentres en adresse IP. Si tu mets une adresse valide (celle d'un hôte), il tourne en mode client. Si tu ymets le mot "serveur", c'est toi qui est l'hôte...
Au fait, d'après les derniers test réseau, il semblerait qu'il n'y aie pas besoin de configurer de port sur les box...à confirmer.
Yves
-
Et on dit merci wikipédia !
Merci wikipédia !
:top:
Mode Vergil :
Et on dit bonjour MrSpock !
15 A : Service ... MrVergil ! ( Tout rolland Garros retient son souffle ... un crétin : " ALLEZ ! ) "
Au fait, d'après les derniers test réseau, il semblerait qu'il n'y aie pas besoin de configurer de port sur les box...à confirmer.
Oh oh ....
Le bon client pour TeamSpeak est là :
Salut ! Tu vas bien ?
Ben moi je l'ai installé , pas eu le temps de le configurer ...
Bienvenue au club Vergil !
;)
Message modifié ( 22-08-2010 23:10 )
-
Des nouvelles, encore....
L'étape des essais sérieux commencent...
En effet, j'ai réinstallé Orbiter 2006 sur un autre ordinateur. Les essais se font maintenant systématiquement en réseau avec le vrai serveur et le vrai client, en alternant les rôles au fur et à mesure des tests pour s'assurer de la compatibilité de l'un vers l'autre.
Pour le moment :
TeamMFD est lancé en mode serveur sur une des machines, procédure que vous connaissez maintenant. Puis je connecte TeamMFD en mode client sur l'autre machine.
Résultats :
La demande de connexion se fait correctement et le serveur réponds avec les choix de postes disponibles puis le client choisi son poste à bord et le serveur affiche alors les positions occupées en fonction de ce nouveau client.
Voilà où j'en suis actuellement. Cette phase m'a demandé beaucoup de correction de bug, et de fausses manip de la part des utilisateurs...bientôt, la suite :
Enregistrement du client pour communication des données essentielles de broadcast. Puis, test de synchro de position et d'attitude entre le serveur et le client. Un bon programme....
Suite au prochain numéro...
Yves
-
L'étape des essais sérieux commence...
:clown: brrr ...
En effet, j'ai réinstallé Orbiter 2006 sur un autre ordinateur. Les essais se font maintenant systématiquement en réseau avec le vrai serveur et le vrai client, en alternant les rôles au fur et à mesure des tests pour s'assurer de la compatibilité de l'un vers l'autre.
:top: :top: :top:
Bravo ! Tiens , une question : Orbiter 2006 communique avec Orbiter 2010 via ton module sans problème ?
J'imagine que oui ...
Suite au prochain numéro...
:bave: :bave: :bave:
-
Orbiter 2006 communique avec Orbiter 2010 via ton module sans problème ?
Oui, tout à fait, sinon, mes essais auraient tourné court !!! :damn:
Mais visiblement, ça ne pose, pour le moment aucun souci, surtout depuis ma correction de la fonction MFDSPECEX.
Je vous laisse imaginer les possibilités entre les deux simulateurs ! (FSX n'a jamais voulu de FS9 par exemple...sauf par l'intermédiaire de DAFSIM ou d'IVAO !).
Voili, voilou...
Yves
-
Beau temps sur la planète !
;)
Mode "Moustache" :
" ... tous derrière et lui ... de ... vant ! " .
:ptdr:
-
Quand même... c'est un truc de gros balèze oufzore que vous nous faites là ! ;)
-
@alexandre :
Ben tu sais, tant qu'à faire quelque chose, autant faire quelque chose qui en vaille vraiment le coup, comme UMMU ou le DGIV ou OrbiterSound....enfin des trucs comme ça quoi...
Alors, oui, ça prend du temps et pas mal d'énergie. Mais si j'arrive au bout de ce projet, je pourrai valablement me regarder dans une glace et me dire : "j'ai essayé d'apporter quelque chose à la communauté, qui m'a déjà tant apporté elle-même...". Ce sera ma maigre contribution...
Yves
-
Toujours un truc qui me perturbe ..... Sa doit vachement tiré sur la connexion du "serveur". Celui qui hébèrge la partie n'a pas interêt d'avoir une connexion en mousse Oo"
Après serai t-il possible de faire tourné ceci sur un serveur dédié ? ( le genre de serveur qu'on peut louer chez OVH par exemple ).
Message modifié ( 22-08-2010 22:29 )
-
Exellente cette émission !
( le micro passe de main en main ... )
:love:
-
En fait, les trames envoyées sont très petites (pour info, la variable de transmission, autrement dit le datagramme, est calibré à 2048 octets ! oui, oui !). Donc la transmission est très légère, donc la bande passante nécessaire, même pour le serveur, est faible. Une connexion de 56 kb/s suffit à envoyer 25 trames par secondes, largement suffisant !
Le serveur, c'est Orbiteur (enfin TeamServer qui tourne dessus). Ici le mot serveur désigne un mode de fonctionnement de TeamServer (en hôte, si tu préfères). L'autre mode de fonctionnement, c'est en client (un joueur qui rejoint une session existante).
Voilà pour les explications qui ont un peu de mal à passer à ce que je vois....y a pas de mal...vaut mieux être clair et il n'y a pas de question idiote, juste des réponses incomplètes parfois...
Yves
-
Pour ce qui est du serveur, j'avais compris, mais je n'arrive pas a posé correctement ma question donc je vais essayer, je dit bien essayer de m'expliquer :
Je fait une partie d'orbiter avec un ami, allez direction mars, on fini la mission cool, entre temps un autre ami rejoin la session. Moi pas de bol je suis crevé je vais au lit. Il faudrait puissent continuer le scénario malgrès mon départ, mais étant le serveur, si je part, déco pour eux et le scénario dans son état actuel est perdu ( juste ? ). Pour éviter cela j'aimerai lancé Teamserveur sur un serveur dédié ( pour faire une sorte de mini monde persistant ).
Voila c'est a peu près cela. Est-ce possible ? ( les dédiés étant souvent sous linux et dénué d'interface graphique ).
Ce pourrait être utile pour des missions de plusieur jours ( jour réel hein ^^ )
Message modifié ( 22-08-2010 23:16 )
-
Alors, j'ai compris. Quoique non encore codé, voici ce qui est prévu à terme, je rappelle d'abord le principe : Il y a à bord un commandant, un pilote et un navigateur (3 pers/4 possibles). Imaginons que le pilote, hôte de la session, s'en aille. Eh bien, c'est le plus haut gradé qui devient hôte. En fait, avant de se déconnecter, le serveur envoie aux clients l'adresse du plus haut gradé restant dans la session (en dehors de celui qui se déconnecte of course) et dit au plus haut gradé :"tu deviens l'hôte" et les clients se connectent à ce nouvel hôte...Voilà le principe....pas besoin de serveur dédié...
voilà...j'espère avoir été clair...
Yves
-
Okay pile ce que je voulais savoir (=
Très bien pensé !
-
Alors, j'ai compris. Quoique non encore codé, voici ce qui est prévu à terme, je rappelle d'abord le principe : Il y a à bord un commandant, un pilote et un navigateur (3 pers/4 possibles). Imaginons que le pilote, hôte de la session, s'en aille. Eh bien, c'est le plus haut gradé qui devient hôte. En fait, avant de se déconnecter, le serveur envoie aux clients l'adresse du plus haut gradé restant dans la session (en dehors de celui qui se déconnecte of course) et dit au plus haut gradé :"tu deviens l'hôte" et les clients se connectent à ce nouvel hôte...Voilà le principe....pas besoin de serveur dédié...
voilà...j'espère avoir été clair...
WAOW .... DONG DONG DONG ( le loup face à la pinup dans TexAvery... :bave: ).
Et tu sors cette idée , tranquille , lentement , avec calme .
Je vois :
L'inspecteur Harry , plan sérré sur le visage.
Fondu enchainé , gros plan sur le Holster .
Sa main saisi la crosse du Magnum44 , et on voit le canon apparaitre , centimètre aprés centimètre ...
WAOw WAOw WAOw ! :top:
Fondu enchainé sur Harry , gros plan sur ses yeux métalliques , il dit :
" voilà...j'espère avoir été clair... " :applause: :applause: :applause:
Non là , si tu continues dans cette voie , tu vas choper un Oscar !
SUPER IDEE !
-
En tout cas s'il le faut tu a un bêta testeur de plus *_*. Voler a plusieur dans le même vaisseaux ... Autant très bonne idée au niveau mission ( sa en ouvre des possibilité ) qu'apprentissage ( rien de tel pour un novice [ Tel que moi ] de s'installer en copilote avec quelqu'un d'expérimenté !
Vergil : Ho c'est quoi cette poignée jaune et noir *_* ?
Mr_Spock : Touche pas à sa !
DG-IV : Eject eject eject
Ouai sa pourrait l'faire :)
Message modifié ( 23-08-2010 15:10 )
-
Et de deux ! ce sera utile le moment venu, on a presque l'équipage au complet. Donc Spock et Vergil, restez à l'écoute de ce fil, ça pourrait bouger d'ici peu....
Je vois que ça commence à intéresser du monde...cool !
Yves
-
Il ne risque pas d'y avoir de saccade pour les autres joueurs ( sauf l'hote evidament ) en cas de très très très haute vitesse ?
-
Non, Vergil, car les données vecteur de poussée et de force sont envoyés atténuant les effets de mise à jour de position. Et même si je n'envoyais pas ces données, le client qui ne reçoit plus de données de position continue sur sa trajectoire actuelle (n'oublie, toute trajectoire dans l'espace est une orbite...avec ses paramètres). Donc pas de saccade. Le fait de ne pas recevoir de données de la part du serveur n'immobilise pas orbiter (en fait, c'est ça l'astuce...).
Yves
-
C'est ce qui s'appelle penser à tout ^^
Bravo et continue comme sa !
( Message court : a 600 seconde de l'apogée + Réparation a faire sur le DGIV ... Le noise cone a laché ><" )
Message modifié ( 23-08-2010 20:54 )
-
Yo Vergil !
:beer:
Vergil : Ho c'est quoi cette poignée jaune et noir *_* ?
Mr_Spock : Touche pas à sa !
DG-IV : Eject eject eject
Ouai sa pourrait l'faire :)
çà le fait , en effet !!
Euh ... tu t'occupes de faire la vidange ? :badsmile:
:top:
Message modifié ( 23-08-2010 21:54 )
-
Sa tombe bien j'ai un Arrow en orbite autour de Mars avec un petit DGIV en soute ( je m'entraine a l'EVA en ce moment ... >< Pas facile de bouger dans l'espace ! )
Sinon je me demande vraiment ce que sa va donner. Avec un TS qui tourne en même temps ! <3
La vidange, pas mal ! Vue mon niveau j'aurais plutot pensé lustré les vitres ou passer le balais dans la soute de l'Arrow :ptdr:
Message modifié ( 23-08-2010 22:07 )
-
Au pire , Nous verrons bien ! ;)
Bon , tu m'excuses , mais j'ai du boulot moi ...
Le temps de mettre ma combi .
A+ , bonne Orbite !
-
(crrr. .. .. . .tiiiui...crr)
MR SPOCK A TOUT L'EQUIPAGE !
Le commandant Kirk et moi-même sommes fiers de vous annoncer la réussite du transfert de données et de connections,
transitant sur un réseau Local , entre 2 PC . La version actuelle du Mfd permet donc à notre " Entreprise " de faire chauffer les moteurs , en vue d'un prochain vol d'essai .
Les données étant encore confidentielles , je ne vous livre pas d'image cette fois-ci .
Je laisse au commandant la Parole , qui vous expliquera la suite des évènements !
Longue vie et Prospérité !
(crrr. .. .. . .tiiiui...crr)
:top:
Message modifié ( 24-08-2010 04:26 )
-
:hot:
-
:friend:
-
:fou:
-
MrSpock à dit:
Longue vie et Prospérité !
Dis moi, Tu as les oreilles pointues ???:eek:
-
Tu veux connaitre LA Vérité ? à mon sujet ...
Ok ...
(http://i225.photobucket.com/albums/dd13/afonseca75/spock.jpg)
Message modifié ( 24-08-2010 22:18 )
-
C'est pas faux !...
Yves
-
Bon, quelques nouvelles, bonnes....et moins bonnes !
Les bonnes d'abord :
La transmission des données d'orientation mais aussi de docking sont bien transmises entre les deux ordinateurs. On a même le nom du vaisseau auquel on est docké. Je n'ai pas encore travaillé sur la synchro, juste sur l'envoi-réception des bonnes données.
Voilà les données que je récupère pour le moment :
- le nom du vaisseau qu'on pilote
- le corps de référence autour duquel il tourne (ou est posé)
- les trois angles d'attitude du vaisseau (lacet, tangage et roulis) en global frame
- le nombre de ports de docking disponibles sur notre vaisseau
- le statut de chaque port de docking (docké, non docké)
- l'objet (surtout son nom) docké pour chaque port avec un statut "docké"
Les mauvaises nouvelles :
Pour le moment, le système ne fonctionne qu'avec un seul client et un serveur. Je n'ai pas encore trouvé la bonne méthode (en TCP/IP) pour envoyer les données à plusieurs clients. Elle existe, mais je cherche encore....
Suite au prochain épisode, je vous avais dit que ça commençait à devenir sérieux...
Yves
-
Sa fonctionne déjà en mode 2 joueurs, Donc c'est déja génial !
Bravo à toi !
Message modifié ( 25-08-2010 23:28 )
-
C'est loin d'être suffisant pour moi....4, c'est le minimum....
Yves
-
C'est comme sa que sa avance ( ;
A quand l'équipage complet pour l'arrow + DG-IV <3
-
Commandant K ?
Un café ?
Non ... Sérieux !
Quel est le problème actuel ?
Pouvons nous t'aider ?
Des munitions ? calibre 44 ...
" clic clic , je n'ai plus de balles , j'ai vidé mon chargeur , je me sens mal ! " . Ma6T va craquer .
Le Net est rempli de caches d'Armement .
Il y a K se servir ? :wonder: aK 47...
Il me reste un ou deux neurones qui pourraient servir ...:badsmile:
Longue Vie et Prospérité !
Message modifié ( 26-08-2010 00:04 )
-
La bombe à hydrogène nucléaire du web c'est :
:google:
Longue Vie et Prospérité à Google !
On dirait qu'on est au jour de l'an :doubt:
Message modifié ( 26-08-2010 00:14 )
-
Bibi ?
Bien reçu !
:beer:
-
Ok, des nouvelles encore et des bonnes :
Les test de synchronisation sont commencés officiellement. J'ai tenté de programmer une synchronisation d'attitude (lacet, tangage, roulis en terme aéronautique. Attitude en termes spatiaux). Et..............(roulement de tambour).............
ça MARCHE !!! et avec une fluidité à laquelle je ne m'attendait pas ! comme quoi, le protocole est bon et vive la rapidité du C++.
C'est quand même joussif de voir le vaisseau de l'ordi n°2 (client) changer d'attitude quand on bouge le manche du vaisseau piloté par le serveur !!!
Nous venons de prouver que le multijoueur coopératif (le cockpit partagé pour reprendre le terme FSX) est possible sur Orbiter. Qui disait qu'Orbiter n'était pas prévu pour le multijoueur ?
CQFD
La suite : synchronisation du MJD (c'est plus tendu, il paraît qu'Orbiter n'aime pas, on verra...) et synchro des éléments orbitaux....(de la position quoi...je ne sais pas si je vais pas utiliser quand même setElements...).
Yves
-
Hourra pour le Capitaine Haddock !
Heu ... non ...
Hourra pour le Commandant K ... alachnikov !
TAC o TAC o TAC o ... ( woody wood picker ! )
:top: :top: :top:
Edith : " If you are a big Tree _e_ e_ , we are a small _all Axe ! Ready to cut you down , to cut you down ! " . Robert Nesta Marley .
:music:
Quoi ? Ah oui ... Vergil !
CQFD (http://www.cqfd.com/)
Message modifié ( 26-08-2010 02:33 )
-
C'est des super bonnes nouvelles ça ! Félicitation :applause:.
Spocky a toujours une chanson dans la tête... et qui fait allusion à WoodyWoodpecker en faisant allusion à la kalachinkov (AK-47 n'est-ce pas ?) en parlant du Commandant K. Ça c'est de l'expertise des mots ! :badsmile:
-
Ça c'est de l'expertise des mots !
" Vos yeux verront ceux qui vous enseignent . " Un inconnu .
:music:
Message modifié ( 26-08-2010 03:37 )
-
Bon, petit test sur le mjd en le passant temps réel, ça ne plante pas. En réalité la mise à jour du mjd se fera tous les 1000 à 10000 transmission pour éviter les perturbations inutiles. Par contre il sera transmis à chaque nouvelle connexion.
Yves
-
Bon, ...pour éviter les perturbations inutiles.
Belle démonstration de Logique , Yves !
Par contre il sera transmis à chaque nouvelle connexion.
et de sagesse !
:top::music::top:
Message modifié ( 27-08-2010 04:17 )
-
Des (bonnes) nouvelles :
Les tests en réseau de synchro continuent...
Données prises en compte et synchronisées :
- MJD
- Attitude
- Attitude Velocity
- Corps de référence (juste transmis pour le moment)
- Nom du vaisseau partagé (transmis uniquement)
- Les élements orbitaux sont récupérés, je m'occupe de leur traitement et synchronisation ce soir...
D'autre part, en allégeant le demande de transmission, j'ai pu connecté un deuxième client simultanément donc pour le moment, les tests se font à un serveur + 2 clients...
Stay connected...
Yves
-
Je peux vous annoncer fièrement que je prévois une première version utilisable du module dans 3 semaines à un mois (en comptant large...) finalement, c'est pour dans pas si longtemps...
Yves
-
Yeah ! Bien joué !
Pressé de tester sa *_*
-
Bon j'avance maintenant à grand pas :
Toutes les données nécessaires à la position et à l'attitude du vaisseau sont synchronisées entre le serveur et le(s) client(s). Il me reste pas mal de choses à faire, mais ayant compris et à peu près maîtrisé le principe, le codage devrait être assez rapide.
pour le moment, les tests ont été faits à deux, on va voir à trois, pas plus tard que tout de suite.
Autre point, j'ai fait le test avec un rafraichissement des données orbitales à 1 fois par seconde, je vais tenter toutes les demi secondes, je vais y gagner en fluidité et en précision (encore que l'influence sur la précision soit limitée...).
Voilà
La prochaine fois, je vous explique les données supplémentaires qui seront synchronisées...
Yves
P.S. : Mr_Spock, tiens-toi prêt pour une série de tests...
-
Salut Pilote334 !
Je me tiens à ta disposition .
Bravo pour l'accroissement du nombre de clients !
De bons moments en perspective !
Je me réjouis avec cqfd , Radio Brighton. " salut à tous les rastas ..." :ptdr:
Message modifié ( 28-08-2010 05:26 )
-
Il manque la communiquation vocale, en attendant on peut aller sur Skype ...
-----------
-
oui ça marche aussi, même s'il est un peu gourmand en ressources...
Yves
-
Alors, bonjour à tous,
Voici quelques nouvelles fraîches :
1°) l'intégration et la synchronisation des données d'Orbiter se poursuit. Aujourd'hui on a une position (grâce aux élements orbitaux) et une attitude précise synchronisée. Mais aussi les RCS en mode rotation et linéaires, avec la synchro du bouton RCS/LIN. Donc le son et le visuel suivent...
Le MJD est synchrone ainsi que le vaisseaux piloté (exemple : si dans un scénario, le GL-02 est le vaisseau piloté sur le serveur, ce sera aussi le cas chez les clients, les autres vaisseaux n'étant pour le moment pas synchronisés -- mais c'est prévu à termes à cause des rendez-vous --).
2°) Pour le moment, seul le serveur a les commandes et cela restera le cas tant que je n'ai pas résolu des problèmes de fiabilité à 3 connectés (1 serveur + 2 clients).
stay connected,
to be continued...
Yves
-
DE TRES BONNES NOUVELLES :
Un test à 4 ordinateurs (équipage au complet) a eu lieu ce soir à 21h15 précises. Ce test est très concluant. La connexion est stable à 4 (2 en distant via internet et 2 en réseau local pour assurer la mixité). En outre, plus l'ordinateur est puissant plus la connexion est sensible (car le framerate est très élevé). L'ordinateur distant était beaucoup plus puissante que le mien, et je craignais des gros souci, surtout qu'il avait planté lors de la première connexion. Or, à la deuxième tentative, malgré différentes manœuvres de test, c'est montré très fluide et surtout très stable.
C'est donc une excellente nouvelle compte tenu de la quantité de données envoyée, et de leur traitement.
Je continue à intégrer de nouvelles données (la poussée principale, notamment, non encore gérée).
Voilà, restez sur ce fil, la sortie d'une version bêta est imminente....
Yves
-
J'espère que CARL pourra enduré ça... Pour l'instant, selon tes posts, ça m'a l'air très bien optimisé. Tout pour faire plaisir à mon ordi :badsmile:.
:merci: de CARL.
-
Salut !
L'Entreprise est entre de bonnes mains .
L'équipage mérite son capitaine , et le capitaine son équipage !
Confiance , donc !
:merci:
-
Bon,
Le module copilotage est opérationnel pour la plupart des fonctions.
Les beta-testeurs volontaires sont priés de se faire connaître maintenant en m'envoyant par MP leur adresse mail.
Merci à vous...
Yves
-
Bonjour à tous,
Donc, comme je l'ai écrit plus haut, le module est fonctionnel et disponible pour les béta testeurs qui le souhaitent (faites-moi savoir que vous voulez participer par mp).
Je souhaiterai que quelqu'un s'occupe de développer un module contrôleur indépendant d'Orbiter mais qui communique avec lui via mon module. Je donnerai au futur développeur tous les rensiegnements nécessaire pour la communication avec TeamServer.
Déjà, quelques infos : le port à utiliser est le 13000 et le protocole est en TCP/IP, c'est facile à programmer avec la bibliothèque standard de Windows (winsock2.h).
Les messages de communication sont en texte, donc facile à comprendre.
La requête de connexion d'un controleur sera un message commençant par le mot clé "CNTRL". Tous client qui enverra ce message au serveur recevra en retour : le vaisseau actif, son corps de référence, son attitude (composant x,y,z), ses éléments orbitaux, le statut de ses moteurs....et toute données que le developpeur du module contrôleur me demandera d'intégrer.
Voilà encore de quoi enrichir le monde multijoueur d'Orbiter...pour ceux qui le souhaitent...
Yves
-
:music:
"Crr ... tiuiu ..."
Mr Spock à tout l'équipage :
Je viens de recevoir la version (d) de TeamServeur , accompagnée de sa Doc .
Avant de faire un compte rendu de ce test , voici la doc qui expose bien les possibilités offertes par ce Module .
Donc , bonne lecture , en attendant le prochain départ .
Doc de TeamServeur (http://dl.free.fr/rKyG4fuTH)
Longue Vie et Prospérité à Tous !
"Crr ... tiuiu ..."
:music:
Message non subliminal : Merci Claude Samuel Levine , pour " Le pays des sages " .
Message modifié ( 30-08-2010 12:04 )
-
:music:
" Tiuiu ..."
MrSpock à tous :
Je viens d'essayer sur mon propre réseau la version d de TeamServeur , et le résultat est contrasté .
Tout d'abord , mon réseau est attaqué par un virus que je dois éliminer , et qui fausse donc les résultats .
Je remplace cet après-midi le système d'exploitation ( depuis le temps que je le dis ... ) du PC2 .
Un premier constat positif , le bouton FNS du coté Serveur fonctionne bien maintenant .
Le serveur reçoit la demande de connection , mais le nom du demandeur est tronqué en cas d'espace :
" Mr Vergil " équivaut à "Mr" ; "MrVergil" passe . ( à priori ... la lenteur du pc2 m'empêche d'être performant pour les tests ) .
Une réflexion :
Même si la connection entre les deux versions d'Orbiter(2006 et 2010) est compatible , nous devons posséder chacun
un même scénario . J'ai cherché rapidement un scénario existant par défaut dans les deux Launchpads , mais je n'en ai pas trouvé . Les connaisseurs dans ce domaine résoudrons le " caillot " .
Je pense que nous aurons le plaisir quoi qu'il en soit de créer ensemble des scénarios compatibles .
Bon , j'ai un système de fichier à détruire et à recréer , moi !
Commandant K ? Je suis bien disposé à t'aider pour la continuité du code , si le moment est venu .
+A+
" Tiuiu ..."
:music:
Message modifié ( 31-08-2010 17:08 )
-
Petit détail important et c'est pour ça que je ne publie pas encore : cette version de teamserver ne fonctionne qu'une fois "en l'air". J'essaie de faire en sorte quelle puisse fonctionner même au départ d'une planète (au sol).
@Mr_Spock : comme scénario compatible, tu peux choisir "DG->Glass Cockpit" pour les essais. Prends soin de copier ce scénarion dans O2006.
Yves
-
@Mr_Spock : comme scénario compatible, tu peux choisir "DG->Glass Cockpit" pour les essais. Prends soin de copier ce scénarion dans O2006.
Copié !
Tiens , pendant que je suis :
Je viens de réinstaller winxp sp2 et Orbiter 2010 , la version .exe de sourceforge .
Petite surprise de dernière minute :
Le module TeamServeur (d) est chargé dans le launchpad , mais n'apparait pas dans le MFD !
Le pare-feu ne s'est pas manifesté pour le bloquer .
Quelque chose ne tourne pas rond , je suis entrain de chercher .
"Quelque chose en toi , ne tourne pas ... rond , un je-ne-sais-quoi , qui me laisse ... con " . Téléphone .
A tout à l'heure !
MrSpock !
:music:
-
Tu dois copier dans le dossier module la dll "Pthreadvce8.dll"...
Yves
-
Salut !
Oui , je l'ai fait de la même manière que d'habitude . ( en copiant l'intérieur du dossier TeamServeur/Modules et le collant
dans Orbiter/Modules .
Mais je vais recommencer l'opération , en isolant "Pthreadvce8.dll" .
Merci !
Longue vie et prospérité !
:top:
-
Salut !
Un petit mot pour rassurer tout le monde :
Le problème ne vient pas de TeamServeur , puisque les autres modules d'origine n'apparaissent pas non plus quand
je fais CTRL+F4 dans la simulation .
Je vais essayer d'installer une autre Version .
Toujours dans la course ...
A+
Edith : " J'ai installé Orbiter2006 , même problème . Mon Pc est un DELL GX280 , je n'ai pas les pilotes d'origine , j'ai
trouvé sur Internet les pilotes de SON , VIDEO , Ethernet , mais je suppose qu'il me manque un pilote pour la carte mère.
La gestion d'intercommunication semble inexistante sur ce PC .
Si quelqu'un connait cette machine , please ,
:help:
me !
PROBLEME RESOLU : Il semble que l'auto update de windows aie réparé mon problème . Je pense que c'était lié à un
FrameWork qui était absent . Test final demain ... Bonne nuit , amis Orbinautes et Passengers !
Message modifié ( 01-09-2010 00:12 )
-
Bonjour à tous !
Aujourd'hui , je viens enfin de réussir mon test du nouveau module TeamServeur version (d ), et je rejoins l'enthousiasme de Pilote334 à son sujet !
Quelques détails à régler encore cependant ( mais quoi de plus normal ?) .
La connection est très rapide sur un réseau local , mais ... la 1ere connection en tant que client était incomplète :
Le mfd affichait Personne à bord , alors que le Serveur était le Navigateur .
Une pression sur le bouton DEC , puis à nouveau sur CON , et tout était fonctionnel .
JE PENSE QU UNE PARTIE DES INFOS N ETAIT PAS ENCORE DISPONIBLE L ORS DE LA CONNECTION .
Une fois la connection bien établie , des boutons de fonction à bord apparaissent sur le bord droit du MFD .
Et là , c'est juste ... magique , de presser sur "copilote" par exemple , et de voir le vaisseau changer immédiatement d'attitude , controlé par le pilote .
J'aimerais à l'avenir que soit développé en profondeur l'aspect visuel de TeamServeur , c'est toujours mon refrain de Panels adaptés à la fonction dans le vaisseau .
Le rôle de chacun à bord devrait aussi être établi , à mon humble avis , en redistribuant les commandes par poste .
A débattre ensemble , si vous le voulez bien .
J'aimerais dans un second temps faire intervenir TOFITOUF par l'intermédiaire d' ORBITERCHALLENGE , qui serait le lieu
IDEAL pour échanger nos Adresses IP respectives et nos scénarios à partager .
Oui , nous pouvons dés maintenant , si nous le voulons , partager le même vaisseau avec les mêmes conditions , dans l'espace !
NULENTOUT étant très Talentueux pour l'écriture de scénario , je fonde beaucoup d'espoir sur sa présente participation , pour nous concocter des scénarios adaptés à ce nouveau mode de Jeu .
Bien entendu , nous aurons l'occasion d'en reparler !
C'est pour moi une belle aventure qui commence !
" Tiuiuiu..." Tout le monde sur le pont !
;)
Message modifié ( 01-09-2010 10:52 )
-
Pour information, je suis encore en train de travailler sur l'aspect fluidité et surtout fiabilité de la connexion. D'ores et déjà, on peut maintenant décoller d'une planète, et le niveau de fuel et synchronisé temps réel.
C'est n'est encore pas fini, donc...
A suivre...
Yves
-
:top::music::top:
-
Une idée :
LE CHAT ( com par texte) .
Je viens de créer grâce à toi ma première boite de saisie , et je pense que tu pourrais sans trop de difficulté , coder
un système de "chat" qui serait génial dans un premier temps pour la convivialité et le réalisme .
Qu'en penses-tu ?
A+
Edith : Boite de saisie pour envoyer un message , ligne de debug pour le message reçu ?
Message modifié ( 01-09-2010 13:13 )
-
Oui, Spock, j'y ai pensé, mais ce n'est pas pour le moment ma priorité, sachant que j'ai d'autre choses à intégrer au module.
1°) fiabiliser les connexions et améliorer la fluidité (c'est en bonne voie)
2°) intégrer la fonctionnalité du passage des commandes (c'est en cours)
3°) synchroniser les autres objets (vaisseaux) du scénario (pour les rendez-vous).
4°) avoir la possibilité de récupérer des infos à partir d'un fichier de configuration.
Voilà, du travail en perspective encore...j'avais dit que ce serait long, mais ça avance...
-
2°) intégrer la fonctionnalité du passage des commandes (c'est en cours)
Aaah !!:bave:
5°) Créer un système de communication par texte .
:ptdr:
-
5°) Créer un système de communication par texte .
Eh non spock, le n° 5 c'est creation-destruction de vaisseaux en temps réel pour les sorties EVA !!! ça me semble plus important, non ?
D'autant que, par expérience, je me vois mal discuter en mode texte pendant une manoeuvre ou un calcul délicat ! Donc je privilégie le mode vocal (TeamSpeak ou Skype ou encore MSN...).
Donc oui, en tant que méthode de secours, pour le chat, mais pas prioritaire pour le moment...
Yves
-
Eh non spock, le n° 5 c'est creation-destruction de vaisseaux en temps réel pour les sorties EVA !!! ça me semble plus important, non ?
Tu ferais pas un super Agent Secret !
Mwah aha aha ah !
8)
Sinon , bonne idée !
:top:
-
Bon, j'ai avancé sur les points suivants :
D'abord la fiabilité et la fluidité : on passe à un rafraichissement toutes les 1/4 de secondes (250ms). C'est beaucoup plus fluide et la connexion est maintenant stable (au moins sur une heure testée à trois).
Ensuite, je travaille à passer les commandes aux uns et aux autres. C'est le commandant de bord qui a cette possibilité (Spock, les boutons C-P, C-C et C-N dans le MFD quand tu es commandant de bord). C'est en bonne voie, mais je n'ai pas fini. Le principe est que les clients transmettent des commandes de moteur et le serveur les prend en compte ajustant son attitude et sa position en fonction de cela. Il retransmet ces mêmes paramètres aux autres clients qui n'ont pas les commandes. Voilà...
A suivre
Yves
-
Le principe est que les clients transmettent des commandes de moteur et le serveur les prend en compte ajustant son attitude et sa position en fonction de cela. Il retransmet ces mêmes paramètres aux autres clients qui n'ont pas les commandes. Voilà...
Beau travail !
Pour l'instant tu traites les données moteurs .
Penses-tu aussi traiter la Navigation ?
Je comprends que tout cela prenne du temps , mais nous ne sommes pas pressés de toute façon .
Courage donc , pour la suite .
:beer:
-
VICTOIRE !!!
On peut se passer les commandes les uns les autres !
En fait pour la navigation, les différents MFDs commandent les moteurs, donc, ça revient au même. Si tu fais l'un, tu fais l'autre et ça marche !!!
Donc je confirme que le commandant de bord seul décide qui pilote à l'instant T. Lorsqu'il donne les commandes, il les perds lui-même mais peut les récupérer à tout moment, c'est sa responsabilité même.
Exemple d'utilisation type : Le navigateur a trouvé une solution d'interception pour rejoindre une planète grâce à IMFD. Celui-ci dispose d'un auto-pilote (AB=auto burn). Si le commandant est d'accord avec la solution choisie par le navigateur, il (le cdt) donne les commandes au navigateur pour exécution de la manoeuvre. Il peut les reprendre en fin de manoeuvre ou à n'importe quel moment, si ça déconne...
Voilà
A suivre...
Yves
-
Donc je confirme que le commandant de bord seul décide qui pilote à l'instant T. Lorsqu'il donne les commandes, il les perds lui-même mais peut les récupérer à tout moment, c'est sa responsabilité même.
+1
:hot:
-
+2 :badsmile:
Excellente idée ! :top:
-
Je suis tout ça avec attention : c'est génial...
-
Bon, tout n'est jamais rose, il faut que je fiabilise cette partie, mais ça ne saurait tarder...
Yves
-
Sa avance plutôt bien !!!!
Courage ! C'est super !
-
Salut à tous, je commence à intégrer l'actualisation des position des autres vaisseaux du scénario.
Je vous tiens au courant de l'avancement des travaux...
Yves
-
1°) fiabiliser les connexions et améliorer la fluidité (c'est en bonne voie)
2°) intégrer la fonctionnalité du passage des commandes (c'est en cours)
3°) synchroniser les autres objets (vaisseaux) du scénario (pour les rendez-vous).
4°) avoir la possibilité de récupérer des infos à partir d'un fichier de configuration.
Pour info les points 1 et 2 sont faits et testé, le point 3 est en cours de codage, le point 4 en cours de réflexion pour savoir ce que j'y mets dedans et Spock va être content, le point n°5 sera la partie chat car je repousse la création/destruction de vaisseaux pour le moment. Cela fera partie d'une mise à jour ultérieure car je voudrais pouvoir diffuser rapidement (une semaine à quinze jour) une première release candidate du module...
Yves
-
+150
Peut-on imaginer la reproduction d'un vol apollo à 3 ?
SI c'est possible, je veux bien mettre toute ma passion à votre disposition.
Le rève pour moi serai de refaire en multijoueur un vol apollo à 3 avec NASSP :hot:
Ca y es, ch'uis chaut bouillant là.
Plein d'idées dans ma tête.
Va falloir groupir les compétences les gars.
Création d'une agence spatiale virtuelle ?
ch'uis chaud les gars :hot: :hot: :hot:
-
Alors dans l'ordre des questions posées :
- Pas testé, mais pourquoi pas...
- Ce sera avec plaisir
- Avec un site et une vraie gestion comme on le fait chez Atlantic avec recrutement des équipage aux petits oignons avec un staff actif, impliqué et volontaire ? Pourquoi pas, mais c'est pas gagné, et je dis ça par expérience !!!
Yves
-
Je ronge mon frein ! oups, comment ne pas dépasser la piste l'attérisage, alors ?
Comptez sur moi pour une bonne grosse vidéo avec sa quand sa sortira ! On vous doit sa, quand même !
---
-
Salut à tout l'équipage !
Votre enthousiasme me réjouit , presque autant que la création du point n°5 ! :hot:
Toutes les compétences sont bienvenues .
Peut-on imaginer la reproduction d'un vol apollo à 3 ?
Imaginer certainement , la réalisation dépend de la préparation du vol .
Tu pourrais établir ,Thrawn , le rôle de chaque équipier à des moments du scénario , une storyline que posséderait chacun ,
avec les actions réparties selon la fonction à bord . Ce serait super , et un exemple pour les scénarios à venir .
Et Bravo Pilote334 !
:top:
Message modifié ( 04-09-2010 14:25 )
-
MOCR : Apollo 11 this is Houston are you reading, over.
Bibi : Houston, Apollo 11. Go ahead.
MOCR : We were talking about the idea of Thrawn. Is he aboard with you ?
Thrawn : Yes, I'm aboard.
MOCR : Ok. We weren't sure about this one. We saw in the... how do you call that ?... the "fofo" that you were the first to propose to be on this flight. Is pilote334 with you ?
pilote334 : Yes. I'm the CMP and the first tester of my own program, which allowed you to do multiplayer sessions in Orbiter.
MOCR : Perfect. We're checking your program down here. Over.
Bibi : Thanks Spock. Over.
EDIT:
MOCR veut dire Mission Operations Control Room, soit la salle de contrôle à Houston.
Message modifié ( 04-09-2010 15:40 )
-
Woawoaw ! :applause: :applause: :applause:
Hey ? BiBi , tu m'avais caché ce Talent ...
J'adooore !
Je sens que nous allons bien nous amuser ...
Bravo pour ce script , n'hésite pas à en proposer d'autres !
Ce serait marrant de " rejouer " des dialogues !
+1000
:hot:
Edith :
MOCR veut dire Mission Operations Control Room, soit la salle de contrôle à Houston.
Encore une super idée du canadien ... mwah ah ah ...!
OUI !
Car en plus de l'équipage connecté , nous pourrions " linker " un MOCR ?
Il surveillerait la trajectoire , la poussée , validerai les calculs ...
T'es trop fort , l'oncle !
Au départ , le projet TeamServeur concernait 8 connections ,BiBi uncle les ramène à notre bon souvenir ...
4+4= ?
:top:
Message modifié ( 04-09-2010 16:24 )
-
Bonne continuation.
-
Et pourquoi pas un vol à 8 à bord d'une capsule orion vers proxima du centaure?
Arf
-
Dans ce cas on a une autre add on a finir =P
-
vous affolez pas, je suis tombé sur un os qui va être difficile à résoudre. J'ai intégré hier l'actualisation et la synchronisation des autres vaisseaux du scénario. J'ai pris comme à mon habitude les éléments orbitaux comme référence.
Hélas, ils ne sont pas assez précis pour permettre un docking. Pour exemple j'ai tenté un rendez-vous avec l'ISS. L'erreur de précision de la position de notre vaisseau ajouté à l'erreur de l'ISS permet tout juste de faire une approche à une quarantaine de kilomètres.
Il va donc falloir que je m'y prenne autrement...c'est pas gagné, je ne sais même pas si c'est possible !
Après pour les voyages interplanétaire à un seul vaisseau, pas de souci, ça fonctionne bien.
Don pour appollo 11, difficile d'accrocher le LEM en réseau ! Je vais voir ce que je peux faire....
Yves
-
Thrawn a écrit:
Création d'une agence spatiale virtuelle ?
Ca ne rappelle rien à personne, ça ?
-
nous pourrions " linker " un MOCR ?
Le truc serait de savoir si en intégrant le sdk d'orbiter, on peut afficher un MFD quelconque dans une application externe...
Yves
-
Pourquoi une application externe ?
Je propose la création d'un type de vaisseau qui dispose d'un Mesh en forme d'immeuble , statique , avec un panel 2d
représentant un poste de controle avec vue sur le pas de Tir .
Le tout *4 et relié à TeamServeur comme client .
Il recevrait les infos de télémétrie , les données de fuel , poussée etc , et communiquerait par chat et voice .
Facile à dire !
:badsmile:
-
ok, dans ce cas, c'est parfaitement faisable. Dés que je publie, je fais un premier SDK pour pouvoir communiquer avec TeamServer...
Yves
-
:top::top::top:
-
Bonjour à tous !
Vous allez être heureux : le module copilotage est terminé dans sa version beta. D'autres versions suivront mais pas tout de suite...
Donc le module est téléchargeable avec sa doc (modifiée, pour Spock qui avait vu la première mouture) à l'adresse suivante : www.simusic.fr/demo/TeamServer_100b.rar
Amusez-vous bien...
Pour le moment, pour les communication qui ne sont pas encore intégrées au module, servez-vous de MSN, SKYPE ou TEAMSPEAK.
Pour l'adresse TeamSpeak, en voici une que je vous ouvre pour cela : spacemusic.selfip.org:8778, vous pouvez y aller sans login ni mdp (en anonymous). Version de TS : RC2 et non la 3 incompatible.
Yves
-
@Toufitouf : tu peux récupérer l'archive pour le mettre en téléchargement sur Orbiter Francophone ? l'archive contient une image au format voulu et un fichier texte de description...
Merci...
Yves
-
YES YES YES !!
J'ai un truc à finir , et je télécharge !
Merci Pilote334 !
A+ ....
:applause::applause::applause:
-
yes !!!
Félicitation ! c'est top !
je le met sur le site dès que possible.
pour l'intégration à orbiter challenge, je suis tout à fait d'accord même super partant. mais il va me falloir un peu de temps pour préaprer tout ca. je vais y travailler et je vous tiens au courant.
en attendant vous pouvez me lister ce que le manager va devoir modifier (fichier de config pour l'ip, etc etc....)
-
Salut Tofitouf !
Merci pour ton message .
En fait , pour le moment , une simple page avec un formulaire , par exemple , suffirait .
Nous avons juste besoin de connaitre :
_ L'adresse IP du Serveur .
_ Le scénario à utiliser .
_ Le vaisseau .
En option :
_ L'heure de démarrage de la session .
_une petite description de la mission .
Pilote334 prévoyait une actualisation des données concernant les connectés , mais son module ne le permet pas encore.
Il prévoyait d'utiliser du Php pour dialoguer avec le site .
Le format évoluera avec les versions , pour le moment , ce qui compte c'est de pouvoir retrouver l'adresse du Serveur
pour se connecter .
:merci:
-
ouaaaiii, enfin :eek: Et plus qu'a faire un topic sur les forum anglo pour les rendre jaloux :badsmile:
-
Quoiqu'il en soit, ce module n'est encore qu'en version beta, fonctionnnelle, certes, mais largement améliorable. Voici mon programme pour les semaines à venir.
Je vais faire un premier SDK pour vous fournir (au gens développant en C++) des fonctions permettant de communiquer avec mon module quelque soit le nombre de personnes à bord (c'est à dire même si il y a déjà 4 personnes), ceci afin de permettre le développement du MOCR fort utile au demeurant (qui s'y colle ?).
D'autre part, je reste à votre disposition pour toute question concernant le module lui-même.
La fiabilisation de la connexion des clients dans la durée me pose toujours problème mais cela reste utilisable si le client se déconnecte quelques instants de temps en temps ( histoire de pas perdre la synchro). Il se reconnecte avec les même droits et s'il avait les commandes à ce moment là, il les retrouve (si le commandant n'a pas changé d'avis entre-temps).
Yves
-
Merci Pilot
je t'invite à boire un verre au papy's bar
mais c'est toi qui laisse le pourboire
Message modifié ( 06-09-2010 16:33 )
-
petite astuce au passage. Si le commandant décide de faire une accélération temporelle, voici une méthode qui marche :
Le commandant annonce :"Time Warp dans 10 secondes"
Action : les clients se déconnectent, le serveur (et pas forcément le commandant) lance l'accélération. A la fin de celle-ci, les clients se reconnectent, il sont de nouveau synchronisés avec le nouveau MJD du serveur.
Voilà, les possibilités sont ainsi nombreuses...
Yves
Message modifié ( 06-09-2010 18:14 )
-
le développement du MOCR fort utile au demeurant (qui s'y colle ?).
Devine !
:badsmile:
Cela fait un mois que j'attends le SDK ...
sans parler du code source ... mais j'ai vu que le module n'est pas ... open .
Qui s'y colle ?
MWah ah ah ah ah
:ptdr: :ptdr: :ptdr:
Allez , sans rancune !
:beer:
Message modifié ( 06-09-2010 17:10 )
-
J'ai une question moi (il en faut bien..)
En commençant le projet, tu t'attendais à 100% à le finir, même si un gros problème se serais présenté (réparable de toute façon) ou il y aurait eu des chances qu'orbiter ne puisse pas boire ton idée et donc impossibilité de faire l'add-on?
Autrement dit : peut-on tout faire en programmant pour orbiter?
-
Oui et non. Tout est programmable, en théorie. Non en pratique car la somme de compétences est telle que c'est difficile de tout connaître...
Alors, j'avais un espoir de réussir, mais c'était loin d'être une certitude...
Yves
-
DagoO a écrit:
J'ai une question moi (il en faut bien..)
En commençant le projet, tu t'attendais à 100% à le finir, même si un gros problème se serais présenté (réparable de toute façon) ou il y aurait eu des chances qu'orbiter ne puisse pas boire ton idée et donc impossibilité de faire l'add-on?
Autrement dit : peut-on tout faire en programmant pour orbiter?
Moi je dirais que non, car on est limité à Orbiter. Si tu parles de la programmation en générale (sans API), oui, tout est possible mais l'explication de pilote334 vient se confirmer.
Déjà une bêta ! J'en ai manqué pendant ma mini-absence... :applause: pilote334.
-
Un bon gros merci !
Je vais essayer sa de suite !
-
Bibi Uncle a écrit:
DagoO a écrit:
J'ai une question moi (il en faut bien..)
En commençant le projet, tu t'attendais à 100% à le finir, même si un gros problème se serais présenté (réparable de toute façon) ou il y aurait eu des chances qu'orbiter ne puisse pas boire ton idée et donc impossibilité de faire l'add-on?
Autrement dit : peut-on tout faire en programmant pour orbiter?
Moi je dirais que non.
Tout, c'est une vaste notion. Mais la prog permet de bidouiller de manière assez vaste pour n'être limiter plus que par l'aspect technique, et non par les limitations d'Orbiter.
On trouve pas mal de projet naze mais mettant en place des choses "non prévues" par Orbiter. Un MFD IRC (lecture de page internet dans Orbiter), un jeu Astéroïde (pas vraiment dans le concept de base d'Orbiter) et d'autres trucs dans le genre que j'ai pas actuellement en tête. On a aussi l'exemple de la galaxie proposée sur le forum. Il me semble que des solutions avait étées avancées pour passer outre la limitation à un seul système solaire. Un dernier exemple : on a pas un module multijoueur en développement?
Je pense qu'au final, on est surtout limité par l'aspect graphique de la chose (moteur graphique pas vraiment performant), mais est-ce vraiment un problème? Un bon addon, c'est surtout des fonctionnalités pratique et interressante, pas des ajouts d'HDR ou des modèles 3D de milliards de polygones.
Bon, il est tôt, j'ai un train à prendre. Désoler de ne pouvoir développer plus. que ça. Puissiez-vous passer une bonne journée. A plus, les copains.
Nico
-
Dsl si je m'éloigne un peu du sujet mais j'ai une idée:
Pour nos vols en réseaux, on devrai créer Huston.
Quoi de plus réaliste? Créons une base avec un VC 3D qui resemblerait a une base de contrôle avec pleins de MFD, comme ca il y'aurait un opérateur dans la base qui suiverait le vol et chercherait les solutions de tir les plus économiques et guiderait le vaisseaux spatial dans sa mission... Vous en pensez quoi???
-
on y pense....
-
Si tu arrive a ce qu'on puisse voler en réseaux avec plusieur vessels différant ca serait une réussit et la realisation de la base ne devrait pas etre trop difficille...
dsl pour lortograf, j'ai écri sous les chapeaux de rou
-
Sur les chapo de roux on dit :applause:
Message modifié ( 11-09-2010 14:29 )
-
Ouais et si tu veux que ton smiley fonctionne, il faut l'écrire correctement:
Toi: ": applause:"
Et en réalité: ":applause:"
-
Alors pour le multijoueurs à plusieurs vaisseaux, pour le moment c'est non car comme dit plus haut :
vous affolez pas, je suis tombé sur un os qui va être difficile à résoudre. J'ai intégré hier l'actualisation et la synchronisation des autres vaisseaux du scénario. J'ai pris comme à mon habitude les éléments orbitaux comme référence.
Hélas, ils ne sont pas assez précis pour permettre un docking. Pour exemple j'ai tenté un rendez-vous avec l'ISS. L'erreur de précision de la position de notre vaisseau ajouté à l'erreur de l'ISS permet tout juste de faire une approche à une quarantaine de kilomètres.
Et je n'ai pas la solution...si quelqu'un la trouve.....je suis preneur !
Yves
-
Ok ... Je m'en rapproche ... via la classe oapi MODULE que j'ai réussi à utiliser en même temps que la classe MFD .
Cette fonction de la classe MODULE devrait t'interresser :
virtual void oapi::Module::clbkVesselJump ( OBJHANDLE hVessel )
Discontinuous vessel repositioning notification.
Sent to modules after a vessel position has been set explicitly (rather than via continuous state propagation. This callback can be used to force a refresh of parameters that depend on vessel position.
Voici comment j'utilise la classe MODULE :
Dans mon fichier .h je déclare la classe :
using namespace oapi; // [color=red]ne pas oublier sinon le compilateur ne la verra pas[/color]
( FXMODULE est le nom que j'ai choisi , tu le remplaces par celui que tu préfères ...)
class FXMODULE: public Module
{
public:
FXMODULE (HINSTANCE hDLL); //mon constructeur
~FXMODULE(); //mon desstructeur
void clbkSimulationEnd();// surcharge des méthodes
void clbkSimulationStart (RenderMode mode);// surcharge des méthodes
//tu pourrais déclarer :
// void clbkVesselJump ( OBJHANDLE hVessel )
//dessous c'est mon code qui n'est pas utile autrement que comme démonstration pour toi
char* GetDate();
bool CreerFichier();
bool DossExist(char* filepath);
bool chargefichier(char *filepath);//ouverture du fichier
void writeLine(FILE* file,char* line);
void writeLog(char* line);
bool simEnd;
CITYDESIGNERFILE baseFile;
PROXBASE BaseLaPlusProche;
FILE* logFile;
bool fileIsOpen();//informe de l'état du fichier
};
// qui cohabite avec le MFD
class MFDMeshPoser: public MFD {
public:
double Altitude ;//ajout de spock
VESSEL *MeshBuilder;//le nom du vaisseau
MFDMeshPoser (DWORD w, DWORD h, VESSEL *vessel);
~MFDMeshPoser ();
Ensuite , dans un .cpp qui contient le .h correspondant , tu définis tes fonctions :
/
/ là c'est mon constructeur
FXMODULE::FXMODULE(HINSTANCE hDLL):Module(hDLL)
{
//initialisation
memset(&baseFile,0,sizeof(CITYDESIGNERFILE));
baseFile.filename="vide";
}
// et là la fonction qui t'interressera je crois
FXMODULE::clbkVesselJump( OBJHANDLE hVessel )
{
// tu sauras quoi faire je pense avec les OBJHANDLE .
}
Une fois toutes tes fonctions définies , tu utilises ta classe ainsi :
...
#define STRICT
#define ORBITER_MODULE
#include "multiplay.h"
#include "windows.h"
#include "orbitersdk.h"
#include "orbiterapi.h"
#include "MFDTemplate.h" // c'est là qu'est ma déclaration de FXMODULE
#include "resource.h"
FXMODULE * moduleFx=NULL ; //[color=red]déclaration portée globale[/color]
DLLCLBK void opcDLLInit (HINSTANCE hDLL)
{
hSpockDLL=hDLL;
static char *name = "City Designer"; // MFD mode name
MFDMODESPEC spec;
spec.name = name;
spec.key = OAPI_KEY_T; // MFD mode selection key
spec.msgproc = MFDMeshPoser::MsgProc; // MFD mode callback function
// Register the new MFD mode with Orbiter
g_MFDmode = oapiRegisterMFDMode(spec);
[color=red] moduleFx=new FXMODULE(hSpockDLL);[/color] // [color=red]LA CONSTRUCTION[/color]
oapiRegisterModule(moduleFx) ;
}
Maintenant , à chaque fois qu'un vaisseau est déplacé d'une manière explicite , ton code s'execute .
MODULE fournit d'autres fonctions qui te permettent de controler chaque frame , telle que :
[quote]virtual void oapi::Module::clbkPreStep ( double simt,
double simdt,
double mjd
) [virtual]
Time step notification before state update.
Called at each time step of the simulation, before the state is updated to the current simulation time. This function is only called when the "physical" state of the simulation is propagated in time. clbkPreStep is not called while the simulation is paused, even if the user moves the camera. [/quote]
J'espère que tu trouveras ici de l'aide .
A+
:music:
Message modifié ( 11-09-2010 15:11 )
-
moi aussi ;)
-
Non, je crois que vous ne m'avez pas compris, ou je me suis mal exprimé : la mise à jour d'un vaisseau quelconque dans sa position, j'y arrive, "setElements" m'y aide bien. Mais c'est la précision qui me fait défaut. Là est mon problème dans la mesure où on a une fonction pour lire la position, mais pas pour l'écrire ! c'est là mon souci, les éléments orbitaux n'étant pas assez précis pour faire de la synchro. Mais je vais voir ton idée, elle peut-être intéressante...
Yves
-
Mais c'est la précision qui me fait défaut.
Ben en fait , c'est la solution , si tu regardes de plus près . ( AutoUpdate dés replacement avec setElement par exemple ,
je ne vois pas mieux ! )
Mais surement que ton code est articulé autour de la fonction update du MFD (faible taux de rafraichissement), si c'est le cas cela explique la perte de temps et de précision . J'ai choisi de faire le pas vers MODULE, la transition m'a couté 24 h de prog , mais les performances sont là .
Maintenant , c'est difficile de t'aider sans savoir autrement qu'en imaginant comment tu as codé ton affaire ...
Bonne chance en tout cas !
A+
PS : L'apprentissage de MODULE est important toutefois car il représente le lien entre OrbiterNG(serveur non graphique) et
la solution graphique nouvelle à développer . Autant dire que c'est l'avenir .
Message modifié ( 11-09-2010 20:21 )
-
ok, bien vu. Non en fait la routine d'actualisation est indépendante du MFD mais de "callbackOPCPreStep", voilà pour l'info...
Yves
-
Salut !
Pour finir bien ...
[b]DLLCLBK void opcPreStep[/b] ( double simt,
double simdt,
double mjd
)
Time step notification before state update.
Called at each time step of the simulation, before the state is updated to the current simulation time. This function is only called when the "physical" state of the simulation is propagated in time. opcPreStep is not called while the simulation is paused, even if the user moves the camera.
[color=red][b]Deprecated[/b]:[/color]
[color=blue]This function has been[color=red] replaced by [b]oapi::Module::clbkPreStep. [/b][/color][/color]
Parameters:
simt simulation time after the currently processed step [s]
simdt length of the currently processed step [s]
mjd simulation time afte the currently processed step in Modified Julian Date format [days]
Note:
[color=red]Plugins should no longer implement this function[/color]. Instead they should create an instance of a class derived from [color=red]oapi::Module [/color]during InitModule that overloads the oapi::Module::clbkPreStep method, and register it with oapiRegisterModule.
opcPreStep is called by Orbiter only if no instance of oapi::Module is created and registered during InitModule, or if a registered module does not overload the oapi::Module::clbkPreStep method
Donc :
Mais je vais voir ton idée, elle peut-être intéressante...
:ptdr: :ptdr: :ptdr:
A+
Message modifié ( 12-09-2010 06:11 )
-
oapi::Module::clbkPreStep.
C'est bien celle dont je me sers...
Yves
-
Va falloir vraiment que je me plonge dans cette histoire de classes....
Pffff !!! J'aimais bien travailler avec les fonctions moi....
Yves
-
Et oui! Mais tu vas voir : une fois le principe des classes à peu prés compris on peut plus s'en passer. Aprés, ça dépend des gens. J'étais sceptique au départ mais j'adore ce truc. La POO, je peux plus m'en passer.
-
Je confirme les dires du pingouin, ca m'avais fait peur aussi au début habitué au pascal et au C.
Je n'y voyais pas l'intérêt, ayant peur de ne pas savoir comment organiser tout cela. et au final, je suis incapable maintenant de revenir aux simples fonctions.
Le langage objet structure naturellement ton code. c'est une simple manière de regrouper dans un même fichier une idée, un concept. En gros tu reunis des variables et des fonctions qui permettent de les manipuler.
rendre els variable privées permet de garantir très simplement que tu ne peux pas les modifier de n'importe où et donc de centraliser les appels, pour débuigger apr la suite cela simplifie tout. si par exemple tu n'as qu'une seule fonction pour changer une valeur d'un classe, il suffit d'y mettre un point d'arrêt pour intercepter toute les modifications. C'est trsè efficace quand ton code commence à grossir.
-
Bon ben ça y est je fous le nez dedans...
Yves
-
pilote334 a écrit:
Bon ben ça y est je fous le nez dedans...
Yves
N'oublies pas les Tylenol, tu en auras besoin.
Je suis avec tofitouf et le pingouin. Au début, ça l'air con mais dès que tu assimiles vraiment le principe, le C est oublié pour toi (mais pas tout à fait car le C++ est très semblable :badsmile: )
:wor:Vive Bjarne Stroustrup !:wor:
(http://i1029.photobucket.com/albums/y355/BibiUncle/BjarneStroustrup.jpg)
C'est pas moi sur la photo. C'est Stroustrup !
Message modifié ( 15-09-2010 01:56 )
-
A ce propos, Mr Stroustrup a écrit un bon bouquin sur le C++ dont la simplicité du titre contraste avec le nom à coucher dehors* dont l'ont affublé ses parents (bien que ça doit paraître plutôt classique pour les Danois) : The C++ Programming Langage. Un livre de référence à avoir absolument.
C'est vrai que le prix peut faire peur : http://www.amazon.fr/Programmation-Applications-avec-Bjarne-Stroustrup/dp/274407442X/ref=sr_1_1?ie=UTF8&s=books&qid=1284522024&sr=8-1
Mais en fouillant, on peu le trouver pour une quinzaine d'euros (frais de port compris). Evidament, c'est de l'occasion à ce prix-là, mais c'est vraiment une super référence à avoir à portée de main lorsqu'on programme.
*Tellement original comme nom, dans un domaine où les anglophones dominent le marché, qu'il a enregistré ça :
http://www.research.att.com/~bs/pronounciation.wav
-
Super le renfort des programmeurs qui ont la classe !
:applause:
C'est bien , yves , que tu aies décidé de gravir cette montagne , le plus dur c'est le premier pas .
:top:
Ce n'est pas une perte de temps , au contraire , au fur et à mesure de ta progression , tu vas prendre de l'altitude , et
ta vision périphérique va s'élargir ! :badsmile:
N'hésite pas à demander de l'aide , puisque nous sommes plusieurs à être capables de t'aider dans ce passage de transition vers la programmation orientée objet !
A+ , bonnes découvertes !
-
Comme c'est étrange. En regardant ton lien Nico, j'ai tout de suite cherché la version anglaise qui est, pour la plupart du temps, beaucoup moins cher... mais pas ici. 62 $ ! http://www.amazon.ca/Programming-Principles-Practice-Using-C/dp/0321543726/ref=sr_1_2?s=books&ie=UTF8&qid=1284585850&sr=1-2
C'est la référence... mais qui coûte cher. :arg:
Message modifié ( 15-09-2010 23:24 )
-
C'est tellement la référence qu'on peut le trouver en français à des prix trés abordables. Evidament, on a pas la dernière révision à chaque fois, mais c'est pas trop trop grave au final.
-
Perso se prix me surprend pas plus que sa malheureusement....
Bouquin technique => bien trop chère pour du papier ^^
me suis payé un bouquin sur de la prog dernièrement => 40 € les 300 pages.. aie..
-
Alors, heureusement, j'ai le bouquin qui va bien :Le Grand Livre du langage C++, pas mal foutu du tout, il m'a bien aidé jusque là. Mais c'est vrai que jusqu'ici, j'ai tout fait pour éviter l'écueil des classes, ça va changer, je vous le dis. D'autant que je m'attaque à un autre projet, mais sur un autre simulateur. Toujours du réseau et toujours du transfert de données, mai sen externe et avec simconnect (!!!).
Yves
-
ça va changer, je vous le dis. D'autant que je m'attaque à un autre projet, mais sur un autre simulateur.
Rhôôooo ... pas bien ! :badsmile:
Ben oui ... et nous ?
Ou alors tu te fais la main sur un autre simulateur , et tu reviens gonflé à bloc avec de nouvelles techniques ?
Ou tu fais tout à la fois ? :trucdeouf:
Ben en tout cas , cela fait plaisir de te voir toujours autant motivé !
:top:
-
Bonjour à tous.
J'ai commencé à réorganiser mon code en classe C++ (POO). Cela ne marche pas trop mal, et c'est vrai que cela rend le code plus indépendant, donc réutilisable, et plus lisible aussi.
Il me reste des question :
Comment faire un SDK ou n'apparaitrait que la déclaration des classes mais pas leur définition dans un header ?
Spock, tu me parlais d'un point d'entrée dans la dll, mais par définition et surtout dans Orbiter, pas de fonction main() dans une dll. Comment faire ?
Voilà, c'est tout....pour le moment...
Yves
-
Salut Pilote334 !
Par définition , le point d'entrée d'une dll s'appelle DllMain (....) .
A l'intérieur de cette fonction ,tu récupères ses paramètres pour gérer les moments qui suivent :
_Quand un processus s'attache à la dll.
_Quand un processus se détache de la dll
_Quand un Thread s'attache et se détache .
Quand la Dll est attachée à un processus , elle peut éxécuter ses fonctions Locales ( pour toi par exemple ouvrir des ports TCP etc ...) .
Elle peut exporter ses fonctions en utilisant un déclarateur spécial qui désigne au compilateur qu'une fonction
est en mode IMPORT ou EXPORT .
Tu déclares cette fonction dans le fichier .H de la dll , et tu l'inclues dans ton .cpp .
Tu dois compiler ton programme (dll) pour obtenir un.lib qui servira de bibliothèque liée à ton projet pour orbiter.
Ton projet pour orbiter dans VC++ utilisera ta lib qui est l'équivalent de la dll .
Ensuite , ton module compilé faira appel à ta dll dés son premier appel de fonction .
Tu trouveras dans leSDK win32 et sur le NET toutes les infos à ce sujet .
http://msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx
A+
-
Permet moi de te corriger mon cher Spock, ce que tu dis est tout à fait exact mais je ne crois pas que c'est ce qu'il demande.
Voici quelques points de fonctionnement sur les DLL.
Effectivement le point d'entré d'une dll est bien le DllMain. une fonction déclarer et qui va recevoir tous les appels systèmes : chargement, déchargement etc...
mais cette fonction n'est pas indispensable, loin de là. par défaut visual c++ en génère une si on n'en déclare pas.
Ce mode de fonctionnement en passant par le dllMain est utile quand on veux faire des librairies qui se chargent manuellement via la fonction LoadLibrary (comme le fait orbiter en interne)
Ici notre pilote a besoin de créer une dll d'ouil permettant d'être utilisé par divers autres projets.
il doit donc déclarer une séries de fonctions qui peuvent être appelés de l'extérieur de son projet sans que 'lautre projet ai connaissance du focntionnement interne de la dll.
C'est tout à fait possible et même assez simple.
tu peux exporter des fonctions C ou des classes.
pour cela il faut que tu passe par deux déclaration : __declspec( dllimport ) et __declspec( dllexport )
dans ton code à toi tu écrit
class __declspec( dllexport ) maClasseDeLaMort
{
public:
void uneFonctionQu'onPeuxAppeler();
}
dans ton fichier cpp associé tu met le code de ta fonction comme d'hab, là rien ne change.
ensuite quand tu compile visual c++ génère 2 fichiers important : la dll et le .lib
si tu veux distribuer ta dll pour être utilisable il faut que tu file le le .lib la dll et le .h ci dessus légèrement modifié.
en effet il faut remplacer dllexport par dllimport.
Comme c'est agacant de devoir réécrire 2 fois la même chose en changeant un détail il y a une ptite astuce.
Souvent on exporte plusieurs classes, dans chacune on met un mot clef à la place du __declspec( dllimport )[/b
par exemple
class MA_DLL maClasse
{
.....
}
dans un .h à part inclus par toutes les autres classes (donc souvent en première ligne des autres .h) tu écrit
#ifdef EXPORT_MA_DLL
#define MA_DLL __declspec( dllexport )
#else
#define MA_DLL __declspec( dllimport )
#endif
et dans les paramètres de visual (préprocesseur) tu définit EXPORT_MA_DLL
les autres projets qui veulent utiliser ta dll eux ne doivent pas définir cette macro et le tour est joué
quand j'inclus ton .h j'inclus alors toujours le bout de code qui fait la définition et je sais donc que ce code là sera à importer ailleurs. Enfin disons que le compilateur et le linker s'y retrouvent et c'est déjà bien.
s'il y a besoin de plus d'infos n'hésite pas.
-
:beer:
-
J'en apprends beaucoup avec vous !
Je connaissais même pas les points d'entrées sur des DLLs. Je croyait que tous fonctionnait comme dans Orbiter (des fonctions prédéterminées par Orbiter).
Je note...
-
@Spock et Tofitouf : MERCI !!!!
Yves
-
Pas de quoi, je pense que je vais ouvrir un fil juste pour expliquer le fonctionnement des Dlls.
là ca va être dur à retrouver, tout au fond d'un fil.
-
Et quoi de neuf sur ce module de copilotage ?
Qui l'utilise ? Quand ? (=
-
Salut !
Qui l'utilise ? Quand ? (=
Une autre version dirait :
Qui l'utilisera ? Quand ?
Time will tell (http://www.youtube.com/watch?v=_7kSjZ9LoIs)
:music:
-
Je dirais que même en version beta, il est parfaitement utilisable ! faut juste se mettre d'accord à plusieurs pour former un équipage. Pour le reste, en avant, vant !
Yves
-
je suis toujours pas retourné sur les challenges mais organiser les parties multijoueur est ma priorité.
-
Je suis toujours présent , moi aussi .
:music:
-
Moi aussi :eek:
-
Pareil (=
-
Dream team ...
Moi aussi
C'était donc toi , ce moi !
moi
foi
loi
roi
soi
JACKPOT ( la mise sur le tapis :love: )
:ptdr:
-
Je te repropose également mon aide pour tester tout ça. :hot:
Avec mon experience de pilote de combat virtuel et longuement habitué au plantage des connex ça devrait être marrant. :ptdr:
-
Avec mon experience de pilote de combat virtuel et longuement habitué au plantage des connex ça devrait être marrant.
çà l' est ! (http://www.connex-network.org/)
:ptdr:
-
Longue vie et prospérité mon ami :beer:
-
Salut!
I have to apologize for not speaking French and rely on Google to translate this forum. The only (lame!) excuse I have is that English is not my native language either and I'm planning to take French lessons :).
But the topic is very interesting to me. What we are trying to achieve is to setup a dedicated air and space flight simulator for teenagers. For the air part MS Flight Simulator is used, which allows to use a second connected PC to display MFDs and a variety of flight indicators, first PC used to run FS itself and show the "picture". Something similar we want to use for Orbiter, with one PC displaying the "picture", the second accepting commands and displaying MFDs.
From what I'm getting so far from this thread, the Copilotage module is dedicated to something very similar. Is it so? If it is, can evaluate or help with development?
Thanks in advance!
-
Hello !
I have to apologize for not speaking English .... :badsmile:
I think the responsable for this project ( Pilote334) will be very happy to learn your interrest about his work .
You are free to evaluate , the module is working between 4 computers .
And sure , you will be a good partner for the development !
Try the last link TeamServer_100b.rar (http://www.simusic.fr/demo/TeamServer_100b.rar) of this Topic !
Thank you for your interest too.
for bibi uncle :
Je regrette de pas pas être Canadien dans ce genre de cas ... mwah ahah ah
Message modifié ( 13-10-2010 21:49 )
-
Merci beaucoup!
-
Je me remet au travail. je prépare le site.
-
MrSpock a écrit:
for bibi uncle :
Je regrette de pas pas être Canadien dans ce genre de cas ... mwah ahah ah
Au contraire, tu es très bon ! :applause:
Welcome a5926 ! Happy to see your participation for this project.
-
I'm joining my colleagues to wish you welcome on this forum.
I would like to give some precision about this project. It's operational in local network with at least two computers running Orbiter 2006P1 or 2010. Please, be conscient that this is a beta version and will be improve in the future (when I'll have more time to develop it again). There's a doc in the archive but it is in french. I will translate it later.
The requirement is to open ports on firewall and router. It's mandatory to make protocol effective. The port number is 13000. At least the computer wich running as server must open this port on itself and on its router (if wan used).
Any question can be asked here in french or exceptionnaly, for you, in english. It will be a pleasure for me to answer.
Sir, excuse my bad english and be sure of my consideration using my module TeamServer.
Regards
Yves
Message modifié ( 16-10-2010 06:16 )
-
Thank you very much for your warm welcome.
All the requirements seem to be clear, realistically I'll have a chance to try a setup in the next two weeks.
I'll let you know the results.
Cheers,
Alex.
-
J'ai essayé, orbiter plante a la connection de mon épuipier ( Orbiter 2010 P1 ). Je suis en mode serveur.
Impossible de savoir pourquoi )'=
-
Salut Vergil !
Pourrais-tu détailler la procédure que tu utilises ?
Il est possible que tu aies oublié un " détail " .
Sympa de t'y être mis .
A+
-
Bon,
0. Je m'occupe du port 13 000
1. je lance le scénario bringhton beach ( DeltaGlider ).
2. Mon équipier fait de même.
3. Sur le MFD gauche je met teamMFD; mon équipier fait exactement de même.
4. Je rentre mon nom ( Vergil Oo" ? ), mon équipier fait de même ( avec SON nom évidement :) ).
5. Je rentre dans "IP" : "serveur". Mon équipier rentre mon IP.
6. Je bois une bonne bierre :drink:.
6. Je met ma fonction a bord ( à savoir navigateur ), mon équipier met commandant.
7. Je clique sur connexion en premier puis mon équipier a son tour quelque seconde plus tard.
8. Je suis connecté, je voie sa demande de connexion. Il me dit qu'il vois a droite a menu qui sert a choisir sa fonction.
9. au moment ou il clique sur ce qui correspond a commandant ... Retour a windows ... Uniquement pour lui. ( je suis toujours sur mon orbiter ).
-
Salut Vergil ! Et merci pour ta description précise .
J'ai déjà eu des soucis avec Brighton Beach dans mes propres addons , ceci étant causé par un bug avec Ummu .
Je ne sais pas pourquoi , mais une fonction du SDK d'Orbiter2010 semble ne pas fonctionner , et je n'ai pas réussi à l'isoler .
Je te propose d'essayer un autre scénario , sans Ummu , pour vérifier cette hypothèse .
En gros , dans une config d'origine , évite la Lune .
Si c'est le cas , nous devrions avertir Martin S , car tous les dev en C++ seront concernés un jour ou l'autre par ce problème .
Autre possibilité : Si tu es le serveur , essaie d'être le commandant .
A+ Vergil .
-
Bonsoir tout le monde !
Jusqu'ici se projet ne m'avait pas accroché, mais sa bouge fort ici !!!
Si vous venez à avoir besoin de quelqu'un n'hésiter pas ! Alexandre peut aussi faire partis de la Dream Team ! :)
-
Si quelqu'un veut Tester avec moi aucun soucis ( Attention, je suis toutefois très mauvais (x ... ).
Je dispose d'un serveur TS au passage ( TS 3 Dernière version S.V.P ).
Sa me tenterai bien d'essayer ce module quand même :bave:
( Bien que là, je suis en pleine réinstallation complète d'Orbiter )
Message modifié ( 07-11-2010 20:39 )
-
Pour les problèmes techniques , c'est Pilote334 qui tient le code .
Si vous voulez , je lui envoie un mail l'informant de la situation ?
Je suis occupé en ce moment , mais je tiens aussi à ce projet , je garde un oeil sur cette affaire , donc .
A+ les gars .
-
Je pense faire 2-3 testes quand j'aurai fini tout ce que j'ai a faire ... ( je suis enterré par des trucs a faire ... au sans propre, IL Y A PU DE PLACE DANS CETTE CHAMBRE !!! )
Message modifié ( 07-11-2010 21:43 )
-
Je suis vos échanges avec attention. Lorsqu'un problème survient, essayez de décrire au mieux le contexte dans lequel cela s'est passé avec une chronologie précise. Pensez aussi à une chose : le port 13000 doit être ouvert côté serveur aussi bien dans le firewall de l'ordi que sur votre routeur (box). Sinon point de salut. Désolé pour cette contrainte, mais je n'ai pas vraiment eu le choix à la conception malgré plusieurs solutions testées.
Tous mes tests en réseau local fonctionnent...
Yves
-
edit
Ok, j'ai lu un peu vite, tu mets que tu es navigateur, donc ça aurait du marcher pour peu que tes ports soient bien ouverts...
Yves
Message modifié ( 13-11-2010 11:42 )
-
Je remarque un truc :
"Vergil Oo" est le nom que tu as rentré ?
Pilote334 ?
Je me rappelle que j'avais eu un problème quand j'avais entré "Mr Spock" , à cause du blanc entre les caractères .
Je ne me souviens plus si tu l'avais fixé ?
Vergil ? Essaye " Vergil_Oo" la prochaine fois ?
-
Désolé si le "Oo" vous a induis en Erreur, j'avais bel et bien écrit "Vergil" ... Je vais mener mes test en réseaux local. Faut juste que j'installe tout le matos maintenant que j'ai "la place".
Au passage j'avais déjà soupçonné ce problème et remplacé par "Ben". Le résultat est le même, mon équipier crashais au moment de sa connexion ( retour au bureau windows ... )
-
Ok, tiens-moi au courant de tes essais en réseau local, puis en réseau ouvert. N'oublie pas de préciser le contexte dans lequel tu fais tes essais, sans quoi, point d'analyse...
Yves
-
bonjour, je voudrez savoir si le mode et enfin fini
-
moi aussi ça m´interresse ce multi. Il est opérationnel? encor merci a vous
-
Des nouvelles ?
-
Bonjour à tous,
Le projet est en pause, il y a des techniques de programmation que je ne maitrise pas encore, ce qui m'empêche momentanément d'avancer sur ce projet, mais, il n'est pas abandonné. Je me forge juste de l'expérience, et ça prend du temps.
-
Je me forge juste de l'expérience, et ça prend du temps.
Eh oui... J'en sais quelque chose!!! :badsmile: :trucdeouf:
-
D'autant que le multijoueur devrais à priori être opérationnel dans pas trop longtemps! C'est chouette!