Spiel-Overlay bleibt nach Rückkehr ins Hauptmenü stehen — ReturnToMenu blendet nur Kamera und DebugHud aus

[cubetribe]

Aus der Spielabnahme vom 2026-08-18 (Arbeitsstand e650864, macOS Editor).

Beobachtung

Nach dem Spiel zurück ins Hauptmenü („Hauptmenü" im Match-Rahmen) — und das Spiel-Overlay steht weiter über dem Menü:

• die Baukarte mit den Gebäuden, die man bauen kann
• die Optionen der zuletzt angeklickten Einheit, falls beim Verlassen noch eine ausgewählt war

Das Menü ist damit nicht das Menü, sondern das Menü mit dem Cockpit darüber.

Ursache

MainMenuController.ReturnToMenu pausiert das Match und blendet genau zwei Komponenten aus — nicht die HUD-Schicht:

// Assets/_Project/Scripts/Presentation/UI/MainMenuController.cs:730
public void ReturnToMenu()
{
    if (_bootstrap != null && _bootstrap.Runner != null && _bootstrap.Runner.IsRunning)
    {
        _bootstrap.Runner.PauseMatch();
    }
    SetGameplayLayerActive(false);
    ...

// Assets/_Project/Scripts/Presentation/UI/MainMenuController.cs:783
private void SetGameplayLayerActive(bool active)
{
    if (_cameraRig != null) _cameraRig.enabled = active;
    if (_debugHud != null) _debugHud.enabled = active;
}

Der Docstring von SetGameplayLayerActive begründet die kurze Liste so:

„The list is short on purpose: every other HUD component already returns early without a running match, and a catalogue of every HUD in the scene would rot with the next one added."

Diese Annahme trägt beim ersten Menüaufruf (es gab noch kein Match), aber nicht beim Rückweg: ReturnToMenu beendet das Match nicht, es pausiert es. Runner, Auswahl und Entitäten bleiben bestehen — „without a running match" trifft also gar nicht zu, und die HUDs zeichnen munter weiter. CommandCardHud prüft nirgends auf IsRunning oder „Menü sichtbar", sondern nur auf vorhandene Auswahl und vorhandenen Runner (CommandCardHud.cs:228 ff.). HudChrome und MinimapHud haben ebenfalls keinen solchen Riegel.

Der Kommentar ist also nicht falsch, sondern nur für den einen Fall geschrieben, für den er gedacht war — der Rückweg ist der zweite.

Wunsch nach Lösung

Ein Riegel statt eines Katalogs, damit die Sorge aus dem Docstring („eine Liste jeder HUD-Komponente verrottet") gar nicht erst eintritt: ein Zustand, den alle HUD-Komponenten lesen („Menü sichtbar" bzw. „kein aktives Match"), gesetzt an genau einer Stelle in ReturnToMenu / StartMatch. Eine gemeinsame Wurzel im UI-Baum, die ein- und ausgeblendet wird, tut es genauso — Hauptsache es ist eine Stelle und nicht n.

MainMenuController.IsMenuVisible existiert bereits und wird in ReturnToMenu gesetzt — es liest bisher nur niemand.

Abnahmekriterium

Spiel starten, Einheit anklicken, Gebäude-Karte offen lassen, zurück ins Hauptmenü: nichts vom Cockpit ist sichtbar. Danach „Neues Spiel": das HUD kommt vollständig zurück und die alte Auswahl ist nicht mehr aktiv.

Schreibhoheit

Scripts/Presentation/ — Netzstrang/Maintainer (13-15_Parallelbetrieb.md). Nicht Einheitenstrang.

[cubetribe]

Erledigt mit PR #113 (Paket 21.8), gemergt als 31fdeba.

Der Riegel ist die UI-Wurzel, kein Katalog. SetGameplayLayerActive schaltet jetzt das GameObject, auf das der Szenengenerator ohnehin alle In-Match-Komponenten legt, statt zweier namentlich genannter. Damit ist jede künftige HUD-Komponente automatisch abgedeckt, ohne je genannt zu werden — die Sorge im dortigen Docstring, ein Katalog verrotte mit der nächsten Komponente, ist strukturell beantwortet statt bestätigt.

Der überraschendste Teil des Befunds: der Ausstiegsklick erzeugte den Fehler selbst. Die modalen Panels standen nicht in IsPointerOverHud, also lief der Klick auf "Hauptmenü" zuerst durch die Auswahl-Logik und markierte eine Einheit hinter dem Panel — genau die Auswahl, die danach über dem Menü stand. Das erklärt, warum es sich so zuverlässig reproduzierte.

Mit erledigt: ein armierter Bau-Ghost überlebte den Menüwechsel und wanderte sogar in die nächste Runde.

Ein Read-only-Audit des Bestands liegt unter reports/v8.6.0/sprint-21/01-kimi-hud-state-audit.md.