Blockline/docs/MAP-SELECTION.md

Map-Auswahl und Bot-Navigation

Spielen

In dieser Projektkopie Start-Local.cmd öffnen, dann PLAY → MAP AUSWÄHLEN → Dust 2 · CS 1.6 → START GAME. Quarry bleibt wählbar. MULTIPLAYER → HOST GAME bietet dieselbe Auswahl samt Match-Einstellungen; im Formular bei Bedarf nach unten scrollen. LAN-Browser zeigt den Mapnamen. Direct Connect und Join übernehmen die Karte des Hosts.

Die Kopie hat kein .git. Start-Game.exe kann daher über seinen vorhandenen Updater eine andere Version auswählen. Start-Local.cmd bzw. Start-Game.exe --local startet zuverlässig diese Dateien. Der Launcher wurde nicht verändert.

CLI mit Godot: -- --host --map=dust2 oder --map=quarry. Dedicated: -- --dedicated --map=dust2; alternativ "map": "dust2" in server.json. Beide Clients müssen denselben Projektstand verwenden.

Dateien und Zuständigkeiten

• scripts/map_catalog.gd: stabile Map-IDs und Anzeigenamen.
• scripts/dust_geometry.gd: GLB-Import, Materialzuordnung und Weltkollisionen. Kein Spieler-Mesh-Collider; Spieler bleiben Capsules.
• scripts/dust_arena.gd: Dust-Spawns, Patrouillen, Objectives, Beleuchtung und Map-Abmessungen (ca. 112 × 133 m).
• scripts/arena_navigation.gd: eigene NavigationServer-Karte je Arena, gebackene NavigationMesh-Ressource, 3D-Pfade; Ressourcen beim Wechsel freigeben.
• scripts/arena.gd: unveränderte Quarry-Geometrie, ergänzt um Map-Metadaten und 3D-Navigation. Der alte AStarGrid bleibt für bestehende Aufrufer verfügbar.
• scripts/bot_routes.gd: ersetzt feste Gebäudeknoten durch echte begehbare Flächen.
• scripts/bot_steering.gd: höhentolerante Wegpunkte, gegenseitiges Ausweichen mit Kollisionsprüfung, Stillstand erkennen.
• scripts/bots.gd: Pfad neu berechnen, erreichbare Patrouillenziele, horizontal normierte Bewegung auch an Steigungen.
• scripts/game.gd, ui.gd, front_end.gd, discovery.gd, server_settings.gd: Auswahl, Host/Client-Übernahme und Server-Konfiguration.
• scripts/hud.gd, round_objectives.gd: passende Kartengrenzen, Minimap und Zielpositionen.
• scripts/snapshot_fragments.gd: große komprimierte Zustandsmeldungen in 1000-Byte-Teilen; nur vollständige aktuelle Meldungen anwenden, veraltete/verlorene Teile verwerfen, Speicher begrenzen.

Assets

assets/scan/dust2/ enthält das GLB, elf externe StandardMaterial3D-Ressourcen und die von Godot extrahierten Texturen, Lizenz/Herkunft, Minimap und navigation.res. Die externe Materialzuordnung bewahrt alle elf Original-UV-Zuordnungen. Keine erfundenen Normal-Maps: Das Paket liefert Farbtexturen mit bereits eingebauter Beleuchtung. Der klassische CS-1.6-Look und die Auflösung des gelieferten Materials bleiben erhalten.

Das zusätzliche ZIP enthält dieselben elf Texturen (vertikal gespiegelt), eine weitere Dust-Quelldatei sowie ein anderes Zone9-Modell. Diese redundanten bzw. fremden Map-Dateien werden nicht zusätzlich ins Spiel kopiert. Sie sind weiterhin in Downloads vorhanden.

Die Quarry-Navigation liegt in assets/navigation/quarry.res. Navigationsnetze werden vorab erstellt, nicht bei jedem Spielstart gebacken. Änderungen an kollidierender Map-Geometrie erfordern erneutes Backen.

Navigation neu erzeugen

Im Projektordner mit Godot 4.5:

$godot = '.\tools\godot\Godot_v4.5-stable_win64_console.exe'
& $godot --headless --editor --path . --import
& $godot --headless --path . --script tests/dust_prepare.gd
& $godot --headless --path . --script tests/quarry_navigation_bake.gd

dust_prepare.gd erzeugt Materialien und Navigation. Bei Layoutänderungen auch Spawns/Zielpositionen in dust_arena.gd und die Minimap aktualisieren. Die Rasterauflösung des NavigationServer für Kantenverbindungen ist bewusst feiner als die Bake-Voxel: dicht benachbarte Kanten dürfen nicht fälschlich zusammenfallen.

Prüfungen

• tests/map_selection.gd: beide Maps, freie Capsules an allen Spawns, Verbindungen, Menüoptionen und acht Spieler.
• tests/bot_navigation.gd: reale Capsule-Bewegung die Quarry-Außentreppe hinauf, Dust-Höhenroute sowie zwei entgegenkommende Bots im selben Weg.
• tests/map_network.gd: zwei echte ENet-Prozesse, Host auf Dust, Client zunächst auf Quarry, anschließend gleiche Map und acht synchronisierte Akteure. Für Windows den eigentlichen Godot_v4.5-stable_win64.exe starten, nicht den Console-Wrapper; Firewall-Freigaben sind programmspezifisch. Testport UDP 27992.
• tests/snapshot_fragments.gd: Reihenfolge, Duplikate, fehlende Meldungen und Größenbegrenzung.
• tests/dust_visual.gd, tests/map_menu_visual.gd: echte Vulkan-Renders, Übersicht/Spielerhöhe/Menüs/Spielansicht; Bilder in logs/.
• tests/audit_gdscript.py: kompletter Parser-/Typdeklarations-Audit.
• Bestehende Grafik-, Waffen-, Auto-Reload- und Architekturtests bleiben erhalten.

Manuell: beide Maps hosten, Treppen und Tunnel laufen, mehrere Bots beobachten, nach Match-Ende verlassen und die andere Map starten. Auf einem zweiten LAN-PC beitreten und Map/Minimap/Spielerpositionen vergleichen.

Grenzen

Navigation und Begegnungstests decken ausgewählte Routen ab, nicht jede denkbare Menschenmenge an jedem Engpass. Sehr enge Stellen können weiterhin kurzzeitiges Ausweichen/Neuplanen auslösen. Der Zweiprozess-Netzwerktest ersetzt keinen Test auf zwei physischen LAN-Rechnern. Keine pauschale FPS-Garantie; Grafik hängt auch von vorhandenen Spieler-Assets und Einstellungen ab.

Ergebnis dieser Integration

Map-/Spawn-Prüfungen bestanden; beide Treppen-Laufwege und das gegenseitige Passieren bestanden. LAN-Test mit zwei Spielprozessen und acht Akteuren: Host und Client erfolgreich auf Dust 2, keine Paketgrößenwarnung mehr. Echte Vulkan-Renders geprüft. Bestehende Grafiktests 81/81, Korrekturen 24/24, Auto-Reload 15/15, Shooting-Polish 19/19 und Node-Architektur bestanden. Der isolierte Polish-Test übernimmt nun auch seine drei erzeugten Modul-Nodes in den Szenenbaum, sodass sie sauber freigegeben werden.

GDScript-Audit: 145/145 bestanden. Lokaler Launcher mit --local --verify geprüft; logs/selected-project.txt bestätigt den neuen Workspace.