Star Citizen Star Citizen [PreRelease Sammelthread] Teil II

[DerkleineGrisu]

Für die die total frustriert sind noch ein Tipp. Als EU Bürger hat man das Recht auf einen Refund, solange das Produkt noch nicht geliefert wurde.

Wo steht das bitte . Würde den entsprechenden Paragrafen gerne wissen .

Zudem wird das für manche keine Option sein da gerade in den Anfangszeiten der Euro vs Dollar kurz weit höher war als
wie er jetzt steht. Manche würden da ein richtiges Minusgeschäft machen.

 

[charmin]

Ich kenne den Paragraphen nicht, aber ich weiß das es so ist und das es funktioniert.

Bzgl. des Wechselkurses unterliegst du einem Denkfehler. Der Euro war wesentlich stärker, ergo hast du weniger Euro für 100€ Dollar ausgegeben als du es heute brauchst. D.h. du bekommst mehr Euro zurück.

 

[Roi-Danton]

@Gojira: Stimmt bzgl Cheating. Je mehr Berechnungen vom Client auf den Server übertragen werden, desto weniger Angriffspunkte gibt es (bspw Client bekommt nur die "sichtbaren" Infos; gegen Wallhacks). Wenn der Server die vom Client empfangenen Daten auf Glaubwürdigkeit überprüft, wird's noch schwieriger mit Cheating (bspw ist der Positionswechsel mit dem aktuellen Schiff überhaupt möglich).

Wenn dann noch NPCs dazu kommen, wird das arg komplex. Viel Belastung läge auf dem Server und die Menge der zu übertragenden Daten zw. Server und Client wären wohl hoch.

Dann noch Sonderfälle für Situation 0 bis Situation 10000000. Da helfen nur noch gut getestete Algorithmen. ;-)

 

[shoKuu]

@Zehkul

Ja es ist falsch beschrieben, aber letztendlich geht es um RTT. Der Client wartet auf die Antwort des Servers bzw. auf alle Clienten und deshalb sind die FPS doch so schlecht... oder nicht.

 

[Zehkul]

Der Client wartet

Nein.

Kannst du ganz leicht selber ausprobieren. Schmeiß Torrents oder irgendwas anderes an, das deine Bandbreite auslastet und so Pings massiv erhöht, und dann Star Citizen. Die FPS werden sich nicht unterscheiden.

Wenn der Server die vom Client empfangenen Daten auf Glaubwürdigkeit überprüft, wird's noch schwieriger mit Cheating (bspw ist der Positionswechsel mit dem aktuellen Schiff überhaupt möglich).

Macht er sowieso. Star Citizen ist derzeit vollkommen Server-autoritativ, der Server berechnet alles, was die Clients auch berechnen, und es gibt auch keine Pläne, das zu ändern.
Gojira hat aber schon recht, dass es weniger Möglichkeit geben sollte, an Daten zu kommen, an die ein Spieler nicht kommen können sollte, wenn das Networking mehr optimiert wird und das meiste schlicht gar nicht erst gesendet wird. Derzeit könnte man vermutlich lustige Cheat Tools bauen, die die Position aller Spieler anzeigen und was sie gerade machen, weil der Client das alles weiß …

 

[shoKuu]

Dann hatte ich das damals falsch verstanden.

 

[sverebom]

@Zehkul
Ich lese bzw. höre da nicht heraus, dass dieser Mechanismus auschließlich oder hauptsächlich die Clients betrifft. Die CPU-Cycles, die Mark zurück haben möchte, können auch CPU-Cycles auf dem Server sein. Und dass die Clients ein Objekt auf der anderen Seite von Crusader ignorieren können, müssen sie auch erst vom Server erfahren. Das Objekt könnte ja in der Zeit, in der sich der Spieler aus der "entity range" heraus bewegt, dem Spieler folgen so dass sich dieser nicht weit genug von dem Objekt entfernen kann. Wenn der Client nun nur für sich berechnet, was in dieser Situation geschieht, dann wird er zu dem Ergebnis kommen, dass er das Objekt ignorieren kann. Der Server und ggf. der Client des anderen Objekts werden diesbezüglich aber eine ganz andere Meinung haben.

Letztendlich geht es sowohl um die Server als auch um die Clients. Je weniger die Server berechnen und übermitteln müssen, umso weniger haben auch die Clients zu tun. Und natürlich ist es nicht so, dass die Server pro CPU-Cycle alles erfassen und übermitteln. Das wäre in der Tat Wahnsinn und sicherlich auch nicht möglich. Die Clients berechnen eine Menge. Genauer gesagt sie interpolieren, was zwischen den Zustandsveränderungen geschieht. Aber das bedingt eben auch, dass die Server das letzte Worte über den Zustand der Spielwelt haben müssen, denn andernfalls werden sich Server und Clients binnen Sekundenbruchteilen uneins über den tatsächlichen Zustand der Spielwelt sein.

