Check-Six Forums

Euh , je suis surpris que personne n'ait remonté cette particularité.
Y-a-t-il une solution pour ne plus avoir ça ?

C'est dans le changelog (ça explique peut-être pourquoi personne ne l'a remonté)

06. Multiplayer fixes & improvements:
=====================================

— Special protection for MP servers / hosts to enforce MP stability: (r19825)
* Prevents any client entering 3D as long as the server is in 2D.
* Prevents to re-enter 3D world if already been in 3D. When you leave 3d you will be asked to reboot.
* Note: When committing, Host will be allowed to enter Ramp 1 minute before the first client's flight.
* Note: This is independent of his own flights TO time or ramp start setting.

aucune idée si c'est contournable ou pas...

C'est parce que BMS est instable si l'hôte entre entre en 3D après les clients, mais tu le savais déjà, puisque qu'il est question plus spécialement de taxi, n'est-ce pas ?

Si c'est de la manière qu'il est question, je ne la trouve pas très fine. Contrairement à ce qui semblait être pensé sur cette nouvelle fonction, on ne sait pas quand l'hôte est 3D en regardant juste la fenêtre Comms, il faut qu'il se signale activement. Il faut également passer à 64x manuellement. Accéder à la fenêtre take-off paraît plus pratique pour l'utilisateur. Pour le codeur ? Pas sûr.

C'est surtout le bordel quand l'hôte est prévu dans un vol qui part en dernier (exemple strike).
Du coup quand les pilotes des vols précédents arrivent cockpit, l'heure du rampstart est déjà bien entamée, et c'est le timing global du package qui part aux fraises, voir même l'ordre des départs........

De ce point de vue, la nouvelle fonction règle les problèmes. Elle ne change pas l'heure des take-off. Les flights qui ne sont pas dans l'ordre à l'appel de la tour sont un problème plus ancien.

au final c'est pour ne plus qu'on fasse du multi player avec falcon ? C'est juste super irritant.

C'est pour qu'on puisse faire du multilayer, justement.

ca fait plus de 20 ans que je fais du multi player sans ça ....
Bref on ne peut pas y échapper ?

Non.

Mais je ne comprends pas, ça fait plus de 20 ans que tu fais du multi sans que l'hôte entre en 3D d'abord, c'est ce que tu dis ? Dans ce cas, bienvenue dans le multi BMS stable (que ça te saute aux yeux ou non).

Sinon c'est que tu entrais le serveur manuellement en 3D avant les autres, ce qui était bien chiant dans bien des cas, et se trouve maintenant automatisé.

Le fait est que ça faisait "vingt" ans (en fait ... plutôt "dix") ... qu'on faisait du Falcon4 (avec Allied force) en pensant que ça marchait sans qu'il soit nécessaire d'avoir le host en 3D ...

Cette illusion était permise par le fait que AF (et les ancienne itérations de F4) soufraient de bug majeurs que personne n'avait véritablement identifiés, voir ne s'en était rendu compte pour beaucoup, voir carrément ... mit sur le compte de "la légendaire IADS" ... Cela est nécessaire depuis toujours et à toujours fait partie des consignes d’utilisations de BMS.

Il y juste que certains utilisateurs (par manque de connaissances ou plus simplement parce qu'ils sont persuadés, sûrement de bonne foi, de mieux savoir comme le soft fonctionne que ceux qui l'on codé) ne respectaient pas cette consignes et passaient beaucoup de temps à se plaindre incohérence, de CTD, d’échec de sessions MP ...

Du coup ... des mesures actives ont été prisent pour interdire ce genre de choses.
Depuis l'U1, le Host doit être initialisé AVANT tous les autres joueurs pour autoriser les jouteur à cliquer sur "FLY". Cette nécessité aboule n'est pas nouvelle. Mais elle est maintenant enforcé pour éviter d'avoir du monde qui se plaint de problèmes en MP et de bug car il ne respectaient pas cette contrainte/limitation. Tout comme celle de ne jamais commiter deux fois de suite en 3D sans relancer Falcon4. Maintenant, le problème est "réglé"par défaut.

Je ne vois aucunement où est le problème de ceci dans le mesure où, avant, cette règle était la mème ... cela ne change rien mis à part que le host, une fois en 3D à juste à envoyer un MSG en chat pour dire quand il est 3D effectif afin que les client sachent quand ils sont autorisé, ou, par Team Speak ou par IVC ... etc ... téléphone, Whatsapp ... signaux de fumé ...

Il faut simplement que les clients pensent à passer x64 avant de cliquer Takeoff (que l'on ne peut malheureusement pas forcer automatiquement dans l'UI au niveau code) C'est tout ce que ça change => Passer x64 avant de commiter.

Ozone a écrit : ↑

ven. janv. 10, 2020 1:49 pm

C'est surtout le bordel quand l'hôte est prévu dans un vol qui part en dernier (exemple strike).
Du coup quand les pilotes des vols précédents arrivent cockpit, l'heure du rampstart est déjà bien entamée, et c'est le timing global du package qui part aux fraises, voir même l'ordre des départs........

Absolument pas.

