CheckSix Forums

Bonjour à tous,

Je vais faire abstration ici des infos de positions en MP qui sont quoi qu'il arrive en peer to peer et dont la consomation en bande passante est de l'ordre de "25kb/s en Upload" et "25kb/s x nombre de clients" en download, pour chaque joueur connecté


------------------------------------------------------------------------------------------------------
Avant toute chose, quelques definitions au niveau de la gestion des IA apres desaggregation :

Lorsqu'un bataillon/flight est desaggregé par un joueur, il est geré suivant 2 statuts differents "Owner" et "SimOwner" pour lui meme et pour tous les autres joueurs connecté en MP avec lui

Owner => gestion d'une entitée tel qu'un bataillon/flight complet => gestion en tant que objets unique (gestion combat 2D : pas beaucoup d'impact sur l'utilisation du CPU et encore moins sur l'utilisation de la bande passante)
SimOwner => gestion de toutes les vehicules (un char, un lanceur SAM, un soldat, un camion, un F16, un Mig29, etc) faisant partie d'une tel entitée "bataillon/flight" => gestion de plusieurs dizaine de vehicules (gestion combat 3D, vehicule par vehicule : gros impact sur l'utilisation du CPU et impact direct sur l'utilisation de la bande passante)

Local => est geré
Remote => n'est pas geré

exemples :

"Owner:local SimOwner:local" => du point de vue d'un joueur donné, cela veut dire que ce bataillon/flight est geré en tant qu'object unique MAIS AUSSI que chaque vehicules faisant partie de ce bataillon/flight est geré par ce joueur donné

"Owner:remote SimOwner:remote" => du point de vue d'un joueur donné, cela veut dire que ce bataillon/flight n'est pas geré en tant qu'object unique MAIS NON PLUS que chaque vehicules faisant partie de ce bataillon/flight n'est pas geré par ce joueur donné

"Owner:local SimOwner:remote" => du point de vue d'un joueur donné, cela veut dire que ce bataillon/flight est geré en tant qu'object unique MAIS QUE que chaque vehicules faisant partie de ce bataillon/flight n'est pas geré par ce joueur donné

"Owner:remote SimOwner:local" => du point de vue d'un joueur donné, cela veut dire que ce bataillon/flight n'est pas geré en tant qu'object unique MAIS PAR CONTRE que chaque vehicules faisant partie de ce bataillon/flight est geré par ce joueur donné
------------------------------------------------------------------------------------------------------


Ok, je ne vais pas rentrer dans les details, mais suite à mes tests ayant pour but de visualiser la gestion de l'aggregation/deaggregation, voici mes conclusions :

les 2 code MP sont

-soit avec le patch Host all units desactivez (=> code que l'on a toujours utiliser)

-soit avec le patch Host all unit activer


Host all units desactiver


ce code est prevu :
-pour un host n'etant pas specialement super puissant en terme de CPU et n'ayant pas specialement une grosse bande passante en upload, mais quand meme un minimum de 512 kb/s)
-pour des clients devant absolument avoir un CPU raisonnable ou meme puissant et avoir une connexion tres stable en upload avec un minimum de 512 kb/s
-peu importe si utilisation d'un server en 2D ou en 3D

principe de fonctionnement de ce code :
-quoi qu'il arrive, le host est celui qui lance la TE/campagne, peu importe si il ne rentre pas le 1er dans le cockpit, peu importe si il reste dans le monde 2D, peu importe si il rentre cockpit (3D) puis qu'il revienne dans le monde 2D, etc => tant qu'il reste dans la TE/campaign, il restera le host (je ne vais pas expliquer ici ce qui se passe pour les clients si le host a un CTD ou une perte de connexion, les tests sont tjrs en cours mais plusieurs resultats ont deja ete mit à jour et ce serait trop long à expliquer)

-si c'est le host qui desaggrege un bataillon/flight : de son propre point de vue, il le vera en tant "Owner:local SimOwner:local" et du point de vue des autres joueurs connecté (les client donc), ces client le verront en tant que "Owner:remote SimOwner:remote"

-si c'est un client qui desaggrege un bataillon/flight : de son propre point de vue il le verra en tant que "Owner:remote SimOwner:local", du point de vue de tous les autres clients, ce bataillon sera "Owner:remote SimOwner:remote" et du point de vue du host : "Owner:local SimOwner:remote"

cela veus dire que :

-quoi qu'il arrive, le host gere en permanence les bataillon/flight en tant qu'object unique (Owner sera toujours local pour le host), ici tres peu d'impact sur l'utilisation du CPU et de la bande passante.
-et donc fatalement, les client ne gere jamais les bataillon/flight en tant qu'object unique (Owner sera toujours remote pour les clients)
-par contre si un joueur (host ou client) desaggrege un ou plusieurs bataillon/flight, c'est lui meme qui devra gerer chaque vehicules de ce bataillon/Flight (=> SimOwner:local) pour tous les autres joueurs connectés, ce qui a un impact direct sur l'utilisation du CPU et de la bande passante upload de ce joueur, qu'il soit host ou client, cela depend alors du nombre de bataillon/flight qu'il a deseggregé en de combien de vehicules se compose tous ces bataillon/flight, cela peut impliquer de devoir gerer plusieurs dizaines d'objects, toutes les tracantes tirées, toutes les trajectoires de missile tirés => imaginez ici un client avec un petit CPU et une petite bande passante qui doit "hoster" tout cela pour tous les autres joueur connecté ....il y a fatalement des infos qui ne passeront pas en MP

bug connus de ce code :
-desynchro aleatoire pendant certaine partie MP, source du probleme non definie precisement a l'heure actuelle


Host all units activé


ce code est prevu :
-pour un host ayant un CPU vraiment puissant et ayant vraiment une grosse connexion en upload (genre 10 Mb/s en upload et download garantis)
-pour des clients avec CPU modeste et ayant une connexion modeste (128kb/s en upload suffit largement)
-recommandation => utilisation d'un server en 2D

principe de fonctionnement de ce code :
-comme pour les Host all units desactivé : quoi qu'il arrive, le host est celui qui lance la TE/campagne, peu importe si il ne rentre pas le 1er cockpit, peu importe si il reste dans le monde 2D, peu importe si il rentre cockpit (3D) puis qu'il revienne dans le monde 2D, etc => tant qu'il reste dans la TE/campaign, il restera le host (l'ideal ici est de laisser le host en 2D, car il y a un bug enorme si le host rentre en 3D

-les bataillons/flight desaggregés par n'importe quel client seront toujours "Owner:remote SimOwner:remote" pour ces clients
-donc fatalement, ces memes bataillons desaggregé par ces clients seront toujours "Owner:local SimOwner:local" pour le host

cela veus dire que:

-ce sera toujours le host qui va absolument gerer la totalitée des bataillons/flights desaggreger par les clients : il sera donc quoi qu'il arrive "Owner:local SimOwner:local" => enorme impact sur l'utilisation du CPU et de la bande passant, surtout en upload
-les clients ne gerent jamais rien du tout, meme si ce sont eux qui ont desaggreger les bataillons/flights => tres peu d'utilisation du CPU et de la bande passant en upload, par contre ils devront avoir un download suffisament stable et important pour pouvoir recevoir la totalitée des info envoyé par le host

Bug connus de ce code :
-si le host rentre en 3D (cockpit donc) : les bataillons desaggregés par les clients se trouvant a plus de 80MN du host ne tireront jamais sur ces clients : aucune tracante, aucun SAM n'est tiré, donc sans debuggage prealable au niveau exe => NE JAMAIS METTRE UN HOST AVEC LE PATCH "Host all units" ACTIF DANS LE MONDE 3D, IL DEVRA TOUJOURS RESTER EN SERVER 2D
-si le host reste en 2D, il y a un bug qui n'a vraiment aucun impact sur la gameplay : les missiles SAM n'apparaissent visuellement (la fumée et le missile) qu'à 15MN de la position d'un joueur (au dela de 15MN, ou 25 bon km, le missile et sa fumée sont invisible). Mais je vous rassure, seul l'activation des labels permet de voir clairement ce bug, par contre je vous certifie qu'il est bien guidé et que vous avez bien une alerte de tir ou un spike de guidage => je le repete, ce bug n'a aucun impact sur le gameplay MP (video du bug avec labels activés : http://users.skynet.be/fb831016/Bug.wmv
-pas encore de confirmation du bug de desynchro dans ce mode MP



Avantages tres important du Host all unit activé au niveau gameplay :
-les bataillon et les chasseur semble 10x plus agressif qu'avec un host ayant le Host all units désactvé => ils n'hesite pas à tirer abondament sur vous (surtout les SAM, mais aussi les vehicule SAM de protection des bataillons HQ etc), c'est vraiment du pur bonheur de vivre enfin dans un environnement vraiment vraiment dangereux
-une meilleur fluiditée dans la gestion de tous les vehicules, de toutes les trajectoire de missile, etc parce que c'est le host qui controle absolument tout correctement, evidement ce host doit imperativement avoir un surpuissant CPU ainsi qu'un grosse bande passant en upload

Vous savez tout

PS : le code MP Host all units ne s'active que pour le host, donc celui qui lance la TE/campagne, peu importe si les clients ont eux aussi le host all units actif ou pas



Cheers,

BB

A la VEAF, nous n'utilisons plus que le code Host all units.

Récement, nous avons investis dans une collocation de server à 100Mbps/s, ce server est suffisament puissant pour hoster une campagne allégée

Caracteristiques du server :

CPU : Core 2 Duo E6850 @ 3.0GHz
RAM : 2048 Mb pc6400

Attention, il est impératif de faire tourner Falcon sur un seul core, sinon ca plante

Nous parvenons à réaliser des vols MP HvsH à plus de 20 joueurs avec une fluiditées pratiquement parfaitement

Cheers,

BB

Effectivement, c'est assez aride à première vue.

Cependant, c'est vraiment fort intéressant. Ca valait la peine de tout lire.

Ainsi, on comprend que ça vaut vraiment le coup d'investir dans un bon serveur, véloce, avec OF (qui ne tournera donc qu'en 2D) et d'activer le Host All Units pour le serveur.
Ainsi, c'est lui qui a la charge de gérer toutes les unités désagrégées, et cela permet d'éviter de buter éventuellement à un moment donné sur les limites individuelles des machines et connexions des joueurs, limitant drastiquement les incohérences en jeu multijoueur.