Nach meinem Verständnis liegt hier der Hund begraben. Die Server können benötigte Updates nicht schnell genug bereitstellen. Die Clients könnten vielleicht fröhlich vor sich hin interpolieren, selbst wenn die Server in die Knie gehen und nur noch sehr langsam Updates liefern. Die Folge wäre Rubberbanding und andere Artefakte, die immer dann auftreten, wenn Server einen Status übermitteln, der sich nicht mit der lokalen Interpretation deckt. Stattdessen ist es aber wohl so, dass die Clients den Zustand der Spielwelt nur bis zu einem gewissen Punkt interpolieren können und dann auf ein Update warten müssen um sicherzustellen, dass Server und Clients nicht vollends aus dem Takt geraten.

Übrigens, wenn die Performance so sehr von den Clients abhängig wäre, sollten wir dann nicht ein großes Leistungsgefälle zwischen den CPUs sehen? Sollte ein System mit einem i7 8700K nicht eine bedeutend bessere Performance erzielen ein alter AthlonFX? Mir ist nicht bekannt, dass dies der Fall ist.

Heißt übrigens auch, dass ab 3.0 einsame, vor sich hin rotierende Schiffe ihre Bewegung komplett verlieren, sobald einmal kein Spieler in Reichweite war.

Wenn ich mich recht entsinne, dann hat Mark gesagt dass der letzte Zustand eines Objekts gespeichert und ggf. wiederhergestellt wird, wenn dieses Objekt wieder relevant für den Spielverlauf wird. Das kann natürlich nicht für alle Objekte funktionieren. Ein Schiff etwa, das auf dem Weg ins sichere Verderben ist, muss auch untergehen, selbst wenn alle Spieler das Gebiet verlassen haben. Andernfalls würde sich das Schiff ja wieder am Ausgangspunkt der Katastrophe befinden, wenn Spieler wieder in Reichweite kommen. Der Drehimpuls eines havearierten Schiffes hingegen könnte in diesem Szenario aber erhalten bleiben. Die Bewegung aller driftender Objeke zu verfolgen, wäre aber wohl widerum etwas zu viel des Guten, selbst wenn man der Stelle wahrscheinlich großzügig und mit sehr wenigen Taktzyklen interpolieren kann.

 

[Zehkul]

@Zehkul
Ich lese bzw. höre da nicht heraus, dass dieser Mechanismus auschließlich oder hauptsächlich die Clients betrifft. Die CPU-Cycles, die Mark zurück haben möchte, können auch CPU-Cycles auf dem Server sein.

Er hat es am Client implementiert und getestet. Er hat danach erklärt, dass und wie es auch den Server betrifft, und natürlich ist das auch sehr nützlich für den Server, aber ganz prinzipiell bringt diese Änderung am Client mehr, eindrucksvoll demonstriert durch den 60 Spieler Evocati Test.
Am Server ist es eher etwas gegen über Zeit degradierende Performance.

Und dass die Clients ein Objekt auf der anderen Seite von Crusader ignorieren können, müssen sie auch erst vom Server erfahren.

Diese Logik ist ist hinter den besagten Events verborgen, wurde im Video nicht thematisiert und war mit Sicherheit der Löwenanteil der Arbeit – der Grund, warum eine so nützliche Änderung erst jetzt kommt.
Die Network Ticks vom Server dürften aber vermutlich noch immer genau so ankommen wie vorher, Network Bind Culling ist schließlich noch nicht fertig. Der Client weiß also, wo alle Schiffe sind. Das einzige, was schlafengelegt wird, sind Boardcomputer und Physikberechnungen.

Letztendlich geht es sowohl um die Server als auch um die Clients. Je weniger die Server berechnen und übermitteln müssen, umso weniger haben auch die Clients zu tun.

Das Übermitteln hat mit dieser Geschichte überhaupt nichts zu tun. Das Übermitteln wäre wirklich Network Bind Culling.
Die Daten werden übermittelt, der Client legt nur einen Teil seiner Simulation auf Eis, weil der aktuelle Zustand derzeit nicht interessiert und er ihn später, wenn er wieder interessiert, leicht vom Server holen kann. (Bzw. vermutlich sogar dauernd gesendet bekommt, zumindest pre-3.0)

