[hammergut]

Zitat von Xeno

Ich glaube hier verwechseln einige das Beheben von Fehlern an der Simulation mit Verbesserungen des Netcodes. Das was jetzt in den Beta Patches zu sehen ist hat nichts mit dem Netcode zu tun, lediglich die Simulation und das was auf dem Bildschirm zu sehen ist sind wesentlich verbessert worden (ansonsten könnte man nicht mit den aktuellen Beta Clients auf dem normalen 1.59 Server connecten).

Xeno

laut dem changelog und aussagen von jungs die addons bauen, ja ich kenne da welche haben die was am netcode geändert. u.a. wurden dinge (kenne mich zuwenig mit netcode aus, wiederhole nur was die gesagt haben) geändert die das handling wesentlich vereinfachen, und zudem schreiben die grad das addon um um diese verbesserungen drin zu haben.

zum changelog:
[84374] Optimized: MP: Reduced bandwidth used by standing AI soldiers. [84271] Fixed: MP: Reduced bandwith usage in missions with many soldiers.

aber vielleicht kannst du mir erklären wieseo das nichts mit änderungen des netcodes
zu tun hat. eine darstellung kanns ja nicht sein. und ja man kann auf 1.59 server connecten
aber alle funktionen haste halt nur wenn auch der server auf beta läuft.

@inno:

was soll beta spielen mit verblödung zu tun haben. du hast den sinn einer beta nicht
kapiert.
aber ich fange schon wieder an trolle zu füttern, deshalb werde ich dich bis arma3
released wurde erstmal ignorieren.
geh leintücher aufhängen für den windschutz in der aufnahme

[Lester]

Zitat von INNOCENT&CLUELESS

Ich glaube das PhysX in einer Engine nicht genutzt werden sollte, jedenfalls nicht optional nach verfügbarer Rechenpower am Client. Oder wenn, dann nur für Effekte, die absolut keinerlei weitere physikalische Auswirkungen auf andere Objekte haben sollen.

Ansonsten würde ja bei unterschiedlicher Client-HW (abgesehen vom Zufallsfaktoren) gravierend andere Ergebnisse entstehen aus denen sich Vor- oder Nachteile ergeben.

Beispiel: Trümmerverteilung könnte statistisch unterschiedlich sein mit und ohne HW-PhysX Unterstützung und damit mögliche Deckung.

Diese Betrachtung ist übrigens falsch, denn man kann es relativ einfach lösen.

Bis dato ist es so das zumindest Treffer bei der KI (möglicherweise auch von den Spielern) vom Server ausgewertet werden.
Der Server bestimmt dann wie die Einheit umfallen soll (Zufallsauswahl der Todesanim) und teilt das den Clients mit.
Sagen wir mal es sieht so aus: [objekt,"animname"]

Mit PhysX würden dann einfach vereinfacht ausgedrückt die Kernelemente nebst Parameter wie Stärke und die genaue Position mitgeteilt werden a la [objekt,"parameterstring"]

Wo da jetzt der problematische Unterschied sein soll kann ich nicht nachvollziehen.

