Beiträge von DCDoerek

Willkommen in der Kantine, Reisender...

Melde Dich an oder registriere Dich kostenlos

login-Button

    Ach Ray, du oller Schwarzseher 🙂
    Wenn man deine Antwort ließt, könnte man meinen du freust dich garnicht darüber dass craften endlich seinen Weg ins Spiel findet. Ich, für meinen Teil, freue mich darauf dass das ganze geloote im Bunker endlich einen tieferen Sinn erfüllt(hoffentlich).

    Bei den bisherigen Playtests zum Crafting konnte man zwar erstmal nur die Items zerlegen, zu denen es auch einen Blueprint gab, aber ich hoffe dass diese Limitierung irgendwann "fallen" wird. Zumindest habe ich Gerüchte von verschiedenen Leuten gehört die in diese Richtung gingen.

    Ich frage mich an dieser Stelle:
    * Wird man Beispielsweise auch Schokoriegel oder Cruz-Lux zerlegen können, weil es dann letztendlich zu denen auch ein Blueprint geben wird?
    Denn wenn man sich das Konstrukt von Marken & Produkten in SC mal genau anguckt, dann könnte es sehr gut sein dass man so simple Items wie Schokoriegel, Cruz Lux & Co zwar irgendwann zerlegen kann, diese aber nicht über ein Blueprint selber herstellen können wird.

    Das käme ungefähr dem gleich, als würde man im echten Leben ein MARS-Blueprint besitzen und man stellt sich fortan seine Snacks, nach Original Rezept, nur noch selber her. Ich fände es zwar klasse wenn ich mir mein Cruz-Lux in Zukunft selber produzieren könnte...Das würde dann aber irgendwie die Authentizität der Marken untergraben, oder nicht?

    Umso länger ich darüber nachdenke, desto mehr bedauere ich es, dass <@185349856980762624> & ich beim letzten Playtest nicht genug Materialien finden konnten um eine Waffe herzustellen. Denn mich würde dann mal interessieren ob auf einer "gecrafteten" P4 dann immernoch "BEHRING" geschrieben steht. Ich fänd' es zumindest nur logisch wenn es nicht darauf stehen würde. 😉

    Wir hatten nur genug Material um Rüstungsgegenstände zu craften und dort gibt es meines Wissens nach, noch keine etablierten Marken wie BEHRING oder VOLT bei den Waffen. Bin im Thema Rüstungen aber auch nicht wirklich kundig.

    MfG

    Koordination zwischen Organisationen

    Da mehrere Gruppen beteiligt sind, fungiert der Kommandostab als Vermittlungsstelle. Er sorgt dafür, dass:

    • Informationen weitergegeben werden
    • Missverständnisse geklärt werden
    • Ressourcen (Schiffe, Personal, Termine) sinnvoll abgestimmt werden

    Repräsentation nach außen

    Über den Flottenkommandanten tritt die A3 Patrouille gegenüber anderen Organisationen, Projekten und der Community geschlossen auf.

    Sicherung der Fairness

    Durch die rotierende Führung und gleichberechtigte Repräsentation soll verhindert werden, dass einzelne Gruppen dominieren oder das Projekt in eine bestimmte Richtung „kippt“.

    Warum ein Kommandostab wichtig ist

    Ohne eine solche Struktur würden größere Community-Projekte schnell unübersichtlich: Absprachen verlaufen im Sande, Entscheidungen bleiben liegen oder Konflikte eskalieren.

    Der A3 Kommandostab schafft hier einen verlässlichen Rahmen, ohne das freie, kreative Rollenspiel einzuschränken. Er gibt Orientierung, keine Befehle.

    Zusammengefasst

    Der A3 Kommandostab ist:

    • Koordinationsstelle
    • Ideenbörse
    • Vermittler
    • Qualitätssicherung

    Er sorgt dafür, dass die A3 Patrouille nicht nur einzelne Events hervorbringt, sondern sich zu einem nachhaltigen, wachsenden Community-Format entwickeln kann, das langfristig Spaß macht, stabil bleibt und für alle Beteiligten fair funktioniert.

    Der A3 Kommandostab ist das organisatorische Rückgrat der A3 Patrouille. Er sorgt dafür, dass aus vielen beteiligten Organisationen, Spielern und Ideen ein handlungsfähiges, koordiniertes Community-Projekt wird – ohne starre Hierarchien, aber mit klaren Ansprechpartnern und nachvollziehbaren Abläufen.

    Sein grundlegender Zweck besteht darin, das Format langfristig zu stabilisieren, weiterzuentwickeln und fair zu steuern. Während die A3 Patrouille als In-Character-Initiative im Verse auftritt, übernimmt der A3 Kommandostab auf Community-Ebene die Planung, Abstimmung und Koordination.

    Zusammensetzung des A3 Kommandostabs

    Jede Organisation, die sich an der A3 Patrouille beteiligt, entsendet bis zu drei Personen in den A3 Kommandostab:

    • einen Hauptrepräsentanten
    • bis zu zwei Sekundärrepräsentanten

    Der Hauptrepräsentant fungiert als primärer Ansprechpartner der Organisation. Die Sekundärrepräsentanten unterstützen ihn, können an Sitzungen teilnehmen und vertreten die Organisation bei Abwesenheit oder zusätzlichem Abstimmungsbedarf.

    Durch dieses Modell bleibt der Kommandostab überschaubar, gleichzeitig aber breit genug aufgestellt, um verschiedene Perspektiven abzubilden. Keine einzelne Organisation besitzt dabei eine Sonderstellung – alle haben die gleiche Stimme.

    Wahl von Flottenkommandant und Vizekommandant

    Aus dem Kreis des A3 Kommandostabs werden in einem festen Turnus zwei zentrale Rollen gewählt:

    • Flottenkommandant
    • Vizekommandant

    Die reguläre Amtszeit beträgt drei Monate. Dieses Rotationsprinzip stellt sicher, dass Verantwortung regelmäßig wechselt und sich nicht dauerhaft bei einer einzelnen Person oder Organisation konzentriert.

    Der Kommandostab kann jedoch mit Zustimmung per Mehrheitsprinzip eine Verlängerung der Amtszeit des Flottenkommandanten auf bis zu sechs Monate beschließen. Diese Option dient der Stabilität in Phasen größerer Projekte, struktureller Veränderungen oder wenn eine kontinuierliche Führung ausdrücklich gewünscht wird.

    Der Flottenkommandant ist primär Sprecher und Koordinator der Initiative. Er repräsentiert die A3 Patrouille nach außen, geht aktiv auf neue Organisationen zu und fungiert als erster Ansprechpartner für Kooperationen. Gleichzeitig leitet er die Sitzungen des A3 Kommandostabs.

    Der Vizekommandant unterstützt ihn dabei und übernimmt diese Aufgaben bei Abwesenheit oder Ausfall.

    Wichtig: Beide Rollen sind ausdrücklich keine „Oberbefehlshaber“ im klassischen militärischen Sinne, sondern Koordinatoren und Moderatoren innerhalb eines Community-Projekts.

    Monatliche Stabstreffen

    Der A3 Kommandostab trifft sich regelmäßig zu sogenannten Stabstreffen. Geplant ist mindestens ein Treffen pro Monat.

    Diese Treffen können:

    • In-Character an Bord der Idris im sicheren Hangar stattfinden
      oder
    • Out-Of-Character über Discord abgehalten werden

    Vor jedem Zeitraum wird per Umfrage ermittelt, wer am jeweiligen Treffen teilnehmen möchte. Dadurch bleibt die Beteiligung freiwillig, aber planbar.

    In diesen Sitzungen werden unter anderem:

    • vergangene Patrouillen ausgewertet
    • organisatorische Probleme besprochen
    • Vorschläge für Anpassungen gesammelt
    • Termine grob abgestimmt
    • neue Organisationen oder Interessenten besprochen

    So entsteht ein kontinuierlicher Verbesserungsprozess.

    Aufgaben des A3 Kommandostabs

    Der A3 Kommandostab ist kein operatives Einsatzkommando, sondern eine Steuerungs- und Koordinationsinstanz. Seine Aufgaben lassen sich grob in vier Bereiche einteilen:

    Konzeptpflege und Weiterentwicklung

    Der Kommandostab achtet darauf, dass die A3 Patrouille ihrem Grundgedanken treu bleibt: organisationsübergreifendes Multi-Crew-Roleplay mit glaubwürdigen Bordbesatzungen.

    Er sammelt Feedback aus der Community, bewertet neue Ideen und entscheidet gemeinsam, welche Anpassungen sinnvoll sind.

    Hallo zusammen,

    mit dem kommenden Crafting-System steht Star Citizen möglicherweise vor einer der größten spielerischen Umwälzungen seit Einführung von Mining und Salvage. Während viele Gameplay-Loops bisher stark auf den direkten Verkauf von Ressourcen an NPC-Konsolen ausgelegt sind, deutet vieles darauf hin, dass sich der Fokus künftig deutlich in Richtung Sammeln, Horten, Veredeln und gezieltes Einsetzen von Materialien verschieben wird. 🙂

    Der Item Fabricator selbst ist mit 16 SCU bereits ein klares Statement: Crafting ist kein Nebenfeature, sondern ein zentrales System. Blueprints bestehen aus mehreren Einzelteilen, z.B. u.A. einem "Insulating Layer" bei Rüstungen oder dem "Barrel" bei Waffen. Wählt man im Fabricator ein Blueprint aus, werden zu jedem dieser Teile die benötigten Materialien angezeigt. Auf der linken Seite erscheinen alle gesammelten Materialien, getrennt nach Qualitätsstufen, während auf der rechten Seite die Basis-Statistiken des Items sichtbar sind.

    Spannend wird es, sobald man Materialien unterschiedlicher Qualität auswählt: Die angezeigten Werte verändern sich in Echtzeit. Bei Waffen betrifft das unter anderem Spread, Reload Speed, Fire Rate, Recoil oder Impact Force. Bei Rüstungen etwa Damage Mitigation, Temperaturbereiche oder Strahlenresistenz.

    Das bedeutet: Man kann nicht im Voraus sehen, wie die „bestmöglichen“ Werte eines Blueprints aussehen könnten. Es sei denn, man besitzt bereits Materialien in sehr hoher Qualität. Dadurch entsteht ein starker Anreiz, Materialien nicht vorschnell zu verkaufen, sondern langfristig einzulagern.

    Materialien scheinen Qualitätsstufen von 1 bis 999 zu besitzen. Es wurden zumindest Materialien mit Werten wie 63 oder 640 gefunden. Das wirft einige Fragen auf:

    • Werden Spieler künftig große Mengen an Ressourcen horten, in der Hoffnung, sie später für ein bestimmtes Blueprint zu benötigen?
    • Werden NPC-Ankaufsterminals nur noch für absolut minderwertige Materialien genutzt?
    • Entsteht eine neue Spielerökonomie, in der hochwertige Materialien wertvoller sind als fertige Items?

    Auch das Zerlegen von Items ist bemerkenswert: Beim Zerlegen erhält man exakt die Materialien zurück, die zur Herstellung genutzt wurden. Allerdings in geringerer Menge, jedoch mit derselben Qualitätsstufe. Dadurch könnten sich Kreisläufe entwickeln, in denen Items gezielt gebaut und später wieder zerlegt werden, um bestimmte Materialqualitäten zu sichern.

    Ein weiterer großer Diskussionspunkt betrifft die Weiterentwicklung von Blueprints:
    CIG erwähnte bereits, dass Blueprints durch das „Erforschen“ mit Materialien verbessert werden können (Tier 2, Tier 3 usw.).

    Hier stellen sich zentrale Fragen:

    • Haben Tier-2- oder Tier-3-Blueprints bei allen Spielern immer identische Basis-Statistiken?
    • Oder beeinflusst die Qualität der Materialien, mit denen ein Blueprint erforscht wurde, dauerhaft die Werte der höheren Tier-Stufe?
    • Lohnt es sich also, ein Blueprint erst dann zu verbessern, wenn man besonders hochwertige Materialien besitzt?

    Zusätzlich steht die Frage im Raum, ob Raffinerien künftig Funktionen erhalten könnten, mit denen große Mengen schlechter Materialien zu kleineren Mengen hochwertiger Materialien veredelt werden können. Warum eigentlich nicht, oder?

    Nicht zuletzt betrifft das System auch unterschiedliche Spielertypen:

    • Wie geht es Spielern, die keine Lust haben, stundenlang Materialien zu sammeln, nur um ein einzelnes Item zu craften?
    • Sollte es Wege geben, fertige Komponenten oder halbveredelte Materialien zu handeln?
    • Wird Crafting eher ein Nischen-Gameplay für Spezialisten oder ein fester Bestandteil für fast alle Spieler?
    • Wie genau wird man sich als Crafter "spezialisieren" können?

    Was denkt ihr? 🙂
    Welche Variante des Craftings würdet ihr bevorzugen? Stark materialgetrieben und komplex oder eher zugänglich und planbar?
    Welche Auswirkungen erwartet ihr auf Handel, Organisationen und Gruppenspiel?

    Teilt hier gerne eure Gedanken, Wünsche und Befürchtungen... 😉

    Zitat von skinwalkerlp
    ja klar kommt das alles noch. sind ja auch nur ein paar Gedanken zum Thema, damits dann alles auch richtig kommt. Das Schiff soll ja nicht nur laufen, sondern sich auch auf seine Mission konzentrieren können 😁 .

    Im Zuge der Planung sind wir beispielhaft alle Position einer Idris durchgegangen und haben sie nach militärischen Standard mit Personal besetzt. Dabei sind wir mit einer Vollbesetzung bei einer Gesamtmenge von über 70 bespielbaren Personalpositionen ausgekommen. **Beispiel:** Im Militärischen Kontext würde der 1. Offizier das Be- und entladen des Schiffes nämlich definitiv **nicht** beaufsichtigen, denn dafür gäbe es wiederum den Logistikoffizier. Der dann Vollzug meldet.

    Wir sind uns auch natürlich der Tatsache bewusst, dass es vielleicht zunächst nicht zu den besagten 70 Spielern kommen wird. Unser Ziel war es allerdings auch erst einmal eine optimal Besetzung zu dokumentieren. Die daraus entstandene Struktur wird dann je nach Anzahl an verfügbaren Spielern zusammen gestaucht und angepasst.

    Die Texte die wir bisher veröffentlicht haben sollen zunächst erstmal nur potenziell Interessierte Rollenspieler über das Community-Projekt informieren und "es" ihnen "schmackhaft" machen. Die detaillierte Ausarbeitung von Themen wie die benötigte Ausrüstung oder der Ablauf von bestimmten Tätigkeiten in verschiedenen Abteilungen folgt noch. Wir werden euer Feedback natürlich in die Ausarbeitung einfließen lasen.

    Zitat von jendrikon
    Anmerkung: Boardschützen haben keine gute Übersicht über das Schiff, können daher nicht beurteilen, ob, wo und was für ein Schaden vorliegt. Sie sehen ausschließlich den Zustand der Schiffshülle, welche aber in erster Linie nicht relevant für eine Situation unter Kampfbedingungen ist.

    Nirgendwo wurde geschrieben dass die Bordschützen beurteilen sollen wo, welcher Schaden am Schiff anliegt.

    Logistikabteilung

    Die Logistikabteilung sorgt dafür, dass das Schiff „atmen“ kann. Munition, Ersatzteile, Medikamente, Nahrung und Ausrüstung müssen vorhanden, sortiert und erreichbar sein.

    Der Logistikoffizier behält den Überblick über das Inventar in der Cargo-Bay, plant Nachschub und stimmt sich mit Technik, Medizin und Sicherheit ab. Die Logistik Crew bewegt Kisten, bereitet Lieferungen vor und verteilt angeforderte Gegenstände an die Abteilungen.

    Im Roleplay entsteht hier viel Hintergrundspiel: Engpässe, improvisierte Lösungen, Prioritätsentscheidungen oder Verhandlungen um knappe Ressourcen.

    Zusammenspiel der Abteilungen

    Das Herzstück des Onboard-Roleplays ist nicht die einzelne Abteilung, sondern das Zusammenspiel:

    • Bordschützen melden Schäden → Technik reagiert.
    • Sicherheit sichert einen Bereich → Medizin versorgt Verletzte.
    • Logistik liefert Ersatzteile → Technik kann weiterarbeiten.
    • Brücke koordiniert → alle Abteilungen setzen um.

    So entsteht ein lebendiger Kreislauf, in dem jede Rolle Bedeutung hat.

    Warum A3 Patrouille?

    Die A3 Patrouille bietet einen Rahmen, in dem genau dieses Zusammenspiel regelmäßig erlebbar wird. Sie richtet sich an Organisationen, kleine Gruppen und Einzelspieler gleichermaßen. Niemand muss alles können – jede Rolle zählt.

    Wer Lust auf strukturiertes, immersives Multicrew-Roleplay hat, findet hier eine Bühne, um Teil einer größeren Geschichte zu werden. Ob als Schütze, Sanitäter, Techniker, Logistiker oder Sicherheitskraft: Jede Funktion trägt dazu bei, dass aus einem Schiff eine glaubwürdige Besatzung wird.

    Die A3 Patrouille ist kein starres Militärprojekt – sie ist ein gemeinsames Rollenspiel-Experiment, das von den Menschen lebt, die sich einbringen. Und genau dafür ist immer Platz.

    Wie Rollenspiel an Bord entsteht

    Auf einem Capitalschiff im Rahmen der A3 Patrouille entsteht Rollenspiel nicht durch starre Militärstrukturen, sondern durch das lebendige Zusammenspiel vieler unterschiedlicher Rollen. Jede Person an Bord trägt auf ihre Weise dazu bei, dass das Schiff funktioniert, Einsätze möglich werden und eine glaubwürdige, immersive Atmosphäre entsteht. Unabhängig davon, ob ein Schiff mit zehn oder dreißig Spielern besetzt ist, folgen die Abläufe stets denselben Grundprinzipien: klare Zuständigkeiten, verständliche Aufgaben und eine enge Zusammenarbeit zwischen den Abteilungen.

    Das Ziel ist dabei nicht, militärisches Fachwissen vorauszusetzen, sondern Rollen zu schaffen, die intuitiv verständlich sind und Raum für persönliches Rollenspiel bieten. Wer Teil der A3 Patrouille wird, schlüpft in eine Funktion, die Verantwortung trägt, Entscheidungen trifft und sichtbar Einfluss auf den Ablauf einer Patrouille hat.

    Bordschützen

    Die Bordschützen bilden die direkte offensive Verteidigung des Schiffes. Sie besetzen bemannte Geschütztürme oder bedienen ferngesteuerte Waffensysteme und reagieren auf Bedrohungen im Raumkampf. Im Roleplay sind sie die „Augen und Fäuste“ nach außen.

    Ihre Aufgaben umfassen das Beobachten des Luftraums, das Melden von Kontakten an die Brücke sowie das gezielte Bekämpfen feindlicher Ziele. Darüber hinaus entsteht viel Rollenspiel durch kurze Lageberichte, Munitionsstatus oder die Abstimmung mit Technikern, wenn Geschütze beschädigt werden. Bordschützen erleben Action, sind aber gleichzeitig Teil einer größeren Kette von Entscheidungen.

    Bordsicherheit

    Die Bordsicherheit sorgt dafür, dass das Schiff im Inneren sicher bleibt. Sie patrouilliert durch Korridore, überwacht sensible Bereiche wie Brücke, Cargo-Bereich, Maschinenraum oder Hangar und betreibt die Waffenkammer.

    Angeführt wird die Abteilung durch den Sicherheitsoffizier, der Einsätze koordiniert, Gefangene überwacht und als Ansprechpartner für die Brücke fungiert. Das Sicherheitspersonal übernimmt Kontrollen, überwacht Gäste, sichert Andockvorgänge und reagiert auf Boarding-Versuche.

    Im Roleplay entstehen hier viele spannende Situationen: Befragungen, Eskorten, Alarmierungen oder interne Sicherheitslagen. Die Bordsicherheit ist damit ein zentraler Träger von Spannung und Action an Bord.

    Technikabteilung

    Die Technikabteilung ist das Rückgrat des Schiffsbetriebs. Ohne funktionierende Systeme gibt es weder Antrieb, noch Schilde, noch Waffen.

    Der Technische Offizier koordiniert die Arbeiten, priorisiert Reparaturen und stimmt sich eng mit dem leitende Ingenieur und anderen Abteilungen ab. Die Engineering Crew setzt diese Anweisungen um, repariert beschädigte Komponenten, tauscht Module, überwacht Energieverteilung und reagiert auf Störungen.

    Im Spiel ergeben sich hier zahlreiche Anknüpfungspunkte: Stromausfälle, überhitzte Systeme, improvisierte Reparaturen oder hektische Einsätze während Gefechten. Technik-Rollenspiel verbindet praktisches Gameplay mit erzählerischer Tiefe.

    Medizinische Abteilung

    Die medizinische Abteilung kümmert sich um das körperliche und mentale Wohlergehen der Besatzung. Der medizinische Offizier organisiert Behandlungsabläufe, teilt Personal ein und entscheidet über Prioritäten.

    Das medizinische Personal versorgt Verwundete, stabilisiert kritische Patienten, führt Nachuntersuchungen durch und dokumentiert Verletzungen. Auch präventive Maßnahmen wie Gesundheitschecks oder Impfungen können ins Rollenspiel eingebaut werden.

    Medizinisches RP schafft ruhige, intime Momente ebenso wie hektische Notfallsituationen und verleiht Einsätzen spürbare Konsequenzen.

    Die A3 Patrouille ist ein organisationsübergreifendes Community-Format, das entwickelt wurde, um der wachsenden Nachfrage nach koordiniertem Multi-Crew-Roleplay auf großen Schiffen gerecht zu werden. Ziel des Formats ist es, Capital- und Großschiffe nicht nur funktional zu betreiben, sondern sie glaubwürdig, lebendig und erzählerisch sinnvoll zu bespielen.

    Im Mittelpunkt steht dabei das Bord- und Crew-Rollenspiel. Anstatt sich auf reine Minimalbesatzungen zu beschränken, sollen Schiffe mit vollständigen oder nahezu vollständigen Crews besetzt werden, um interne Abläufe, soziale Dynamiken, Konflikte, Hierarchien und Zusammenarbeit erlebbar zu machen. Das Schiff wird damit selbst zu einem aktiven Schauplatz von Geschichten.

    Als erste Testplattformen dienen mehrere Capital-Schiffe, die von unterschiedlichen Organisationen bereitgestellt werden. Die Besatzungen setzen sich bewusst organisationsübergreifend zusammen und umfassen unter anderem:

    • Brücken- und Kommandooffiziere
    • Piloten und Navigatoren
    • Bordschützen und Sicherheitskräfte
    • Techniker, Ingenieure und Wartungspersonal
    • Medizinische Abteilungen
    • Logistik- und Versorgungseinheiten

    Diese Struktur ermöglicht es, Schiffe deutlich über das Funktionsminimum hinaus zu besetzen und ein dauerhaftes, glaubwürdiges Bordleben zu simulieren.

    Loreseitig tritt die A3 Patrouille als unabhängige zivile Patrouillen- und Unterstützungsinitiative auf. Ihr Aufgabenfeld umfasst vor allem Aufklärung, Präsenzfahrten, Sicherungsaufgaben sowie private Unterstützungsleistungen im Umfeld größerer Siedlungsgebiete und Handelsrouten. Öffentliche Ordnungskräfte wie Advocacy oder Navy stufen die A3 Patrouille dabei als zivile Flotte ein, vergleichbar mit privaten Sicherheits- oder Söldnerverbänden.

    Organisatorisch wird das Projekt durch einen A3-Kommandostab getragen. Jede beteiligte Organisation stellt Haupt- und Sekundärrepräsentanten. Aus diesem Kreis wird in regelmäßigen Abständen ein Flotten-Kommandant bestimmt, der die Initiative nach außen repräsentiert, neue Kooperationen anbahnt und die interne Koordination übernimmt.

    In der Anfangsphase ist maximal eine Patrouille pro Monat vorgesehen, um dem Format seinen besonderen Charakter zu erhalten und eine Überfrachtung zu vermeiden. Perspektivisch kann sich die A3 Patrouille von einem einzelnen Capital-Schiff zu einer erweiterten Flottenstruktur entwickeln, ergänzt durch Begleit- und Unterstützungsschiffe mit eigenem Bord- und Crew-Rollenspiel.

    Out-of-Character wird die Planung und Abstimmung über Discord und das RPU-Forum begleitet, um Transparenz, Beteiligung und langfristige Nachhaltigkeit sicherzustellen.

    Hallo zusammen,

    ich habe gerade eben einen Vorschlag zum Thema: "Komponentenbasierte Explosionsgefahr beim Salvaging" im Spectrum gepostet. Falls euch die Idee gefällt, lasst gerne einen Upvote im Spectrum da oder antwortet mit euren Ideen darauf. Den Link zum englischen Thread findet ihr hier: Suggestion: Add Component-Based Explosion Risk During Salvaging to Deepen Gameplay

    Für alle, die lieber eine deutsche Version lesen möchten, hier eine Übersetzung:

    Hallo CIG-Team,

    im Zuge der fortlaufenden Erweiterung der Engineering- und Salvage-Gameplay-Loops möchte ich eine Mechanik vorschlagen, die dem Salvaging mehr Tiefe, Risiko und spielerische Anforderung verleihen könnte: die Einführung einer Explosions- und Überhitzungsgefahr durch intakte Schiffskomponenten während des Hull-Strippings.

    Grundidee

    Beim Salvagen von Schiffen, in denen sich noch interne Komponenten befinden (Power Plants, Coolers, Fuel Tanks, Shield Generatoren etc.), sollten diese Komponenten ein potenzielles Risiko darstellen, wenn sich ein Salvage-Laser ihrer physischen Position nähert.

    Zum Beispiel:

    • Nähert sich ein Salvage-Laser dem Bereich einer internen Komponente, könnte diese beginnen, sich zu erhitzen.
    • Bei längerer Einwirkung oder zu hoher Laserintensität könnte die Komponente in einen instabilen Zustand geraten.
    • Bei unsachgemäßer Handhabung könnte sie ausfallen, Energie entladen oder sogar explodieren.

    Dies würde Spieler dazu anregen, sich mit den Positionen von Komponenten innerhalb verschiedener Schiffstypen vertraut zu machen und beim Abtragen der Außenhülle deutlich sorgfältiger vorzugehen.

    Gameplay-Vorteile

    • Fügt eine Risiko-/Belohnungsmechanik hinzu, ähnlich dem Mining, bei dem unachtsames Vorgehen zu kritischen Zuständen führen kann.
    • Fördert das Erlernen von Schiffslayouts und entwickelt professionelles Salvage-Fachwissen.
    • Lässt Salvaging weniger wie reine Materialgewinnung und mehr wie technisches Zerlegen wirken.
    • Erzeugt echte Entscheidungsfindung: langsam und präzise arbeiten oder schneller, aber riskanter vorgehen.

    Bedeutung unterschiedlicher Lasergrößen & Ausrüstung

    Ein solches System würde unterschiedlichen Salvage-Lasergrößen automatisch mehr Sinn verleihen:

    • Kleinere Laser für präzise Arbeiten in der Nähe von Komponenten-Schächten.
    • Größere Laser für großflächiges Hull-Stripping fernab sensibler Bereiche.

    Zusätzlich könnten passive oder aktive Module – ähnlich wie beim Mining – Einfluss nehmen auf:

    • Die Geschwindigkeit des Hitzeaufbaus in Komponenten
    • Stabilitätsschwellen
    • Warnzeiten vor einem kritischen Zustand

    Dadurch würden Ausrüstungsentscheidungen und Spezialisierungen im Salvage-Bereich weiter vertieft.

    Synergie mit zukünftigen Systemen

    Sollten Treibstofftanks in zukünftigen Updates weiter physikalisiert werden, könnten insbesondere diese beim Salvaging ein zusätzliches Gefahrenpotenzial darstellen. Das würde Immersion und Systemtiefe weiter erhöhen.

    Zusammenfassung

    Diese Mechanik würde:

    • die Immersion steigern
    • Salvaging mehr Tiefe und Meisterschaft verleihen
    • die Verbindung zu Engineering und physikalisierten Komponenten stärken
    • einen klaren Unterschied zwischen erfahrenen und unerfahrenen Salvagern schaffen

    Vielen Dank für die Berücksichtigung dieses Vorschlags und für die kontinuierliche Weiterentwicklung der systemischen Gameplay-Elemente in Star Citizen.

    Beste Grüße,
    DCDoerek

    DCDoerek hat einen neuen Termin erstellt:

    DCDoerek
    8. Februar 2026 um 11:07

    Hinweis:

    Bei diesem Text handelt es sich um eine Übersetzung des Beitrags: "Star Citizen VR Support - Experimental Release (4.6 Updates)" von Silvan-CIG


    Hallo zusammen,

    wir hoffen, ihr hattet über die Feiertage bereits Gelegenheit, den nativen experimentellen VR-Support auszuprobieren, den wir mit Alpha 4.5 eingeführt haben. Die Resonanz war absolut überwältigend, und zu sehen, wie ihr das Feature nutzt und welche Begeisterung es auslöst, war für das Team enorm motivierend.

    Natürlich gibt es noch eine Menge Arbeit, bis VR dort angekommen ist, wo es langfristig hin soll. Vor diesem Hintergrund möchten wir euch hier die Änderungen vorstellen, die wir für Alpha 4.6 vorbereitet haben, ergänzt um einige zusätzliche Entwicklerkommentare meinerseits.

    Bugfixes & Stabilität

    • Eine Reihe von Abstürzen wurde behoben, insbesondere beim Aktivieren von VR. Zusätzlich wurden bessere Fehlermeldungen mit Hinweisen zu häufigen Problemen ergänzt (z. B. das Deinstallieren der OpenXR Tools, die derzeit noch Probleme verursachen können).
    • Ein Fehler wurde behoben, bei dem Nebel (FOG) transparente Objekte nicht beeinflusst hat – besonders auffällig auf microTech während Schneestürmen.
    • CameraViewLookBehind berücksichtigt nun korrekt das HMD-Tracking.
    • Die IPD-Skalierung wird nicht mehr auf Headtracking-Bewegungen angewendet, wenn sie unter 1.0f liegt. Zuvor führte dies dazu, dass Kopfbewegungen langsamer wurden, je weiter die IPD-Skalierung reduziert wurde.
    • Das Headtracking wird nicht mehr zurückgesetzt, wenn man sich im FPS-Modus in Interaktionen befindet. Dadurch wird das Problem behoben, dass Spieler nicht nah genug an Terminals herankamen, um diese korrekt lesen zu können.

    Neue Optionen

    • Auswahl, ob der FPS-ADS-Versatz (Zielen über Visier) am dominanten Auge ausgerichtet wird.
    • Erweiterter Mirror Mode – dazu weiter unten mehr Details.
    • Einstellungen für den Stereo-Cursor: Skalierung, Empfindlichkeit und Kopplung an Kopfbewegungen.
    • Eye-Tracking-Unterstützung für den Stereo-Cursor.
    • Umschaltmöglichkeit für Depth of Field (Tiefenunschärfe).
    • Einstellung für die MobiGlas-Distanz.

    Verbesserungen am Stereo-Cursor

    • Der Stereo-Cursor wurde von der Kopfbewegung entkoppelt. Diese Einstellung ist nun auch der Standard und sollte sich deutlich natürlicher anfühlen.
      Bitte beachtet, dass der Stereo-Cursor über eine begrenzte Reichweite verfügt und beim Aktivieren an einer festen Pixelposition verankert ist. Dieses Verhalten kann in den Einstellungen angepasst werden.

    Eye-Tracking-Unterstützung

    Ein kleines Experiment meinerseits, da ich neugierig war, wie gut das Ganze funktionieren würde. Getestet habe ich es bislang ausschließlich mit der Pimax Crystal Super. Das Ergebnis war bereits brauchbar, wenn auch noch nicht perfekt. Eine saubere und korrekte Kalibrierung ist hierbei extrem wichtig.

    Das Verhalten des Eye-Trackings lässt sich über die folgenden vier cvars anpassen:

    • r_StereoEyeTrackingSmoothing
    • r_StereoEyeTrackingDeadzone
    • r_StereoEyeTrackingCalibrationX
    • r_StereoEyeTrackingCalibrationY

    Mirror-Mode-Update

    • r_StereoScreenOutput wurde in r_StereoMirrorMode umbenannt.
    • Es wurden Varianten für linkes und rechtes Auge hinzugefügt – jeweils für Fill-Modi sowie für Modi mit beibehaltener Seitenratio.
    • Ergänzt wurden Smoothing-, Zoom- und Pan-Funktionen. Diese lassen sich über
      r_StereoMirrorModeZoom, r_StereoMirrorModeSmoothing sowie r_StereoMirrorModePanX/Y anpassen.
    • Das aktuelle Smoothing ist eine einfache Roll-Stabilisierung, ähnlich wie in Half-Life: Alyx. Dafür muss die Ansicht herangezoomt werden, da sonst schwarze Ränder sichtbar wären.
      Bitte beachtet außerdem, dass die Fill-Modi nun stärker zoomen als zuvor, da sie versuchen, die Ansicht zu zentrieren. Für individuelle Setups könnt ihr jederzeit die entsprechenden cvars manuell anpassen.

    Ich bin mit den aktuellen Mirror-Modi noch nicht ganz zufrieden, aber hoffentlich verbessern diese Änderungen die Situation zumindest vorerst etwas.
    Das beste Betrachtungserlebnis lässt sich letztlich nur mit einer separaten Kamera erreichen, die eine komplett eigene Ansicht rendert – was allerdings sehr rechenintensiv ist. Ich denke, wir sollten das RTT-System (Render-to-Texture) nutzen können, um eine separate Kamera mit eingeschränkten Möglichkeiten zu realisieren. Einen ETA dafür gibt es aktuell noch nicht.

    Theater Mode

    • Unterstützung für Bildschirmkrümmung im Theater Mode wurde hinzugefügt, basierend auf XR_KHR_composition_layer_cylinder.

    Diese Extension wird leider nur sehr eingeschränkt unterstützt (SteamVR und Pimax unterstützen sie aktuell nicht, Meta hingegen schon). Dabei handelt es sich lediglich um einen temporären Test, der in Zukunft durch eine eigene, maßgeschneiderte Lösung mit deutlich mehr Funktionen ersetzt werden soll.

    Was ich mir dafür wünsche:

    • Ambient Lighting
    • 3D-Modus
    • Verschiedene Umgebungen (z. B. unterschiedliche Skyboxen je nach Aufenthaltsort im Universum!)
    • und mehr!

    Launcher-Update

    Der Launcher erhält in Kürze ein Update, mit dem sich VR explizit ein- und ausschalten lässt. Das ist notwendig, damit SteamVR bei bestimmten Headsets nicht mehr automatisch startet, wenn VR gar nicht gewünscht ist.

    Standardmäßig ist VR dabei deaktiviert. Sobald das Launcher-Update verfügbar ist, müsst ihr VR also bewusst aktiv einschalten, wenn ihr es nutzen möchtet.

    What's Next?

    The Marker/UI rework is still a work in progress. I can't promise that we will be able to fix it for 4.6, but we are trying!

    Many people have already figured out that you can use r_StereoUILensDepth and CV_r_StereoScaleformDepth to fix it. However, that breaks other stuff. Feel free to experiment with it and find something that works for you.

    Edit 19.01.26:

    • Behebung des Smurf-Modus (invertierte Farben) in VR unter Linux.
    • Sämtliche UI- und Visor-Wackler in VR wurden entfernt.
    • Neue Option für Direct-Offset-Steuerung beim Zielen (ADS) hinzugefügt.
      Diese wirkt sich nur aus, wenn der Actor Control Mode auf Grounded Look (stabiles Bild) eingestellt ist.

    Edit 22.01.26:

    • Ein Crash beim Aktivieren von HDR mit angeschlossenem Headset wurde behoben.
      HDR wird nun automatisch deaktiviert, sobald VR aktiviert ist, um Anzeigeprobleme zu vermeiden.
      Zusätzlich wurde echte HDR-Unterstützung für VR implementiert. Diese kann über
      r_StereoModeAllowHDR=1 aktiviert werden.
      Dafür ist jedoch auch ein HDR-Monitor erforderlich.
      Bitte beachtet: HDR für VR ergibt keinen Sinn und sieht falsch aus, wenn das Headset selbst kein HDR unterstützt.
    • Die Motion-Compensation-Layer wurde standardmäßig deaktiviert, um Abstürze zu verhindern
      (kann über sys_openxr_layer_disable_motion_compensation=0 in der user.cfg wieder aktiviert werden).
    • Das OpenXR Toolkit wurde aufgrund von Kompatibilitätsproblemen standardmäßig deaktiviert
      (umschaltbar über sys_openxr_layer_disable_openxr_toolkit=0 in der user.cfg).
    • Das UI-Menü ist nun weltverankert vor dem Spieler, statt an die Blickrichtung gekoppelt zu sein.
      Das verbessert die Bedienbarkeit deutlich, insbesondere bei Headsets mit niedrigerer Auflösung.
      Das alte Verhalten kann weiterhin mit CV_r_StereoUIAttachedToView=1 wiederhergestellt werden.

    Zusätzlich arbeiten wir weiterhin daran, native Pimax-OpenXR-Unterstützung mit EAC kompatibel zu machen.
    Bitte habt hier noch etwas Geduld.

    Das war’s für den Moment!
    Wir sehen uns im ’Verse – und hoffentlich auch in VR! :)

    Silvan

    Alle verfügbaren Konsolen-Variablen in v4.6 (CVar)

    Quelle: https://gist.github.com/troubleNZ/706f…-attributes-xml

    Hinweis: Bei dem folgenden Text handelt es sich um eine Übersetzung vom Technical Support Artikel: "SteamVR Starts Automatically" von "Thrysurr-CIG" vom 18.12.2025

    Die VR-Funktion (Virtual Reality), die derzeit in Star Citizen experimentell getestet wird, ermöglicht es den Spielern, auf ganz neue, immersive Weise mit dem 'Verse zu interagieren. Weitere Details und die Möglichkeit, Feedback zu dieser Neuerung zu geben, findest du in diesem Thread auf Spectrum: Star Citizen VR Support – Experimentelle Veröffentlichung. (Hinweis: Eine Übersetzung ist hier verfügbar: VR Support - Experimental Release (4.5 PTU) | Silvan-CIG)

    Wie bei allen neuen Features, insbesondere bei experimentellen, gibt es auch hier einige Anlaufschwierigkeiten. Ein Problem, dass das CIG Team bereits identifiziert hat und an dessen Behebung arbeitet, betrifft SteamVR. In einigen Fällen kann es vorkommen, dass das System beim Start des Spiels automatisch SteamVR aktiviert und das zugehörige Headsets startet. Das ist natürlich in Ordnung, wenn ein Spieler die VR-Funktion nutzen möchte, kann aber ansonsten unerwünscht sein. Die folgenden Schritte beschreiben, wie du dieses Verhalten unterbinden kannst.

    Workaround um den automatischen Start von SteamVR zu verhindern

    Um den automatischen Start von SteamVR zu verhindern:

    1. Beenden das Spiel und den RSI Launcher.
    2. Navigiere zu deinem Spiel-Installationsordner.
      1. Der Standardinstallationspfad lautet: (Installationslaufwerk)Programme\Roberts Space Industries\StarCitizen\LIVE
    3. Such nach einer Datei namens user.cfg.
      1. Wenn es hier keine Datei mit diesem Namen gibt, erstell ein neues Textdokument und nenn es user.cfg.
    4. Öffne die Datei user.cfg mit einem beliebigen Texteditor.
    5. Füg eine neue Zeile hinzu: sys.openxr=0
    6. Speicher die Datei.
    7. Öffnen den RSI Launcher erneut und starten das Spiel erneut.

    Dadurch sollte die automatische Initialisierung verhindert werden. Wenn du auf weitere Probleme stößt oder einfach nur Feedback geben möchtest, melde dich bitte in diesem Spectrum-Beitrag.

    MfG