NEWS, SC-LIVE, PIRATE WEEK & MEHR ! GIVEAWAY: APOLLO + LTI ! STAR CITIZEN 4.3.1 GAMEPLAY STREAM @sternenschleuder

Star Citizen: SC Live zu Server-Technologien, Pirate Week & Apollo Giveaway

KnebelTV
- 11.09.25 - 05:57:00 - 13.843 - Star Citizen

• Zusammenfassung
• Original

knebeltv analysiert das aktuelle SC Live, das sich mit Server-Technologien wie Server-Mashing und Persistenz befasst. Parallel laufen die Pirate Week und der PTU-Patch 4.3.1 mit medizinischen Updates. Zudem wird ein RSI Apollo mit LTI verlost. CitizenCon Direct Package wird erwähnt, ebenso Roadmap-Anpassungen und technische Aspekte von Star Citizen.

Star Citizen

00:00:00

Der Stream beginnt mit der Ankündigung des heutigen SC Live mit Benoit, in dem es um Server Mashing, Persistenz und Datenpunkte gehen wird. Parallel dazu läuft die Pirate Week weiter und der neue Patch 4.3.1 mit Medic-Updates und der Onyx ist auf dem PTU verfügbar. Zusätzlich wird auf das RSI Apollo mit LTI Giveaway hingewiesen. Es wird erwähnt, dass Sternensteller läuft, es doppelte Stars und Bonus-Stars gibt. Der Streamer freut sich auf den bevorstehenden Wissen-Kram und bedankt sich für die zahlreichen Follows. Erwähnt wird, dass Benoit ehemals Chef des Studios Turbulent war und nun eine hohe Position bei CIG innehat, zuständig für Technologie, Server-Mashing und das Backend-System. Das SC Live wird mit deutschen Untertiteln gezeigt und die Schatzsuche wird fortgesetzt, wobei der nächste Hinweis auf den Piratencode noch aussteht.

Es wird das CitizenCon Direct Package für Interessierte erwähnt, die ein Goodies Pack erwerben möchten. Die Roadmap wird nur kurz angesprochen, da es keine wesentlichen Neuerungen gab. Der Streamer berichtet von Problemen mit dem Einloggen auf der CIG-Website und dem Issue Council, was er als Account-seitigen Bug vermutet. Ein neuer PTU-Patch 4.3.1 wird für den gleichen Tag angekündigt, in dem das Medical Gameplay getestet werden soll. Es wird kurz auf die Möglichkeit eingegangen, dass jemand versucht, auf den Account zuzugreifen, dies aber ausgeschlossen. Verschiedene Lösungsansätze wie das Löschen von Cache und Cookies wurden bereits erfolglos ausprobiert. Das Problem tritt nur bei CIG auf, was einen Fehler auf deren Seite vermuten lässt.

Es wird die Vorfreude auf das kommende SC Live thematisiert und die Frage aufgeworfen, ob das Interesse an technischen Details bei den Zuschauern vorhanden ist. Der Streamer äußert die Beobachtung, dass Star Citizen im Vergleich zu anderen Spielen ein überdurchschnittliches Interesse an technischen Aspekten hervorruft. Er betont, dass CIG es gut versteht, die technischen Inhalte verständlich zu präsentieren, ohne zu sehr ins Detail zu gehen. Frühere ISC-Formate werden positiv hervorgehoben, insbesondere der Schiff-Talk mit dem Schiff-Team. Der Streamer berichtet von Schwierigkeiten beim Looten des ASD-Brustpanzers und empfiehlt den Ingame-Chat für Tauschgeschäfte. Er testet den Kauf von Munition in Area 18 und den Weg ins Verse von dort aus.

Das SC Live beginnt mit einem Rückblick auf das "Jahr der Spielbarkeit" und die damit verbundenen Fortschritte. Es wird betont, dass der Fokus im vergangenen Jahr auf der Verbesserung der Stabilität und der Behebung von Fehlern lag, anstatt auf der Einführung neuer Features. Dies geschah im Hinblick auf den bevorstehenden Release von Squadron 42. Es wird ein Vergleich zum Vorjahr gezogen, als die Serverleistung deutlich schlechter war und 30k-Fehler häufig auftraten. Durch Static Server Meshing konnte die Serverleistung jedoch erheblich gesteigert werden, wodurch höhere FPS-Werte und eine verbesserte Stabilität erreicht wurden. Es wird hervorgehoben, dass die erreichten Fortschritte nicht als Selbstverständlichkeit angesehen werden, sondern das Ergebnis gezielter Anstrengungen und organisatorischer Veränderungen sind. Die Einführung von "Hero Squads", die sich auf spezifische Problembereiche konzentrieren, sowie die Einbindung von QA-Testern in die Entwicklungsteams haben maßgeblich zur Verbesserung der Spielbarkeit beigetragen. Diese Teams sind stark auf die Auswirkungen auf die Spieler fokussiert und priorisieren entsprechend die Fehlerbehebung.