J'ai bon?

eutoposWildcat a écrit :Effectivement, c'est assez aride à première vue.

Cependant, c'est vraiment fort intéressant. Ca valait la peine de tout lire.

Ainsi, on comprend que ça vaut vraiment le coup d'investir dans un bon serveur, véloce, avec OF (qui ne tournera donc qu'en 2D) et d'activer le Host All Units pour le serveur.
Ainsi, c'est lui qui a la charge de gérer toutes les unités désagrégées, et cela permet d'éviter de buter éventuellement à un moment donné sur les limites individuelles des machines et connexions des joueurs, limitant drastiquement les incohérences en jeu multijoueur.

J'ai bon?

Tu as tout compris eutoposWildcat , seul le bug lié au server 2D peut etre un peu genant, pour les SAM tirant à plus de 15MN (voir la video)

Cheers,

BB

Hello BB, c'est quand même étrange car moi j'ai un CPU : Core 2 Duo E6850, et je ne plante jamais en MP et Solo .

Que ce soit en campagne, en TE, ou en dfg, jamais planté alors que je n'ai jamais passé OF sur un seul core, very strange... .

Pour le reste, merci pour les infos BB .

@+Markus

Markus a écrit :Hello BB, c'est quand même étrange car moi j'ai un CPU : Core 2 Duo E6850, et je ne plante jamais en MP et Solo .

