BF3 - Meckerthread, was euch derzeit daran nervt.

[The Toxicity 18]

Oh jemand ist besser als Burner? Lieber mal reporten.

ooh biste immer noch eingemukkelt?

hier kleiner, kauf dir nen lutscher. mitm lutschen kenste dich ja aus

such dir einen Job, rauch weniger Pot, vl steigt dein spm ja dann über 150.

[Recki 663]

Geht das wieder los?

Lasst den Blödsinn und benehmt euch.

[sid6.5 319]

Geht das wieder los?

Lasst den Blödsinn und benehmt euch.

+1

Das muss doch nicht sein, oder?

[Burner 1635]

Geht das wieder los?

Lasst den Blödsinn und benehmt euch.

joa wie wärs, wenn ihr mal die verwarnen würdet die anfangen?

[PFLO 167]

Nein, ich verwarne jetzt mal den, der immer zu beleidigen beginnt. Und in PMs dann weitermachen, nur weil du genau weißt, dass du dafür im Forum eine Sperre bekommst, kannst du dir auch sparen.

2 Tage Sendepause für dich!

[Hero-of-War 46]

266h spielzeuit, 930 spm, 42k kills. seems legit

Mal die Awards angeschaut? Über 700 Runden TDM. In TDM machst du halt pro Minute 2-5 Kills, und hast eine Respawnzeit von 4(?) statt 15 sekunden.. Davon mal ab hat er ja auch etwa 20k Tode..

Wobei 930 SPM schon ziemlich ordentlich sind, selbst für TDM

Aber a) noch im Bereich des Möglichen und b) sonst nicht auffällig

Bearbeitet 12. Mai 2012 von Hero-of-War

[eisvogel10 11]

was mich nervt...nicht vorhandenes teamplay...so mies war es noch bei keinem battlefieldteil.

wie du siehst ist es nicht so wichtig wenn man auf "...nicht vorhandenes teamplay..." hinweisst, geht keiner drauf ein weil alle die Stats im Kopf haben

[c4m3l 128]

was mich nervt...nicht vorhandenes teamplay...so mies war es noch bei keinem battlefieldteil.

wie du siehst ist es nicht so wichtig wenn man auf "...nicht vorhandenes teamplay..." hinweisst, geht keiner drauf ein weil alle die Stats im Kopf haben

Wir spielen eigentlich immer mind. zu viert, kenne das Problem nicht!

[panzerfahrer 272]

was mich nervt...nicht vorhandenes teamplay...so mies war es noch bei keinem battlefieldteil.

wie du siehst ist es nicht so wichtig wenn man auf "...nicht vorhandenes teamplay..." hinweisst, geht keiner drauf ein weil alle die Stats im Kopf haben

Wir spielen eigentlich immer mind. zu viert, kenne das Problem nicht!

Jupp, wenn man mit ein paar Leuten (mit TS) in einem Squad spielt, geht es wirklich gut und meistens zieht dann auch das gesamte Team mit. Imho ist es wirklich serverabhängig. Manchmal klappt auch ohne viel Kommunikation das Teamplay wirklich gut, machmal ist es eine Katastrophe.

Aber: Ein Punkt, den man auch Bf2 anlasten könnte. Damals war auch nicht immer alles rosig.

Bearbeitet 12. Mai 2012 von panzerfahrer

[pnshr 1433]

was mich nervt...nicht vorhandenes teamplay...so mies war es noch bei keinem battlefieldteil.

wie du siehst ist es nicht so wichtig wenn man auf "...nicht vorhandenes teamplay..." hinweisst, geht keiner drauf ein weil alle die Stats im Kopf haben

Wir spielen eigentlich immer mind. zu viert, kenne das Problem nicht!

Jupp, wenn man mit ein paar Leuten (mit TS) in einem Squad spielt, geht es wirklich gut und meistens zieht dann auch das gesamte Team mit. Imho ist es wirklich serverabhängig. Manchmal klappt auch ohne viel Kommunikation das Teamplay wirklich gut, machmal ist es eine Katastrophe.

Aber: Ein Punkt, den man auch Bf2 anlasten könnte. Damals war auch nicht immer alles rosig.

auf jeden fall.

