{
"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 `TryStraightFirst` fehlt der Fall „wenn weder geradeaus noch links noch rechts möglich ist, rechtsum kehrt machen“ (also 180° drehen), wie in der Aufgabenbeschreibung verlangt.\n- In `BacktrackingAlgorithm` verwendest du `labyrinth.goalAt(row, col)` und `labyrinth.rows()/cols()` über ein separat erzeugtes `Labyrinth`-Objekt aus `LabyrinthApp`; das ist nicht das Labyrinth/Level, in dem die `Figure` gerade unterwegs ist (das wird in `LabyrinthGame` neu erstellt). Dadurch prüfst/initialisierst du gegen die falsche Map.\n- In `LabyrinthApp` erzeugst du `BacktrackingAlgorithm` mit `new Labyrinth(MAPS[1])` (fix Level 2) und verwendest denselben `navi` dann für alle Levels; das passt nicht zum Spielablauf, weil jedes Level ein anderes Labyrinth hat.\n- `BacktrackingAlgorithm.navigate` macht keinen Loop, der garantiert bis zum Ziel läuft; `checkPath` kann zurückkehren, obwohl das Ziel nicht erreicht ist, und dann endet `navigate` einfach.\n- In `checkPath`: Beim „Sackgasse“-Fall drehst du zwar 180°, rufst aber dann rekursiv `checkPath` auf, ohne einen Schritt zurück zu gehen; so ändert sich die Position nicht und du kannst in endlose Rekursion laufen.\n- In `checkPath`: Nach dem Erkunden von links/rechts drehst du dich zwar zurück und läufst zurück, aber du stellst nicht in allen Fällen sicher, dass die Orientierung am Ende wieder gleich ist wie vor dem Abzweig (durch die Mischung aus `turnRight`/`turnLeft` kann sich die Endausrichtung je nach Zweig unterscheiden).\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir eine vollständige `if/else if/else`-Kette, bei der der letzte `else` genau den „Kehrtwende“-Fall abdeckt, wenn wirklich keine Richtung möglich ist.\n- Für `BacktrackingAlgorithm`: Versuche, den Algorithmus so zu bauen, dass er ausschließlich über das `Figure`-Interface arbeitet (Position/Wege/Goal-Abfrage), statt zusätzlich ein eigenes `Labyrinth` zu speichern. Dann ist er automatisch für jedes Level korrekt.\n- Für die Level-Schleife: Denke darüber nach, wann und wo das jeweilige Level-Labyrinth überhaupt existiert (Hinweis: es steckt in `LabyrinthGame`). Dein `NaviAlgorithm` sollte level-unabhängig sein und nicht an eine bestimmte Map im Konstruktor gebunden werden.\n- Für das Stop-Kriterium: Stelle sicher, dass deine Rekursion/Iteration erst dann beendet, wenn `figure.isGoalReached()` wirklich `true` ist, nicht nur wenn ein Feld „besucht“ ist oder keine Optionen mehr geprüft werden.\n- Für den Sackgassen-Backtrack: Überlege dir die minimale Sequenz „Umdrehen + genau einen Schritt zurück“, bevor du weitere Alternativen am vorherigen Knoten ausprobierst.\n- Für die Orientierung: Es hilft, pro „Exploration“ (ahead/left/right) ein klares Muster zu haben: (1) drehen, (2) vorwärts, (3) rekursiv, (4) umdrehen, (5) zurücklaufen, (6) wieder in Ausgangsrichtung drehen. Prüfe das konsequent für alle drei Richtungen.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind `int col = labyrinth.cols(); int row = labyrinth.rows();` missverständlich benannt (das sind Größen, nicht Koordinaten); bessere Namen reduzieren Verwechslungen.\n- Auskommentierter Codeblöcke in `navigate` machen es schwer lesbar; besser entfernen oder in eine separate Test-Version auslagern.\n- `BacktrackingAlgorithm` hat ein Feld `labyrinth`, aber nutzt davon nur `rows/cols/goalAt`; wenn du (wie oben angedeutet) nur mit `Figure` arbeitest, kann das Feld ganz wegfallen und die Klasse wird klarer.\n- Wiederholter Code zum „zurücklaufen und Orientierung zurücksetzen“ (mehrfach `turnLeft(); turnLeft(); moveForward(); ...`) könnte in eine kleine Hilfsmethode ausgelagert werden, um Fehler durch Copy/Paste zu vermeiden.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `City`, `Lake` und `Mountain` veränderst du das geforderte Beschreibungsformat durch einen Zeilenumbruch in `toString()`; erwartet ist die Beschreibung in einer Zeile (wie in der Aufgabenbasis vorgegeben).\n- Die von dir verwendeten Bildpfade (`swissmap_img/...`) weichen von den in der Aufgabe/Library erwarteten Ressourcenpfaden ab (z. B. `swissmap/...`); wenn diese Ressourcen im Projekt nicht genau so vorhanden sind, werden Seen/Berge/Karte nicht korrekt angezeigt.\n- `ModeButton` zeichnet ein Rechteck mit `65x25`, aber `getInteractiveArea` gibt nur ein `15x15`-Rechteck zurück; damit ist nur ein kleiner Teil des Buttons tatsächlich hover-/klickbar.\n\n### Suggestion\n- Schau dir die vorgegebenen `toString()`-Ausgaben aus dem Startcode nochmal an und übernimm deren Format 1:1 (insbesondere ohne Zeilenumbruch), damit die angezeigte Beschreibung genau dem erwarteten Text entspricht.\n- Vergleiche deine Bildpfade mit den Pfaden, die in `SwissMap` (im Startcode) bzw. im `resources`-Ordner verwendet werden, und stelle sicher, dass deine Strings exakt zu den tatsächlichen Ressourcen im Projekt passen.\n- Leite die Größe/Position deines interaktiven Bereichs beim `ModeButton` direkt aus dem, was du in `draw()` zeichnest, ab, sodass der komplette sichtbare Button interaktiv ist.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(...)` in `SwissMap.draw()` und `City.onMouseEnter()`, da `draw()` sehr häufig aufgerufen wird und die Konsole sonst “zugespammt” wird.\n- In `ModeButton` sind die Felder `hovered` und `clicked` aktuell wirkungslos (sie werden gesetzt, aber nirgends fürs Zeichnen/Verhalten verwendet) – entweder nutzen oder entfernen.\n- In `Mountain` (und auch `SwissMap`) importierst du Klassen wie `ImageIO`, `BufferedImage`, `IOException`, `Objects`, nutzt sie aber nicht; diese Imports entfernen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt nicht die Informationen bereit, die der `Visualizer` braucht: es fehlen insbesondere Werte für x- und y-Koordinate (als `double`) sowie Strings für Gruppierung/Legende und Tooltip/Highlight.\n- Die Methoden im `DataPoint`-Interface sind als `void` definiert und wirken wie Setter; der `Visualizer` braucht aber (gemäss Aufgabenstellung und Dummy-Stellen) Getter-artige Methoden, um Werte *abzufragen*.\n- In `Visualizer` sind die Dummy-Werte (`DUMMY_DOUBLE`, `DUMMY_STRING`) nirgends durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt worden; dadurch kann keine korrekte Visualisierung entstehen.\n- `Movie` implementiert das `DataPoint`-Interface nicht (analog auch `Country` und `Processor` nicht), damit ist die Schnittstelle nicht integriert.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt den geladenen Datensätzen; damit wird nichts visualisiert.\n- Die geforderten Javadoc-Kommentare für die Methoden im `DataPoint`-Interface fehlen.\n\n### Suggestion\n- Schau dir im `Visualizer` jede Stelle mit `DUMMY_DOUBLE`/`DUMMY_STRING` an und leite daraus ab, *welche* Informationen ein Punkt liefern muss (z.B. genau zwei numerische Achsenwerte und mehrere Textinfos); entwirf daraus passende Methoden im Interface.\n- Überlege bei jeder Interface-Methode: Muss der `Visualizer` einen Wert *setzen* oder *lesen*? Wenn er ihn an mehreren Stellen braucht (Min/Max finden, zeichnen, Hover), ist es sehr wahrscheinlich eine abfragende Methode mit Rückgabewert.\n- Für die Gruppierung: In `collectGroups()` wird ein String in ein `Set` gelegt und später in `colorOfGroup()` wieder gesucht – daraus kannst du ableiten, welche Art String jeder Punkt liefern sollte (und wann dieser auch `null` sein darf).\n- Für die Highlight-Ansicht: In `drawHighlighted()` wird ein Titel sowie ein mehrzeiliger Text (`split(\"\\n\")`) erwartet – plane im Interface eine Methode, die genau so einen Tooltip/Detailtext liefert.\n- Sobald das Interface steht, implementiere es in `Movie` (Budget auf x, Rating auf y) und passe `VisualizerApp` so an, dass wirklich die geladenen Movies als `DataPoint[]` an den `Visualizer` gehen; danach analog für `Country`/`Processor` (inkl. der Besonderheiten beim Prozessor: kombiniertes Datum, effektive Geschwindigkeit, logarithmische y-Achse).\n\n### Code Style\n- Die aktuellen Methodennamen im Interface (`title`, `information`, `secondInfo`) sind semantisch unklar (und ohne Javadoc schwer verständlich); benenne sie so, dass direkt ersichtlich ist, ob es um Achsenwerte, Gruppennamen, Titel oder Detailtext geht.\n- `Map<String, Integer>` für “Information” passt schlecht zu den im UI gezeigten Textdetails (dort werden Strings gezeichnet und sogar per `\\n` in Zeilen getrennt); das macht die Schnittstelle unnötig kompliziert.\n- Im `DataPoint`-Interface ist der Kommentar `// TODO` stehen geblieben, aber es fehlen die geforderten Javadoc-Kommentare an den Methoden.\n",
"status" : "SUCCESS"
}
}