Meme si son vol est en dernier, le host rentrera systématiquement 1 minute avant l'heure de rentrée du premier vol du client.

je cite le changelog
Celà ne perturbe donc aucunement l'heure de rentrée des clients.

Mad Fly a écrit : ↑

ven. janv. 10, 2020 10:56 pm

au final c'est pour ne plus qu'on fasse du multi player avec falcon ? C'est juste super irritant.

Une des raisons principale de l'instabilité en MP était l'incapacité des utilisateurs à respecter une règle simple : mettre le host en 3D avant le clients.

Il faut reconnaitre que ceci était par le passé "pénible" , car il fallait que le host soit dans le premier vol, ce qui n'est pas toujours celui que voulait le host.

Donc je résume:

Il y a des mecs qui passent des centaines d'heures pour que les utilisateurs aient la garantie qu'il n'y a pas un abruti qui commite avant le host et foute en l'air la session , qui s'assurent que le host puisse rentrer 3D indépendemment de son heure de décollage pour que ca soit transparent pour l'utilisateur...

Au final on a droit à :

1) comment on le contourne ?
2) BMS cherche à tuer le MP !

Je n-ai pas de mots pour dire ce que je ressens quand je lis ca !

Tu es le cancer de la communauté Falcon4 ... tu le sais bien, MorteSil te l'as déjà dit.



EDIT: C'est quand même fou hein. Les après-midi, soirs ... les nuits jusqu’à deux, trois heure du mat à se lever quatre heures plus tard pour aller bosser ... et puis ce genre de choses. C'est comme ça mon gars. C'est comme ça.

Je note donc que ça corrige un bug qui ne m'a jamais perturbé sous bms...

Salut Mad Fly.

Mad Fly a écrit : ↑

sam. janv. 11, 2020 2:23 am

Je note donc que ça corrige un bug qui ne m'a jamais perturbé sous bms...

Un ... non. Des bugs.
En fait, ça ne les corrige pas, ça les empêche de pouvoir se produire.

Cooy that
La procédure de connexion est dans la doc révisée avec la nouvelle version ?

Il n'a pas de doc révisée avec U1. La procédure est toujours la même, c'est BMS qui se débrouille pour que les utilisateurs entrent en 3D dans le bon ordre.

Il n'y a pas de doc révisé. Tous le monde n'a pas désiré ou n'a pas pu "faire ses devoirs" avant le release. Sinon, vous l’attendriez encore cet U1. Ce sera pareil avec l'U2 je pense ...

Il faudra que la communauté prenne sa part de boulo sur ce coup là. (ce que fait déjà Lorik entre autres ... ) Et il me semble bien que l'info fait parti du change-log que Kolbé a eut l'amabilité de mettre en forme de manière compréhensible pour la majorité des utilisateurs non développeurs.
...

Pré-Edit:

Confirmé: https://www.benchmarksims.org/forum/sho ... -Installer

06. Multiplayer fixes & improvements:
=====================================

— Special protection for MP servers / hosts to enforce MP stability: (r19825)
* Prevents any client entering 3D as long as the server is in 2D.
* Prevents to re-enter 3D world if already been in 3D. When you leave 3d you will be asked to reboot.
* Note: When committing, Host will be allowed to enter Ramp 1 minute before the first client's flight.
* Note: This is independent of his own flights TO time or ramp start setting.
— Allow Carrier moving in MP. (r20568)
— Make sure the AI does not set the pilot as ejected when player is leaving. (r20571)
— Fixed the throttle bug when leaving / re-entering 3d. (r20571)
— Fixed the KIA status for AI on ground after leaving. (r20571)
— Fixed AA TACAN not working if reconnecting in MP. (r19835)
— Allow local DOF computed changes for MP remote aircraft entities (on client). (r19837)
— Re-enabled AI pilot head random animations for MP remote entities. (r19837)
— Fixed AI pilot visor for MP remote entities. (r19837)
— Fixed parked AI F-16 vertical stabs for MP remote entities. (r19837)
— Nozzle and AB MP remote animations. (r19837)
— Fix helicopter position on carrier deck on client's side. (r20568)
— Fix for Client taking control of battalion even if not allowed by the host (B3 flag On). (r20572)

...

Post-Edit: Grillé par Lorik.

Le mode ramp est mentionné, celà implique-t-il une différence pour le mode taxi ?

... non. C'est pareil pour tout il me semble (facile à vérifier in-game).

DeeJay a écrit : ↑

sam. janv. 11, 2020 1:07 am

Cela est nécessaire depuis toujours et à toujours fait partie des consignes d’utilisations de BMS.

Je ne vois aucunement où est le problème de ceci dans le mesure où, avant, cette règle était la mème ... cela ne change rien mis à part que le host, une fois en 3D à juste à envoyer un MSG en chat pour dire quand il est 3D effectif afin que les client sachent quand ils sont autorisé, ou, par Team Speak ou par IVC ... etc ... téléphone, Whatsapp ... signaux de fumé ...