Es wurden interne Prozesse optimiert, um Fehler besser zu klassifizieren und zu beheben. Ein System wurde eingeführt, bei dem Entwicklerteams Assert-Dialoge, die ihren Bereich betreffen, nicht einfach ignorieren können. Assert-Fehler, die anzeigen, dass ein bestimmter Wert im Code nicht korrekt gesetzt ist, müssen nun vom zuständigen Team behoben werden. Früher konnten diese Fehler ignoriert werden, was zu Problemen führte. Es gibt nun auch ein internes Stabilitätsscore-System, das auf Daten basiert und automatisch für jeden Build berechnet wird. Dieser Score, der von 'optimal' bis 'kritisch instabil' reicht, berücksichtigt Faktoren wie Server- und Client-Abstürze sowie Verbindungsabbrüche. Das Ziel ist, eine möglichst stabile Spielerfahrung zu gewährleisten. Das Stabilitätsscore-System wird kontinuierlich weiterentwickelt, um auch lokale Abstürze und andere Faktoren besser zu berücksichtigen. Die Entscheidung, ob ein Build live geht, basiert unter anderem darauf, ob er stabiler ist als die aktuelle Live-Version. Es wird betont, dass man immer versucht, besser als die Live-Version zu sein, auch wenn nicht immer alles optimal sein kann.

Der Übergang zu einem vierwöchigen Patch-Zyklus hat die Entwicklungsteams stark gefordert, da nun kontinuierlich neue Patches veröffentlicht werden. Dies hat die Geschwindigkeit der Entwicklung deutlich erhöht, wobei in diesem Jahr bereits acht oder neun Patches veröffentlicht wurden, verglichen mit drei oder vier in früheren Jahren. Für 2026 werden Anpassungen des Patch-Zeitplans diskutiert. Um die Stabilität zu verbessern, werden Patches nun aus einem separaten Stream namens 'scpatch' erstellt, der fast keine Technologie-Updates enthält. Dies soll die Content-Teams entlasten und verhindern, dass breaking changes die Entwicklung verlangsamen. Die Session-Länge, also die Zeit, die Spieler im Spiel verbringen, hat sich seit der 3.x-Ära mehr als verdoppelt, was ein Indikator für die Qualität und den Spaßfaktor des Spiels ist. Tech Previews werden genutzt, um neue Technologien und Features zu testen, bevor sie in den Live-Build integriert werden. Die aktuelle Tech Preview beinhaltet Grafikänderungen und Vulkan-Optimierungen, die seit acht bis neun Monaten entwickelt wurden. Zudem gibt es Backend-Tooling-Updates, darunter ein neues Material Edition System und Light Group System für den Editor sowie Upgrades für das Scripting-System, das Missionen steuert (Starscript).

Nach der aktuellen Tech Preview ist die nächste geplante Tech Preview das Engineering Gameplay. Ziel ist es, diese noch vor Ende des Jahres zu veröffentlichen. Die hohe Frequenz an Patches und Tech Previews führt jedoch zu einer Zersplitterung der Spielerschaft, da diese sich entscheiden müssen, ob sie die Live-Version, die PTU-Version oder die Tech Preview spielen möchten. Es wird überlegt, wie man die Teilnahme an PTU und Tech Preview incentivieren kann, ohne dabei einen falschen Anreiz zu schaffen. Eine Herausforderung im Entwicklungsprozess ist, dass die Server nicht einfach täglich zurückgesetzt werden können, da dies nicht alle Probleme behebt. Stattdessen werden Systeme zur Leistungsoptimierung eingesetzt und regelmäßig neue Shards emittiert. Es gibt nun auch regelmäßige Wartungsfenster, typischerweise dienstags, um Hotfixes zu synchronisieren und neue Shards zu erstellen. Diese Wartungsfenster sollen in Zukunft verstärkt genutzt werden.