Nach meinem Verständnis liegt hier der Hund begraben. Die Server können benötigte Updates nicht schnell genug bereitstellen. Die Clients könnten vielleicht fröhlich vor sich hin interpolieren, selbst wenn die Server in die Knie gehen und nur noch sehr langsam Updates liefern. Die Folge wäre Rubberbanding und andere Artefakte, die immer dann auftreten, wenn Server einen Status übermitteln, der sich nicht mit der lokalen Interpretation deckt. Stattdessen ist es aber wohl so, dass die Clients den Zustand der Spielwelt nur bis zu einem gewissen Punkt interpolieren können und dann auf ein Update warten müssen um sicherzustellen, dass Server und Clients nicht vollends aus dem Takt geraten.

In solchen Situationen bleiben in Multiplayerspielen dann meist die Charaktere einfach alle stehen, laufen auf der Stelle oder Ähnliches. Ist auch oft ganz witzig damit rumzuspielen explizit Traffic zu verlangsamen oder zB nur UDP Traffic ganz zu blockieren, habe schon Spiele gesehen, wo das einen Godmode für Arme ergab. (Bei vernünftig geschriebenen aber natürlich einen sofortigen Disconnect)

In irgendeiner Form den zentralen Renderloop an Netzwerkupdates zu koppeln ist aber Unfug auf einem Level, dass das nicht einmal in Cryengine legacy code vorhanden sein könnte. Na ja, und selbst wenn, dann würdest du eher mittlere bis lange Hänger beobachten anstatt konstant niedrige FPS.

Übrigens, wenn die Performance so sehr von den Clients abhängig wäre, sollten wir dann nicht ein großes Leistungsgefälle zwischen den CPUs sehen? Sollte ein System mit einem i7 8700K nicht eine bedeutend bessere Performance erzielen ein alter AthlonFX? Mir ist nicht bekannt, dass dies der Fall ist.

Ich habe keinen AthlonFX hier, aber ich bin mir ziemlich sicher, dass du damit miserable Performance in Star Citzien kriegen wirst.

Einen gewissen ausgleichenden Effekt hast du aber sicherlich dadurch, dass immer noch einiges singlethreaded ist und erst mit 3.0 so langsam auf das auf Multithreading ausgelegte Items 2.0 umgestiegen wird. Wenn der Flaschenhals an einem Kern hängt, macht es wenig Unterschied, ob man einen 3 Kerner oder einen 8 Kerner hat.

Wenn ich mich recht entsinne, dann hat Mark gesagt dass der letzte Zustand eines Objekts gespeichert und ggf. wiederhergestellt wird, wenn dieses Objekt wieder relevant für den Spielverlauf wird.

 

[sverebom]

Nachdem ich nun lange darüber nachgedacht und lange darüber geschlafen habe, bin ich zu dem Schluss gekommen, dass du offensichtlich in den wesentlichen Punkten Recht hast. Letzten Endes ist die einfachste Antwort oft die richtige, in diesem Fall ist die einfachste Antwort die, dass wir es hier mit einem schnöden Performanceproblem zu tun. Die scheinbare Wechselwirkung zwischen Server und Clients ist nur eine scheinbare, die darin begründet liegt, dass beide das gleiche Problem haben. Server und Clients müssen zu viele Objekte und Wechselwirkungen berechnen und im Auge behalten.

Die unsinnige Annahme, dass die Clients durch die Server ausgebremst werden, rührt vielleicht von der Annahme her, dass die Server ganz spezielle Maschinen mit enormer Rechenleistung sein müssen. Und das sind sie sicherlich auch. Aber die Server, die wir derzeit sehen, sind nur Häppchen dieser Rechenleistung. Nach meinem Verständnis entspricht eine Instanz einer virtuellen CPU, die für sich alleine vielleicht nicht wesentlich mehr leisten kann als eine Desktop-CPU. Die enorme Rechenleistung des Systems wird erst dann sichtbar werden, wenn das Server-Meshing ins Spielt kommt und die CPUs dynamisch zusammen geschaltet werden, um die anfallenden Lasten zu tragen. Vorher wird CIG aber die Effizienz der Instanzen optimieren, und solange werden wir noch auf getrennte "Server" verteilt bleiben.

Ich bleibe dabei, dass wir beide Recht haben bzw. beide Aussagen Teil der Wahrheit sind. Aber die Annahme, dass die Clients auf die Server warten müssen, stimmt so nicht. Was die Server in die Knie zwingt, zwingt auch die Clients in die Knie. Und was den Clients hilft, hilft auch den Servern.

 

[Nightspider]

