[Ebola]

Hab gerade zum ersten mal diesen Thread entdeckt und finde die Geschichte mit dem Outterra echt spannend, auch wenn das wohl eher die Grundlage für diese komische Heli Sim wird (Sorry ich mag ja Helifliegen, aber die Aktion geht nach hinten los).
Dennoch muss ich zugeben, dass BIS sich lieber auf Ihre Projekte konzentrieren sollte statt die Zeit mit irgendwelchen Rätseln zu vergeuden...
Dann lieber ein schöner offener Dev-Blog...

Gruß

Ebo

P.S.: Ich hab gerade 25 A4 Seiten hinter mir, die Kommata könnt Ihr selber setzen

[KidDynamite]

Zitat von KH

Halt nur kein zweiter Weltkrieg-Szenario mehr, ich glaube davon haben wir alle genug.

Geht so

Ne, so ein WK3 Szenario in welcher Form auch immer... Finanzkrise lässt Griechenland zu ungeahnte Aktionen treiben... wäre schon interessant.
Tendenziell bin ich ja auch eh der Freund des "klassischen Krieges"... Arrowhead war mir persönlich eh viel zu dicht an bestehende Konflikte gestrickt.
Ob nun 85er Szenario oder modern Warfare ist mir fast egal, auch wenn ich das 85er Szenario interessanter finde. War irgendwie ausgeglichener.

Grüße

[Buccs]

Es geht wieder los...

Wednesday, May 11th 2011, 06:00 CEST - Arma Enigma Wiki

Bisher vier Avatarbilder mit einem QR Code... spannend

[INNOCENT&CLUELESS]

Zitat von Buccs

Es geht wieder los...

Wednesday, May 11th 2011, 06:00 CEST - Arma Enigma Wiki

Bisher vier Avatarbilder mit einem QR Code... spannend

Genau, wie ner Kuh beim kacken zuschaun.

[Buccs]

Jenau!
Und die Kuh kackte ne Ankündigung....

[King Homer]

Hey, Rätselraten ist lustig.

[[HSP] NoFu]

Macht aber auch richtig Spaß, wenn man die ganze Zeit mitmacht !

[Snevsied]

Zitat von INNOCENT&CLUELESS

Genau, wie ner Kuh beim kacken zuschaun.

Wenn man darauf steht bestimmt! Also Inno, die Leute nicht beim zuschauen stören

[INNOCENT&CLUELESS]

Natürlich ist Rätselraten lustig.

Wenn aber als Lösung rauskommt dass deine Katze überfahren wurde eher nicht.

Und wenn als Ergebnis eh wieder rauskommt das BIS Energien in irgendwelche Wurstideen steckt, dann will ich die Auflösung gar nicht aktiv suchen, die Konsequenz wird mir beim nächsten Patch eh ins Gesicht gedroschen.

[[HSP] NoFu]

Die Lösung ist, das meine Katze überfahren wurde ?


toll Inno. Hab Dank. Jetzt war all meine Arbeit für die Katz.
Oder auch nicht, da diese ja nun Rad-Pizza ist.

[INNOCENT&CLUELESS]

Zitat von [HSP] NoFu

Die Lösung ist, das meine Katze überfahren wurde ?


toll Inno. Hab Dank. Jetzt war all meine Arbeit für die Katz.
Oder auch nicht, da diese ja nun Rad-Pizza ist.

*Träum* Ja wenn die zugegebenermaßen witzig aufgezogenen Marketing-Rätsel in etwas zeitgemäß Außerordentliches münden würden wie anno-dunnemals OFP..........

....aber der Berg kreißte - und warf einen Haufen Trollscheiße aus.

[Snevsied]

Welche Innovationen willst du bei Arma3 haben, gab es doch schon alles bei OFP! Der einzige Unterschied ist einfach nur die Grafik ...

OK, wenn Sie ein ordentliches Schadensmodell einbauen oder Physik.

[INNOCENT&CLUELESS]

Zitat von Snevsied

Welche Innovationen willst du bei Arma3 haben, gab es doch schon alles bei OFP! Der einzige Unterschied ist einfach nur die Grafik ...

OK, wenn Sie ein ordentliches Schadensmodell einbauen oder Physik.

Oder.....ihr versprechen von Massenschlachten einlösen und die serverapp auf mehr als einem core laufen lassen?

Xeno rennt ja beim scripten 3 mal um die Insel damit auch ja nicht zu viele Einheiten gleichzeitig in einer Domi sind.

DAC ist ja auch nur ein Kniefall an dieses Limit.

Bandbreite server-client kann ja nicht mehr der primäre Flaschenhals sein.

[flickflack]

*gähn*