Vor der Veröffentlichung von Patch 4.3 gab es ein Problem mit dem Wolf-Schiff, das erst kurz vor dem Release entdeckt wurde. Spieler berichteten, dass sie nach dem Aussteigen aus dem Wolf desynchronisiert wurden und die Welt um sie herum verschwand. Das Problem lag an einer Kombination aus Fehlern in den neuen Animationen, der Physik-Engine und der fehlenden Gravitation im Schiff. Nach mehreren Iterationen von Fixes und der Hilfe des 'Bug Smashers' Mark Abin konnte das Problem behoben werden. Um den Fix zu validieren, wurden Spieler auf dem PTU mobilisiert, um das Problem zu reproduzieren. Seit dem Launch von Server Meshing am Ende des letzten Jahres läuft das Spiel in einer Static Server Mesh Umgebung. Das bedeutet, dass das Universum in Zonen aufgeteilt ist, die auf verschiedenen Servern laufen. Jede Zone ist auf einem von zehn Game-Servern verteilt. Die Konfiguration der Server Mesh wird mit jedem Patch angepasst, um Ressourcen dort zu allokieren, wo sie benötigt werden. Neben den Game-Servern gibt es auch den Hybrid, der für die Netzwerkkommunikation zuständig ist. Die Stabilität des Hybriden hat höchste Priorität, da er für die Übertragung von Datenpaketen und die Bindung an Zonen verantwortlich ist. Dynamic Server Meshing soll in Zukunft die Last der Simulation dynamisch auf die verschiedenen Server verteilen.

Dynamisches Server Meshing ermöglicht die Zuweisung eines Servers zu einer Streaming-Gruppe innerhalb einer großen Baumstruktur, wobei jeder Knoten als Streaming-Gruppe von einem Server verwaltet werden kann. Es gibt Parallelen zwischen dynamischem Server Meshing und Instancing, wobei die Mechaniken des Instancing bereits in Form von Instance-Hangars im Spiel vorhanden sind. Diese Technologie ermöglicht es, mehrere gestapelte Hangars zu haben, von denen jedoch nur einer für den Client sichtbar und repliziert wird. Die Instance-Technologie wird Konzepte des dynamischen Server Meshings nutzen, um Instanzen über das Mesh zu verteilen und die Auslastung der Server zu optimieren. Das Ziel ist es, die Verteilung der Simulations- und Rechenlast zu optimieren, um eine bestimmte Leistung zu gewährleisten, wenn ein Spieler eine Instanz betritt. Obwohl die Erhöhung der Spielerzahlen derzeit nicht im Fokus steht, ist es weiterhin geplant, dies in Zukunft zu realisieren, wobei die Priorität auf der korrekten automatischen Verteilung der Funktionalität und der Rechenlast liegt. Im Vergleich zu anderen Spielen, die ebenfalls Server Meshing verwenden, unterscheidet sich der Ansatz von Star Citizen dadurch, dass die Simulation und die Replikation vom Spiel entkoppelt wurden. Die Replikation, also die Synchronisierung zwischen Server und Clients, wird vom Hybrid übernommen, der alle Netzwerkkomponenten und den Zustand des Shards verwaltet. Clients sind mit dem Hybrid verbunden, während die Game-Server als Clients mit Autorität fungieren. Ein weiterer Unterschied besteht darin, dass die Territory Mappings in 3D-Raum erfolgen und nicht in einem Grid, was eine flexiblere Verwaltung der Autorität ermöglicht. Wenn ein Server überlastet ist, kann die Autorität an den übergeordneten Server übertragen werden. Das Ziel ist es, das größte Universum aller Zeiten zu schaffen, was den schwierigsten, aber auch skalierbarsten Ansatz erfordert.

