Doch die letzten Tage erweckten zumindest den Eindruck, dass das Studio daraus die richtigen Schlüsse gezogen hat. Da wäre zum einen die scheinbare Verschiebung der Alpha 4.10 (welcher eine Verbesserung darstellt) um zwei Wochen, zum anderen aber auch die Worte, die CIG-CEO Chris Roberts in seinem neuesten "Letter from the Chairman“ zum Thema Kommunikation gefunden hat.
In dieser Woche gab es aber noch zwei weitere Beiträge der Entwickler, die ebenfalls auf eine Verhaltensänderung seitens des Studios hindeuten.
Inhaltsverzeichnis
Improving the Live Experience
Die wichtigsten Bug Fixes der Alpha 4.10
So geht es bei CIG weiter
Inside CIG - Ein neues Youtube Format
Improving the Live Experience
Unter diesem Titel veröffentlichte Cloud Imperium Games parallel zum Release der Alpha 4.10 einen Blogeintrag, in dem das Unternehmen genauer auf jene Dinge einging, die im Zuge des Patches angegangen wurden.
Allgemein ist es das Ziel des Unternehmens, einen gemeldeten Bug nicht mehr einfach nur zu beseitigen, sondern dessen Ursache herauszufinden und ebenfalls zu beheben. Dies dauert zwar länger, sorgt aber insgesamt für ein langfristig besseres Spielerlebnis.
Um die Probleme zu priorisieren, kommen mittlerweile zweimal pro Woche verschiedene Teams von CIG zusammen. Bei der Priorisierung werden mehrere Faktoren berücksichtigt, darunter die Häufigkeit, interne Erkenntnisse, der Zeitpunkt des erstmaligen Auftretens und natürlich die Auswirkungen des Bugs.
Im Zuge der Entwicklung der Alpha 4.10 kamen so 1.239 behobene Bugs zusammen. Darunter waren auch Bugs, die während der Tests des Patches gemeldet wurden. 479 davon stammten jedoch aus vorherigen Patches und wurden daher explizit in den Patchnotes erwähnt.
Zusätzlich wurde auch an der Leistung des Clients gearbeitet. Die durchschnittliche Bildrate soll mit dem neuen Update gerade in den Landezonen um 15 % gestiegen sein.
Die wichtigsten Bug Fixes der Alpha 4.10
Im selben Beitrag hat Cloud Imperium Games außerdem die wichtigsten Bugs und Probleme genannt, die die Teams in den vergangenen Wochen angegangen sind. Exploits wurden in diesem Zusammenhang nicht näher erläutert, einige von ihnen jedoch ebenfalls beseitigt.
Leere Inventare
Das hat sich als drei separate Probleme herausgestellt:
Das sichtbare Symptom bestand darin, dass sich "ausstehende Verschiebungen“ anhäuften. Jede Inventarinteraktion fügte eine weitere hinzu; sie wurden nie abgeschlossen. Sobald die Warteschlange feststeckte, erschien das Inventar beim nächsten Öffnen leer. Die Ursache war, dass die erste Einlagerungsanfrage an den Dienst wegen einer Zeitüberschreitung abgebrochen wurde. Der anschließende Wiederholungsversuch lieferte die Antwort "existiert bereits“. Das bedeutete, dass die ursprüngliche Anfrage tatsächlich erfolgreich gewesen war und wir lediglich keine Bestätigung erhalten hatten. Da "existiert bereits“ kein Fehler ist, bei dem ein erneuter Versuch sinnvoll wäre, gab der Client an diesem Punkt auf, und die Verschiebung blieb unbegrenzt ausstehend.
Das zweite Problem bestand darin, dass es keinen Ladestatus gab, sodass ein gerade geladenes Inventar genauso aussah wie ein defektes.
Drittens blieb das Raster während des Ladevorgangs interaktiv, sodass die Spieler zusätzlich fehlschlagende Anfragen zu den bereits feststeckenden hinzufügen konnten.
Alle drei Probleme wurden behoben, indem CIG die Ereignisverarbeitung im zuständigen Service korrigiert und das Zeitüberschreitungslimit reduziert hat. Zusätzlich wurde ein Lade-Widget hinzugefügt, das die Interaktion blockiert, während eine Verschiebung abgeschlossen wird. Dadurch änderte sich die Wahrnehmung von “Mein Inventar ist weg“ zu ”Mein Inventar wird geladen“.
Schiff verschwindet nach dem Landen im Hangar direkt
Mit Server-Meshing kann eine einzelne Entität gleichzeitig auf mehr als einen Server gestreamt werden. Das sollte nicht häufig vorkommen, tritt jedoch in der Nähe von Servergrenzen und bei Entitäten mit sehr großen Streaming-Radien auf. Levski erwies sich als besonders anfällig dafür. Der Code, der entscheidet, ob ein Schiff eingelagert werden soll, war an eine Prüfung namens IsAuthorityPossible() gebunden. Das Problem bestand darin, dass diese Prüfung auf jedem Server true zurückgibt – und nicht nur auf dem Server, der tatsächlich den Hangar besitzt.
Um die eigentliche Ursache zu finden, waren zwei Durchläufe nötig. Der erste zeigte, dass die Nachverfolgung weder erfasste, warum ein Fahrzeug eingelagert worden war, noch, welcher Server dies veranlasst hatte. Schlimmer noch: Mehrere Codepfade – darunter die Beschlagnahmung nicht besessener Fahrzeuge und die Bergung über Frachtaufzüge – lagerten Fahrzeuge ein, während sie die Standardfunktion vollständig umgingen, sodass überhaupt keine Spur hinterlassen wurde. CIG behob zunächst dieses Problem, sodass jede Einlagerungsanforderung nun über eine einzige Funktion läuft, einen Grund protokolliert und meldet, welcher Server sie initiiert hat. Diese zusätzliche Protokollierung machte den Fehler bei der Zuständigkeitsprüfung schließlich sichtbar.
Die eigentliche Lösung bestand darin, die fehlerhafte Prüfung im Bereinigungspfad des Landebereichs durch eine echte Besitzprüfung zu ersetzen: HasAuthority(). Ein gutes Beispiel für eine relativ unkomplizierte Fehlerbehebung, die erst erkennbar wurde, nachdem sich die wahre Natur des Fehlers gezeigt hatte.
Schiffe gehen verloren
Schiffe konnten verschwinden und direkt nach der Landung in einem Stationshangar oder nach dessen Verlassen (z. B. in Levski) auf dem ASOP-Terminal als "eingelagert“ angezeigt werden, wodurch der Pilot zu Boden fiel. Ursache war eine Race Condition, bei der zwei separate Prozesse gleichzeitig versuchen konnten, dasselbe Fahrzeug zu zerstören und erneut einzulagern. Dies konnte unter anderem ausgelöst werden, wenn Schiffe mit einer fehlerhaften Zonen- oder Zugriffskennung gespawnt wurden. Die Fehlerbehebung ergänzt eine Prüfung, die verhindert, dass ein Fahrzeug abgebaut wird, während es bereits an anderer Stelle eingelagert wird.
Beim Abrufen eines Schiffs aus einem Hangar konnte es bereits mitten in einem Quantensprung erscheinen und in dem Moment, in dem die Aufzuganimation des Schiffs endete, in das Hangartor oder gegen die Wände fliegen. Das zugrunde liegende Problem bestand darin, dass ein Schiff beim Spawnen einen laufenden Quantentransit fortsetzen konnte, selbst wenn es innerhalb eines geschlossenen Hangars materialisiert wurde. Die Fehlerbehebung verhindert nun, dass der Quantentransit bei Schiffen fortgesetzt wird, die in geschlossenen Bereichen spawnen. Nachfolgende Tests mit mehreren Stationen und Schiffen ergaben keine weiteren Reproduktionen.
Das ASOP-Terminal in Stationslobbys konnte fälschlicherweise anzeigen, dass ein Schiff "beansprucht“ werden müsse, obwohl es sicher auf seinem Stellplatz eingelagert war. ASOP überprüfte bisher nur den direkten Lagerstatus des Schiffs. Ein eingelagertes Schiff befindet sich jedoch tatsächlich als untergeordnetes Objekt im Hangar. Wenn der Hangar den Einlagerungsvorgang abschloss, während der Spieler bereits zu weit entfernt war, verlor ASOP den Überblick darüber. Die Fehlerbehebung stellt sicher, dass ASOP nun auch das Inventar des Hangars direkt überprüft.
Hangar & ASOP-Terminal
Hangartore an einigen Stationen konnten dazu führen, dass das Außentor geschlossen blieb, während sich das Innentor öffnete, wodurch Spieler aus dem Hangar ausgesperrt oder darin eingeschlossen wurden Die Außen- und Innentore des Hangars waren im Backend nicht korrekt miteinander verknüpft, sodass sich eines unabhängig vom anderen öffnen konnte – etwa an Stationen wie Stanton Gateway, Ruin Station und Orbituary. Die Verknüpfungen zwischen dem Hangar und seinen Toren wurden wiederhergestellt, sodass sich beide nun korrekt gleichzeitig öffnen.
Gefördertes Erz verschwand, nachdem ein Bergbauschiff in einem Hangar eingelagert wurde Die Ursache lag in der Backend-Datenbank, die die Schiffsfracht verwaltet und unter hoher Auslastung instabil wurde. Dadurch konnte der Frachtcontainer eines Bergbauschiffs beim Einlagern und Abrufen auf einen früheren Zustand zurückgesetzt werden. Eine Korrektur im Backend behob die Instabilität und stellt nun sicher, dass das Erz auch nach der Einlagerung erhalten bleibt.
Treibstoff in externen Treibstofftanks ging beim Einlagern eines Schiffs über ASOP verloren Dies hatte dieselbe Ursache wie der oben beschriebene Fehler mit dem verlorenen Erz: Das Backend verlor während des Einlagerungsvorgangs den Überblick über gespeicherte Daten. Der Fehler wurde durch dieselbe Korrektur behoben.
Das Abrufen eines Schiffs, das eine andere Hangargröße benötigte als ein bereits eingelagertes Schiff, konnte fehlschlagen, zu einer automatischen Einlagerung führen oder das Schiff zerstören Das Spiel unterstützte pro Spieler gleichzeitig nur eine instanzierte Hangargröße. Wurde eine anders große Hangarinstanz angefordert, während eine andere verwendet wurde, konnte dies unbemerkt fehlschlagen oder im schlimmsten Fall das ankommende Schiff zerstören. Die Korrektur beendet nun ordnungsgemäß die alte Hangarinstanz und erstellt eine Hangarinstanz mit der richtigen Größe. Eine nachfolgende Korrektur verhindert außerdem, dass Aufzüge Spieler in veraltete Hangarinstanzen leiten, die bereits entladen wurden. Dadurch wurden Schiffe zuvor fälschlicherweise als "beanspruchbar“ angezeigt.
Spieler ohne Helm konnten in bestimmten Hangar-Servicebereichen und Aufzugsbereichen auf Levski ersticken Einige Servicebereiche der Hangars waren nicht vollständig mit Atmosphäre versorgt. Die Atmosphärenabdeckung wurde nun auf diese Bereiche ausgeweitet, wodurch das Problem behoben wird.
Frachtaufzüge
Frachtaufzugsplattformen konnten dauerhaft auf dem Bildschirm "Übertragung läuft …“ hängen bleiben, nachdem Missionsfracht wiederholt angehoben und abgesenkt worden war, wodurch der Zugriff vollständig blockiert wurde. Ursache war, dass das Sammelziel einer Mission bereits nach dem Aufnehmen eines Teils der erforderlichen Gegenstandsmenge als abgeschlossen galt. Das Zurücklegen der Gegenstände setzte dieses Ziel nicht zurück, wodurch der Übertragungsstatus des Aufzugs beschädigt wurde. Die Lösung verschiebt erneut eingelagerten Missionsgegenstände nun ins persönliche Inventar, statt sie wieder der Mission zuzuordnen, und vermeidet so den Konflikt. In einem späteren Folgefix wurde außerdem ein Sonderfall behoben, der eine leere Übertragungsanfrage in die Warteschlange stellen konnte. Bei Tests konnte das Problem anschließend an zahlreichen Orten und mit vielen Missionstypen nicht mehr reproduziert werden.
Missionsfracht für Transportmissionen konnte am Abholort vollständig fehlen, wodurch der Abschluss der Mission unmöglich war. Ursache war eine Race Condition im Backend: Eine Aktualisierung der Inventarmenge konnte neuere Frachtdaten mit einer veralteten, zwischengespeicherten Kopie überschreiben. Der Warehouse Manager, der diesen Ablauf verarbeitet, wurde überarbeitet und verarbeitet solche Aktualisierungen nun in der korrekten Reihenfolge, um das Überschreiben zu verhindern. Bei anschließenden Tests traten keine weiteren Fehler auf.
Die Meldung "Aufzug überladen“ machte nicht deutlich, dass tatsächlich eine teilweise Frachtübertragung stattgefunden hatte. Dies sorgte bei den Spielern für Verwirrung darüber, welche Gegenstände auf die Plattform gelangt waren. Die Formulierung wurde angepasst, um klarzustellen, dass eine teilweise Übertragung stattgefunden hat. Ein separates, noch offenes Problem verfolgt weiterhin die zugrunde liegende fehlerhafte Kapazitätsberechnung, durch die die Meldung unnötigerweise ausgelöst werden kann.
Die Abgabe von Eiern des borealen Quasi-Grasers an einem Frachtaufzug während der Inhalte des Nyx-Missionspakets 2 schloss die Ressourcensammelmission nicht ab. Ursache waren fehlende Standardkonfigurationsdaten am zugrunde liegenden Objekt der Kreatur, nachdem sich ein früherer Lösungsversuch als unwirksam erwiesen hatte. Ein korrigierter Fix wurde inzwischen verifiziert.
Inventar
Das persönliche Inventar, das Stationsinventar oder das Beuteinventar konnte vollständig geleert und für mehrere Minuten unzugänglich werden. Dadurch wurde das Aufnehmen und Ablegen von Missionsgegenständen verhindert. Die Ursache waren gelegentlich ablaufende Backend-"Stow“-Anfragen, die nicht abgeschlossen wurden. Dadurch sammelten sich ausstehende Verschiebungen an, und das Inventar erschien leer. Eine clientseitige Lösung zeigt nun einen Ladeindikator an, während dieses Problem behoben wird.
Durch einen Doppelklick auf ein Rüstungsteil im Inventar konnte gleichzeitig ein angrenzender Gegenstand angelegt werden. Dadurch konnte der Slot für den Unteranzug vollständig verschwinden, sodass die Spielfigur ihre Ausrüstung nicht mehr ablegen konnte. Dies wurde durch dasselbe Problem verursacht wie ein früherer Fehler beim Anlegen von Rüstung. Nachdem dieser Fehler vollständig behoben worden war, bestätigten Tests, dass das Problem nicht mehr auftrat.
Beim Anlegen bestimmter Unteranzüge, insbesondere nach der Entlassung aus Klescher, verschwand das Symbol für den Unteranzug-Slot aus der Inventaroberfläche. Dadurch konnten Spieler keine Unteranzüge mehr wechseln. Die Ursache war ein Hemd, das vor dem Betreten von Klescher getragen und nicht tatsächlich abgelegt worden war, wodurch es zu einem Konflikt mit dem Unteranzug-Slot kam. Eine Lösung entfernt das Hemd nun beim Betreten des Gefängnisses ordnungsgemäß.
Einige Schlüsselkarten und Festplatten konnten bei der Interaktion verschwinden und blieben verborgen, bis ein anderer Gegenstand aufgenommen wurde. Diese Gegenstände waren ausschließlich zum Tragen vorgesehen, verfügten jedoch fälschlicherweise über die Interaktionsoption "Anlegen“. Dadurch gelangten sie in einen Zwischenzustand, anstatt normal getragen zu werden. Die Option "Anlegen“ wurde für die betroffenen Schlüsselkarten und Festplatten entfernt.
Wenn im Inventar bei bereits gehaltenem Gegenstand, etwa einem Multitool, auf "Tragen“ geklickt wurde, spielte das Spiel eine Verstau-Animation ab, ließ den gehaltenen Gegenstand jedoch vollständig verschwinden. Die Ursache war, dass die "Tragen“-Interaktion bereits gehaltene Gegenstände nicht korrekt verarbeitete und sie in einem internen Container statt im persönlichen Inventar verstaute. Die Verarbeitung wurde korrigiert, und eine Validierung wurde hinzugefügt, um zu verhindern, dass Gegenstände auf diese Weise verloren gehen.
Die Kategoriefiltermenüs an Inventar-, Fracht- und Herstellungsterminals konnten beim schnellen Überfahren oder Anklicken geöffnet bleiben und sich überlagern, wodurch sich mehrere Menüs auf der Benutzeroberfläche stapelten. Ursache war ein Hover-Status, der nicht zurückgesetzt wurde, wenn der Cursor den Filter-Button zu schnell verließ. Dadurch blieben alte Menüs sichtbar. Eine Lösung schließt nun alle anderen geöffneten Menüs zwangsweise, sobald ein neues geöffnet wird.
Bestimmte Waffen wurden direkt nach dem Anlegen in den Ausrüstungsslots und der Beuteoberfläche als schwarze Silhouetten angezeigt, bis das Inventar geschlossen und erneut geöffnet wurde. Das Problem wurde durch eine Korrektur der Darstellung behoben.
Das Ziehen oder Verschieben geplünderter Gegenstände per Umschaltklick in Rucksack- oder Körperschutz-Slots schlug an vielen Orten fehl. Das betroffene Oberflächenpanel benötigte einen anderen Darstellungsmodus, damit Ziehereignisse korrekt registriert werden.
Die Schaltfläche "Kaufen“ am Raffinerie-Shop-Terminal in Nyx auf Levski war optisch falsch ausgerichtet, wodurch präzises Anklicken erschwert wurde. Dies wurde durch eine Korrektur der Position auf dem Bildschirm behoben.
Das Aufteilen eines Gegenstandsstapels im persönlichen Inventar und anschließende Wiederzusammenführen konnte das Inventar in einen fehlerhaften Zustand versetzen. Die Ursache war, dass aufgeteilte Gegenstände bis zur Aktualisierung des lokalen Caches doppelte interne IDs behielten. Zusätzlich wurde das Problem dadurch verschärft, dass Loadouts Gegenstände ohne korrekte Sortierreihenfolge hinterließen. Mehrere Korrekturen behoben beide Ursachen, und umfangreiche Tests bestätigten die Stabilität.
Neu aufgenommene Gegenstände, etwa Sicherungen oder Erz, konnten erst aus dem Inventar platziert werden, nachdem der Spieler das Inventar einmal geöffnet und wieder geschlossen hatte. Die Ursache war ein veralteter Inventar-Cache. Korrekturen aktualisieren den Cache nun ordnungsgemäß, wenn ein Gegenstand aufgenommen wird, und entfernen eine alte Übergangslösung, durch die das Drücken der ESC-Taste den Cache ungültig machte.
Beim Auffüllen der Munition wurden nur Magazine aus den Körperschutz-Slots verwendet; zusätzliche Magazine im Rucksack wurden ignoriert. Dies wurde durch dasselbe Problem mit dem veralteten Inventar-Cache verursacht wie der Fehler beim Platzieren aus dem Inventar und durch dieselbe Korrektur behoben.
Login & Verbindungsprobleme
Spieler werden beim Versuch, in das Persistent Universe zu laden, mit einem 64008-"Spawn Resolver Error“ ins Hauptmenü zurückgeworfen Im Laufe der Zeit gab es zwei separate Ursachen: Eine frühere Welle wurde durch einen fehlerhaften Datenausschluss verursacht, während ein späteres Wiederaufflammen auf eine Backend-Desynchronisierung des Kontostatus der Spieler zurückzuführen war, die auch 64006-Verbindungsabbrüche auslösen konnte. Eine Korrektur am Backend-Service behob die Hauptursache.
Spieler bleiben mit einem 60029-Fehler hängen und können dem Persistent Universe nicht beitreten Bei den betroffenen Konten befanden sich die Charakterdaten im Backend in einem fehlerhaften Zustand und waren effektiv gleichzeitig an zwei Orten "verstaut“. Eine Korrektur am Backend-Service behob das zugrunde liegende Problem. Bereits betroffene Konten wurden mithilfe von Support-Tools manuell repariert.
Ein 64010-Spawn-Fehler, bei dem Spieler nach mehr als zwölf Minuten Wartezeit auf die Auflösung ihres letzten bekannten Aufenthaltsorts durch den Server einen Timeout erhielten Die Ursache waren Durchsatz- und Verfügbarkeitsgrenzen des Backend-Services, der für die Ermittlung der Spielerpositionen zuständig ist, und kein clientseitiges Problem. Dieses Problem wurde durch Verbesserungen am Backend-Service behoben.
Ein 64006-Verbindungsabbruch ("Location Resolution Request failed“), der auftrat, wenn das Backend beim Anmelden den Charakterdatensatz eines Spielers nicht finden konnte, um ihn wieder online zu bringen Dabei handelte es sich um eine vorübergehende Desynchronisierung bei der Nachverfolgung des Kontostatus im Backend und nicht um einen tatsächlichen Verlust von Charakterdaten. Das Problem konnte sich nach wenigen Sekunden oder erst nach etwa 15 Stunden von selbst beheben. Es war für den Großteil einer damit verbundenen Welle von 64008-Fehlern verantwortlich; beide Probleme werden durch dieselbe Korrektur am Backend-Service behoben.
Quantum-Reise & Starmap
Die Quantumreise-Routenplanung aus einem Stationshangar schlug fehl, wenn sich das Ziel nicht in direkter Sichtlinie befand. Die Station selbst blockierte die Routenberechnung, weil Stationen mit einem Kartentyp versehen waren, bei dem Navigationspunkte deaktiviert sind. Durch das Aktivieren von Navigationspunkten für Stationen funktioniert die Routenplanung aus Hangars nun.
Das Anklicken einer verfolgten Missionsmarkierung auf der Starmap zoomte die Kamera viel zu nah heran. Die Zoomdistanz wurde anhand des winzigen Radius der Markierung selbst berechnet, anstatt anhand eines sinnvoll dimensionierten Objekts in der Nähe. Die Korrektur berechnet die Zoom- und Fokusdistanz nun anhand eines geeigneteren Referenzobjekts.
Gruppenmitglieder erhielten jedes Mal eine "Verbunden“-Benachrichtigung, wenn sich die Serverautorität eines Teammitglieds änderte, und nicht nur beim ersten Beitritt. Der Backend-Nachrichtendienst löste die Benachrichtigung bei jeder Server-Meshing-Übergabe aus, statt nur beim ersten Beitritt eines Spielers zu einem Shard. Die Benachrichtigung wurde vorerst über ein Konfigurationsflag deaktiviert.
Schiffe konnten per Quantumreise direkt durch Monde fliegen, die die Route eigentlich blockieren sollten. Die Kollisionsprüfung zur Validierung der Ankunftspunkte für die Quantenreise berücksichtigte die Verdeckung durch Monde nicht, sodass Schiffe durch sie hindurchfliegen konnten. Die Prüfung erkennt nun korrekt Monde, die den Weg blockieren.
KI
Unberechenbares Kampfverhalten feindlicher Schiffe, einschließlich des Einfrierens der KI mitten im Kampf oder des direkten Hineinfliegens in den Spieler Zu den Ursachen gehörten ein fehlendes Jägerklassen-Tag bei einem Schiffstyp, ein fehlerhaftes Manöver, das ein sichtbares Taumeln verursachte, sowie ein Stoppbefehl, der bedingungslos ausgelöst wurde und die KI an Ort und Stelle festsetzte. Jede Ursache wurde einzeln behoben. Anschließende Tests bestätigten ein korrektes Manövrieren ohne weiteres Einfrieren oder Rammen.
Vanduul-Scythe-Jäger erschienen an einem Missionsort passiv, anstatt anzugreifen Die KI-Konfiguration des Piloten verwies fälschlicherweise auf eine übrig gebliebene Standardaktivität aus einem nicht verwandten Projekt statt auf das korrekte Verhalten "warten, dann angreifen“. Durch die Korrektur dieser Referenz wurde das passive Auftreten der Jäger behoben.
Yormandi blieb untätig und weigerte sich, nach einer Betäubung den Angriff wieder aufzunehmen Eine kombinierte Logik- und Datenkorrektur behob sowohl das KI-Motiv der Kreatur als auch die Verarbeitung von Unterbrechungen durch Schmerzreaktionen. Das Problem trat während eines Angriffs kurzzeitig noch in einem bestimmten Randfall auf, wurde durch eine nachfolgende Korrektur jedoch ebenfalls behoben.
Docken & Auftanken
Schiffe, denen von der ATC ein Andockkragen zugewiesen wurde, konnten trotz perfekter Ausrichtung nicht andocken Schiffe in Stanton, Nyx und Pyro konnten manchmal nicht auf Hangars und Stationen zugreifen, weil ein nahegelegener anderer Spieler den Andockvorgang stören konnte. Außerdem konnten Andockröhren in einem Status "Bereits zugewiesen“ stecken bleiben, wodurch weitere Versuche blockiert wurden. Es wurde bestätigt, dass die Fehlerbehebung an zahlreichen Stationen und bei vielen Schiffstypen funktioniert.
ATC-Frachtdienste reagierten nicht mehr und blockierten dadurch Anfragen für Frachtladezonen Die Kontaktaufnahme mit den Frachtdiensten an Stationen in Stanton, Nyx und Pyro blieb manchmal ohne Reaktion, sodass Spieler keine Ladezone zum automatischen Beladen von Fracht erhielten.
Erste Spielstunden
Spieler konnten nach einer Kollision, bei der das Cockpit zerstört wurde, im Cockpit eines Schiffs gefangen bleiben Die Ursache war, dass sich ein Sitz gelegentlich von einem beschädigten Schiff löste, bevor die Zerstörungssequenz vollständig abgeschlossen war. Dadurch blieb der Pilot am Leben, war jedoch ohne Möglichkeit zu entkommen oder auszusteigen gefangen – manchmal auf unbestimmte Zeit. Die Fehlerbehebung sorgt dafür, dass das Lösen des Sitzes die Zerstörungssequenz ordnungsgemäß abschließt, anstatt den Spieler festzusetzen.
Abgerufene Fahrzeuge konnten mit im Hangarboden steckendem Fahrwerk erscheinen und den Start blockieren Wenn man ein Fahrzeug während der Einlagerungsanimation abrief und den Bereich verließ, konnte es mit im Boden steckendem Fahrwerk erscheinen. Ein erneuter Abruf konnte außerdem den Abruf-Button des ASOP-Terminals blockieren. Eine Fehlerbehebung ergänzt nun eine Überprüfungs- und Reparaturphase, die die Fahrzeugplatzierung in solchen Fällen korrigiert.
Schiffsradar und andere Systeme blieben nach einem Neustart der Stromversorgung deaktiviert Das Aus- und Wiedereinschalten der Schiffsstromversorgung konnte dazu führen, dass Radar und andere Systeme deaktiviert blieben – besonders für neue Piloten ein schlechter erster Eindruck. Ursache war ein Zeitsteuerungsproblem im Stromversorgungssystem. Die Fehlerbehebung verfolgt nun alle Systeme, die nach der erneuten Stromzufuhr nicht aktiviert wurden, und stellt sie automatisch wieder her.
Patrouillenmissionen mit einem Satellitenscan-Ziel konnten festhängen, wenn ein Satellit nicht erschien Einige Patrouillenmissionen erfordern das Anpingen eines bestimmten Gebiets per Satellitenscan. Gelegentlich erschien dort jedoch kein Satellit, wodurch das Ziel dauerhaft blockiert und die Mission unlösbar wurde. Die Missionslogik erhielt keine Bestätigung darüber, ob der Satellit tatsächlich erschienen war. Die Fehlerbehebung fügt nun einen alternativen Erscheinungsort hinzu, sodass das Ziel auch abgeschlossen werden kann, wenn der ursprüngliche Ort fehlschlägt.
Ping-Scans zeigten den Namen und die Fraktion eines Ziels als "Nicht verfügbar“ an Beim Scannen eines Ziels mit der Ping-Welle des Schiffs oder dem MFD für Zielstatus wurden Name und Fraktion als "Nicht verfügbar“ angezeigt, obwohl diese Daten bekannt sein sollten. Eine Fehlerbehebung zeigt nun sofort den Modellnamen des gescannten Fahrzeugs an.
Bemannte und ferngesteuerte Geschütztürme verwendeten standardmäßig unterschiedliche und uneinheitliche Zielmodi Bemannte Geschütztürme verwendeten standardmäßig Gimbal-/Auto-Aim, während derselbe Geschützturm bei Fernsteuerung standardmäßig auf Pip-Ziele basierte. Das Verhalten hing somit davon ab, wer im Sitz saß. Die Logik für den Zielmodus wurde beim Wechsel zwischen bemannter und ferngesteuerter Kontrolle nicht korrekt neu initialisiert.
Die Auswahl von "Reparieren“ an einer Landebucht blockierte andere Dienste nicht schnell genug Bei der Auswahl von "Reparieren“ an einem Lande-Service wurden andere Optionen nicht schnell genug gesperrt. Dadurch konnte eine widersprüchliche Serviceanfrage eingehen und die Reparatur unbemerkt abbrechen. Die zugrunde liegende Race Condition zwischen den beiden Anfragen wurde behoben.
Gleichzeitiges Anfordern mehrerer Lande-Services konnte dazu führen, dass "Reparieren“ ein zweites Mal angefordert werden musste Wenn gleichzeitig "Reparieren“ sowie "Auffüllen“ oder "Tanken“ angefordert wurden, wurden alle Dienste als in Bearbeitung angezeigt. Die Reparatur schlug jedoch unbemerkt fehl und musste erneut angefordert werden.
Das Festlegen einer Route auf der Minikarte zeichnete keine Routenlinie Beim Erstellen einer benutzerdefinierten Route über die Minikarte wurde keine sichtbare Führungslinie angezeigt, sodass Spieler keinen Weg zu ihrem Ziel verfolgen konnten. Die Routenberechnung war nur serverseitig verfügbar. Die Fehlerbehebung ruft nun direkt die Pfadfindungslogik auf, sodass die Routenlinie wie erwartet dargestellt wird.
Viele FPS-Waffen wurden aus mittlerer Entfernung als kantige Modelle mit niedriger Detailstufe dargestellt Gewehre, Maschinenpistolen, Schrotflinten und Scharfschützengewehre zeigten in Inventar- und Herstellungs-Kiosk-Vorschaubildern sowie aus mittlerer Entfernung in der Spielwelt auffällig niedrig detaillierte Modelle. Die Einstellungen für den Detailstufenwechsel dieser Waffen wurden angepasst, sodass Modelle mit höherem Detailgrad wie vorgesehen angezeigt werden.
Der Erzkiosk in Klescher schlug die Transaktion "Edelsteine gegen Verdienste“ immer fehl Insassen der Rehabilitationsanstalt Klescher konnten abgebautes Erz nicht gegen Verdienste für ihre Haftstrafe eintauschen, da der Erzkiosk stets den Fehler "Transaktion fehlgeschlagen“ zurückgab. Der Kiosk erkannte fälschlicherweise, ob sich das Erz in einem Rucksack befand, und leitete die Verkaufsanfrage an die falsche Inventarliste weiter. Diese Abfrage wurde korrigiert.
Der Verkauf von Erz aus einem Frachtaufzug über einen Rohstoffkiosk schlug mit einem Entitätsabfragefehler fehl Der Verkauf von abgebautem Erz (Dolivine, Aphorite, Hadanite), das in einem Frachtaufzug gelagert war, über einen Rohstoffkiosk schlug mit dem Fehler "Entitätsabfrage fehlgeschlagen“ fehl, anstatt den Verkauf abzuschließen. Der Client berechnete den Transaktionspreis falsch, wodurch die serverseitige Validierung die Transaktion ablehnte. Die Berechnung wurde korrigiert.
Erschöpfte Abbauknoten wurden beim Wiedererscheinen des Knotens nicht entfernt Basen von abbaubaren oder abbauwürdigen Knoten blieben nach ihrer Erschöpfung unbegrenzt bestehen. Dadurch wurden Abbauorte auch nach dem Erscheinen eines neuen Knotens an derselben Stelle zugemüllt. Die Timeout-Warteschlange des Bereinigungssystems war in der falschen Reihenfolge sortiert, weshalb die Entfernungstimer nie ausgelöst wurden. Die Sortierreihenfolge wurde korrigiert.
Der Hinweis zum Auftanken blieb nach einem Respawn während einer Mission auf dem Bildschirm und blockierte andere Benachrichtigungen Eine Variante des festhängenden Hinweises "Beim Tanker andocken“ trat diesmal nach einem Respawn während einer Auftankmission auf.
Aktiven oder scharfen Granaten fehlte die Warnmarkierung im HUD Geworfene Granaten, die noch scharf waren, zeigten nicht die HUD-Markierung an, die Spieler in der Nähe vor der Gefahr warnen soll. Das FPS-Radar, von dem diese Markierung abhängt, war als Überbleibsel einer alten Exploit-Fehlerbehebung vollständig deaktiviert worden. Durch das Entfernen dieser Übergangslösung wurde die Granatenwarnung wiederhergestellt.
Party-HUD-Markierungen zeigten nur einen Pfeil und die Entfernung, nicht aber die Namen der Mitglieder Die HUD-Markierung von Partymitgliedern zeigte ein Richtungssymbol und die Entfernung, jedoch nicht den Namen des Mitglieds. Eine UI-Datenbindung, die die Sichtbarkeit der Namensbeschriftung steuert, gab dauerhaft den Wert null zurück. Diese Bindung wurde korrigiert.
So geht es bei CIG weiter
Alpha 4.10 ist erst der Anfang. Auch bei zukünftigen Updates möchte man bei Cloud Imperium Games in dieser Form weiterarbeiten. Dadurch wurde die Entwicklung neuer Features in den betroffenen Teams jedoch zunächst zurückgestellt. Einen Zustand wie 2025, in dem die Feature-Entwicklung gänzlich eingestellt wurde, müssen wir jedoch nicht erwarten.
Ein Punkt, der sich ebenfalls wieder ändern soll, ist die Kommunikation. Laut Chris Roberts sollen wir in Zukunft wieder mehr über den aktuellen Stand erfahren – unabhängig davon, ob alles wie geplant läuft oder es Fehlschläge gibt.
In diesem Zuge wurde auch ein neues YouTube-Format namens "Inside CIG“ veröffentlicht. In der ersten Ausgabe ging es um Patch 4.10 und die Herausforderungen der vergangenen Wochen.
Hier befindet sich ein externes Video von Youtube.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Personenbezogene Daten können an Drittplattformen übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
