{
"llm" : {
"feedback" : "# Exercise: parking\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n\n\n# Exercise: labyrinth\n\n### Correctness\n- In `LabyrinthApp` erstellst du `NaviAlgorithm navi = new BacktrackingAlgorithm(l)` mit einem `Labyrinth`, das nur aus `MAPS[1]` gebaut wird; in der Level-Schleife wird dann aber für jedes Level ein neues `LabyrinthGame` (mit eigenem Labyrinth) erstellt. Dein Algorithmus arbeitet damit potenziell mit einem *anderen* Labyrinth als dem, in dem die Figur tatsächlich läuft (weil du in `BacktrackingAlgorithm` `labyrinth.cols()/rows()` und `labyrinth.goalAt(...)` verwendest).\n- `TryStraightFirst` erfüllt die Aufgabenbeschreibung nicht vollständig: Wenn vorne kein Pfad ist, soll links oder rechts versucht werden, und wenn gar nichts geht, soll die Figur „rechtsum kehrt“ machen. Bei dir fehlt der Fall „nichts geht“ (Umdrehen), und außerdem drehst du bei links/rechts nur die Richtung, machst aber in diesem Schleifendurchlauf keinen Schritt.\n- In `BacktrackingAlgorithm.checkPath` kann der Fall `if(!figure.pathAhead() && !figure.pathToTheLeft() && !figure.pathToTheRight())` zu einer Endlosrekursion führen: Du drehst nur um und rufst `checkPath` erneut auf, ohne die Position zu ändern oder den aktuellen Knoten als „fertig abgearbeitet“ zu behandeln (du bist ja weiterhin auf demselben Feld, das bereits als besucht markiert ist).\n- In `BacktrackingAlgorithm.checkPath` nutzt du zum Zieltest `labyrinth.goalAt(row, col)` statt `figure.isGoalReached()`. Damit hängt die Korrektheit wieder daran, dass `labyrinth` wirklich zum aktuellen Spiel passt (was bei dir in `LabyrinthApp` nicht der Fall ist).\n- Dein Backtracking-„Zurückgehen“ (`turnLeft(); turnLeft(); moveForward(); ...`) passiert nach jedem rekursiven Abstieg pauschal. Wenn du aber aufgrund von `besucht[row][col]` sofort zurückkehrst, oder wenn du in einen bereits besuchten Knoten läufst, stimmt die Annahme „ich bin genau einen Schritt vom Parent entfernt“ nicht immer zuverlässig mit deiner Kontrolllogik überein.\n\n### Suggestion\n- Schau dir an, welche Informationen du in `navigate(Figure figure)` wirklich garantiert hast: Die Aufgabe gibt dir die Welt über das `Figure`-Interface. Überlege, wie du Backtracking implementierst, ohne im Algorithmus ein separates `Labyrinth`-Objekt zu brauchen, das evtl. nicht zum aktuellen Level gehört.\n- Für `TryStraightFirst`: Überlege eine klare Prioritäten-Reihenfolge „vorwärts, sonst links, sonst rechts, sonst umdrehen“ und stelle sicher, dass in *jedem* Schleifendurchlauf genau eine sinnvolle Aktion abgeschlossen wird (z.B. Drehen + Schritt, oder Umdrehen + Schritt), damit du nicht in einem Zustand hängen bleibst, wo du nur drehst.\n- Für den Sackgassen-Fall im Backtracking: Ein Umdrehen allein bringt dich nicht raus, wenn du danach nicht auch wirklich einen Schritt zurück machst. Denk daran, was „backtracking“ konkret bedeutet: Entscheidung treffen → vorgehen → wenn es nicht klappt, wieder **zurück auf die vorherige Zelle** und nächste Option probieren.\n- Für das `besucht`-Raster: Wenn du „besucht“ verwendest, überlege, *wann* ein Feld als besucht markiert werden soll (beim Betreten) und was das für das Zurücklaufen bedeutet. Prüfe insbesondere, dass deine Abbruchbedingungen nicht dazu führen, dass du zwar zurückkehren willst, aber die Figur gar nicht mehr passend zurückbewegst.\n- Wenn du Rekursion verwendest: Achte darauf, dass jeder rekursive Pfad entweder (a) das Ziel findet und sauber hoch-returnt oder (b) garantiert die Figur wieder in den Zustand/auf die Position bringt, die sie beim Aufruf hatte (gleiche Zelle, gleiche Richtung), bevor du die nächste Alternative probierst.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` legst du `int col = labyrinth.cols(); int row = labyrinth.rows();` an, benutzt die Variablen aber nur für das Array; die Namen sind verwirrend, weil `col`/`row` später auch als aktuelle Position verwendet werden. Bessere, eindeutigere Namen würden die Lesbarkeit stark erhöhen.\n- In `BacktrackingAlgorithm` ist viel auskommentierter Code im `navigate`-Block; räum den weg, sobald du dich für eine Strategie entschieden hast.\n- Wiederholter Code fürs „zurückgehen“ (4x `turnLeft`/`moveForward` Sequenzen) macht es schwer, Fehler zu sehen. Eine kleine Hilfsmethode (z.B. „drehe um“, „gehe einen Schritt zurück“) würde das deutlich verständlicher machen.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMap` verwendest du andere Resource-Pfade (`swissmap_img/...`) als in der Aufgabe/Lib-Beispiel erwartet (`swissmap/...`). Wenn diese Dateien im Projekt nicht exakt so existieren, wird der Hintergrund (und auch Lake/Mountain Icons) nicht angezeigt.\n- `ModeButton`: Deine `getInteractiveArea` ist deutlich kleiner (15×15) als das, was du zeichnest (65×25). Damit ist der Button nur in einem Teilbereich hover-/klickbar und nicht “als Knopf auf der Karte” wirklich korrekt bedienbar.\n- `City`: Dein `getInteractiveArea` ist ein 5×5-Rechteck ab dem Punkt `(x,y)`. Da du den Kreis “um den Punkt” zeichnest, liegt ein Teil der sichtbaren Stadt-Markierung ausserhalb des interaktiven Bereichs; Hover wird dadurch oft nicht ausgelöst, obwohl man visuell “auf dem Punkt” ist.\n- `Lake`/`Mountain`: Du skalierst die Icon-Grösse mit `WIDTH * scale(gui) / BG_PIXEL_WIDTH` (also anhand der gesamten Kartenbreite). Das führt sehr wahrscheinlich dazu, dass die Icons riesig werden (weil `WIDTH` mehrere hunderttausend ist). Die Objekte werden dadurch nicht “wie oben dargestellt” angezeigt, sondern überdecken die Karte.\n\n### Suggestion\n- Prüfe die Ordnerstruktur unter `resources`: stimmen die Pfade, die du an `drawImage(...)` übergibst, exakt mit den tatsächlich vorhandenen Dateien überein?\n- Leite die interaktive Fläche des `ModeButton` aus den gleichen Breiten-/Höhenwerten ab, die du auch beim Zeichnen des Rechtecks verwendest, damit man wirklich auf den ganzen Button zeigen/klicken kann.\n- Überlege bei `City` (und generell allen Markern), ob dein `Shape` den sichtbaren Marker vollständig abdecken sollte (z.B. zentriert um die Koordinate statt nur “rechts unten” ab `(x,y)` zu starten).\n- Für Lake/Mountain-Icons: Verwende für die Bildgrösse eine “Icon-Grösse” in Pixeln (oder skaliert mit `SwissMap.scale(gui)`), aber nicht die komplette Kartenbreite (`WIDTH`). Rechne dir mal grob aus, was `WIDTH * scale / BG_PIXEL_WIDTH` numerisch ergibt, dann siehst du, warum das aus dem Ruder läuft.\n\n### Code Style\n- Du hast mehrere unbenutzte Imports (z.B. `ImageIO`, `BufferedImage`, `IOException`, `Objects`, `Component`, `Arrays`) – die entfernen, damit der Code übersichtlich bleibt.\n- In `ModeButton` sind `hovered` und `clicked` aktuell ohne Effekt auf das Verhalten/Rendering; entweder verwenden (z.B. für Hover-Optik) oder weglassen.\n- `System.out.println(...)` in `SwissMap.draw` und `City.onMouseEnter` spammt die Konsole (und `draw` wird sehr häufig aufgerufen). Debug-Ausgaben besser entfernen oder gezielt/selten auslösen.\n- `toString()` mit Zeilenumbruch (`\"\\n\"`) ist für Debug ok, aber fürs Zeichnen kann das je nach GUI-Textfunktion unschön sein (nicht jede `drawString`-Implementierung unterstützt Multiline wie erwartet).\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface liefert keine Werte zurück, die der `Visualizer` für Plotting/MinMax/Tooltip braucht (x- und y-Wert als Zahlen, Gruppenname, Titel/Details als String). Mit `void title(...)`/`void information(...)` kann der Visualizer nichts abfragen.\n- In `Visualizer` wurden die `DUMMY_DOUBLE`/`DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt; damit kann keine korrekte Visualisierung entstehen.\n- `Movie`, `Country` und `Processor` implementieren `DataPoint` nicht, dadurch können die geladenen Datensätze nicht als `DataPoint[]` an den `Visualizer` übergeben werden.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt einen der Loader (`loadMovies`, `loadCountries`, `loadProcessors`) als Datensatz zu übergeben.\n- Die geforderten Javadoc-Kommentare zur Dokumentation des erwarteten Verhaltens der `DataPoint`-Methoden fehlen.\n\n### Suggestion\n- Überlege dir das Interface aus Sicht des `Visualizer`: Wo braucht er Zahlen (für Achsen/MinMax/Distanz zur Maus) und wo Strings (für Legende und Hover-Text)? Definiere genau dafür Getter-Methoden, die Werte **zurückgeben**.\n- Geh im `Visualizer` jede Stelle mit `DUMMY_DOUBLE`/`DUMMY_STRING` durch und frage dich: „Welcher Wert gehört hier zum aktuellen `point` bzw. zum `closest`?“ Ersetze dann genau dort durch den passenden Methodenaufruf.\n- Damit `loadMovies()` etc. direkt in ein `DataPoint[]` passen, müssen die Datensatz-Klassen das Interface implementieren. Fang mit `Movie` an (x = Budget, y = Rating) und arbeite dich dann zu `Country` und `Processor` vor.\n- Wenn du in `VisualizerApp` auf einen Datensatz umstellst: Achte darauf, dass der Rückgabetyp des Loaders (z.B. `Movie[]`) auch wirklich als `DataPoint[]` verwendbar ist (Stichwort: Interface implementieren).\n- Schreibe Javadoc so, dass klar ist, was z.B. x/y bedeuten, was bei „keine Gruppe“ passieren soll (null oder leerer String), und wie der Detailtext formatiert sein soll (z.B. Zeilenumbrüche für mehrere Zeilen im Tooltip).\n\n### Code Style\n- Die Methodennamen im Interface (`title`, `information`, `secondInfo`) wirken wie Setter und sind semantisch unklar; benenne sie so, dass direkt ersichtlich ist, **welchen** Wert man abfragen kann (und nutze passende Rückgabetypen).\n- `Map<String, Integer>` im Interface koppelt die Darstellung unnötig an eine konkrete Datenstruktur und schränkt spätere Formatierung stark ein (z.B. Einheiten, Dezimalzahlen, mehrzeiliger Text).\n",
"status" : "SUCCESS"
}
}