Que ce soit en campagne, en TE, ou en dfg, jamais planté alors que je n'ai jamais passé OF sur un seul core, very strange... .

Pour le reste, merci pour les infos BB .

@+Markus

Salut Markus, je parlais plus specifiquement d'un server restant en 2D avec le patch Host all units activé

Cheers

BB

Merci BB pour tes explications.

Sans le savoir nous étions en "MP Host all units", mais avec tes explications, et surtout les qualités de cette option de connection à condition de laisser le serveur dans le monde 2D (ce que nous faisons aussi pour la dedibox), nous avons une meilleur garantie stabilité et réalité du simu.

Il m'arrive par moment d'avoir toujours une inversion de RWR par rapport à la position réèlle de l'appareil qui m'éclaire, une idée ??.

Exemple en dfg, je poursuis un appareil dans mes 12 sans pouvoir le padlocker et le voir, normal car il est dans mes 6, et c'est lui qui me poursuit (remarqué plusieurs fois avec Rouge notemment).

Merci BB .

@+Markus

Salut Gilles et Markus

On a remarqué ça chez nous aussi, lemême problème que décris Markus.

Une petite vidéo de 5.6Mo pour illustrer tout ça

http://users.edpnet.be/yoman/OF-RWR.rar

Merci de votre aide

Hyper intéressant !

Wildcat : on pourrait en faire un sticky avec un titre explicite, du genre : "gestion du multiplayer", non ?

J'y pensais oui, mais paradoxalement je crains qu'épingler le sujet tout de suite ne lui fasse perdre en visibilité.

Cela dit, je lui ai ajouté des chtites étoiles et un pouce ravi, déjà, pour qu'on le voie un peu plus, c'est déjà ça.

J'ai oublié de rajouter que le RWR reste cohérent quand il s'agit d'indiquer le côté de la menace: même en plein "bug" si on passe sur le dos la menace change de côté. donc de ce côté là ( si je puis dire) RAS

Ce que tu décris Eagle ressemble à une rémanence RWR. Elles ont été drastiquement réduites mais de temps en temps on en trouve encore. J'ai remarqué qu'elles interviennent principalement lorsque des appareils ou (missiles actifs) sont très proches de ton appareil et que tu manœuvres violemment.