als wäre auf jedem bf2/bf42 public immer tollstes teamplay

[Angstman 1394]

http://battlelog.battlefield.com/bf3/user/DoctorMcGunner/

meine erster cheater bei bf3.

bitte mal reporten, der hat mein team die ganze runde über ständig aus den helis/jets geschossen, während er am andern ende der map kreise geflogen ist...

[Ale42er 19]

auf jeden fall.

als wäre auf jedem bf2/bf42 public immer tollstes teamplay

das brauch man nicht unbedingt.

man brauch nur eine handvoll leute die auf den commander hören.

[BigKahuna 0]

DIE HITBOX

moinmoin,

ihr habt ja die letzten paar seiten über die hitbox in bf3 disskutiert... ich würd da auch gerne meine 3 cents zu geben

viele von euch wundern sich wie die hitbox so random sein kann... naja im grunde ist sie überhaupt nicht "random" sondern die hitbox leidet unter der komplexität von bf3 und naja...seines programmkonzeptes

(klarstellung: ich hab nicht wirklich rausfinden können wie die hitbox TATSÄCHLICH funktioniert... ich hab aber auch keine lust immer ich glaube... es kann sein... etcetc zu schreiben... also alles was ich schreibe ist reine vermutung und schätzung^^)

grundlegendes...

wie funktioniert bf3 netzwerktechnisch?

bf3 ist ein host-client spiel.

das bedeuted, dass der (server)host und der (spieler)client ständig daten austauschen müssen.

der client (also dein monitor^^) "rendert" das spiel für dich. alle daten die der client zu einem bestimmten zeitpunkt angesammelt hat, bestimmen die situation auf deinem monitor.

das dumme an mp spielen ist, dass man nicht allein ist. dein client hat keine ahnung was die anderen clients machen, ein client sendet die informationen seiner spielfigur zum host (positionen, aktionen)

der host wiederum sammelt alle daten aller clients und sendet diese gesammelten datenpakete widerum an alle clients und der client rendert daraus das spielt.

daraus ergibt sich eine natürliche verzögerung die uns unter ping, latenz oder lag bekannt ist.

auch wenn heutige datenverarbeitung technik sehr weit fortgeschritten ist und daten mit unglaublicher geschwindigkeit versendet werden können, kann unser gehirn diese kleinen unterschiede erkennen.

ein "LIVE" oder "ECHTZEIT" spiel ist somit unmöglich.

man stelle sich vor man würde ein spiel in echtzeit spielen.

spieler A beobachtet spieler B

spieler B bewget sich mit einer konstanten geschwindigkeit

was sieht spieler A?

im reallife würden wir eine fliesende und konstante bewegung von "mensch" B sehen können. denn die informationen im reallife werden bekannterweise in lichtgeschwindigkleit übertragen, unsere "technische limitierung" (sichtweite, wahrnehmbare bilder pro sekunde) sorgt dafür das die informationen schneller übertragen werden als wir sie verarbeiten können ERGO wir sehen eine fliesende bewegung

aber was passiert im spiel?

nun, gehen wir davn aus dass beide spieler stehen.

der client von A hat die information der position von spieler B

nun fängt spieler B an loszulaufen. der client von spieler B sendet seine position an den host, der host sendet diese information an den client von A, A erhählt diese neue information und rendert sie auf den monitor -> wir sehen die aktualisierte position von B

da das senden und rendern von information zeit benötigt und zwar soviel zeit dass die information langsamer verarbeitet wird als wir sie verarbeiten können, hat das zwei wichtige konsequenzen.

1. spieler A sieht spieler B nicht in einer fließenden bewegung, sondern einer sprungbewegung (als ob er sich zwischen zwei punkten teleportieren würde)

2. spieler A sieht nicht die aktuelle position von spieler B sondern eine die in der vergangenheit liegt (spieler B hat sich in wirklichkeit ja schon weiter bewegt, die info ist aber noch auf den dem weg)

das ist ein grundlegendes problem, was wir in naher zukunft nicht gelöst bekommen...

aber was kann man dagegen tun?

zum einen könnte das spiel die framerate limitieren. z.b. auf 15 fps. somit wird nur alle 1/15 sek ein bild gerendert und der host/client hat genügend zeit um alle informationen zu verarbeiten. man sieht also immer das "echtzeitgeschehen"