Wir wissen halt gar nicht welche Hardware in den Amazon Servern stecken, die für die Instanzen jetzt und in Zukunft genutzt werden.
In einen simplen Serverschrank passen 16 Racks und auf jeden Rack sind bis zu 4 CPUs mit je bis zu 28 Kernen.
Rein theoretisch passen alleine in einen Serverschrank schon fast 1800 CPU Kerne rein und das weniger auf einen Quadratmeter.

Ich habe ehrlich gesagt keinen Plan wie andere Gameserver so aussehen und wie viele Games und Game-Server auf einem Serverschrank laufen aber wenn man deren volle mögliche Leistung für ein Spiel nutzt und die Kerne intelligent vernetzt und deren Potential nutzen kann...dann geht sicherlich die Post ab.

Das Multithreading beim Client-Build kann man wahrscheinlich nicht mal mehr mit dem Multithreading vom Client-Build vergleichen.

Das wäre aber mal eine interessante Frage, welche man in einem Q&A mal stellen sollte.

Das sind die Arten von Fragen die einem dann bei Events wie der CitizenCon nicht einfallen wenn man den Entwicklern gegenüber steht.

 

[sverebom]

Ist die Frage nach der Hardware nicht ohnehin wenig zielführend, da die Server nicht auf physikalischen, sondern auf "virtuellen CPUs" laufen? Kann uns ja wurscht sein, viele virtuelle CPUs auf einer physischen CPU emuliert werden bzw. wie viele physische CPUs nötig sind, um eine virtuelle CPU für Star Citizen zu emulieren. Die Leistung bleibt ja gleich. Nur der Aufwand und somit die Kosten verändern sich. Eine Gleichung, die natürlich auch in mehr Leistung zu gleichen Kosten umgestellt werden kann.

Oder verstehe ich die Art der Visualisierung, die hier zum Einsatz kommt, falsch?

Das wäre aber mal eine interessante Frage, welche man in einem Q&A mal stellen sollte.

Wäre mal ein Thema für AtV, macht aber wohl erst dann Sinn, wenn Server-Meshing vor der Tür steht.

 

[Zehkul]

Nach meinem Verständnis entspricht eine Instanz einer virtuellen CPU, die für sich alleine vielleicht nicht wesentlich mehr leisten kann als eine Desktop-CPU. Die enorme Rechenleistung des Systems wird erst dann sichtbar werden, wenn das Server-Meshing ins Spielt kommt und die CPUs dynamisch zusammen geschaltet werden, um die anfallenden Lasten zu tragen.

Nicht nur das, vor geraumer Zeit wurde auch bestätigt, dass 4 Serverinstanzen pro physischem Server laufen. 4 physische CPU Kerne pro Serverinstanz anstatt 16, oder so. Das war zwar vor Amazon, aber ich bezweifle, dass sich fundamental etwas an diesen Zahlen geändert hat, eher dürften die Server noch mehr Kerne bekommen haben, mit denen Star Citizen derzeit noch nicht umgehen kann. Schon vor Server Meshing hat CIG also einen ganz einfachen Schalter, mit dem sie die Spieleranzahl pro Server (oder die Server-FPS) vervierfachen können – vorausgesetzt, das Spiel skaliert annähernd linear. Was es derzeit garantiert nicht tut, weshalb überhaupt erst 4 Instanzen pro Server laufen.

Ich bleibe dabei, dass wir beide Recht haben bzw. beide Aussagen Teil der Wahrheit sind.

Jep, irgendwie stimmt es ja, dass der Server den Client ausbremst. Ohne Server weniger Spieler, mit weniger Spielern mehr FPS. „Weniger Spieler“ kann nur nicht die Lösung des Problems sein.

Das Multithreading beim Client-Build kann man wahrscheinlich nicht mal mehr mit dem Multithreading vom Client-Build vergleichen.

Meinst du Server Build? Prinzipiell läuft da bei Star Citizen derselbe Code, da alles serverautoritativ ist und CIG keinen extra Validierungscode schreibt, sondern die volle Simulation laufen lässt. Deshalb hat Chris auch so oft betont, dass die Optimierungen am Server auch alle den Clients zugute kommen.

 

[Amusens]

mal ne frage nutzt wer die T.A.R.G.E.T GUI Software?
Wenn ich jetzt alles Programmiere würde, was muss ich inGame alles einstellen?
Wollte Komplett alles so machen mit der T.A.R.G.E.T GUI Software, das jeder Knopf vom Joystick quasi eine Tastatur Taste ist.

Ich konnte vor der Target Software, inGame bei Optionen zb. einen Joystickwerten/Knopf zwar belegen mit Lock&Fire Missles hat aber nie inGame beim AC Modul funktioniert .....musste immer den Joystick los lassen und per Mittler Maustaste das Gegner Schiff "einloggen" und dann per Maustaste die Rakete abfeuern.

