Author Topic: Multijoueur -> Module Copilotage (Read 110359 times)

MrSpock · Reply #75 - 09 August 2010, 11:50:14

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 !

pilote334 · Reply #76 - 09 August 2010, 12:32:25

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

tofitouf · Reply #77 - 09 August 2010, 13:00:49

eh ca prends forme tout cela, excellent.

MrSpock · Reply #78 - 09 August 2010, 14:13:49

Quote

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 .

Spoiler :

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

pilote334 · Reply #79 - 09 August 2010, 17:11:56

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

Bibi Uncle · Reply #80 - 09 August 2010, 17:15:24

Quote

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

tofitouf · Reply #81 - 10 August 2010, 11:43:08

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

pilote334 · Reply #82 - 10 August 2010, 15:13:00

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

MrSpock · Reply #83 - 10 August 2010, 15:25:26

CHampagne !!

pilote334 · Reply #84 - 10 August 2010, 20:15:05

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 !

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

OUUUFFF ! sur ce coup là, je reviens de loin....

Yves

MrSpock · Reply #85 - 11 August 2010, 05:19:08

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

Quote

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 .

Spoiler :

J'espère qu'on aura pas à aller jusque là ...

Message modifié ( 11-08-2010 06:26 )

MrSpock · Reply #86 - 11 August 2010, 05:29:33

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 :

Code: [Select]

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 )

MrSpock · Reply #87 - 11 August 2010, 06:06:05

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ù :

Quote

BINGO !!! j'ai ma solution pour contourner le problème....

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 )

pilote334 · Reply #88 - 11 August 2010, 11:46:42

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

MrSpock · Reply #89 - 11 August 2010, 12:16:49

Quote

Si je peux me passer d'un système comme fsuipc

Sûr ! La boucherie en dernier recours !

Quote

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

Quote

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

Quote

C'est testé en récupération, ça marche.

Ouaip , mais tu dis pas comment !

Spoiler :

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 )

pilote334 · Reply #90 - 11 August 2010, 13:51:56

Quote

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

Quote

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

florentin · Reply #91 - 11 August 2010, 15:57:16

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

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

pilote334 · Reply #92 - 11 August 2010, 16:27:39

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 )

pilote334 · Reply #93 - 12 August 2010, 02:21:50

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

MrSpock · Reply #94 - 12 August 2010, 10:20:22

Quote

(qui peut-être le Soleil lui-même, je vous le rappelle).

Tu pensais à qui quand tu écrivais çà ?

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+

MrSpock · Reply #95 - 12 August 2010, 12:18:53

'jour !

Pilote334 m'ayant fait l'honneur d'essayer son TeamServeur en tant que testeur bêta (

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

Message modifié ( 12-08-2010 12:34 )

Jim Lovell · Reply #96 - 12 August 2010, 13:54:59

Et bien, que de bonnes nouvelles !!!

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

Quote

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 !

Ça pue le NAT ça, non ?
Dans l avenir pilote334, comment comptes-tu régler ce "souci" ? Ça m'intéresse !!

pilote334 · Reply #97 - 12 August 2010, 15:56:51

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

Bibi Uncle · Reply #98 - 12 August 2010, 16:49:46

Ça l'avance super bien !

Ça va ~~marcher~~ fonctionner sur Orbiter 2006 ? Je tourne toujours avec lui.

pilote334 · Reply #99 - 12 August 2010, 16:55:13

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