Ein großes Thema waren die Probleme mit Freight Elevators, insbesondere im Zusammenhang mit Obstruktionen. Diese Probleme traten auf, weil die Elevators Gegenstände, die den Durchgang blockierten oder auf dem Dach platziert wurden, als Hindernisse erkannten. Oftmals reichte ein kleines Objekt wie ein MedPen aus, um den gesamten Elevator zu blockieren. Dies lag an fehlerhaften Begrenzungen der Gegenstände, die dazu führten, dass sie in den Elevator hineinragten und fälschlicherweise als Hindernisse erkannt wurden. Um dieses Problem zu beheben, werden nun umfassende Überprüfungen der Gegenstandsbegrenzungen durchgeführt. Ein weiteres Problem war, dass zerstörte Gegenstände, deren Geometrie verschwunden war, weiterhin als Hindernisse galten. Auch die Einrichtung der Freight Elevator-Geometrie selbst war fehlerhaft, insbesondere bei den planetaren Versionen. Ein weiteres Problem bestand darin, dass die Plattform und der Kiosk der Freight Elevators, die für die Verwaltung zuständig sind, aufgrund von Streaming-Problemen die Verbindung zueinander verlieren konnten, was die gesamte Station unbrauchbar machte. Um dies zu beheben, wurde ein Self-Healing-Ansatz eingeführt, bei dem das System versucht, die Verbindung wiederherzustellen. Es gab auch Probleme mit der UI, die nicht mit dem tatsächlichen Inhalt der Plattform synchronisiert war. Dies wurde durch das Streaming und die Reconnection behoben, aber auch durch die UI, die sich mehrfach aktualisiert. Die Freight Elevators verwenden ein Inventarsystem, bei dem Gegenstände entweder verstaut oder entstaut werden können. Es gab Fälle, in denen die Zustände des Containers und der tatsächlich entstauten Gegenstände nicht synchron waren, was durch einen Reparaturmechanismus behoben wurde. Generell wurde festgestellt, dass mehr Multiplayer-Tests erforderlich sind, da viele Probleme erst bei der Interaktion mehrerer Spieler auftraten. Ein wichtiger Aspekt zur Verbesserung der Stabilität ist das Self-Healing, bei dem Systeme Fehlerzustände erkennen und versuchen, diese selbstständig zu beheben. Dies ist besonders nützlich, wenn an einer langfristigen Lösung gearbeitet wird und das aktuelle System am Laufen gehalten werden muss.

Es wurde über Entity Cleanup gesprochen, also das Entfernen von Gegenständen und Fahrzeugen aus der Spielwelt. Hierfür gibt es nun ein vereinheitlichtes System mit Density Classes, die festlegen, wie viele Gegenstände eines bestimmten Typs in einem bestimmten Volumen vorhanden sein dürfen. Designer können diese Density Classes regional anpassen. Es gibt auch eine Lifetime Cleanup, bei der Gegenstände nach einer bestimmten Zeit verschwinden. Verlassene Fahrzeuge werden nach einer bestimmten Zeit (derzeit etwa zwei Stunden) entfernt, wobei größere Schiffe möglicherweise schneller entfernt werden sollen. Das System für verlassene Fahrzeuge wird ebenfalls regional angepasst. Das Pink Slip-System sorgt dafür, dass Schiffe, die sich in einer tiefen Überschneidung mit anderen Objekten befinden, zuerst pink werden und dann verschwinden, um Physikprobleme zu vermeiden. Das Spawn Management von NPCs ist ein weiteres Problem, bei dem es häufig zu Overspawning kommt. Dies liegt an verschiedenen Ursachen, insbesondere an Fehlern in den Mission Modules, die NPCs doppelt initialisieren. Die langfristige Lösung ist ein Population Manager, der weiß, welche NPCs sich bereits in der Spielwelt befinden und entsprechend spawnt. Bis dahin werden zusätzliche Überprüfungen implementiert, um Overspawning zu verhindern. Im Zusammenhang mit Server Meshing gab es auch Probleme mit Interdiction und Beacons. Das Interdiction-System musste angepasst werden, da es zuvor auf der Annahme basierte, dass sich alle Entitäten auf einem Server befinden. Nun wurde ein Entity Cluster Service entwickelt, der eine kleine Datenrepräsentation der Spielwelt bereitstellt und es den Game-Servern ermöglicht, Interdiction über Server hinweg zu koordinieren. Dieser Service wird auch für Beacons verwendet, um Cross-Server- und Cross-Star-System-Funktionalität zu ermöglichen. Medizinische Beacons hatten seit der Einführung von Server Meshing viele Probleme, aber die Technologie zur Behebung dieser Probleme ist nun vorhanden. Es ist geplant, medizinische Beacons wieder zu aktivieren und sie mit dem Entity Cluster Service zu integrieren.