--------------------
Habe am Sonntag etwas ausprobiert, wo ich auf dem Joystick eine Taste Waffengruppe 1 gelegt habe (Linke Maustaste) und den Thottle nach Anleitung zum Schubhebel eingestellt habe..

Wenn ich jetzt Waffengruppe 1 benutze schaue ich mich nach rechts um? und beim Gas geben rolle ich mich nach Links oder Rechts?

Gibt es ne Möglichkeit ein Komplett leeres Profil zu nutzen? für Joystick und den Kram? (oder muss ich alles per Hand löschen?)

Finde auch im www nicht über die inGame Einstellung mit Joystick 1 bis 4 bei den Optionen inGame?

Zu dem Thottle könnte ich mir denken das er die selben Axis nutzt wie meine Pedale? O_o ..müsste ich noch extra mal schauen.

 

[Tharamur]

Falls du eine deutsche Anleitung für die Target-SW haben willst, sag mir bescheid. Ich hab eine als PDF rumliegen. Ich selber hab mir das nur Testhalber mal angeschaut. Ingame musst da da letztendlich gar nichts mehr einstellen. Du startest SC oder andere Spiele, für die du in Target ein Profil hinterlegt hast, direkt über Target. Sprich, Target-Software starten, das Profil vom passenden Spiel auswählen und über Target starten. Wenn du ein Profil für ein Spiel dort anlegst, verknüpfst du quasi die Spiel-exe mit Target. Sonst funzt das nicht.

 

[Nightspider]

Wer hat hier denn einen 6700K oder 7700K mit ~4,5 Ghz oder mehr (und halbwegs schnellen RAM) und kann mir sagen wie viel fps er in Crusader bei einem vollen Server hat?

 

[ZeT]

Dein Setup ist komplett irrelevant. Eventl lässt sich mit 3.0 eine bessere Aussage treffen.

 

[Amusens]

Falls du eine deutsche Anleitung für die Target-SW haben willst, sag mir bescheid. Ich hab eine als PDF rumliegen. Ich selber hab mir das nur Testhalber mal angeschaut. Ingame musst da da letztendlich gar nichts mehr einstellen. Du startest SC oder andere Spiele, für die du in Target ein Profil hinterlegt hast, direkt über Target. Sprich, Target-Software starten, das Profil vom passenden Spiel auswählen und über Target starten. Wenn du ein Profil für ein Spiel dort anlegst, verknüpfst du quasi die Spiel-exe mit Target. Sonst funzt das nicht.

Nun die Anleitung habe ich auf Deutsch und auch alles gemacht mit der Verknüpfung und das Spiel über Target starten.

Aber irgendwie ist der Wurm drin???

 

[Magerquark]

Einfach bis zum Release der Beta von SC warten und gut. Kann sich nur noch um Wochen und Tage handeln soon™
Vorher ist das alles irrelevant, was Unterstützung von Gear wie MFDs, Track ir oder PC Ausstattung von CPU, RAM oder benötigen Grafikkarte betrifft. Wie schreibt ihr hier seit 2013: Geduld haben...

 

[Silencium]

Das ist korrekt. Ich erinnere mich noch, dass ich 2012 eine GTX 680 mein Eigen nannte und diese Karte unter High Settings bei den Requirements gelistet wurde. Insofern - warten. Aber für die anderen Spiele ist die 1080Ti auch nice ;-)

Bis auf solche wie 7 days to die, wo auch eine 1080Ti mit 4,5GHz-Proz keine ausreichende Leistung hat um eine Horde ohne Ruckeln, unter "High", darzustellen.

 

[Tharamur]

Nun die Anleitung habe ich auf Deutsch und auch alles gemacht mit der Verknüpfung und das Spiel über Target starten.

Aber irgendwie ist der Wurm drin???

Hm, da kann ich dir dann leider nicht helfen. Ich hatte selber bisher nur etwas rumgespielt. Und da hat es auch dann soweit geklappt. Bin aber mittlerweile wieder dazu übergegangen, direkt im Spiel alles so einzustellen, wie ich das mag. Bzw hab ich das in Elite Dangerous dann so gemacht. Mit 3.0 werde ich mich dann auch in SC intensiv mit der Einstellung der Steuerung befassen. Das wollte ich dann jetzt doch nicht, da mit 3.0 ja eh wieder alles übern Haufen geworfen wird. Ich war bisher nur sehr wenig ingame unterwegs. Hab mir nach dem kauf des Starterpakets damals alles angeschaut und bin auch etwas rumgeflogen. Mehr aber auch dann nicht.