Multijoueur -> Module Copilotage

[pilote334]

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

[tofitouf]

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

[pilote334]

@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

[MrSpock]

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 )

[MrSpock]

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 ?

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++ ?
Un autre , les sdk Clients/seveurs :SDK

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 )

[pilote334]

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

[MrSpock]

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 !

[tofitouf]

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.

[MrSpock]

Un petit post pour demander où tu en es de tes éssais  ...
A+,
Spock !

[pilote334]

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

[MrSpock]

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 !

[pilote334]

ouais, ça va pas être facile de le réaliser, mais bon...

Donc patience...

[MrSpock]

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.

[pilote334]

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 !!!
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

[MrSpock]

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 )

[pilote334]

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....

[MrSpock]

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:

Mr SPock !

[pilote334]

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

[MrSpock]

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 ...
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 )

[pilote334]

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

[MrSpock]

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 .

[pilote334]

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

[MrSpock]

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.

[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 )

[pilote334]

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 :




On le retrouve dans le menu "Custom" d'Orbiter une fois lancé le scénario.










Enfin, on retrouve son activation et paramétrage...ultra-simple !!!




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 )