....von Half-Life lernen, heißt siegen lernen...

Edith: Bandbreite Server-Client ist immer der Flaschenhals und das wird auch noch ne Weile so bleiben fürchte ich. Es wird nicht jeder Client den benötigten Upstream bereitstellen können, wenn man sich 'ne Welt wünscht in der so gut wie alles geht. Skalierbarkeit ist zwar schön, aber irgendwo muss man das Minimum/Maximum legen - den gemeinsamen Nenner als pseudo Layer.

[INNOCENT&CLUELESS]

Zitat von flickflack

*gähn*

....von Half-Life lernen, heißt siegen lernen...

Edith: Bandbreite Server-Client ist immer der Flaschenhals und das wird auch noch ne Weile so bleiben fürchte ich. Es wird nicht jeder Client den benötigten Upstream bereitstellen können, wenn man sich 'ne Welt wünscht in der so gut wie alles geht. Skalierbarkeit ist zwar schön, aber irgendwo muss man das Minimum/Maximum legen - den gemeinsamen Nenner als pseudo Layer.

UPSTREAM < UPSTREAM_MIN=KICK

Und wenn ALLE AI auf dem server berechnet werden würden, dann wären doch nur meine aktionen zu "upstreamen" hrrr-hrr, gelle?

[flickflack]

Zitat von INNOCENT&CLUELESS

UPSTREAM < UPSTREAM_MIN=KICK

Und wenn ALLE AI auf dem server berechnet werden würden, dann wären doch nur meine aktionen zu "upstreamen" hrrr-hrr, gelle?

Klar so kannste da rangehen, aber dann kommt der BWLer aus seiner Höhle gekrochen und springt Dir an den Hals weil du damit 10-30% Kunden ausschließt.

Bei einer Verengung der Sicht auf die KI magst Du recht haben, wobei dass dann derzeit einfach nur noch in warpende Begleiter enden dürfte (also umgekehrt zu dem Effekt den man jetzt schon kennt, wenn Mitspieler mit KI durch die Gegend rennen).
Allerdings besteht so ein Frame aus mehr als nur KI-Daten. Man muss auch noch den Unterschied zwischen "Daten dispatchen" und "Daten verarbeiten/kontrollieren und dann dispatchen" in Betracht ziehen und wieviel es kostet.
Es ist schon nicht doof die Arbeit gleichmäßig zu verteilen und die relevanten Dinge vom Server ausführen zu lassen, oder wenigstens zu kontrollieren. Denn meistens ist es ja so, dass in der Summe die angeschlossenen Clients über wesentlich mehr Rechenkraft verfügen als der Server.

Unabhängig davon hat der NetCode definitiv ein paar Tage im Protokoll-Pimpmobil nötig und kann auch ein Review der Lastverteilung vertragen.

[INNOCENT&CLUELESS]

Zitat von flickflack

Klar so kannste da rangehen, aber dann kommt der BWLer aus seiner Höhle gekrochen und springt Dir an den Hals weil du damit 10-30% Kunden ausschließt.

Bei einer Verengung der Sicht auf die KI magst Du recht haben, wobei dass dann derzeit einfach nur noch in warpende Begleiter enden dürfte (also umgekehrt zu dem Effekt den man jetzt schon kennt, wenn Mitspieler mit KI durch die Gegend rennen).
Allerdings besteht so ein Frame aus mehr als nur KI-Daten. Man muss auch noch den Unterschied zwischen "Daten dispatchen" und "Daten verarbeiten/kontrollieren und dann dispatchen" in Betracht ziehen und wieviel es kostet.
Es ist schon nicht doof die Arbeit gleichmäßig zu verteilen und die relevanten Dinge vom Server ausführen zu lassen, oder wenigstens zu kontrollieren. Denn meistens ist es ja so, dass in der Summe die angeschlossenen Clients über wesentlich mehr Rechenkraft verfügen als der Server.

Unabhängig davon hat der NetCode definitiv ein paar Tage im Protokoll-Pimpmobil nötig und kann auch ein Review der Lastverteilung vertragen.

Rechnerei verteilen war 1985 sinnvoll, wenn BIS sich am Riemen reißen würde, dann könnten sie die clients als terminals nutzen.

Da für einen client der status aller anderen objekte und einheiten der server und other-clients seinem client mitgeteilt werden muss, bleibt der downstrem fast gleich wenn man alles am server berechnen lässt. der synctraffic der einheiten unter eigenem kommando wandert von up- nach downstream.


serverbasierend

Vorteile:

- relativ gut kontrollierbar da an einem punkt

Nachteile:

- teurer server