problem: niemand will games mit 15 fps zocken -.-

zum anderen kann der client daten/informationen interpolieren. d.h. er "simuliert" informationen der anderen clients. solange man keine aktualiesiierten infos vom host bekommen hat. die trannsferrate von datenpaketen zwischen host und clients liegt ungefähr bei 10-30 ms. in der zeit zwischen dieser aktualisierung, schmeisst das spiel die wahrsagerkugel an.

beispiel

nehmen wir pong als beispiel.

die bewegung des balles folgt einem bestimmten algorithmus. also ist die "zukünftige"-positions-bestimmung" kein problem.

der spieler kann sich nur in zwei richtungen bewegen. sobald sich spieler B bewegt, nimmt der client von A an er würde sich immer weiter bewegen bis er vom host die info bekommt dass spieler B gestoppt hat.

die bewegung von B kann also fließend dargestellt werden. (nur beim stoppen und "losfahren" von B gibt es einen kleinen fehler, ein "springen" von B)

nun stellt euch mal eine BF partie vor^^

- 64 spieler, fahrzeuge, trümmmer, projektile etc etc... viel info die interpoliert werden muss

es kommt zu massiven fehlberechnungen.

daher viel stockt, ruckelt und befehle (wie tastatur eingaben und ihre resultierenden aktionen) werden nicht richtig ausgeführt.

(spieler befinden sich im grunde nicht an den positionen die der client vorberechnet hat)

dies gilt im übrigen nicht nur für andere clients sondern auch für den eigenen. meine eigene position, wird also im grunde nicht von mir bestimmt sondern vom host. denn der host ist derjenige der alle positionen aller objekte bestimmt. wenn ich mich bewege sende ich diese information zum server, und der server aktualisiert meine position und sendet diese info an alle clients.

WIE??? werdet ihr euch fragen... mein client kann ja wohl meine eigene position schnell genug erfassen!!! ich lagge ja nicht auf meinen eigenen client!!! WTF?! hör auf scheiße zu erzählen!

naja^^ man muss sich dies so vorstellen:

wenn ich mich bewege, geschieht dies auf meinen client natürlich in "echtzeit". AAAABER. die position die auf meinen client in echtzeit berechnet wird, ist im grunde vollkommen irrelevant. denn da andere clients meine eigene position vom host bekommen und diese vom host stammende position für alle berechnungen genutzt wird, ist diese VOM HOST STAMMENDE POSITION der motherload. the one and only. ergo: kommt es auch zu dieser "zeitverschiebung" beim berechnen der eigenen position.

man merkt schon jetzt dass es mit der hitbox nicht so genau zugehen kann

aber wie funktioniert die hit-detection?

grundlegendes... (dabei ist egal ob es darum geht ob eine kugel einen spieler trifft oder ein spieler gegen eine wand rennt)

hit detection sieht meist so aus... wir haben einen dreidimensionalen raum (also eine anhäufung von X- Y- und Z-koordinaten)

jedes objekt hat eine dreidimensionale hitbox. ein objekt das in die hitbox eines anderen objektes gerät löst ein ereignis aus. (z.b. einen treffer, oder eine mechanik die verhindert das wir durch wände laufen)

das bedeuted bei einem spieler-wand beispiel, dass der spieler ständigt seine position mit der der wand abgleicht um zu checken ob eine kollision stattfindet.

bei einem spieler-kugel beispiel sieht dies dann so aus, dass die kugel ständig seine position mit allen andern objekten abgleicht um zu checken ob die eine kollision verursacht hat. (ich möchte jetzt nicht allzusehr in destail gehen... aber jeder der sich n bissle mit programierung auskennt weiß wie unglaubölich rechen intensiv dies sein kann^^)

bei counterstrike oder quake oder anderen shootern, ist dies zwar auch ein problem, aber bei langem nicht so ein großes wie bei BF.

1. BF ist GROSS. bei cs oder quake sind die maps relativ klein. eine objekt wird keine lange dauer bererechnet werden müssen, denn sie wird meist innerhalb von sekundenbruchteilen irgendetwas treffen (spieler wände etc) und die berechnung endet.

