Angepasste Garage, verbessertes Icon Asset system, range der türme vorschau beim ziehen

HANDBOOK_HANDOVER.md

@@ -1,6 +1,6 @@
 # Handbuch / Gameplay – Übergabe
 
-Stand: 15. Oktober 2026. Daten sind einsatzfähige Unity-Assets, aber vorläufig balanciert. Grafik und echtes Kampfverhalten werden nicht durch das Handbuch implementiert.
+Stand: 2. November 2026. Daten sind einsatzfähige Unity-Assets, aber vorläufig balanciert. Grafik und echtes Kampfverhalten werden nicht durch das Handbuch implementiert.
 
 ## Wo die Daten liegen
 
@@ -74,7 +74,7 @@ Grafiken: `Assets/Art/Handbook`. Original-PNGs sind unverändert übernommen; ac
 
 `category` ist Waffentechnik/Basisfarbe (physisch, Energie, Spezial), `menuGroup` die Buchkategorie. Spezialgebäude gehören vorläufig zu Anlagen, Fallen/Fähigkeiten/Reparaturtrupp zu Einsätzen. Die Gruppe bedeutet nicht automatisch eine Baufläche.
 
-`baseSprite`/`basePrefab` sind die gezeichnete Basis, `previewSprite` vorerst ebenfalls diese Basis. `gameplayPrefab` bleibt frei für den echten vollständigen Turm. Zum Aufbau zuerst eine Basis instanziieren, darüber ein separat drehbares Geschütz; keine gezeichnete Basis als fertigen Turm behandeln.
+Aktuelle Grafikfelder: Book Icon, Preview Layers und Gameplay Prefab. Die Basis-/Geschütz-Hierarchie liegt vollständig im Gameplay-Prefab. Die alten separaten Basisfelder wurden am 03.11.2026 nach Migration entfernt.
 
 Die einmaligen Aufbau- und Umbauwerkzeuge wurden nach Fertigstellung entfernt. Szene, Prefabs und Assets normal im Inspector bearbeiten; kein Generierungs- oder Einrichtungsschritt ist nötig.
 
@@ -96,4 +96,66 @@ Die verbliebenen Editor-Prüfungen werden per Unity-Batchmode ausgeführt. Sie s
 - `SupplyBasementValidation.Validate`: Keller ohne Backend, Anschlüsse, Priorität, Aufzug und LKW-Ausrichtung.
 - `SupplyBindingValidation.Validate`: Versorgungsschnittstelle mit isolierter Testkomponente.
 