Das Transit System, das Elevators, Züge und andere Transportmittel steuert, war ein ständiges Problem. Zu Beginn des Jahres wurde ein Hero Squad eingesetzt, um diese Probleme zu beheben und Self-Healing-Techniken einzuführen. Self-Healing ist ein Ansatz, bei dem Systeme Funktionen enthalten, um Fehlerzustände zu erkennen und zu beheben. Dies ist besonders nützlich, wenn an einer langfristigen Lösung gearbeitet wird und das aktuelle System am Laufen gehalten werden muss. Das Streaming-System von Star Citizen macht triviale Dinge oft sehr komplex, und es kann schwierig sein, die Ursache eines Problems zu identifizieren. Self-Healing ermöglicht es den Game Developern, eine temporäre Lösung bereitzustellen, während die eigentliche Ursache untersucht wird. Es wurde auch die Frage angesprochen, warum nicht jeder Developer an jedem Problem arbeiten kann. Dies liegt daran, dass es eine Hyper-Spezialisierung gibt und nicht alle Game Programmer für alle Aufgaben austauschbar sind. Die Game Teams sind zwar multidisziplinär, aber für Cross-Disziplin-Aufgaben ist eine konzertierte Anstrengung erforderlich. Abschließend wurde noch erwähnt, dass die Probleme mit Wicklow Rewards untersucht werden und dass das Team aktiv an einer Lösung arbeitet.

Das Transportsystem, eine komplette Überarbeitung des alten Transit-Systems, verfolgt einen neuen Ansatz im Umgang mit Peripheriegeräten wie Gateways und Waggons. Es ist widerstandsfähiger gegenüber Streaming-Problemen und robuster in seiner Entwicklung. Intern wird bereits eine Version genutzt, in der die New Babbage Habs vollständig vom Transportsystem gesteuert werden, was einen wichtigen Meilenstein darstellt. Aktuell wird an der Instanziierung von Transitverbindungen gearbeitet, um dynamische Gateways, wie sie durch instanziierte Hangars entstanden sind, adäquat zu unterstützen. Ziel ist es, Transportverbindungen zu und aus Instanzen zu ermöglichen, was in Zukunft auch für andere Bereiche relevant sein könnte. Langfristig soll das System unter dem Namen 'Starport System' bekannt werden. Der Plan ist, einen kompletten Standort, inklusive Aufzüge und Züge, vollständig über das Starport-System zu steuern und dies als Tech-Preview zu testen. Das System soll unauffällig im Hintergrund arbeiten und die Spieler nicht durch offensichtliche Änderungen stören. Die Funktionalität des ATC (Air Traffic Control) ist zwar cool, aber ähnlich wie Transit verbesserungswürdig. Der Fokus liegt aktuell auf Metriken, um die Stabilität und Wartezeiten zu optimieren. Geplant ist, die Verantwortlichkeiten zwischen ATC und Hangars aufzuteilen, um die Last auf das alte System zu reduzieren und einen Hangar-Manager einzuführen.

Das LTP-System, das entwickelt wurde, um den Fortschritt der Spieler zwischen den Patches zu erhalten, steht vor erheblichen Herausforderungen. Ursprünglich war es ein kleines System, das mit der Skalierung des Spiels und der Einführung von PES 3.18 und Dynamic Server Meshing an seine Grenzen gestoßen ist. Das System speichert Informationen darüber, welche Gegenstände ein Spieler besitzt, in einer separaten Datenbank, die über Patches hinweg erhalten bleibt. Allerdings gibt es zahlreiche Fehlerquellen, die dazu führen können, dass Gegenstände nicht korrekt gespeichert oder wiederhergestellt werden. Ein häufiges Problem ist, dass Gegenstände als Komponenten anderer Objekte gespeichert werden, was zu falschen Einträgen in der LTP-Datenbank führt. Das System ist fragil und anfällig für Fehler, insbesondere bei komplexen Szenarien wie dem Verstauen von Schiffen in anderen Schiffen. Um diese Probleme zu beheben, wird ein neuer Ansatz verfolgt, bei dem die Berechtigungen (Entitlements) der Spieler über Patches hinweg persistent gespeichert werden. Dies soll sicherstellen, dass Spieler immer Zugriff auf ihre gekauften oder verdienten Schiffe haben. Das bedeutet, dass die Liste der Schiffe im ASOP-Terminal auch nach einem Patch unverändert bleibt. Die Implementierung dieser Lösung ist komplex und erfordert umfangreiche Tests, um sicherzustellen, dass sie robust und zuverlässig ist. Als Übergangslösung könnte eine ähnliche Maßnahme wie in Patch 4.2.1 wiederholt werden, um den Verlust von Schiffen zu reduzieren.

