Erste Aktionen und Windows-Eingabediagnose
Änderung
Die ersten beiden Einsätze erklären Fliegen und Scannen mit einem kleinen Gerätesymbol im vorhandenen unteren Hinweisbereich. Keine neue Sprache oder zusätzliche Leiste. Der Flughinweis wartet 1,2 Sekunden und verschwindet nach 1,2 tatsächlich manuell geflogenen Welteinheiten. Der Scannerhinweis erscheint erst an einem erreichbaren Satelliten, Helfer oder Signal und bleibt bis zu einer erfolgreichen Verbindung erhalten. Pause und Rettung blenden ihn sofort aus; gesprochene Untertitel haben Vorrang.
Gelernte Aktionen bleiben während der laufenden Anwendung je Pilot getrennt erhalten. Nach einem Neustart dienen abgeschlossene Einführungseinsätze als Nachweis. Der Spielstand erhält keine neuen Felder. Steuerungsbelegung, Schwierigkeitswerte und Bossbewegungen bleiben unverändert.
Diagnoseverfahren
Die vorherige native Fensterprüfung hatte funktionierende UI-Mausklicks, aber keinen eindeutigen Nachweis für Flugbewegung durch press_key oder drag. Das allein belegt keinen Fehler physischer Geräte.
Der neue, ausschließlich opt-in aktive FlightInputDiagnostic verlangt sowohl --spacehero-input-diagnostic als auch einen tatsächlich angegebenen --spacehero-data-Pfad. Normale Starts erzeugen keine Eingabedatei. Ein ausdrücklich isolierter Teststart schreibt lokale JSONL-Daten unter InputDiagnostic im Testordner.
Erfasst werden nur bekannte Spiel-/Menütasten, Maustasten und Zeigerkoordinaten sowie die benutzten Controller-Eingänge. Keine Texteingabe, beliebigen Tasten, Geräteseriennummern oder Signale anderer Anwendungen. Die Aufzeichnung verändert und verbraucht keine Eingaben. Fokuswechsel, ursprüngliche Ereigniszeit, Unity-Eingabeupdate, endgültiger Dynamic-Zustand, aktueller Bildschirm, Kamerabereich und tatsächliche Schiffsposition werden unterschieden. Nach zehn Minuten Laufzeit oder rund 20.000 Einträgen endet die Diagnose; Dateifehler beenden nur die Diagnose.
event_button beschreibt den Zustand aus dem eingetroffenen Ereignis vor seiner Anwendung. dynamic_input beschreibt die tatsächlich gelesene Produktionsbelegung nach dem Eingabeupdate. Ein Druck und Loslassen innerhalb eines Updates kann in beiden Ereignissen sichtbar sein und anschließend einen nicht gehaltenen Zustand ergeben. late_state beobachtet das Ergebnis im Spiel. Die Diagnose ist keine Leistungsmessung.
Nachweise
Spielquellstand: b6b1741 (Hinweise aus b7ca9e2, anschließend nur Diagnose-Lebensdauer korrigiert).
- Reguläre Suite
Artifacts/20260908-052333-editmode-results.xml: 52 bestanden, null Fehler, drei explizite GPU-Prüfungen separat. Zwei neue Integrationsprüfungen belegen tatsächliche Bewegung, abgeschlossene statt lediglich angefangene Scans, erreichbare Ziele, Pause/Hilfe/Wiederaufnahme, getrennte Piloten und ausbleibende Wiederholungen. Die vollständige frische Kampagne und bestehenden Eingaberegeln bleiben abgedeckt. - UI-Geräteerkennung beobachtet die bereits konfigurierten Menüaktionen. Der gezielte Lauf
Artifacts/20260908-051953-editmode-results.xmlbesteht drei Prüfungen inklusive kurzer Enter-Paare. Die anschließend ausgeführte reguläre Suite enthält dieselben Prüfungen. Die zunächst versuchte Erkennung über Frame-Button-Abfragen scheiterte im Lauf051624; diese Variante ist verworfen, ohne die Steuerungsbelegung abzuschwächen. - Finale GPU-Prüfung
Artifacts/20260908-052618-editmode-results.xml: bestanden, 140 Bilder unterArtifacts/TestProfiles/20260908-052618/Offscreen. Maus-, Tastatur- und Controllerdarstellung, Scanner bei 4:3 und Ultrawide, versteckte Pause und wiederhergestellter kurzer Missionstext nach erfolgreichem Scan. Der letzte reine Textabbau der alten Steuerungssätze ist durch diesen finalen GPU-Lauf abgedeckt. Der vorherige erfolgreiche Lauf052236zeigte dieselbe Geometrie; Ansichten tatsächlich gesichtet. - Der erste GPU-Anlauf
052042erkannte den Scanner bereits als gelernt, weil sein Sammelpilot vorher einen optionalen Helfer gescannt hatte. Die Bildfixture absolviert die erste Mission jetzt ausschließlich durch Sammlung und erreicht danach den ersten echten Satelliten. Keine künstliche Rücksetzung des Lernzustands in der Produktion.
Nativer Windows-Nachweis
Der erste Lauf unter Artifacts/NativeQA/20260908-052538-v12-input ist als unvollständige Diagnose erhalten: Im Flug blieb der verwaltete Wrapper der zerstörten Menüauswahl erreichbar. Der nullbedingte C#-Zugriff auf deren Namen löste deshalb eine Unity-Exception im Diagnosewerkzeug aus. Die Korrektur verwendet Unitys tatsächlichen Objektgültigkeitsvergleich. Sie ändert keine Spieleingabe.
Zusätzlicher Regressionslauf Artifacts/20260908-053736-editmode-results.xml: drei Prüfungen bestanden, darunter die neue Diagnoseprüfung über zerstörte Menüauswahl, Flug, Pause und geschlossenen Bericht. Zwei vorangegangene Fixtures wurden korrigiert: 053430 las vor Unitys verzögerter Komponentenzerstörung; 053609 hatte die beabsichtigte Diagnose-Startmeldung nicht als erwartetes Log registriert. Der abschließende Lauf prüft weiterhin vollständige Flug-/Pauseneinträge und keine unerwarteten Logs. Zusammen mit der regulären Suite sind damit 53 unterschiedliche reguläre Prüfungen abgedeckt; dies ist kein neu behaupteter vollständiger 53er-Suitenlauf.
Korrigierter sichtbarer Lauf: Artifacts/NativeQA/20260908-053855-v12-input-fixed. Normaler Windows-Player ohne Prüfpilot, nur explizite Diagnose und getrenntes v11-Testprofil. Prozess 73212 ordnungsgemäß beendet. Player.log, native-actions.json, InputDiagnostic/20260908-033949-890.jsonl und input-analysis.json dokumentieren den Ablauf. Native Fensterbilder wurden tatsächlich betrachtet, aber nicht als separate PNG-Dateien gespeichert.
- 492 Diagnoseeinträge, davon 152 Flugzustände. Tastatur und Maus sind bei Unity registriert. Alle gezielt geprüften Aktionen finden bei aktivem Spielfokus statt; ein früher Fokuswechsel vor der Prüfung ist gesondert protokolliert.
Return,Right,d,spaceundEscapeüber das native Automationswerkzeug erzeugen jeweils null zusätzliche Tastaturereignisse und keine zugehörige Aktion. Dieser Befund liegt vor der Spielbelegung und belegt keinen Defekt physischer Tastaturen. Die Windows-Aktion Alt+F4 beendet den Player, ohne einen Spieleingang nachzuweisen.- Maus-Menüklicks erzeugen Druck-/Loslassereignisse und funktionieren durch Profil → Hangar → Karte → Briefing → Flug → Pause.
- Die Mauszieh-Aktion erzeugt einen gehaltenen Zustand in genau einem Dynamic-Update (9894); Update 9895 enthält bereits das Loslassen. Abstand der ursprünglichen Ereigniszeiten: 15,908 ms. Zeigerziel
(401,316)liegt im gültigen Kamerabereich. Das Schiff bewegt sich real von(0,-5)nach(-0,0836564,-4,9453959), also 0,1 Welteinheiten. Die geringe sichtbare Bewegung entspricht diesem kurzen Halten; die Koordinaten kommen brauchbar an. Keine dauerhafte Mausbewegung oder physische Handhabung daraus ableiten. - Im korrigierten Playerlog keine Laufzeitexception oder Shaderfehler. Die bekannte ComputeBuffer-Abschlusswarnung bleibt. Die Diagnose ist wegen zusätzlicher Dateiarbeit kein Performance-Benchmark. Eine vorbeiziehende Energiezelle wurde regulär aufgenommen; dies gilt nicht als manuell gespielte Mission.
Die ursprüngliche Eingabe-Unklarheit ist damit eingegrenzt. Weitere Wiederholungen derselben kurzen nativen Signale ersetzen keinen echten Geräte-/Kindertest. Die drei Originalansagen bleiben aktiv; neue Sprecheraufnahmen und menschliche Abnahme bleiben offen. Die v11-Nachweise sind unter QA-Menu-Continuation-2026-09-08.md erhalten.