Dès que la rémanence est détectée il te faut éteindre et rallumer le Rwr via le panel gauche et tout rentre dans l'ordre. Pas facile en dog, c'est d'alleurs pour ça que certain on mappé la commande sur leur hotas.

Très interressant tout ça.
Nous utilisons à la Force27 la dedibox en mode MP Host Units=> 0 probleme

Pensez vous qu'un jour nous pourrons lancer une serveur 2D sur un Windows 2003 qui n'a pas de carte son (genre serveur OVH) ? J'ai un C2D6600 2Go qui n'attends que ça

Non non Chips, ce n'est pas une rémanence... .
C'est bien pour ma part une alerte RWR placé dans mes 12 heures qui se déplace en fonction de la position de celui qui me poursuit.

Par exemple, lorsque celui qui me poursuit se place dans mes 7 heure, le spot RWR sera dans mes 1 heure, et si il se place dans mes 5 heure, le spot se place bien dans mes 11 heure.

Le spot RWR est donc bien associé à la position de celui qui me poursuit, et ne peut donc être assimilé à une rémanence qui aurait pour effet de rester figé sur mon RWR.

@+Markus

Je pense peut etre a une désyncro non?

Amraam.

Alors là Amraam, je ne sais pas comment le vérifier si tel est le cas... .
C'est sur une partie que j'hoste en dfg, avec juste un client (mon opposant).

En gros, moi je suis Tiger et lui Crimson, et on est que deux sur ma bp qui fait 128up/2048down en dfg.

@+Markus

Je suis loin d'etre spécialiste MP comme BB mais tu as combien en bandwith?

Amraam.

128 up, c'est ce que je règle dans mon RL.

@+Markus

Tu peux faire un test avec 256?

Amraam.

Markus a écrit :Merci BB pour tes explications.

Sans le savoir nous étions en "MP Host all units", mais avec tes explications, et surtout les qualités de cette option de connection à condition de laisser le serveur dans le monde 2D (ce que nous faisons aussi pour la dedibox), nous avons une meilleur garantie stabilité et réalité du simu.

Il m'arrive par moment d'avoir toujours une inversion de RWR par rapport à la position réèlle de l'appareil qui m'éclaire, une idée ??.

Exemple en dfg, je poursuis un appareil dans mes 12 sans pouvoir le padlocker et le voir, normal car il est dans mes 6, et c'est lui qui me poursuit (remarqué plusieurs fois avec Rouge notemment).

Merci BB .

@+Markus

Salut Markus, et par la meme occasion Eaglebow et Sparrow

Pour repondre à vos questions, nous avions aussi un server dedibox à la VEAF (meme deux server ) => malhereusement le probleme des dedibox est le manque de puissance du CPU justement, qui reste une limitation pour les partie MP chargées (campagne ou TE chargées) => de la peuvent venir certains lags comme les vecteurs vitesse sur le radar qui s'allongent tres fort, etc (=> et donc l'investissement dans un server avec CPU puissant)

Pour le RWR, c'est un bug de l'exe (rien à voir avec la BP) => pas de solution sans hex edit, mais comme l'a dit Chips, ce bug intervient lors d'evolutions serrées (dogfight)

Cheers,

BB

Oui mais là j'ai un 6600/2Go RAM qui n'attend qu' OF mais le souci c'est que ça marche pas sous 2003 (OS du serveur). J'ai tenté d'installer une VM en 2000Pro sur ce serveur et même problème ça marche pas non plus... c'est vraiment dommage :(

Chais bien que c'est la faute de personne, c'est comme ça c'est tout, mais si un jour une solution voit le jour, ce serait vraiment top

Et faire un serveur avec XP Pro ?

Et faire un serveur avec XP Pro ?

C'est pour cette raison que nous avons opté pour une colocation :

en fait, colocation veux dire que tu dois fournir le server au datacenter, nous avons donc investit dans un Barbonne Vintage avec windows XP Pro installé dessus, nous l'avons envoyer chez iWeb Technologies au Canada car c'est le seul datacenter que je connaisse qui accepte les server au format mini-tower (et pas rack 1U), en plus avec le dollars fort haut, la colocation reste raisonnable (l'equivalent de 60 euros par mois pour du 100Mbps)

Cheers,

BB

Sparrow a écrit :Oui mais là j'ai un 6600 qui n'attend qu' OF

bha toute maniere quad core ou pas, c'est pareil vu qu'il faut lancer l'exe sur un seul proc

A combien est la bandwidth de votre serveur dans la fenêtre COMMS / PHONE BOOK / Connection Bandwidth xxxx ??

A combien doit-elle être pour un serveur à 100MB/sec ?

@+Markus