Das Checkout- und Stow-System spielt eine entscheidende Rolle bei der Long-Term Persistence (LTP). Wenn ein Spieler ein Schiff in seinem Hangar verstaut, wird es zunächst aus der Spielwelt entfernt und in das Inventarsystem verschoben. Wenn der Spieler das Inventar besitzt, in dem das Schiff gelagert wird, wird ein LTP-Eintrag erstellt. Dieser Eintrag stellt sicher, dass das Schiff auch nach einem Patch wiederhergestellt werden kann. Allerdings gibt es viele Bereiche, in denen Schiffe erstellt werden, wenn sie bereits gelagert sind, oder in denen Reparaturen und Modifikationen durchgeführt werden. In diesen Fällen wird möglicherweise kein LTP-Eintrag erstellt oder er wird falsch interpretiert. Beim Verstauen von Gegenständen wird nicht nur das Schiff selbst, sondern auch die gesamte Baumstruktur des Schiffs berücksichtigt. Das bedeutet, dass auch alle Gegenstände, die sich im Schiff befinden und für die LTP aktiviert ist, gespeichert werden. Designer legen fest, welche Gegenstände über Patches hinweg gespeichert werden sollen und welche nicht. Um die Probleme mit dem Stow-System zu beheben, ist eine Überarbeitung im Rahmen des Item Imprint Epic geplant. Anstatt zu versuchen, alle Daten aus dem GameState abzugleichen, sollen zukünftig die Berechtigungen (Entitlements) der Spieler persistent gespeichert werden. Dies soll sicherstellen, dass Spieler immer Zugriff auf ihre Schiffe haben, unabhängig davon, wie sie diese erworben haben.

Zukünftig sollen beim Erwerb eines Schiffes durch legitime Mittel (Kauf, Missionen, etc.) Entitlement Records erstellt werden, ähnlich wie bei Käufen im Webstore. Diese Records werden in einer separaten Datenbank gespeichert und garantieren, dass der Spieler auch nach einem Patch Zugriff auf sein Schiff hat. Diese Änderung betrifft vorerst nur Schiffe, nicht aber andere Gegenstände. Turbulent, ein Teil von Turbulent, wird in Cloud Imperium Games Montreal umbenannt. Diese Anpassung soll die Integration der Teams vereinfachen und eine einheitliche Botschaft vermitteln. Die Teams arbeiten bereits eng zusammen und der Austausch zwischen den Standorten ist positiv. Es gibt keine Pläne, Squadron 42 auf der CitizenCon Direct vorzustellen. Das Team arbeitet weiterhin intensiv an dem Spiel und möchte sich nicht von externen Veranstaltungen ablenken lassen. Es wird betont, dass die Ressourcen nicht ausschließlich auf Squadron 42 konzentriert sind, sondern dass beide Spiele (Star Citizen und Squadron 42) gleichermaßen vorangetrieben werden. Sobald der Zeitpunkt für Squadron 42 gekommen ist, wird es eine umfassende Marketingkampagne geben. Die Entscheidung, weniger ISC- und SCL-Formate zu produzieren, ist Teil der Reorganisation und soll den Fokus der Teams auf die Entwicklung der Spiele lenken.

Nach der Vulkan Tech Preview ist eine Ingenieurs Gameplay Tech Preview geplant, voraussichtlich nach der CitizenCon. Das Team erkannte, dass zu wenige Tester für PTU und Tech Previews vorhanden sind und erwägt Belohnungen für Tester, wie z.B. die Übertragung eines Teils des Fortschritts auf die Live-Server. Wöchentliche Serverwartungen mit Neustarts und Hotfixes sind geplant, idealerweise jeden Dienstag, um die Stabilität zu verbessern. Dynamisches Server-Mashing ist in aktiver Entwicklung, um Streaming-Gruppen dynamisch eigene Server zuzuweisen. Aktuell gibt es einen Server für Hurston und seine Monde, aber mit dynamischem Server-Mashing könnte beispielsweise der Mond Clio einen eigenen Server erhalten, der bei Ausfall vom Hurston-Server übernommen wird. Dungeons und Co. sollen ebenfalls auf diese Weise funktionieren, wobei jede Instanz einen eigenen Miniserver erhält.

Es wird der Unterschied zwischen dem Server-Meshing in Star Citizen und anderen Spielen wie Dune Awakening erklärt. Bei Dune gibt es mehrere Server, und Spieler können zwischen diesen wechseln, wobei der jeweilige Server die Autorität über die Spieler hat. Bei Star Citizen hingegen haben alle Spieler quasi die gleiche Farbe, da nicht der Server, auf dem sie sich befinden, die Autorität hat, sondern der Replication Layer (RL). Dieser Hybrid-Dienst kontrolliert die Spielwelt, und die Server sind Teile des Replication Layers. Dadurch kann CRG dynamisch neue Server erstellen, wenn viele Spieler an einem Ort sind, ohne dass die Spieler etwas davon merken, da sie alle am Replication Layer hängen. Dies gilt auch für Objekte, NPCs und Schiffe, die bei Bedarf dynamisch einen eigenen Server erhalten.