wenn man aber sieht das BIS am server nur eine einzige CPU nutzt ist da noch jede menge platz nach oben, zumal sich zyklische scripte angeblich gut parallelisieren lassen.

Zitat:

Klar so kannste da rangehen, aber dann kommt der BWLer aus seiner Höhle gekrochen und springt Dir an den Hals weil du damit 10-30% Kunden ausschließt.

Liegt am serveradmin wie er parameter für betcode setzt.

Schon heute gibt es minimalanforderungen nach denen clients abgehangen werden.

[flickflack]

Zitat von INNOCENT&CLUELESS

Rechnerei verteilen war 1985 sinnvoll, wenn BIS sich am Riemen reißen würde, dann könnten sie die clients als terminals nutzen.

Ehm nein... parallele Entwicklung bspw. war zu Beginn dieses Jahrtausends noch richtig frisch. Ein Client ist kein Terminal, das geht am Beispiel nur durch so Spässe wie onlive (oder wie die sich nennen). Ein Terminal im klassischen Sinne ist ähnlich aber trotzdem kein Client im selben Sinn

Zitat von INNOCENT&CLUELESS

Da für einen client der status aller anderen objekte und einheiten der server und other-clients seinem client mitgeteilt werden muss, bleibt der downstrem fast gleich wenn man alles am server berechnen lässt. der synctraffic der einheiten unter eigenem kommando wandert von up- nach downstream.

serverbasierend

Vorteile:

- relativ gut kontrollierbar da an einem punkt

Nachteile:

- teurer server

Ehm der Server ist jetzt schon die Instanz der die Clients vertrauen. Wäre schlimm wenn nicht. Ich dachte nämlich dass hätte sich zum selben Zeitpunkt durchgesetzt, wie die Einsicht die Bewegungen eines RT-3D-Objekts nicht mehr an die FPS zu binden sondern an einen Timer.

Zitat von INNOCENT&CLUELESS

wenn man aber sieht das BIS am server nur eine einzige CPU nutzt ist da noch jede menge platz nach oben, zumal sich zyklische scripte angeblich gut parallelisieren lassen.

Richtig. Aber ich glaube Skripte sind das geringste Problem.

Zitat von INNOCENT&CLUELESS

Liegt am serveradmin wie er parameter für betcode setzt.

Schon heute gibt es minimalanforderungen nach denen clients abgehangen werden.

Und?! Blende mal wieder den Communityumfang ein. Und Lagger springen selbst bei EgoShootern im MP durch die Gegend, also Titel wo vermutlich nur 2 KiB (glaub bei OFP warens bei C&H so um die 4) getauscht werden.

Ich sag ja, zum optimieren ist noch Platz.

Edith: Unabhängig davon würde ich KI des Clients trotzdem nicht auslagern, sondern da liegen lassen und eher im Protokoll wurschteln und Frames reduzieren.

[INNOCENT&CLUELESS]

terminal ist das falsche wort, ich meine das am client nur die controllerinfo aufgenommen und zum server geschickt werden sollte und nur der downstream am bildschirm dargestellt werden sollte + sound.

KI am client berechnen hat zum problem das in einer gemeinsamen welt die KI völlig unvorhersehbar resourcen erhalten. Und immer wenn ein cleint kommt zb in WF dann geht die KIs zum client, und wenn er disconnected, dann wieder zum server, gelle?

Wenn man alles am server macht, dann kann man auch viel besser bei der resourcenverteilung reagieren im grenzbereich zur überlast.

Egal wie, wenn man eine Quadcore server hat und ArmA nagelt eine CPU auf 100% und dann laggt es vor sich hin........ääch kräch da ein Hals.

[flickflack]

Klar lol, dass SingleCoreDing ist auch das größte Übel fürchte ich.

Es könnte einfach daran liegen, dass sie vllt jetzt doch zum ersten Mal eine fremde LIB nutzen und die nur gegen Windows hämmern können, oder nur Lizenzen für die Clients besitzen. Oder sie haben, das vermute ich eher (ich glaube auch viele viele andere), den MP eher als Beinlast empfunden. Last die so hinterherschwingt beim vorwärts gehen. Also wie'n Lepra-Opfer.

Mit KI am Client meine ich vom Client kontrollierte KI. Nix weiter. Also in einer CTI wären dass deine persönlichen Pappkameraden. Also auf keinen Fall die vom Server/der Mission kontrollierte KI. Da haben wir uns falsch verstanden, oder ich mich schlecht ausgedrückt. Wie auch immer, genau so läuft es atm schon denke ich mal. Also die Effekte kann man jedenfalls unter OFP in einer CTI noch erleben. Eigene KI warpt und laggt nicht, aber die des Servers oder die KI von anderen Clients spielt Hoppsehäschen.