-Beispiel: Unity mit `-batchmode -nographics -projectPath "<Projektpfad>" -executeMethod SupplyBindingValidation.Validate -logFile "<Logpfad>"` starten. Optional rendert `SupplyBasementValidation.Validate` mit Grafikunterstützung (ohne `-nographics`) und dem zusätzlichen Argument `-captureSupplyPreview` ein Bild nach `Temp/HandbookValidation/basement-preview.png`. Der Temp-Ordner wird nicht versioniert.
+Beispiel: Unity mit `-batchmode -nographics -projectPath "<Projektpfad>" -executeMethod SupplyBindingValidation.Validate -logFile "<Logpfad>"` starten. Optional rendert `SupplyBasementValidation.Validate` mit Grafikunterstützung (ohne `-nographics`) und dem zusätzlichen Argument `-captureSupplyPreview` ein Bild nach `Logs/HandbookValidation/basement-preview.png`. Der Logs-Ordner wird nicht versioniert.
+## Mauer-Baubereich im Inspector (02.11.2026)
+
+`PlacementTest > BuildArea` besitzt `WallBuildArea`; `HandbookRoot > TestPlacementController > Build Area` verweist darauf. Namenssuchen nach BackgroundTower/BackgroundOuterwall sind für die Grenzen entfernt.
+
+- `Boundary Source = Sprite Renderers`: `Inner Boundary Sprite` und `Outer Boundary Sprite` zuweisen. Es wird der kleinere halbe Welt-Bounds-Durchmesser der zugewiesenen SpriteRenderer verwendet, wie bisher. Kreisförmige Sprites mit derselben Mitte wie BuildArea verwenden.
+- `Boundary Source = Custom Radii`: `Inner Radius` und `Outer Radius` in Welt-Einheiten einstellen, unabhängig von Sprite- und BuildArea-Skalierung. 0 <= innen < außen. Die Mitte ist BuildArea.transform.position.
+- BuildArea auswählen und Gizmos in der Scene-Ansicht aktivieren: orange = innen, cyan = außen. `Show Selected Gizmos` schaltet diese Hilfslinien.
+- Die Testplatzierung liest Werte bei Spielstart. Einstellungen außerhalb von Play ändern und Play neu starten. Bestehende Szene: bisherige Sprites zugewiesen, Innenradius 3 / Außenradius 4 erhalten.
+- Ein echtes IHandbookGameplay-Backend muss dieselbe WallBuildArea-Konfiguration für seine eigene Bauprüfung verwenden. UI und Prototyp übernehmen sie bereits. Der gesamte Turmfuß muss weiterhin in den Ring passen; Angriffsreichweite und Abstandskreis sind davon unabhängig.
+
+`WallBuildAreaValidation.Validate` prüft die Zuweisung unabhängig vom Objektnamen, eigene Radien, ungültige Konfigurationen und das vollständige Einpassen der Basis. Das einmalige Einrichtungsscript wurde nach der Umstellung entfernt.
+
+## Ergänzungen vom 02.11.2026
+
+### Keller außerhalb des Spielfelds
+
+Die bestehende Raumoberfläche liegt jetzt unter `SupplyBasementRoom / RoomCanvas / SupplyBasement`, außerhalb der Turmebene bei X=50. Das ist ein World-Space-Canvas mit austauschbaren Grafiken und unveränderter Raum-Anordnung. `BasementCamera` zeigt diesen Raum beim Aufzugwechsel. Die normale Kamera und alle Spielobjekte bleiben aktiv. Nur Canvas-Darstellung, UI-Raycaster und Kellerkamera werden umgeschaltet. `Canvas_SupplyBasement` enthält weiterhin Aufzugschild und Übergangstüren als Bildschirm-UI.
+
+Die bisherige LKW-Fahrvorschau läuft auch bei geschlossenem Keller weiter und verwendet Spielzeit. Ein echtes ISupplyGameplay-Backend bleibt unverändert für die eigentliche Versorgung zuständig. Es muss dauerhaft aktiv sein und darf seine Berechnungen nicht von IsInBasement abhängig machen.
+
+### Angriffsvorschau und Zielgeometrie
+
+Buildables besitzen unter combat zusätzlich minimumRange, coverage (Automatic / Circle / Sector) und forwardAngleOffset. range, unlimitedRange und coneAngle werden wiederverwendet. Automatic zeigt bei fest gerichteten Kegelwaffen einen Sektor, bei frei drehbaren Waffen einen Kreis. Ein kegelförmiger Angriff beschränkt bei frei drehbaren Geschützen nicht automatisch den erreichbaren Rundumbereich.
+
+`AttackRangeGeometry.CanReach(combat, origin, target, baseAngleDegrees)` ist ein gemeinsamer optionaler Helfer für die Zielprüfung. Ein echtes Schießsystem muss diese Grenzen beachten; die Vorschau allein verhindert noch keine Schüsse. Winkel in XY: 0=rechts, 90=oben; forwardAngleOffset standardmäßig 90 relativ zur Platzierungsrotation.
+
+`PlacementTest / PlacementPreview / AttackRangePreview` enthält die vier dauerhaft angelegten Linien. Dort sind Farbe und Sichtbarkeit einstellbar. Blau = Angriff, der bisherige grün/rot/graue Kreis = Platzierungsabstand. Der ausgesparte Innenbereich wird über den inneren blauen Rand markiert. Unbegrenzte Reichweite bekommt keinen irreführenden endlichen Außenkreis; der General nennt sie beim Platzieren. Bei flächengezielten Einmalaktionen zeigt der Kreis stattdessen die Wirkungsfläche.
+
+Howitzer: vorläufig minimumRange=1.5. Flammenwerfer, Pusher, Knocker und Laser Shotgun dürfen beim Bauen mit R gedreht werden. Bestehende Schadens-, Kosten- und Versorgungswerte bleiben gleich. Die Mindestreichweite bleibt bei Reichweiten-Upgrades zunächst unverändert.
+
+### Statistikseite
+
+`OpenBook / PageArea / Page_Statistics / StatisticsContent` ist dauerhaft angelegt, ohne Scrollen oder Seitenwechsel. Links stehen Bauplätze/Kaufressourcen und die drei Versorgungspools mit Lager, Verteiler, gemessenem Verbrauch und geschätzter Verteiler-Restzeit ohne weitere Lieferungen. Rechts stehen bis zu acht versorgte Türme, nach Typ und Instanz sortiert, mit Magazin und gemessenem Verbrauch. Die Einheit lässt sich zwischen pro Sekunde und pro Minute umstellen.
+
+Die Statistik liest vorhandene ISupplyGameplay-Snapshots. `consumedPerSecond` muss tatsächliche Entnahmen über ein Messfenster (beispielsweise die letzten zehn Sekunden) beschreiben, keine theoretische Feuerrate. null = unbekannt (Strich), 0 = kein Verbrauch. Die Schätzung buffer / consumedPerSecond nimmt ausdrücklich keinen weiteren Nachschub an. Sie ist keine Garantie für den wirklichen Leerzeitpunkt. Ohne Versorgungssystem zeigt die Seite vorhandene Turmtypen und Bauressourcen, aber keine erfundenen Verbrauchs- oder Magazinwerte.
+
+### Schleusenübersicht im Keller
+
+Die kleine Ebenenkarte oben am Raum zeigt vier Richtungen, HP, offene Schleusen, Angriffe und kritische Zustände. Datenquelle: optionale MonoBehaviour-Komponente mit ICombatOverview, zugewiesen an `BattleOverview > Basement Battle Overview > Combat Backend`. Geschlossen/offen und angegriffen sind getrennte Zustände. hitSequence erhöht sich bei Treffern und löst kurzes Blinken aus; bei kritischen HP bleibt die Warnung bestehen. Ohne Daten stehen Striche. Die UI implementiert keine Schleusen- oder Schadenslogik.
+
+### Noch tatsächlich offen
+
+Echte Waffen/Verbrauch, LKW-Versorgung und Schleusenzustände müssen vom Gameplay-System geliefert werden. Die dafür erforderlichen Schnittstellen und Anzeigen sind vorbereitet. Endgültige Grafik, Sound, Balancing und spätere Statistik-Erweiterungen (z.B. Abschüsse/Schaden) bleiben Teamaufgaben.
+
+### Zusätzliche Prüfung
+
+`UINotesValidation.Validate` prüft den aktiven Raum, Hintergrund-Vorschau, Kreise/Sektoren/Mindestreichweite, Statistik und Einheiten sowie Schleusenwarnungen. Mit Grafikunterstützung schreibt sie Ansichten nach Logs/HandbookValidation. Die einmalige Szenenumstellung wurde nach Verwendung entfernt.
+
+
+## Grafik- und Vorschau-Struktur (03.11.2026)
+
+Die bisherigen Felder baseSprite, basePrefab und previewSprite sind nach Migration entfernt. Im Inspector: Book Icon (intern weiterhin icon), Preview Layers und Gameplay Prefab. Die Ebenenliste hat standardmäßig zwei Plätze, oben = vorne, unten = hinten. Alle Sprite-Pivots liegen auf demselben Anker; offset, scale und rotation sind optionale Korrekturen. Gleiche Pixels-per-Unit verwenden, wenn die Zeichnungen denselben Pixelmaßstab haben. previewScale ist eine gemeinsame Skalierung für alle Ebenen; 0 passt sie anhand der untersten belegten Ebene an die Basisgröße an. rotateWithAim lässt sich pro Ebene abschalten, etwa für die Basis. Leere Ebenen werden ausgelassen. Änderungen beim nächsten Ziehen prüfen.
+
+Vorhandene Vorschau-/Basisgrafiken wurden in die unterste Ebene übertragen. Wo Gameplay Prefab zuvor leer war, wurden vorhandene Basis-Prefabs als vorläufiges Gameplay-Prefab übernommen; echte Geschützmodelle und Spiellogik folgen durch den Gameplay-Programmierer. Bereits zugewiesene Gameplay-Prefabs bleiben erhalten. Der Prototyp instanziiert das zugewiesene Prefab ohne nachträgliche Größenänderung; bei weiterhin leerem Feld bleibt der bisherige Test-Platzhalter. Eigene IHandbookGameplay-Backends müssen ebenfalls gameplayPrefab instanziieren und die Instanz-ID melden.
+
+Die Ziehvorschau richtet sich während des gesamten Ziehens weich zur Arenamitte aus. alignPreviewToCenter am TestPlacementController kann dies abschalten. R versetzt bei erlaubter Rotation die Blickrichtung zusätzlich. Der Bauauftrag verwendet die tatsächlich sichtbare Rotation. Die fertige Geschütz-/Basis-Hierarchie muss das echte Gameplay-Prefab selbst behandeln.
+
+Angriffsvorschau: dünne blaue Grenzen und sehr schwache blaue Fläche; Mindestreichweite ausgespart/gestrichelt. RangeArenaClip begrenzt die Darstellung auf den Innenradius von WallBuildArea, da Gegner nur dort existieren. Bei abweichender tatsächlicher Arenageometrie die Quelle entsprechend anpassen. Die wirklichen Kampfwerte bleiben unverändert. Der grün/rot/graue Abstandskreis ist davon unabhängig und unverändert.
+
+Der Keller besitzt zusätzlich einen Hintergrundaufzug als anklickbaren Rückweg, einen Versorgungsmonitor sowie Wandnischen, Schattenstreifen und einen Vordergrundabschluss. Ein großer Hintergrund deckt auch freie Bildschirmbereiche ab; Bedienelemente bleiben im sicheren Referenzrahmen. Alle Teile sind austauschbare, graue Platzhalter. Die separate Ebenen-/Schleusenanzeige bleibt außerhalb des Monitors. Aktuelle Werte stammen weiterhin ausschließlich aus den Gameplay-Schnittstellen.
+
+Decke, Boden, Wandhintergrund und äußere Seitenbegrenzungen passen ihre Breite an die Kellerkamera an. Die Bedienelemente bleiben im sicheren Referenzbereich; auch auf breiten Bildschirmen entstehen keine freien Seitenflächen außerhalb des Raums.