Zumal egal ob mit PhysX via HW oder via SW (afaik wird das doch eh nur der PhysX -Schnittstelle mitgeteilt und je nach Möglichkeiten arbeitet PhysX das dann in SW oder HW ab.
Solange dann die Kernelemente (die großen Brocken) gleich bleiben ist es doch kein Problem ob da noch 20 oder gar 200 max. faustgroße Brösel rumliegen die sich dann auflösen.
Bei stärkeren PhysX Effekten hätte man genaugenommen sogar eher Sicht-Nachteile.



Übrigens, die Panzerloops haben wir seid Monaten nicht mehr auf den Server gesehen, allerdings spielen wir seid einigen Monaten auch ohne Modifikationen die wir nicht selber gemacht haben.
Mag sein das es der Grund ist, sofern andere es nach wie vor sehen ...
mit den letzten 3 Mainreleases meinste damit (OFP,ArmA1 und ArmA2 ?)
Das sich nichts getan hat ist zudem nicht aussagekräftig, es sagt nicht aus das es mit der nächsten Version nicht besser werden könnte !
Bislang hat BIS von "Arschumreisser" mal abgesehen druchaus neue funktionierende Dinge eingebaut und auch alte Sachen behoben.
Ich glaube aber kaum das BIS zu ArmA3 Sachen rauswirft die zu ArmA2 gut funktioniert haben.



Ich habe nie gesagt das der Stand jetzt 100% fertig ist und keine Pflege mehr bedarf, sondern nur das man im Schnitt eine klare Verbesserung sehen kann wenn man es nur will.
Wenn man aber 10% , 50% und 90% "perfekt" alles als Müll deklariert, nur weil die 99,9% Marke noch nicht überschritten wurde, dann bleibt es natürlich immer unfertig.

[INNOCENT&CLUELESS]

Zitat von Lester

Diese Betrachtung ist übrigens falsch, denn man kann es relativ einfach lösen.

Bis dato ist es so das zumindest Treffer bei der KI (möglicherweise auch von den Spielern) vom Server ausgewertet werden.
Der Server bestimmt dann wie die Einheit umfallen soll (Zufallsauswahl der Todesanim) und teilt das den Clients mit.
Sagen wir mal es sieht so aus: [objekt,"animname"]

Mit PhysX würden dann einfach vereinfacht ausgedrückt die Kernelemente nebst Parameter wie Stärke und die genaue Position mitgeteilt werden a la [objekt,"parameterstring"]

Wo da jetzt der problematische Unterschied sein soll kann ich nicht nachvollziehen.

Zumal egal ob mit PhysX via HW oder via SW (afaik wird das doch eh nur der PhysX -Schnittstelle mitgeteilt und je nach Möglichkeiten arbeitet PhysX das dann in SW oder HW ab.
Solange dann die Kernelemente (die großen Brocken) gleich bleiben ist es doch kein Problem ob da noch 20 oder gar 200 max. faustgroße Brösel rumliegen die sich dann auflösen.
Bei stärkeren PhysX Effekten hätte man genaugenommen sogar eher Sicht-Nachteile.



Übrigens, die Panzerloops haben wir seid Monaten nicht mehr auf den Server gesehen, allerdings spielen wir seid einigen Monaten auch ohne Modifikationen die wir nicht selber gemacht haben.
Mag sein das es der Grund ist, sofern andere es nach wie vor sehen ...
mit den letzten 3 Mainreleases meinste damit (OFP,ArmA1 und ArmA2 ?)
Das sich nichts getan hat ist zudem nicht aussagekräftig, es sagt nicht aus das es mit der nächsten Version nicht besser werden könnte !
Bislang hat BIS von "Arschumreisser" mal abgesehen druchaus neue funktionierende Dinge eingebaut und auch alte Sachen behoben.
Ich glaube aber kaum das BIS zu ArmA3 Sachen rauswirft die zu ArmA2 gut funktioniert haben.



Ich habe nie gesagt das der Stand jetzt 100% fertig ist und keine Pflege mehr bedarf, sondern nur das man im Schnitt eine klare Verbesserung sehen kann wenn man es nur will.
Wenn man aber 10% , 50% und 90% "perfekt" alles als Müll deklariert, nur weil die 99,9% Marke noch nicht überschritten wurde, dann bleibt es natürlich immer unfertig.

Gut dass ich da falsch liege, ich hoffe es ist wirklich so, dass nur für die Simulation unwesentliche "Brocken" unterschiedlich sind, hingegen die großen "Objekte" gleich landen würden.


Übrigens, ich spiele nur nackerte beta so wie sixupdater die liefert, tagesgenau. Und gerade gestern hatte ich beide Effekte wie beschrieben, Panzerloops und Panzer die kurz vor Einschlag "wegspringen".

WFBE missionscode kann auch Sauereinen machen, aber ich hab selbiges auch in Domis erlebt und da werden ja noch mehr AI zwischenzeitlich verbuddelt um CPU und sync zu sparen als in WFBE.

Zitat:

Ich glaube hier verwechseln einige das Beheben von Fehlern an der Simulation mit Verbesserungen des Netcodes. Das was jetzt in den Beta Patches zu sehen ist hat nichts mit dem Netcode zu tun, lediglich die Simulation und das was auf dem Bildschirm zu sehen ist sind wesentlich verbessert worden (ansonsten könnte man nicht mit den aktuellen Beta Clients auf dem normalen 1.59 Server connecten).

Xeno

Vielleicht unterschiedliche Begrifflichkeiten. Zum Netcode zähle ich die Funktionen, die datagramme charakterisiert und tagged und an die Transportschicht abgibt b.z.w abnimmt.
Weiterhin sollte eine eigene QoS/GoS Funktion dabei sein welche oberhalb des benutzten TransportStacks die virtuellen Queues abgehend und ankommend (anhand Zeit+Sequenz) überwacht. Normal hat man eigentlich einen eigenen Tunnel offen mit eigenen QoS Meachanismen.

Wenn jetzt zB Daten "verspätet" eintreffen dann hat BIS scheinbar knochentrocken die Unit von einem Frame auf den anderen von der angenommenen Position auf die tatsächliche gesetzt - mein geliebtes Warpen. Wenn sie jetzt "sliden" ist dass ja nur optische Schummelei.

Aber all dass passiert nach meine Definition oberhalb des netcode in der "Applikation".

Zitat:

@inno:

was soll beta spielen mit verblödung zu tun haben. du hast den sinn einer beta nicht
kapiert.
aber ich fange schon wieder an trolle zu füttern, deshalb werde ich dich bis arma3
released wurde erstmal ignorieren.
geh leintücher aufhängen für den windschutz in der aufnahme

Du kannst ja nicht mal lesen. Demnach wäre ich ja komplett Verblödet weil ich fast 100% beta spiele. Ich finde immer nur deine Argumentation verblödet wenn du Leuten vorhältst >das sie</>das sie nicht< Beta spielen. Je nachdem wie du es brauchst. Beschwert sich jemand flaumst du "spiel final", bemekert jemand den final flaumst du "dödel, mussu beta spielen".

Damit wir dei Kurve zu A3 bekommen:

Für server und client Monitoring-modi-switche um die Auslastung der Queues in Logs zu schreiben oder auch nur die Überschreitung von Schwellwerten hätte was. Dann könnte die Community noch genauere Situationsbeschreibungen und logs liefern für die gerade diskutierten Probleme.

Bis jetzt stochern doch selbst die "Experten" im Ungefähren rum.

Da fliegt das Leinentuch drüber.

[flickflack]

Zitat von INNOCENT&CLUELESS;388664[...

Vielleicht unterschiedliche Begrifflichkeiten. Zum Netcode zähle ich die Funktionen, die datagramme charakterisiert und tagged und an die Transportschicht abgibt b.z.w abnimmt.
Weiterhin sollte eine eigene QoS/GoS Funktion dabei sein welche oberhalb des benutzten TransportStacks die virtuellen Queues abgehend und ankommend (anhand Zeit+Sequenz) überwacht. Normal hat man eigentlich einen eigenen Tunnel offen mit eigenen QoS Meachanismen.[...]

Das musste ich zweimal lesen

[Xeno]

Zitat von hammergut

aber vielleicht kannst du mir erklären wieseo das nichts mit änderungen des netcodes
zu tun hat. eine darstellung kanns ja nicht sein. und ja man kann auf 1.59 server connecten
aber alle funktionen haste halt nur wenn auch der server auf beta läuft.

Obwohl das absolut nichts mehr mit ArmA 3 zu tun hat (ok, ein wenig schon noch, da das was jetzt geändert wird ja so auch in A3 kommt)...

Das die KI nun weniger Bandbreite benötigt ist keine Änderung des Netcodes sondern die Behebung eines Fehlers der sich wohl irgendwann mal eingeschlichen hat. Eventuell wurde ein Datensatz anstatt nur einmal x mal pro KI über das Netz gejagt.

Die komplette Net Engine der RV Engine müsste umgeschrieben oder besser noch, wesentlich optimiert werden. Dafür hat BIS aber nicht das Know How in diesem Bereich (so blöd sich das auch anhört) und auch nicht die Manpower.
Sie müssten Externe mit ins Boot holen die sich in diesem Bereich auskennen und nichts anderes machen. Das kostet aber entsprechend sehr viel Geld (es gibt in diesem Bereich richtige Cracks, speziell z.B. auch für Linux (Server)).

Und niemand der Addons macht kann irgendwas am Netcode ändern (der ist in der Engine drin).
Das einzige was Du machen kannst ist Fehler in den Scripten von BIS beheben bzw. deine eigenen Sachen entsprechend den Möglichkeiten der Engine zu optimieren. Ändert aber rein gar nichts am Netcode.

Edith: Ist genauso wie im BIF wo es einen Thread gibt mit der Frage ob denn UDP endlich abgeschafft wird. Die wissen anscheinend gar nicht was der Vorteil von UDP ist.

Xeno

[Biba92]

Mr. Charles spielt die Beta

[MrCharles]

NDA

(wieso verkleinert er immer das DA?)

[Marscl]

Klick

[TeilX]

New Drug Application?

[INNOCENT&CLUELESS]

Zitat von flickflack

Das musste ich zweimal lesen

Bin halt ein Freund von

OSI-Modell ? Wikipedia




Wobei A2 sich neben/über FTP und Konsorten bewegt.

Zitat:

Ist genauso wie im BIF wo es einen Thread gibt mit der Frage ob denn UDP endlich abgeschafft wird. Die wissen anscheinend gar nicht was der Vorteil von UDP ist.

Wie baut man TCP/UDP aus dem OS/LAN-Treiber aus?


So wie die IP Leute IntServ/DiffServ auf IP Layer und auch den Fakt dass es niemand nutzt, und wenn, sich nicht an die Regeln hält.

Deswegen muss man weiter oben eben eine eigene QoS Schicht reinziehen und alle darunter liegenden Schichten zum Transport zugehörig behandeln und keine der darunter liegenden Funktionen für QoS benutzen.

Wenn man das macht, muss man aber auch ALLE Messungen der unteren Schichten nachäffen, sequenz, jitter, integrität, roundtrip........

Vorteil so etwas komplett selbst auf app-ebene nochmal abzubilden: Man weiss wie es reagiert.


Mal ein Beispiel wie es in meiner Welt gelöst ist:

UMTS QoS, Quality of Service



Wenn da einer an den code/detection points wurstet dann hat es meist auch sofort Auswirkungen, ihr seht also, es gibt eine Welt jenseits des Chaos .

Übrigens wird ja vermehrt IP als "Backbone Bearer Service" genommen, aber eben eng eingehegt in ein darüberliegendes Korsett.



Xeno hat schon recht, BIS bräuchte Experten, die ihnen etwas basteln was dann am Ende 5-7 Queues bereitstellt, Q1 hat Parameter besagend dass die wichtig und sofort wechmüssen, Q7 ist so Zeug wie Sidechat.

Bin sicher BIS hat so etwas in der Art irgendwie, aber sie beherrschen es nicht.

Was übrigens selten gelöst ist in solchen theoretischen Machwerken ist die Algorithmen der Qeuebearbeitung. Theoretisch muss ja ein Weg gefunden werden, bei immer voller Q1 auch mal Q2-Q7 abzufragen. Das ist selten oder so vage geregelt dass jeder was anderes macht und damit bei gleichen QoS settings eben doch bei jedem was anderes rauskommt.

Deswegen: selba mache!

[Biba92]

Zitat von Marcel

Klick

Wenn es nichtmal auf deren Rechner flüssig läuft
Wird hoffentlich noch etwas optimiert.

[TeilX]

Werds wohl erst mal aufm C64 testen obs läuft

[Muecke]

Zitat:

Normal hat man eigentlich einen eigenen Tunnel offen...

Is klar...

[JumpingHubert]

@I&C
bin mal gespannt, wieweit du mit einer Netcode-Mod kommst. Denn nur reden gildet nich

@Biba
und dabei war ja offenbar die Bodentextur lowres gehalten plus Megastottern plus niedrigste Objektdetails, sicher wegen der gigantischen Sichtweite. Kein gutes Marketing, wenn sie einen Aspekt demonstrieren wollen und 3 andere als Defizite dabei in die Augen springen.

[Buccs]

Typisch BIS.
Mit ihrer Art Ehrlichkeit aber auch wieder sympathisch

Am Ende wird es wieder eine Kunst sein, die idealen Einstellungen für den eigenen PC zu finden. Und ein Kompromiss. Weil alles auf High bei ArmA wie immer ein reines Theorem bleiben wird.

[INNOCENT&CLUELESS]

Zitat von JumpingHubert

@I&C
bin mal gespannt, wieweit du mit einer Netcode-Mod kommst. Denn nur reden gildet nich

Noch so ein Knaller: Dem Soundverwurster einen Werbefilm und dir jetzt gleich einen neuen Netcode versprochen?

Zitat:

Mücke: Is klar...

Nicht im Sinne von Verschlüsselung sondern tunneln wie bei MPLS mit eigenem Routinglabel.

[piTu]

gibt man netcode bei wiki ein ist gleich der 4.treffer auf arma bezogen

[flickflack]

Zitat von INNOCENT&CLUELESS

Bin halt ein Freund von

OSI-Modell ? Wikipedia

Das OSI-Modell konnte ich schon heraushören, danke, allerdings fällt mir immernoch schwer zu verstehen, aus welchem theoretischen Bauchladen heraus du deine Posts konstruierst. Denn was Du schreibst, ist nicht verständlich.

[Snevsied]

@Hubert
Das macht doch schon Project Reality mit der Verbesserung des Netcodes! Man sieht doch, dass da keine Lags auftretten. Da muss sich Inno nicht auch noch einmischen!

[INNOCENT&CLUELESS]

Zitat von flickflack

Das OSI-Modell konnte ich schon heraushören, danke, allerdings fällt mir immernoch schwer zu verstehen, aus welchem theoretischen Bauchladen heraus du deine Posts konstruierst. Denn was Du schreibst, ist nicht verständlich.

War der Versuch allgemein zu bleiben weil ja hier vermutlich alle nur auf den üblichen IP Stack firm sind und sich eher in der app-ebene oberhalb TCP/UDP rumtreiben.

Theoretisch, weil alles was ITU, 3GPP und RFC nicht hergibt muss ich immer funktionell umschreiben und dann wird es meist selber gebacken.

Wenn alles nicht hilf, äfft man Stacks oder Teile davon in Corba nach. Funktioniert aber nicht für ArmA, weil man leider das "Internet" nicht mal eben durch was gefälligeres austauschen kann.

Worauf ich hinaus will: Es IST MÖGLICH auch das chaotische "Internet" besser für Anwendungen wie ArmA zu benutzen. Aber wie Xeno schon sagte, da muss man Geld reinstecken. Ist aber eine wichtige Investition, die sie für VBS und evtl. alle IDEA-Games weiterverwerten können.
Deswegen verstehe ich überhaupt nicht dass BIS das so schleifen lässt.