bei bf allerding, haben wir weite maps mit vielen freien schußbahnen, so dass oft die gesamte lebenszeit einer kugel berechnet werden muss (in bf lösen sich kugeln nach einer gewissen zeit auf)

2. BF berechnet JEDE kugel EINZELN. während (ich glaub bei quake war das der fall) viele projektile zu einem objekt zusammen gefasst werden. wird in BF wird jede kugel einzeln berechnet was den rechenaufwand enorm erhöht. dass bring uns auch zum nächsten problem:

3. 64 gewehre mit einer durschnittlichen feuerrate von 600-700 rpm. die schire anzahl von möglichen abgefeuerten kugel ist enorm. eine waffe schießt durchschnittlich bis zu 10 kugeln die sekunde...

4. die geschwindigkeit der abgefeuerten kugeln. je schneller ein objekt sich bewegt desto größer die auswirkungen eines "lags" also der fehlerquote von eigentlicher position und vom client (vor)berechneter position

5. durch die resultierende komplexität der hit detection, wird diese CLIENT-seitig ausgeführt.

es gibt natürlich noch weitere pürobleme... aber ....i think u can see my point^^

conclusion.

etwas komplexeres beispiel, wenn man mal die ganzen informationen zusammen nimmt:

ich laufe auf ner map rum.

ich laufe im vollem sprint zu einer niedrigen wand und möchte rübersteigen und drücke "space", da der client aber einige millisekunden "zurückhängt" befindet sich mein spieler nicht wirklich exakt an der wand und deshalb kommt es zu fehlberechnungen und die animation "über wie wand steigen" kann nicht ausgeführt werden (ja daher rührt dieser bug^^)

ich dürcke also nochmal space, just in diesem moment sieht mich ein gegner (ich stehe vor der wand da die sprunganimation noch nicht ausgeführt wurde) und beschießt mich, meine "sprunganimation" wird nun endlich ausgeführt und mein client erhählt das datenpaker "dein-arsch-ist-unter-beschuß". die ersten drei kugeln die mich eigentlich hätten treffen müssen, gehen in die wand, da ich beim abschuß dieser kugeln für den gegnerischen client noch hinter der wand stand. die anderen kugel gehen (dank spread) daneben. ich gerate in panik...

renne ein wenig durch die gegend

da schießt der gegner seine zweite savle ab.

(sein client sendet diese info an den host, und startet die hit-detecion mit meiner position die er als letztes vom host erhalten hat )

ich entscheide mich wieder zurück über die wand in deckung zu hechten. ich springe also über die wand

(mein client sendet diese info an der server)

meine sprunganimation startet, und ich ducke mich hinter die deckung

(in diesem moment erhält mein client die info dass der gegner auf mich geschossen hat, und teilt mir mit das ermich 7 mal getroffen hat)

ich liege also hinter der deckung, ein treffersymbol erscheint und ich bin instant DEAD.

vielleicht wird es jetzt ein wenig klarer, warum man getroffen wird obwohl man schon in deckung/sicherheit geflüchtet ist.

oder warum man (fälschlicherweise) "geonehitted" wird.

die berechnungen bzw die hitbox kommt einfach nicht unseren 30-60fps hinterher.

man kann dieses problem eindämmen indem man komprommisse zwischen flüssigem spielen und hostabfrage eingeht oder andere programm technische kniffe vornimmt. aber dice hat sich halt so entschieden wie sie sich entschieden haben.

naja... hoffe mein text interresiert überhaupt jemanden^^

und wie gesagt... ich habe nicht rausfinden können wie das spiel TATSÄCHLICH funktioniert... das sind annahmen die ich aus informationstückelchen zusammen tragen konnte und die ich mit meinen eigenen programmier/netzwerk kenntnissen verbunden und meinen eigenen erfahrungen aus battlefield in relation gesetzt habe...

p.s.

nach dem ganzen tippen hab ich keinen bock mehr den text auf fehler zu prüfen, also verzeit mir die geschätzten 3.000.000.000 rechtschreib und grammatig fehler

[panzerfahrer 272]

- großes Kino

[Underdog 4347]

- großes Kino

">