Community durchsuchen: Zeige Ergebnisse für die Stichwörter "'Tastatur'".

  • Suche mithilfe von Stichwörtern

    Trenne mehrere Stichwörter mit Kommata voneinander
  • Suche Inhalte eines Autors

Inhaltstyp


Forum

  • Willkommen
    • // Organisations Modul
    • News
    • Botschaft
    • Bewerbungen
  • Schiffskneipe
    • Off-Topic
    • Website & Forum
    • Hard & Software

Kalender

Keine Suchergebnisse


3 Ergebnisse gefunden

  1. Genau Artikelbeschreibung: QPAD MK-50, Cherry Brown Tactile, DE Layout Ich möchte vorweg anmerken, dass ich bis jetzt noch keine mechanische Tastatur hatte. Daher kann ich keine Vergleiche zu anderen Cherry Tasten ziehen. Tastengefühl: Das allgemeine Tastengefühl ist wirklich großartig. Wenn man einen vergleich ziehen müsste, dann wäre dieser zwischen einer alter Pampelmuse und einer knackiger Karotte. Das etwas schwammige Gummitastengefühl gehört der Vergangenheit an. Der allgemeine Tastenwiederstand ist dabei für mich persönlich passend. Der Auslösewiederstand könnte allerdings noch etwas deutlicher sein. Wenn die Taste am Ende beim durchdrücken aufschlägt, hat sie einen kleinen sauber defenierten Punkt. Beim loslassen wird die Taste rasch durch die Feder wieder in Position gebracht. Dies ermöglicht es, eine extrem hohe Tastfrequenz ohne Fehler zu erreichen. Die Taste muss dazu nicht vollkommen durchgedrückt werden. Der Auslösepunk kommt sehr früh. Dies stört allerdings nicht beim normalen schreiben. Hier kann die Tasten getrost komplett furchgedrückt werden, wie man es gewöhnt ist. Auch der Lautstärkepegel bleibt dabei absolut im Rahmen und ist nur geringfügig lauter als bei meiner alten G11. Als persönliches Highlight möchte ich die Resistenz gegen Querkräfte hervorheben. Auch wenn man die Tasten von weit weg nur am Rand betätigt, gibt es kein hakeln, die Taste schaltet sauber durch. Meine Schreibgeschwindigkeit konnte ich dadurch deutlich erhöhen. Das ist auch hauptsächlich der geringeren Fehlerrate zu verdanken. Geliefertes Zubehör: Tastatur, PS2 -> USB Adapter, 4 Orange blanke Tasten, Handablage, Tastenabzieher Pluspuntkte: Gutes Tastengefühl, besonders bei Querkräften n-key rollover + CPU Interrupt via PS2 kleiner Formfaktor bei normaler Tastengröße und Tastenabstand. massive Anschlussleitung abnehmbare Handablage Minuspunkte: keine rechte Windows Taste (fällt mir auf, da ich gerne Win + L mit einer Hand drücke) Plastiktyp der Handablage wird sich wohl schnell abnutzen Befestigungsmechanismus für die Handablage eher fragil dürftige Bedienungsanleitung Neutrale Punkte: kein Schnickschnack wie z.B. extra Software, extra Makrotasten keine Beleuchtung Fazit: Die QPAD MK-50 stellt im unteren Preissegment der mechanischen Tastaturen eine gute alternative dar, wenn man auf andere Hersteller verzichten möchte. Im Vergleich zu normalen Tastaturen ist das schreibgefühl deutlich besser, jedoch auch die Ausstattung bei gleichem Preis deutlich geringer. Wer auf Makros und programmierbare RGB Hintergrundbeleuchtung verzichten kann ist mit dieser Tastatur sicherlich gut bedient.
  2. Wie der Titel schon vermuten lässt, suche ich für meinen GB eine mechanische Tastatur. Ich wollte euch daher nach eurer Meinung fragen. Was kann man sich kaufen? Was soltle man sich nicht kaufen? Was würde ihr bis 100€ empfehlen? Ich würde zudem eine starke eigenbeleuchtung bevorzugen, muss aber kein RGB sein. Welche Cherry Taste ist euer Liebling und warum?
  3. Bevor Ihr die News lest würde ich euch bitten, kurz an der Umfrage teilzunehmen. Seid ruhig ehrlich und sollte etwas fehlen, könnt ihr natürlich gerne auch auf den Post antworten. Lg Mith --------- // Offizielle News: https://robertsspaceindustries.com/comm-link/transmission/13951-Flight-Model-And-Input-Controls // VOM CHAIRMAN: FLUGMODELL UND EINGABEGERÄTE Greetings Citizens, es ist schön zu sehen, dass sich so viele von euch bereits am Space Combat beteiligen und einen ersten Eindruck gewinnen. Ich, genau wie der Rest des Teams, haben bereits begeistert den Twitch Streams von Backern zugesehen und verfolgen im Forum das gesammelte Feedback. Zwei der heiß debattierten Themen sind das Flugmodell sowie die Vor- bzw. Nachteile der verschiedenen Eingabegeräte. Daher habe ich mir gedacht, ein wenig eurer Zeit zu nehmen und euch ein wenig zu diesen Themen zu erklären. Flugmodell Die meisten Weltraumspiele (so auch meine bisherigen) vereinfachen die Simulation dramatisch, für gewöhnlich in Form eines atmosphärischen Flugmodells ohne Gravitation und Luftwiderstand - Schiffe haben vordefinierte Roll-, Nick- und Gier-Winkel/Raten, eine lineare Beschleunigung (die auf eine vereinfachte Punkt-Masse Anwendung findet) und eine beschränkte Höchstgeschwindigkeit. Wenn ihr euch drehen wollt, ist der Joystick- bzw. Maus-Input direkt auf die zuvor spezifizierte Dreh-Rate gemappt und das Trägheitsmoment wird ignoriert. Schaden wird für Gewöhnlich als Multiplikator behandelt und entsprechend auf Dreh-Rate und Beschleunigung angewendet. Star Citizen macht genau das nicht. Wir modellieren all das, was bei einem echten Raumschiff benötigt würde, so auch die korrekte Anwendung von Schub und zwar an den Stellen wo die Schubdüsen (Thruster) am Schiff angebracht sind - in unserem Modell sind das Trägheitsmoment, Masseveränderungen und Gegenschub EXTREM wichtig und nötig. Die Simulation in Star Citizen basiert auf dem was im All tatsächlich passieren würde. Es gibt einige Gründe, warum wir uns für diesen Weg entschieden haben: Weil wir von Anfang an geplant hatten, Raumschiffe und den Flug im All auf einem Level zu simulieren, das bisher in einem Spiel so noch nicht da war. Ich wollte eine System in dem sich Schiffe unterschiedlich verhalten und ihre Flugeigenschaften ändern wenn sie z. B. einen beschädigten Thruster haben, einen Flügel verlieren oder vom Piloten mit zu vielen Waffen und Munition überladen werden. Ich wollte ein System, dass dieses Gefühl für eine Vielzahl an Schiffen ermöglicht, egal welche Größe oder Rolle das Schiff hat; vom Einsitzer mit 15 Metern Länge bis hin zum Capital-Ship mit über 1 Kilometer Länge für viele Spieler. Ich wollte dass diese Schiffe alle ihren eigenen Charakter haben, ähnlich wie bei vergleichbar großen Autos, die sich trotzdem komplett anders anfühlen können. Ich wollte, dass Schiffe ihre eigene Persönlichkeit bekommen und nicht nur eine schnellere oder langsame Version eines einzelnen Schiffs sind. Der zweite Aspekt ist, dass Star Citizen einen erheblich Anteil an PvP haben wird. Ich weiß nicht wie viele Leute Wing Commander Armada (der erste Wing Commander Teil mit Multiplayer), es hat jedenfalls nicht besonders viel Spaß im "Battle Mode" gemacht. Wenn man ein Singleplayer designt kann man die KI gezielt dümmer machen, damit der Spieler z. B. aufschließen oder mehrere Ziele abschießen kann, sodass er ein Erfolgserlebnis hat. Es gibt nichts besseres als im Alleingang 10 Kilrathi zu erledigen. Doch wenn wir ehrlich sind, hat der Erfolg des Spielers im Singleplayer weniger mit Skill zu tun denn viel mehr mit der Tatsache, dass er im Verhältnis zum Standard-Gegner übermächtig ist und so mit Leichtigkeit Wellen von Gegnern besiegen kann. Dieses Vorgehen ist im PvP unmöglich und es ist wahrscheinlich, dass mehrere Speiler das selbe Schiff haben werden. Ohne ein ausgeklügeltes Simulationssystem und Flugmodell, das dem Spieler eine Vielzahl an taktischen Möglichkeiten eröffnet, kann das Gefecht schnell langweilig werden, wenn keiner es schafft hinter den anderen zu gelangen, weil beide Schiffe sich identisch verhalten (und es weder Luftwiderstand noch andere Faktoren gibt, die Einfluss auf die Manöver haben). Das sind die Hauptgründe, warum wir uns die Mühe machen und eine volle Simulation anstreben die das Steuern und Manövrieren eines Schiffes im All realistisch abbildet - ohne Abkürzungen oder Vereinfachungen. Genauso versuchen wir die Schiffssysteme realistisch zu simulieren. Jede Funktion "hängt" an einem Gegenstand, der tatsächlich im Schiff vorhanden ist - die Waffen, Thruster und Wärmetauscher, der Reaktor, das Radar, der Tank, Batterien, das Zielsystem, CPU, HUD und selbst das "Intelligent Flight Control System (IFCS) sind alles Gegenstände die im Schiff abgebildet werden und miteinander verbunden sind. Es gibt Verbindungen für Energie, Hitze, Treibstoff und CPU-Zyklen. Der Zielcomputer benötigt Energie vom Reaktor und CPU-Zyklen vom Schiffs-Computer, sowie Positionsangaben vom Radar um so Ziele aufzulösen. Gibt es z. B. nicht genügend CPU-Zyklen, wird das Ziel verzögert aufgelöst, fehlt Energie kann der Zielcomputer sogar komplett ausfallen. Wird nicht genügend Energie von den Waffen abgeleitet, können sie überhitzen, ausfallen oder beschädigt werden. Wird einer eurer Flügel mit den Wärmetauschern weggeblasen, reduziert ihr besser schnell eure Hitzeentwicklung. Da wir sowohl die Schiffssysteme als auch die Schiffsphysik komplett simulieren, ermöglicht uns dies ein extrem hohes Maß an Emergenz und Vielfalt im fertigen Spiel. Die Konfiguration der Schiffe wird nicht nur im Hinblick auf Funktionalität sondern eben auch bezogen auf Flugverhalten und Feedback sehr wichtig. Genau wie in der Realität könnt ihr auf ein redundantes und damit ausfallsicheres System setzen oder euch ein schlagkräftiges Schiff mit mehr Feuerkraft zu Lasten der Manövrierfähigkeit zusammenstellen. Klingt vielversprechend, oder? Warum also die ganze Aufregung? Eine solide Simulation vom Flug im All unterscheidet sich grundsätzlich von Flugmodellen in der Atmosphäre. Im All gibt es keine aerodynamischen Kräfte (Auf- oder Abtrieb), daher werden die lineare Masseträgheit sowie die Winkelgeschwindigkeit (Rotationsgeschwindigkeit) umso wichtiger. Ohne eine Gegenkraft zu setzen, um das Momentum eines Objekts zu verändern, bewegt sich dieses im All unverändert weiter. Zieht ein Spieler am Jaystick, aktiviert er damit die Thruster um eine Rotation auszulösen, was wiederum die Winkelgeschwindigkeit des Schiffs erhöht. Zentriert sich der Joystick wieder oder wird er in die entgegengesetzte Richtung bewegt, muss nun das IFCS Gegenschub erzeugen um zuerst die aktuelle Winkelgeschwindigkeit umzukehren und schließlich die gewünschte neue Rotationsgeschwindigkeit zu erreichen. Sofern das Schiff keine unendlich starken Thruster hat, wird dies nicht sofort passieren. Da das ICFS nicht in die Zukunft gucken kann, weiß es vorab nicht wann ihr die Winkelgeschwindigkeit verändern wollt; es kann eure Handlungen nicht voraussehen. Daher wird entweder der Pilot dafür sorgen, dass sich der Kurs langsam stabilisiert, oder er wird zwangsläufig über das Ziel hinausschießen. Stellt euch einfach vor ihr sitzt in einem fahrenden Auto und wollt anhalten. Normalerweise habt ihr ein gutes Gefühl dafür, wie lange euer Auto braucht um zum Stehen zu kommen, daher wisst ihr wann ihr mit dem Bremsvorgang beginnen müsst, damit ihr z. B. an einem Stoppschild anhaltet. Ihr erwartet nicht, dass das Auto von 80 Km/h augenblicklich zum Stehen kommt. Dieses Verhalten unterschiedet sich maßgeblich von dem eines konventionellen Flugzeugs, das Oberflächen nutzt um den Luftwiderstand bzw. Auf- und Abtrieb zu verändern. In diesem Fall ist die Änderung der Winkelgeschwindigkeit proportional zur Veränderung der Ruder-/Flaps-Position. Das bedeutet, dass ihr bis zu einem gewissen Grad vorwegnehmen müsst wo ihr hin wollt und den Bordcomputer entsprechende Bewegungen frühzeitig ausführen lasst. Wenn ihr den atmosphärischen Flug gewöhnt seit und zum ersten Mal in einem Modell fliegt, in dem Trägheit und Beschleunigung eine viel wichtigere Rolle spielen, ist es sehr wahrscheinlich dass ihr anfangs regelmäßig übersteuert und euer Ziel verfehlt. Da der Gegenschub ebenfalls nicht augenblicklich wirkt, korrigiert ihr im zweiten Schritt die Flugbewegung zu stark und verfehlt euer Ziel erneut. Dieses Verhalten des Schiffs kann als "schwammig" wahrgenommen werden, wenn man die Steuerung nicht gewöhnt ist. Da die Leute nicht an diese Art der Simulation gewöhnt sind, nimmt derzeit ein Teil der Community das Flugmodell als "falsch" Wahr. Wenn ihr jedoch einmal genau darüber nachdenkt, ermöglicht unser Modell eine viel größere Vielfalt an Variationen und Nuancen im Kampf, die in einem Wing Commander/X-Wing in seiner einfachen Form nicht ansatzweise möglich wären. So wie es dauert ein Auto richtig fahren zu können... dauert es einfach bis man eine neue Steuerung erlernt hat. Ihr müsst überlegen was euer Ziel ist und vorher planen wie ihr es erreicht. Ist das System damit perfekt? Nein! Das ist einer der wichtigen Gründe, warum wir alles daran gesetzt haben, euch so früh wie möglich testen zu lassen. Es ist super Leute zu sehen, die das Spiel spielen und ihr Feedback geben. Es ist auch großartig zu sehen, dass Spieler, die das Flugmodell im ersten Moment komplett abgelehnt haben, nach einem Besuch im Forum das Potential verstanden und die neuen Möglichkeiten als Chance verstanden haben. Dies bedeutet nicht, dass alle vom System überzeugt sind, es ist jedoch immer schön zu sehen, wie Leute für Neuerungen offen sind und sich nicht verschließen. Das bedeutet ebenfalls nicht, dass ich mit dem derzeitigen Stand zufrieden bin. Mein Ziel ist es, dass alle Nuancen, die ich oben beschrieben habe, für jeden verfügbar zu machen und gleichzeitig den Einstieg so einfach wie bei Wing Commander zu gestalten. Den wichtigsten Punkt den es zu bedenken gibt, ist dass das IFCS lediglich das Interface zwischen der physikalischen Simulation der Schiffsbewegung (Thrustern) und den Kräften die hierbei Anwendung finden ist. Es ist nicht das Modell. Ich habe viele Post gelesen, in denen der Wunsch nach dem "Newstonian"-Mode geäußert wird. Die physikalische Simulation ist bereits eine vollwertige Newton'sche Starrkörpersimulation. Für das was wir erreichen wollen wird immer die Notwendigkeit eines Fly-by-Wire-Interface zwecks Umsetzung des Spieler-Inputs bestehen, da kein menschlicher Spieler gleichzeitig 8 Thruster bedienen können wird, vor allem nicht wenn er eigentlich den individuellen Schub berechnen müsste, um eine bestimmte Beschleunigung in die gewünschte Richtung zu erzielen. Im Rahmen der Simulation kann das IFCS im Prinzip all das machen, was wir uns vorstellen können und physikalisch möglich ist. Der Schlüssel liegt darin, dass IFCS so anzupassen, dass der Spieler-Input wie gewünscht interpretiert und umgesetzt wird. Die erste Iteration der verschiedenen Modi - basic IFCS, De-Coupled, G-Safe und Comstab sind alles unterschiedliche Modi die wir in verschiedenen Situationen als nützlich erachten. Das bedeutet nicht, dass diese Modi nun fix sind, oder dass die Ausprägung der Anwendung nicht geändert wird. Viele Spieler haben nach einem "echten" 6DOF (6 degrees of freedom; 6 Freiheitsgrade) gefragt - zu jeder Zeit. Die würde bedeuten, dass "strafe" während des normalen IFCS-Modus verfügbar wäre und die diagonale Beschleunigung im De-Coupled Modus hinzuaddiert wird. Das sind alles Punkte, mit denen wir experimentieren werden, wobei wir zusätzlich überlegen, noch weitere Modi einzuführen; z. B. einen weiteren G-Safe Modus der die Drehung begrenzt, anstelle von einer Limitierung der Geschwindigkeit. Wir werden ebenfalls mit der Stärke der Thruster experimentieren, die derzeit 1/2 bis 1/3 der Kraft des Hauptantriebs haben, was in unseren Augen noch zu stark ist. Bedenkt dass je schwächer die Thruster, desto "schwammiger" wird sich das Schiff anfühlen und desto eher wird es über das Ziel hinaus schießen, wenn ihr euch in einer Drehbewegung neu ausrichten wollt. Um euch noch mehr Einblick in die Funktionsweisen des IFCS zu geben, hat euch John Pritchett, der hauptverantwortliche Entwickler für die Umsetzung und Implementierung des IFCS eine detaillierte Beschreibung des Systems zusammengestellt. Ich hoffe dass ihr alle den Detailgrad zu schätzen wisst, den wir mit Star Citizen versuchen umzusetzen. Vergesst nicht, dass das Spiel soviel mehr als nur Arena Commander beinhalten wird - und selbst in Arena Commander könnt ihr noch bei weitem nicht alles sehen, da wir derzeit durch ein WIP HUD und fehlende Items geblockt werden. Beides wird ebenfalls einen maßgeblichen Einfluss haben. Eingabegeräte Es gab viele Diskussionen zur Frage "Maus vs. Joystick als Eingabegerät" und ein Teil der Community hatte die Sorge, dass die Nutzung der Maus das Spiel zu "arcadey" werden lässt, wobei die HOTAS-Nutzer offen das Gefühl zum ausdruck brachten, dass ihre Geräte zu wenig und zu schlecht unterstützt werden. Lass mich vorab sagen, dass das Ziel von Star Citizen schon immer war, keinen der Controller einem anderen vorzuziehen. Persönlich bin ich ein Joystick-Pilot (entweder HOTAS oder Gamepad). Ich bin einfach der Meinung, dass meine Steuerung mit einem Joystick viel präziser ist. In unseren verschiedenen Studios gibt es eine Vielzahl von unterschiedlichen Nutzungsarten und Präferenzen, einige nutzen die Maus, andere den Joystick, wieder andere nur ein HOTAS und ein Teil Gamepads. Diese Tatsache ist die beste Garantie, dass keines der Eingabegeräte jemals bevorzugt behandelt wird. Jetzt wo dies gesagt ist muss ich ergänzen, dass jedes der Controller-Schemata noch weiterer Arbeit bedarf; insb. im Hinblick auf Flexibilität und Konfigurierbarkeit. Eine unserer Prioritäten bzgl. Arena Commander ist die freie Konfigurierbarkeit der Tastenbelegung im Spiel. Hieran arbeiten wir mit Hochdruck und hoffen, dass wir euch die Funktionalität nächsten Monat bereitstellen können. Wir werden ebenfalls an einer Reihe von HOTAS Profilen arbeiten und dem Feintuning der Joystick-Kontrolle, damit eure Monöver noch präziser ausgeführt werden können. Es existieren bereits Ansätze für zusätzliche Modi in denen der Joystick-Spieler die Vorteile der Kardanaufhängung einiger Waffen analog zur Verwendung mit der Maus nutzen können. Natürlich könnt ihr auch eine Kombination wählen, wenn ihr der Meinung seid, dass mit der Maus das Aiming präziser ist. Nutzt doch einfach den Joystick zum Fliegen und die Maus zum schießen! Gierung vs. Rollen (Yaw vs. Roll) Es gab ebenfalls einige Diskussionen um die Tatsache, dass die Gier-Bewegung keinen Einfluss auf den Piloten bzgl. negativen G-Effekten hat (black out & red out durch vertikale G-Kräfte). Hier gibt es einige Dinge zu beachten. Erstens ist reines Gieren, ohne Schräglage im All sicherlich möglich, auch wenn es nicht der optimale Weg für eine Drehung ist. Man kann mehr Schub durch die Kombination der seitlichen und unteren Thruster erreichen, als wenn man lediglich erstere nutzt. IFCS bringt euer Schiff automatisch in eine Schräglage, um den Dreh-Schub zu optimieren und das ist der Punkt an dem vertikale G-Kräfte ins Spiel kommen (bedenkt dass sich atmosphärische Flugmodelle hier wieder anders verhalten müssen, da eine Schräglage bei einem Kurvenflug nötig wird, um das Flugzeug zu stabilisieren). Zweitens ist die Stärke der Schräglage bei jeder Gier-Bewegung abhängig vom maximalen Schub der durch eure seitlichen Thruster erzeugt werden kann, was zur Folge hat, dass die auftretenden vertikalen G-Kräfte von Situation zu Situation unterschiedlich sind. Drittens sind "black/red out" und Bewusstlosigkeit alleinige Folge von vertikalen G-Kräften, weil das Blut entweder aus dem Kopf oder in den Kopf des Piloten gepresst wird. Korrekt fixierte Piloten können sehr hohen G-Kräften widerstehen ohne das Bewusstsein zu verlieren. Für horizontale G-Kräfte ist der limitierende Faktor struktureller Natur. Unglücklicherweise wurde diese Einschränkung von uns noch nicht in unser Modell implementiert. Sofern wir dies nachgeholt haben, werden auch diese Manöver Konsequenzen haben. Anstelle des eines "black/red out", kann es passieren dass ihr einen Thruster oder Flügel als Konsequenz der extrem hohen horizontalen G-Kräfte abreißt. Und - sofern aktiv - wird der G-Safe Modus die strukturelle Integrität des Schiffes schützen, indem der Schub in bestimmten Manövern limitiert wird. "Turreting" Ein Teil der Community hat die Besorgnis zum Ausdruck gebracht, dass man als Spieler "turreten" kann und sich im De-Coupled Modus einfach umdrehen und immer alle Ziele angreifen kann, was gefühlt "Skill" im Dogfighting unnötig macht. Mir war bewusst das Leute über diese Art der Nutzung nachdenken werden und lasst mich euch versichern, dass es weniger in unserem initialen Multiplayer niemand sich nur auf den De-Coupled Modus verlassen hat geschweige denn verlassen konnte, da man so ein leichtes Ziel wird. Der Schlüssel zum Überleben im Dogfighting ist es, nicht getroffen zu werden und daher seine Flugbahn so unvorhersehbar wie möglich zu machen - Stillstand oder die lineare Bewegung in eine Richtung (was im De-Coupled Modus passiert) sind gute Wege um schnell getötet zu werden. Der De-Coupled Modus wird am besten nur für sehr kurze Zeit verwendet, um sich einen Überblick zu verschaffen und ihn dann sofort wieder zu verlassen. Da wir den Schub der Thruster anpassen und tweaken sodass das Haupttriebwerk eine größere Rolle spielt, wird der De-Coupled Modus die beste Möglichkeit für eine schnelle Richtungsänderung bieten. Ich weiß dass viele nun denken, dass der De-Coupled Modus und die Fähigkeit sich im Gegensatz zur Atmosphären-Simulation schnell auf der Stelle drehen zu können das Spiel zu einfach macht; es geht bei Star Citizen jedoch um den Weltraumkampf und NICHT um eine Atmosphären-Simulation und die Fähigkeit in den De-Coupled Modus zu schalten ist absolut eine Funktion die auch in echten Kämpfen genutzt werden würde. Vergesst nicht, ein Großteil der Community hat besonders auf diese Art der Manövrierbarkeit bestanden um Szenen wie in Battle Star Galactica zu ermöglichen! Kardanaufhängung vs. fixierte Waffen In Arena Commander V1.0 (und Star Citizen allgemein) wird es sowohl fixierte Waffen als auch solche an einer Kardanaufhängung/im Geschützturm geben. Die fixierten Waffen werde eine langsame Auto-Konvergenz von vielleicht +/- 5 Grad ermöglichen, die es ihnen erlaubt sich an einem vom Nutzer spezifizierten Punkt (Standardwert entspricht 1/2 maximale Reichweite) zu fokussieren oder sich der Entfernung des derzeitigen Zeils anzupassen. Wir hatten bisher keine Zeit dieses Feature fertigzustellen, daher haben wir für V0.8 alle Waffen mit einer Kardanaufhängung versehen, sodass die Hornet keinen zu großen Vorteil gegenüber der Aurora oder der 300i hat. Hierbei handelt es sich nicht um einen Dauerzustand. Fixierte Waffen werden einen Frühindikator haben (analog zu realen Kampfflugzeugen). Wir überlegen uns derzeit ebenfalls die Funktion des Fadenkreuzes der aufgehängten Waffen anzupassen. Bisher musste es lediglich auf dem ziel platziert werden und der Zielcomputer hat die Waffen automatisch in Feuerposition gebracht, sobald der gestrichelte Linie innerhalb des Fadenkreuzes verschwindet bedeutet dies, dass alle Waffen ausgerichtet sind. Wir denken darüber nach, dass das Fadenkreuz über dem Frühindikator (nicht direkt über dem Ziel) platziert werden muss damit die Waffen korrekt ausgerichtet werden. Dies erlaubt es dem Piloten, der nicht die volle Kraft der aufgehängten Waffen nutzt (es ist nicht immer einfach in eine Richtung zu fliegen während man in eine andere zielt oder wenn man sich in einem kombinierten Flugmodus wie z. B. dem "Freelancer" Maus-Modus befindet), eine sinnvollere Flugbahn zu wählen, da er im allgemeinen dorthin fliegen will wohin sich das Ziel hin bewegt und nicht in die Richtung an der sich das Ziel derzeit befindet. Für alle die der Meinung sind, dass aufgehängte Waffen keinen "Skill" mehr erfordern sei gesagt, dass Waffenaufhängungen sowie Geschütztürme ein Hauptbestandteil des derzeitigen militärischen Equipments sind und sicherlich auch in der Zukunft sein werden. Es bedeutet ja nicht, dass man automatisch trifft. Die Waffe muss trotzdem noch ausgerichtet werden und das eigene Schiff muss die Flugbahn so anpassen, dass der Zielcomputer die Ausrichtung überhaupt ausführen kann. All das setzt voraus, dass das Ziel eine vorhersehbare Flugbahn hat und nicht plötzlich die Richtung ändert! -- Chris Roberts // ÜBERSICHT: INTELLIGENT FLIGHT CONTROL SYSTEM (IFCS) In Star Citizen ist das IFCS ein Flugkontrollsystem das Piloten dabei unterstützen soll ein Raumschiff zu fliegen. Es übersetzt die Eingaben des Piloten in Schubvektoren der Thruster um einen bestimmten Befehl auszuführen, auch bei einem sub-optimalen oder ausfallenden Antriebssystem. Es ist ein adaptives System das mit Hilfe von Sensoren und Feedback-Kontrolle versucht den Fehler zwischen dem gewünschten Zielzustand und dem tatsächlichen Zustand des Raumschiffs gegen Null gehen zu lassen. Es ist insofern fehlertolerant als dass es jederzeit das Wegfallen eines oder mehrer Thruster wenn nötig unter Zuhilfenahme des Ersatz-Gyros auszugleichen versucht, um das Raumschiff zu stabilisieren und wenn möglich dem Piloten die Kontrolle zu erhalten. Selbst mit einem verbleibenden Thruster kann der Pilot aktiv sein Raumschiff kontrollieren, auch wenn dies nicht ganz einfach ist. IFCS: Subsysteme Das IFCS besteht aus vielen Subsystemen die zusammenarbeiten um dem Piloten die optimale und stabile Kontrolle über das Raumschiff zu ermöglichen. Es beinhaltet: Propulsion and Attitude Control (PAC) – PAC beinhaltet typischerweise das volle Thruster-Set, das sowohl für die translatorische ("strafe") als auch die Roll-Bewegungen zuständig ist, sowie ein Backup Moment Gyro (CMG), der zusätzliche Fluglagenkontrolle ermöglicht. Es beinhaltet ebenfalls alle Schaltkreise sowie die Kontrollsoftware die diese Elemente nutzen. Primary Control System (PCS) – Das PCS stellt ein Interface zwischen dem Piloten und dem IFCS bereit. Es übersetzt die Anweisungen des Piloten in Aktionen die in einen "virtual control frame" übersetzt werden, der die optimale Zielaktion des Piloten darstellt und vom System interpretiert werden kann. Das "virtual control frame" besteht aus einer Zielgeschwindigkeit entlang einer beliebigen Kombination von Achsen, der Ziel-Rotationsrate entlang einer beliebigen Kombination von Achsen, sowie einer Referenz-Fluglage. Dieses virtuelle Abbild stellt den Idealzustand des Raumschiffs unter perfekter Kontrolle dar und jede Eingabe des Piloten wird auf dieses Abbild angewendet, womit die Effekte externer Fehler durch den Piloten limitiert werden. Reaction Control System (RCS) – Der physikalische Zustand der im PCS herangezogen wird, kommt durch den antizipierten Thrusterschub sowie unter Verwendung des CMG zustande und basiert auf den Piloteneingaben. Unter idealen Bedingungen weicht die vorhergesagte Fluglage nicht von der tatsächlichen Fluglage des Raumschiffs ab. Einflüsse wie sub-optimal funktionierende oder beschädigte Thruster sowie externe Faktoren wie Waffenfeuer und Explosionen etc., führen dazu, dass regelmäßig eine Abweichung zur antizipierten Fluglage entsteht. Wenn das passiert ist es die Aufgabe des RCS diese Abweichungen gegen Null zu korrigieren. Hierbei greift das RCS sowohl auf alle Thruster sowie das CMG zurück. Schlägt eine Synchronisierung der Fluglage innerhalb vertretbarer Zeit fehl, ist das RCS in der Lage die virtuelle Fluglage zurückzusetzen und durch die tatsächlichen Werte (reale Fluglage) zu ersetzen sodass eine Desorientierung des piloten verhindert wird. Anti-gravity System (AGS) – Das AGS erkennt und kompensiert Gravitation sowie jegliche andere externe Kraft die auf das Raumschiff einwirkt, sodass es die relative Position zum Ursprung dieser Kraft hält. Turn Control System (TCS) – Das TCS unterstütz den Piloten dabei stabile Kurven zu fliegen. Besonders bei hohen Geschwindigkeiten kann es vorkommen, dass die Thruster nicht genügend Schub liefern, um das Schiff in im Kurvenflug zu stabilisieren. Das führt dazu, dass das Schiff "schlingert", was wiederum zu einer Kollision führen kann. Normalerweise würde ein Pilot die Geschwindigkeit drosseln, bevor er sich dreht, dies kann jedoch ebenso das TCS übernehmen indem es die vorwärtsgerichtete Bewegung der gewünschten Dreh-Rate anpasst bei gleichzeitiger Berücksichtigung des maximal verfügbaren Schubs. Das System berücksichtigt ebenfalls den optimalen Schub für die benötigte Schräglage in Abhängigkeit der Verfügbarkeit. G-force Control Mode (GCM) – GCM ist einer Sicherheitsmodus der den Piloten vor potentiell gefährlichen G-Kräften schützen soll. Die größte Gefahr für einen Piloten geht von einer länger andauernder vertikalen G-Belastung. Sie kann zu einem "black out", "grey out", red out", Orientierungslosigkeit, Bewusstlosigkeit und sofern die Situation länger anhält, zum Tode führen. Besonders starke horizontale G-Kräfte werden ebenfalls vermieden, da sie zu physischen Schaden des Piloten oder sogar strukturellem Schaden am Raumschiff führen können. Zusätzlich zu den genannten Subsystemen können weitere implementiert werden, die z. B. erweiterte Funktionen bieten. IFCS: Funktionsweise Das IFCS nimmt die Eingaben des Piloten entgegen, die aus einer Vielzahl an Kombinationen und Befehlen bestehen können, aber letztendlich in 3 Bewegungs- sowie 3 Rotationsrichtungen übersetzt werden. Zusätzlich können andere Eingaben des Piloten als Parameter in diversen Phasen des IFCS verwendet werden. Sobald Eingabewerte von IFCS Modulen wie dem TCS und GCM verändert wurden, gelangen sie ins PCS, welches sowohl den PID-Controller (Proportional Integral Differential Regler) für die Linear- als auch jenen für die Kreisgeschwindigkeit enthält. Diese Kontrollfunktionen berechnen die optimale Kraft und das optimale Drehmoment die, wenn sie auf das Schiff angewandt werden, die vom Piloten angeforderte Bewegung erzeugen. Gleichzeitig wird die Fluglage ausgelesen und an das RCS weitergegeben, wo ein PID-Controller verwendet wird, um die tatsächliche Ausrichtung des Raumschiffs der gewünschten Ausrichtung die vom PCS vorgegeben wird, anzugleichen. Die Steuereinheit gibt dann ein Drehmoment an, das im besten Fall den Fehler in der Fluglage im nächsten Zeitintervall korrigiert. Zuletzt werden noch bestehende Kraftfelder, typischerweise Schwerkraft, an das AGS weitergegeben, welche die nötige Gegenkraft berechnet. Sobald die benötigten Kräfte und Drehmomente berechnet wurden, werden ihnen die verfügbaren Antriebsmodule priorisiert zugeordnet. Das AGS wird zuerst berücksichtigt, da ein Fehler in der Generierung von ausreichend Gegenschub katastrophal enden könnte. Anschließend wird das RCS versorgt, wobei die Ressourcen erst vom primären Schubsystem herangezogen werden und anschließend, wenn nicht bereits genügend Schub verfügbar ist, vom CMG. Danach wird das PCS versorgt, welches ebenfalls zuerst vom Haupttriebwerk Schub erhält (anschließend das CMG). Zum Schluss wird mit der niedrigsten Priorität die translatorische Bewegung ("strafe") versorgt. Nach kurzer Zeit, sobald das Schubsystem die IFCS Kommandos ausgeführt hat, lesen Sensoren den aktuellen Schiffsstatus aus, welcher vom erwarteten Zustand abweichen kann, weil Schubdüsen ausgefallen sind, unkompensierte externe Kräfte gewirkt haben, usw., und gibt diese dann wieder an das IFCS zurück, welches den Vorgang wiederholt. Geschwindigkeits- und Fluglagenkontrolle Da das IFCS sich nicht auf das Schubsystem verlassen kann um die angeforderte Bewegung auszuführen, benutzt es einen PID (Proportional Integral Derivative) Controller, um den Fehler zwischen gewünschtem Status und gemessenem Status zu minimieren. Diese Controller werden sowohl vom PCS verwendet, um die optimale Kraft und das optimale Drehmoment für die Ausführung der Steuerungsbefehle zu berechnen, als auch vom RCS, um die Fluglage zu halten. PID Controller können modifiziert werden um eine Reihe an Reaktionscharakteristika zu haben. Am Beispiel der Geschwindigkeit wird ein "überdämpfer" Controller das Schiff sehr schnell in Richtung der Referenzgeschwindigkeit beschleunigen, darüber hinweg schießen und etwas schwanken wenn es sich der Zielgeschwindigkeit angenähert hat. Ein "unterdämpfter" Controller wird langsamer beschleunigen und ohne über die Zielgeschwindigkeit hinauszuschießen diese annehmen. Ein kritisch "gedämpfter" Controller wird optimal beschleunigen, um möglichst schnell die Zielgeschwindigkeit zu erreichen, ohne über sie hinauszuschießen. Das PCS, das für Linear- und Kreisgeschwindigkeitssteuerung verantwortlich ist, wird dynamisch angepasst. Basierend auf der Stärke der Eingaben des Piloten können diese von schwacher bis hin zu aggressiver Beschleunigungsreaktion reichen. Des Weiteren könnten einzelne Piloten eine mehr oder weniger starke Beschleunigungsreaktion bevorzugen. Die tatsächliche Antwortzeit des IFCS Controllers ist nicht nur von den Einstellungen abhängig, sondern auch von der Reaktionszeit der Schubsystemkomponenten. Schubsystem Thruster Die Primärkomponente des Schubs auf den meisten Schiffen wird der Thruster sein. Das Star Citizen Flugmodell bietet eine 100% akkurates Thruster-Modell, das die Position jedes Thrusters relativ zum Massepunkt des Schiffes berücksichtigt, und ebenfalls die maximale Schubkraft und Reaktionszeit jedes Thrusters in die Berechnung mit einbezieht. Unter idealen Bedingungen werden die Thruster gleichmäßig um den vorgesehenen Massepunkt des Schiffs verteilt. Dies erlaubt eine optimale Kontrolle über die Thruster. Auf dem folgenden Bild sind die oberen, hinteren Thruster ausgeglichen um den Massepunkt positioniert und werden kein Drehmoment auf die Z-Achse anwenden Nachdem das Schiff Schaden erlitten hat kann es passieren, dass sich das Massezentrum verschiebt und somit das Thrustersystem destabilisiert. Im folgenden Bild sind die Thruster nicht mehr ausgeglichen um das Massezentrum positioniert. Geben die Thruster Schub wird ein Drehmoment auf die Z-Achse angewendet, was zu einem Drehen auf ihr führt (Yaw). IFCS wird versuchen, dieses Drehmoment zu kompensieren, indem andere Thrusterpaare verwendet werden, und ein Gegendrehmoment erzeugen wird. Ist dies nicht möglich wird es versuchen, das ungewollte Drehmoment durch ein Reduzieren des Schubes der betroffenen Thruster auszugleichen. Schaden und andere Umstände können auch den möglichen maximalen Schub, die Reaktionszeit oder sogar die Genauigkeit jedes Thrusters verringern, oder ein Thruster könnte vollkommen funktionslos oder komplett verloren werden. Jede dieser Änderungen wird einen Effekt auf die Balance der Thruster haben und sich somit auf das Flugverhalten des Schiffes auswirken. Control Moment Gyro (CMG) Jedes Schiff hat ein kleines Drehmoment zur Verfügung, auch wenn alle Thruster verloren oder beschädigt sind. Dieses Drehmoment kommt von einigen internen Control Moment Gyros. Solange die CMGs funktionsfähig sind, wird der Pilot immer ein Minimum an Drehmoment für die Drehung auf jeder Achse zur Verfügung haben. Dieses Drehmoment reicht aus, um die Ausrichtung des Schiffes zu stabilisieren und kann zur langsamen Drehung unter direkter Kontrolle des Piloten verwendet werden. Schlusswort Dieses Dokument ist keine fiktionale Beschreibung des Star Citizen IFCS, sondern stellt eine akkurate Beschreibung des tatsächlichen Steuerungsmodelles dar, welches in das Spiel implementiert wurde. Dieses Realismus-Niveau ist notwendig, um ein Steuerungsmodell bieten zu können, das vollständig integriert und von der Umgebung, Schäden, Änderungen der Gewichtsverteilung, der Energieverteilung, Thrusterplatzierung, usw. beeinflusst werden kann. Das IFCS befindet sich derzeit noch im Aufbau und kann daher manchmal fehlerhaft sein. Genau das spiegelt jedoch die Realität wider. Und zum Schluss möchte ich anmerken, dass große Anstrengungen unternommen wurden, die Steuerung der Raumschiffe auf jene Arten zu beschränken, die durch das IFCS abgebildet werden können. Kein Spieler, keine KI und selbst IFCS wird jemals die Position, Geschwindigkeit, Rotation oder Drehgeschwindigkeit eines Schiffes direkt beeinflussen, mit Ausnahme der Initialisierung und Netzwerkkorrektur. Dies garantiert, dass die Steuerung der Raumschiffe konsistent ist und das Spiel niemals einen unfairen Vorteil einem Spieler gegenüber haben wird. Ich freue mich auf euer Feedback, während wir daran arbeiten, das System zu verfeinern und zu verbessern. Schlussendlich handelt es sich hier nur um den Beginn. Wir legen grade erst los! John Pritchett Physics Programmierer bei CIG