mpc oder die große ernüchterung

hi flieger,

etwas grundsätzliches und sehr ernüchterndes zum multiplayercode in f4. diese anleitung wurde von c3po aus verschiedenen boards zusammengetragen.

1. der host muss in der lage sein 33.6 kbps pro client zu hosten. d.h., bei einer bandbreite von 112 kb(dsl) können nur drei clients mitspielen. weit gefehlt, denn das ist der download und bei den 33.6 ist der upload gemeint. ich glaube, wir alle sind hier immer von der falschen voraussetzung ausgegangen. die von den anbietern angegebenen werte sind sowieso theoretisch und deshalb prüft einmal hier eure tatsächlichen werte.

tasächliche bandbreite ermitteln.
verbindungscheck

den upload durch 33.6 teilen und schon wißt ihr genau, was eure verbindung kann, bzw. was sie nicht kann.
meine leitung gab heute 12.49 kbps upload her. ein ernüchterndes ergebnis, denn ich wäre nicht einmal in der lage nur einen einzigen client zu hosten. das verringern der bandbreite ist ausgeschlossen, denn 33.6kbps ist das minimum, was in f4 einen korrekten datenfluß gewährleistet. leider sind wir immer vom download ausgegangen und haben uns gewundert, warum bei einer vermeintlich dicken leitung warpen und ähnliches ungemach zustande kommt.

2. jetzt kommt ein ganz wichtiger part. alle falconspieler geben in ihre befehlszeile ihre bandbreite ein. das sieht dann so aus:
e:\bms2\F4-BMS.exe -bandwidth 12
damit wird verhindert, dass der datenfluß übersteuert wird, also der client mehr angeboten bekommt, als er vertragen kann. d.h., selbst wenn wir im spiel auf 33.6 gehen, wird dem host signalisiert, "geht nicht, ich kann nur 12kbps" dann werden die daten mit der geschwindigkeit gesendet, dass es wieder paßt. ist stark vereinfacht ausgedrückt und ein trick, damit wir falcon auch mit einer dünnen leitung noch spielen können. 100% laufen aber nur mit 33.6kbps pro client.

3. weiter ist sicherzustellen, dass ALLE die gleiche configuration haben. d.h. im einzelnen: alle bäume an oder aus. wird mit staffelfilter erledigt.

4. wenn der host das spiel eröffnet hat und alle clients ins spiel gekommen sind, muss im planungsschirm die missions uhr überprüft werden, ob alle synchron "laufen". eine sekunde unterschied macht nichts.

5. das ernüchternste bei dieser geschichte ist, dass ein normaler dsl nutzer nur einen client hosten kann und das schon nicht mehr 100%.

6. es dürfen absolut keine alten te, cp aus vorgängerversionen genutzt werden. dass alle das gleiche theater eingestellt haben müssen, versteht sich glaube von selbst.

tja leute, das ist ein ganz schöner schlag ins kontor. aber wir lassen den mut nicht sinken und hoffen, dass ein test mit einer exakten persönlichen bandbreiteneinstellung trotzdem ein gutes ergebnis liefert. ich verpreche mir jedenfalls einiges davon und mich wundert nach diesem artikel nicht mehr, dass einige von uns immer so große probleme haben, weil sie ihre leitung falsch eingeschätzt haben und sie regelmäßig vom host überfahren bzw. überfordert wurde.

es ging eigentlich nie richtig. erinnere dich an das gewarpe z.b. im dogfight oder in der cp und was wirklich in falcon passierte, blieb im verborgenen. ich könnte jetzt eine ewig lange liste aufführen. stellvertretend für alle probs greife ich eines heraus. wie oft war einfach kein ziel an der stelle, wo es hätte sein müssen.
wir sind auch unter ibeta mit bis zu 8 piloten geflogen, aber eben nicht 100%ig. in der abhandlung steht ja nicht, dass man nicht mit 10 piloiten online fliegen kann, es steht nur drin, warum wichtige daten verloren gehen und warum z.b. ein jet manchmal bei einem mit und beim anderen ohne fahrwerk dahinrollt, usw. usf.. die daten, dass das gear draußen ist, wurden einfach nicht an alle richtig übertragen, weil sie die falsche bandbreite hatten, so einfach ist die erklärung. mit der persönlichen einstellung könnte diese fehlerrate u.u. unterdrückt werden, weil der client nicht von vornherein "überfahren" wird. also laßt uns nicht von gestern reden, wo angeblich alles richtig lief, das tat es nämlich nicht, sondern mit der exakten bandeinstellung testen, denn dann sind wir schlauer. vielleicht bringt es ja was.

Zitat

Original von Intruder
Hi Nik

das wenn einer ne bescheidene Anbindung hat, den Rest mit runterzieht. ... wenn einer die z.b. max. Strecke zum nächsten Knotenpunkt hat. Wenn einer mit nem Stau anfängt, ist es vorbei, dann klappt nix mehr.

Dann fallen die Leute erst, etwa 5 min nachdem man sie erschossen hatte.

Gruß Intruder

Alles anzeigen

genau intruder, das war uns auch schon vorher bekannt, nur wir wollten es nie so richtig akzeptieren.
wenn wir aber jetzt unsere tatsächlichen einstellungen vorwählen und nicht mit phantasieübertragunsraten prahlen, 3000kbps download usw., dann kommt der stau erst gar nicht zu stande.
ein defektes kabel ist etwas anderes als eine schwache leitung, durch die nur eine bestimmte datenmenge geht. ich sagte es schon einmal, laßt es uns testen, denn so haben wir die ganze sache noch nie betrachtet.

Zitat

Original von Viper

Moin Nik

schmeisst ihr da vielleich kbit und kByte durcheinander ?

hab grad den test gemacht und habe einen upstream von 13.26 kByte/s = 106.08 kbit/s

die 106.08 sind die relevante Zahl mit der ich dann 3 Clients hosten könnte (3*33.6kbit/s = 100.8 kbit/s)

Alles anzeigen

hast recht viper,

habe nocheinmal nachgelesen und siehe da, es wurden bit und byte gemischt. nichts desto trotz, die ernüchterung bleibt. außerdem ist die persönliche einstellung u.u. das entscheidende kriterium, damit der host den client nicht überfährt. deshalb sollte jeder die leistungsfähigkeit seiner leitung prüfen und den falken mit der richtigen bandbreite configurieren. schlechter kann es dadurch nicht werden.

hi flieger,

in meinem posting ist ein gravierender fehler enthalten. neo hat mich darauf hingewiesen und er hat recht. die bandwidth einstellung darf nur der host vornehmen. die clients stellen in falcon comms immer auf 33,6 kb/s. desweiteren muss der host seine bandwidth exakt auf die anzahl der clients einstellen.

wer hostet kann sich die bandwidth einstellung aus einer tabelle holen, die hier zu finden ist