Es gab Informationen zu den größten Bugs, darunter Probleme mit Frachtaufzügen, für die diverse Checksysteme implementiert wurden, um Blocker zu lösen und das Grid automatisch zu reparieren. Der Density Manager, der für das Aufräumen bei zu vielen Objekten zuständig ist, wurde vereinheitlicht und soll nach Zeit, Volumen oder Location aufräumen. Das Ziel ist, dass ungenutzte Objekte und Schiffe nach zwei Stunden entfernt werden. Ein weiteres Problem ist die zu hohe Anzahl an NPCs und Respawns in allen Locations, was am Missionssystem liegt, das die Population festlegt, um die Herausforderung für die Spieler konstant zu halten. Hier wird an einer Verbesserung gearbeitet.

Es wird ein neues System für Ingame-Vehikel-Persistenz eingeführt, bei dem durch Ingame-Käufe erworbene Fahrzeuge in einer neuen Datenbank gespeichert und bei neuen Patches wiederhergestellt werden, ähnlich wie Echtgeld-Items. Dies betrifft jedoch nicht Ingame gefundene Items, für die eine Itemversicherung geplant ist. Die Apollo kommt in den aktuellen Patch, inklusive aller Module. Es wird eine Apollo Medivac mit LTI verlost, für die man sich bis zu 160 Tickets im angepinnten Kommentar ziehen kann. Doppelte Stars und doppelte Boni sind für Abos und das Zuschauen aktiv. Es gab keine neuen Informationen zu Base-Building oder Crafting, und zur CitizenCon wird es keine Rolle spielen. Der Fokus liegt auf Star Citizen und einem Ausblick auf die Features und Inhalte für das vierte Quartal 2025 und das Jahr 2026.

Es gibt spannende Infos zum Thema Framerate und Vulkan. Tenpon42 hat im Tech-Preview Tests durchgeführt und einen deutlichen Zuwachs der Framerate unter Vulkan festgestellt. Die 1% Low FPS sind um einiges besser als bei DX11. Es wurden auch optische Tests mit dem neuen DLSS durchgeführt, die zeigen, dass der Quality-Mode im neuen Transition Model fast genauso gut aussieht wie natives 4K. Der DLSS im Quality-Mode verdoppelt fast die Frames bei fast gleicher Qualität. Die Vulkan-Updates und DLSS-Verbesserungen sind besonders für Nutzer von Nvidia-Karten von Vorteil. Es wird darauf hingewiesen, dass Standbilder mehr aussagen als bewegte Bilder, da man im Standbild die Qualität besser vergleichen kann.

Es wird betont, dass in Star Citizen viel passiert ist und das Spiel heute viel besser spielbar ist als noch vor einem Jahr. Das SC-Live hat deutlich zur Transparenz beigetragen und fast alle Themen angesprochen. Das SC-Live wird als das beste in diesem Jahr bezeichnet, da es uns alle betrifft. Der Piraten-Code ist noch nicht geknackt, und es gibt noch keinen weiteren Hinweis. Es wird empfohlen, sich bei Stream-Elements neu einzuloggen, wenn die Stars nicht zählen. Die Zählung der Stars wurde auf dem 2-Channel auf 6 Minuten reduziert, um Probleme zu beheben. Es wird empfohlen, den Tech Preview mit alter Hardware zu testen, um zu sehen, ob die Updates Verbesserungen bringen. DLSS wird empfohlen, wenn man eine NVIDIA-Karte hat, da es optisch keine relevante Verschlechterung gibt und man wesentlich mehr Frames hat.