Je suis dans la même situation que Mad : étonné.
Je n'ai jamais entendu parler d'une telle règle, que ce soit dans les manuels (j'ai sans doute passé ce paragraphe?) ni dans les forums.
D'ailleurs, il existe des topics préconisant des méthodes pour éviter les beugs : le topic de Wild indique bien qu'il ne faut pas ré-entrer en 3D par exemple (http://www.checksix-forums.com/viewtopi ... 1&t=204652), mais aucun post (sticky ou non) pour ce problème. Je n'ai rien vu non plus dans le forum bms concernant les best practice.
J'étais d'ailleurs pas loin de penser qu'il s'agissait presque d'une "légende urbaine" (pas en dogfight, mais en tout cas, pour une TE et une campagne).
Je m'étonne d'apprendre que tous les falconeux et toutes les escadrilles procédaient déjà de cette façon (une confirmation serait bienvenue )
Si vous avez des liens, des sources, des études, des méta-analyses, je serais le premier preneur.

DeeJay a écrit : ↑

sam. janv. 11, 2020 1:07 am

Maintenant, le problème est "réglé"par défaut.

Personnellement, je trouve que c'est limitant effectivement. Même s'il y a des abrutis (ce sont tes mots) qui n'ont jamais entendu parler de ce problème (et je me demande dans quelle mesure ils en sont coupables) ou qui s'en foutent (ça, c'est leur soucis), on devrait pouvoir, comme tu le préconises : être prévenu, biensûr! Mais pas obligé, à mon sens.

mav-jp a écrit : ↑

sam. janv. 11, 2020 1:58 am

Même si son vol est en dernier, le host rentrera systématiquement 1 minute avant l'heure de rentrée du premier vol du client.

Ce qui explique que si je définis l'heure de taxi-time dans Falcon_CFG.conf à 6min plutôt que les 4 par défaut, et que je vole en solo, je rentre à -7min alors ?

C'est de multiplayer qu'il s'agit. S'il est clair et établi qu'un host en 3D en retard cause des problèmes, je préfère que l'host à qui j'ai affaire n'ait pas le choix, ça m'évite d'argumenter des heures ou de laisser tomber et de savoir qu'en coulisses, BMS foire.

BMS Manual, p7-82. Le tort est de présenter ça comme une procédure pour les sessions de longue durée ou à grand nombre. Perso, que BMS foire à 2 ou à 15, ça m'embête autant.

https://www.benchmarksims.org/forum/sho ... ayer-Setup
En solo: comme tu as pu le vérifier en essayant directement, c'est ça. Solo time = Host time = +1 minute.

PS: pour mémoire concernant "l'host à qui j'ai affaire", j'ai quand même eu affaire à des hosts, qui n'étaient pas des abrutis, mais qui avaient trop la flemme d'enlever les hélicoptères dans 34.0. Inutile de dire qu'après 5 ou 6 CTD hélicos dans diverses circonstances, j'ai laissé ces gens de côté, les soirées sont assez précieuses comme ça.

J'étais tombé sur ce topic sur les forums BMS effectivement, mais la phrase m'avait échappé, my bad.
Merci Lorik pour les précisions

Salut Fullnegi.

Fullnegi a écrit : ↑

sam. janv. 11, 2020 11:29 am

Personnellement, je trouve que c'est limitant effectivement.

Explique-moi en quoi c'est "limitant" s.t.p. (?)

Fullnegi a écrit : ↑

sam. janv. 11, 2020 11:29 am

Même s'il y a des abrutis (ce sont tes mots)

... non, ce ne sont pas mes mots Fullnegi.
Jp parle essentiellement de chez F.O. qui le savaient bien car ont leur a dit des dizaines de fois ... sinon bien plus. Mais ils continuaient à n'en faire qu'a leur tête et reportaient les bugs ensuite en se plaignant de problème de stabilité chronique.

DeeJay a écrit : ↑

sam. janv. 11, 2020 11:48 am

... non, ce ne sont pas mes mots Fullnegi. Jp parle surtout de chez FO qui le savant bien car ont leur a dit des dizaines de fois sinon plus. Mais il continuait a n'en faire qu'a leur tête et reportait les bugs ensuite en se plaignant de problème de stabilité chronique.

Pardon, c'était ses mots, pas les tiens, autant pour moi.
Chez FO ? Malgré que vous leur avez dis des dizaines des fois, je n'étais jamais remonté sur cette info. Ma réaction est surtout celle de la surprise, comprenez-moi.
En échange, je tente de comprendre les Devs qui reçoivent des bugs reports sans arrêt pour un problème qu'ils ne connaissent que trop bien visiblement.

Donc si j'ai compris la procédure :
1:
Pour le concepteur : le premier et le dernier vol humain doivent être espacé d'un maximum de 1min concernant l'heure de TO(si l'host est dans le dernier vol), sinon le host doit être dans le premier vol.
Une fois que tout le monde est OK, l'host fait taxi/ramp et tout le monde se met en 64x.
L'host rentra automatiquement 1min avant son heure de taxi/ramp supposée.
Une fois ceci fait, tout le monde peut faire take-off taxi/ramp.
2:
Disposer d'un serveur dédié qui fait tourner le jeu en 3D.