{
"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 **ein** `BacktrackingAlgorithm` mit einem `Labyrinth l = new Labyrinth(MAPS[1])`, spielst dann aber **alle** Levels mit demselben `navi`. Dadurch arbeitet dein Algorithmus intern mit einem anderen Labyrinth/Map als das gerade gespielte Level (die `Figure`, die du bekommst, gehört zum `LabyrinthGame`-Labyrinth, dein Feld `labyrinth` aber zu `MAPS[1]`).\n- `TryStraightFirst` erfüllt die Anforderung „Sollte das alles nicht gehen, soll die Figur rechtsum kehrt machen“ nicht (bei Sackgasse machst du aktuell weder Kehrtwende noch einen Rückwärts-Schritt, die Figur kann dadurch stecken bleiben und die Schleife läuft endlos).\n- `BacktrackingAlgorithm` beendet die Navigation nicht zuverlässig, wenn das Ziel erreicht ist: du prüfst in `checkPath` über `labyrinth.goalAt(row,col)` (falsches Labyrinth, siehe erster Punkt) statt über den Zustand der übergebenen `Figure`/`isGoalReached()`. Dadurch kann `navigate` auch dann weiterlaufen/„zurücktracken“, obwohl im aktuellen Spiel das Ziel erreicht wäre.\n- In `BacktrackingAlgorithm` kann dein Backtracking-Schritt `moveForward()` beim „Zurückgehen“ in bestimmten Situationen den Pfad verlassen (GameOver), weil du vor dem Rückwärts-Move nicht prüfst, ob in der aktuellen Blickrichtung wirklich ein Pfad ist (du drehst zwar 180°, aber du gehst davon aus, dass der Rückweg immer frei ist; das stimmt nur, wenn die Orientierung/Bewegung exakt konsistent bleibt).\n- In `checkPath` führst du nacheinander drei unabhängige `if`-Blöcke für vorne/links/rechts aus. Weil du dabei die Figur drehst und bewegst, beziehen sich die späteren `if`-Bedingungen nicht mehr auf die ursprüngliche Situation im Feld. Das kann dazu führen, dass du Abzweigungen überspringst oder inkonsistente Bewegungen machst.\n\n### Suggestion\n- Überlege dir, ob dein `BacktrackingAlgorithm` wirklich ein eigenes `Labyrinth`-Objekt speichern muss: Die `navigate`-Methode bekommt schon alles Nötige über das `Figure`-Interface. Wenn du trotzdem Map-Infos brauchst, muss es garantiert das Labyrinth des aktuellen Levels sein.\n- Für `TryStraightFirst`: Implementiere explizit den Fall „keine Richtung möglich“ (ahead/left/right alle false). Eine Kehrtwende besteht aus zwei Drehungen in dieselbe Richtung; danach braucht es typischerweise auch einen Schritt, sonst kommst du aus der Sackgasse nicht raus.\n- Für das Beenden beim Ziel: Nutze als Abbruchbedingung das, was dir das Interface gibt (`figure.isGoalReached()`), und sorge dafür, dass deine Rekursion/Schleifen diesen Zustand respektieren (z.B. vor weiteren Moves prüfen).\n- Für sicheres Backtracking: Bevor du beim „Zurückgehen“ `moveForward()` machst, stelle sicher, dass die Figur tatsächlich wieder in Richtung der vorherigen Zelle zeigt und dass dort ein Pfad ist (denn `moveForward()` crasht, wenn kein Pfad).\n- Für die drei Richtungen im Backtracking: Speichere dir (gedanklich oder in Variablen) den Ausgangszustand (Position + Richtung) an einer Kreuzung und stelle ihn nach dem Erkunden eines Astes wieder her, bevor du den nächsten Ast prüfst. Sonst prüfen deine späteren `if`s eine veränderte Orientierung/Situation.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind die lokalen Variablen `int col = labyrinth.cols(); int row = labyrinth.rows();` etwas verwirrend benannt (col/row sind eigentlich Dimensionen). Klarere Namen wie `cols/rows` würden Missverständnisse vermeiden.\n- Der auskommentierte Codeblock in `BacktrackingAlgorithm.navigate` macht die Lösung schwer lesbar; besser entfernen, sobald du dich für eine Variante entschieden hast.\n- `BacktrackingAlgorithm` hat unnötigen Zustand (`private Labyrinth labyrinth`), der die Kopplung erhöht und hier sogar zu einem Fehler geführt hat; als Stil/Design-Hinweis: lieber nur mit dem `Figure`-Interface arbeiten, wenn möglich.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Deine `SwissMap`-Hintergrundbilder liegen bei dir unter `swissmap_img/...`, die vorgegebene Karte verwendet aber `swissmap/...`; wenn der Ordner/Dateiname im Projekt nicht genau so existiert, wird der Hintergrund (und auch Lake/Mountain-Icons) nicht angezeigt.\n- Bei `ModeButton`: Du zeichnest ein Rechteck mit `65x25`, aber dein `getInteractiveArea` ist nur `15x15` gross; dadurch ist nur ein kleiner Teil des Buttons wirklich hover-/klickbar, obwohl der ganze Button sichtbar ist.\n\n### Suggestion\n- Prüfe im `resources`-Ordner (und in der Aufgabenbeschreibung), wie die Bildpfade genau heissen, und passe deine Strings in `drawImage(...)` daran an (Ordnername + Dateiname inklusive Gross-/Kleinschreibung).\n- Leite die interaktive Fläche des `ModeButton` aus den gleichen Werten ab, die du zum Zeichnen benutzt (Position + Breite/Höhe), damit “sichtbar” und “klickbar” deckungsgleich sind.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(...)` in `SwissMap.draw` und `City.onMouseEnter`, weil `draw` sehr oft aufgerufen wird und die Konsole sonst “zugespammt” wird.\n- In `Mountain` (und auch `SwissMap`) hast du Imports wie `ImageIO`, `BufferedImage`, `IOException`, `Objects`, die du nicht verwendest – die solltest du löschen.\n- `clicked` und `hovered` im `ModeButton` werden gesetzt, aber in `draw` nicht genutzt; entweder verwenden (z.B. für Darstellung) oder entfernen, damit der Code klar bleibt.\n- In `getInteractiveArea` bei City/Lake/Mountain: du erstellst jeweils erst eine Variable (`Rectangle r/s`) und gibst sie direkt zurück – du kannst das knapper halten (hilft Lesbarkeit).\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface liefert keine Werte für x/y-Koordinaten, Gruppierung und Textausgabe, die der `Visualizer` für die Darstellung (min/max bestimmen, Punkte zeichnen, Legende, Hover-Details) benötigt.\n- Die Methoden in `DataPoint` sind als `void` definiert und wirken wie “Setter” (`title(...)`, `information(...)`), aber der `Visualizer` braucht “Getter”-Informationen vom Datenpunkt (also Rückgabewerte), um Dummy-Werte zu ersetzen.\n- In `Visualizer` wurden die `DUMMY_DOUBLE`/`DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt; damit bleibt die Visualisierung funktional unvollständig.\n- `Movie`, `Country` und `Processor` implementieren das `DataPoint`-Interface nicht, dadurch können `loadMovies()/loadCountries()/loadProcessors()` nicht direkt als `DataPoint[]` an den `Visualizer` übergeben werden.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt einen der Loader (z.B. Filme) als Datensatz zu übergeben.\n\n### Suggestion\n- Schau dir jede Stelle im `Visualizer` an, wo `DUMMY_DOUBLE` steht: dort wird jeweils ein numerischer Wert des aktuellen `point` gebraucht (z.B. für x, y sowie min/max). Überlege dir dafür je eine Methode im Interface, die genau diesen Wert *zurückgibt*.\n- Schau dir jede Stelle im `Visualizer` an, wo `DUMMY_STRING` steht: dort wird entweder eine Gruppenzuordnung (für Farben/Legende) oder Text für die Anzeige (Titel + Detailzeilen) benötigt. Plane im Interface getrennte Methoden für “Gruppe” und “Beschriftung/Details”.\n- Überlege dir das Interface so, dass es für alle drei Datentypen passt: Filme (Budget/Rating), Länder (Literacy/GDP per capita), Prozessoren (Zeitpunkt/“effektive Geschwindigkeit” und Detailtext). Das Interface sollte nichts “setzen”, sondern nur Informationen “liefern”.\n- Sobald das Interface steht, implementiere es in `Movie` zuerst und mappe dort x/y wie in der Aufgabenstellung (Budget auf x, Rating auf y); danach kannst du in `VisualizerApp` testweise den Movie-Loader verwenden und prüfen, ob min/max, Punkte und Hover funktionieren.\n- Für Länder/Prozessoren dann analog: gleiche Interface-Methoden, aber andere Berechnungen/Strings. Achte bei Prozessoren darauf, dass x ein kombinierter Wert aus Jahr+Monat sein soll und y auf der “effektiven Geschwindigkeit” basiert; die Log-Skalierung muss sich irgendwo im Wert oder in der Achsen-Logik widerspiegeln (je nachdem, wie du es entwirfst).\n\n### Code Style\n- Methodennamen im Interface wie `title(String name)` sind missverständlich, weil sie wie Setter wirken; benenne Methoden so, dass klar ist, dass sie Werte liefern (und gib passende Typen zurück).\n- `information(Map<String, Integer> info)` / `secondInfo(...)` ist sehr allgemein und zwingt alle Datensätze in ein Map-Format; für die Anzeige im GUI ist meist ein klarer String (oder String-Liste) pro Datenpunkt einfacher zu handhaben als Maps.\n",
"status" : "SUCCESS"
}
}