Es wird diskutiert, ob man sich extra eine 50er Grafikkarte kaufen sollte, und betont, dass dies jeder für sich selbst entscheiden muss. Es wird angemerkt, dass FSR kaum Priorität hat, weil AMD-Grafikkarten im Gaming-Bereich nicht sehr verbreitet sind. Es wird vermutet, dass FSR 4 nicht mit Vulkan funktioniert, was ein Grund sein könnte, warum es nicht so vorangetrieben wird. Nvidia ist mit DLSS ziemlich stark. Es wird betont, dass Star Citizen das Potenzial für High-End hat und man später auch mit einem Mittelklasse-Rechner zocken kann, aber dann nicht in 4K mit Raytracing. Bei CPUs wird AMD bevorzugt, während bei Grafikkarten Nvidia eher für Raytracing empfohlen wird. Es wird betont, dass man kaufen soll, was Preis-Leistungstechnisch für einen Sinn macht.

Es wird ein Workaround für ein Problem mit der neuen ASD-Rüstung gefunden, bei dem man das Mobi-Glas nicht benutzen kann. Der Workaround ist, die Arme der Rüstung in den Rucksack zu legen. Die Rüstung bekommt man im dritten Flügel. Es wird diskutiert, wie viel Damage Reduction die Rüstung hat und dass die Tooltips noch fehlen. Es wird angemerkt, dass es aktuell drei Rüstungstypen in Star Citizen gibt: Leicht, Mittel und Schwer, und alle Schweren haben die gleichen Stats, bis die Itemization ins Spiel kommt. Es wird mit der Quest im Engineering begonnen.

Es wird über den Batterieraum gesprochen und darauf hingewiesen, dass ein Video dazu auf YouTube verfügbar ist. Es folgt eine Diskussion über negative Kommentare zu PTU-Videos, wobei Unverständnis darüber geäußert wird, dass Inhalte als Spoiler wahrgenommen werden. Die veränderte Community seit Corona wird angesprochen, wobei eine Zunahme von negativen Reaktionen festgestellt wird. Es wird betont, dass man es nicht jedem recht machen kann und dass eine Akzeptanz von 97% der Community ausreichend ist. Abschließend wird sich bei Zuschauern für Abonnements bedankt und auf das Einfügen von Batterien hingewiesen.

Es wird ein bevorstehendes Community-Event angekündigt, das voraussichtlich am nächsten Sonntag stattfinden wird. Anschließend wird auf die Problematik von Spoilern eingegangen, insbesondere im Bezug auf den Discord-Server. Es wird erklärt, warum im Discord ein spezieller PTU-Channel existiert, um Spoiler zu vermeiden und den Nutzern die Wahl zu lassen, ob sie gespoilert werden möchten oder nicht. Der Respekt gegenüber den Spielern, die Spoiler vermeiden möchten, wird betont. Es wird ein Beispiel genannt, wie im eigenen Video bewusst auf ein bestimmtes Bild verzichtet wurde, um nicht zu spoilern. Es wird klargestellt, dass bei offiziellen Ankündigungen, wie z.B. der Veröffentlichung eines neuen Schiffs, natürlich Bilder verwendet werden.

Es werden verschiedene Locations im Spiel erkundet, darunter die Test-Chamber und ein Gebiet mit Zombies. Dabei werden Gameplay-Elemente wie das Stabilisieren von Objekten und das Aktivieren von Mechanismen ausprobiert. Es wird festgestellt, dass einige Features noch nicht wie erwartet funktionieren. Der verbesserte Respawn wird positiv hervorgehoben. Es folgt ein Test der Regenerationsanalyse bei den Zombies. Es wird die Verbindung zwischen Spiel und Real Life hervorgehoben und über das ewige Leben philosophiert. Es wird über einen Bug berichtet, der zu einem unerwarteten Wegporten führte. Abschließend wird auf die Möglichkeit hingewiesen, Untertitel in deutscher Sprache zu aktivieren.

Es wird ein Raum mit einem Vendul erkundet und dessen Aussehen im Detail betrachtet. Es wird spekuliert, dass der Patch erst Ende nächster Woche live geht, da noch Inhalte fehlen. Anschließend wird ein Experiment durchgeführt, bei dem ein Knopf gedrückt wird, was jedoch unspektakulär verläuft und zu Strahlung führt. Es folgt ein Test des neuen Heilungssystems mit verschiedenen Verletzungsstufen und Schiffen. Dabei wird festgestellt, dass das UI zwar funktioniert, aber die Kosten für die Heilung verbuggt sind, da unabhängig von der Anzahl und Schwere der Verletzungen immer der gleiche Betrag abgezogen wird. Es wird kritisiert, dass die Idris ihr Tier 1 Bett verliert und dies als reinen Marketing-Move zugunsten der Apollo gesehen wird. Abschließend wird die Community aufgefordert, Feedback zu diesem Thema auf Spectrum zu geben.