{
"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- `TryStraightFirst` macht keinen Schritt, nachdem Du links/rechts abgebogen hast; laut Aufgabenstellung soll in dem Fall (nach dem Drehen) auch vorwärts gegangen werden.\n- `TryStraightFirst` macht keine Rechtsumkehr, wenn weder vorne noch links noch rechts ein Pfad ist (das ist explizit gefordert).\n- `BacktrackingAlgorithm` hängt von einem `Labyrinth`-Objekt im Konstruktor ab und benutzt `labyrinth.goalAt(...)`/`labyrinth.rows()`/`cols()` statt nur über das gegebene `Figure`-Objekt zu arbeiten; das passt nicht zum Interface-Design der Aufgabe (die Algorithmen sollen nur via `Figure` navigieren).\n- In `LabyrinthApp` erzeugst Du ein eigenes `Labyrinth l = new Labyrinth(MAPS[1]);` und gibst dessen Algorithmus dann in alle Levels; dadurch arbeitet Dein `BacktrackingAlgorithm` mit einem anderen Labyrinth als dem, das im `LabyrinthGame` gerade gespielt wird.\n- `BacktrackingAlgorithm` beendet die Navigation nicht zuverlässig, wenn das Ziel erreicht ist: Du prüfst das Ziel über `labyrinth.goalAt(row,col)` statt über `figure.isGoalReached()`, und nach dem Zurückkehren aus Rekursion können trotzdem noch weitere Richtungs-`if`s ausgeführt werden, obwohl das Ziel ggf. schon erreicht ist.\n- Beim Backtracking bewegst Du Dich nach dem Rekursionsaufruf immer “einen Schritt zurück” (180° drehen, vor, 180° drehen), auch wenn der rekursive Aufruf das Ziel gefunden hat; dadurch kann die Figur das Ziel wieder verlassen, sodass `LabyrinthGame` am Ende evtl. “Ziel nicht gefunden” wirft.\n- In `BacktrackingAlgorithm`: Wenn Du in einer Sackgasse bist, drehst Du 180° und rufst erneut `checkPath` auf, ohne vorwärts zu gehen; damit änderst Du die Position nicht und landest sofort wieder im selben Zustand (nur andere Blickrichtung), was das Backtracking in Sackgassen nicht korrekt ausführt.\n\n### Suggestion\n- Bei `TryStraightFirst`: Überlege Dir pro Schleifendurchlauf eine klare Priorität (vorwärts, sonst links, sonst rechts, sonst umdrehen) und stelle sicher, dass bei einer gewählten Richtung auch wirklich ein Feld betreten wird (also nicht nur drehen).\n- Für `BacktrackingAlgorithm`: Versuche, den Algorithmus so zu bauen, dass er keinerlei Kenntnis vom `Labyrinth` braucht, sondern ausschließlich `Figure`-Methoden nutzt (inkl. Zielprüfung). Dann kannst Du denselben Algorithmus in jedem Level verwenden, ohne ihn an ein bestimmtes Map-Objekt zu koppeln.\n- In `LabyrinthApp`: Stelle sicher, dass der Algorithmus nicht mit einem “falschen” Labyrinth konstruiert wird. Wenn Dein Algorithmus aktuell einen `Labyrinth`-Parameter braucht, ist das ein Hinweis, dass Du das Design nochmal überdenken solltest.\n- Für das Beenden beim Ziel: Baue eine durchgängige Abbruchbedingung ein (z.B. am Anfang jeder Rekursionsstufe und/oder nach jedem Zug), und sorge dafür, dass nach “Ziel gefunden” keine weiteren Bewegungen mehr passieren (insbesondere kein automatisches Zurücklaufen).\n- Für Sackgassen im Backtracking: Prüfe, welche Aktion nötig ist, um tatsächlich einen Schritt zurück zum vorherigen Feld zu kommen (Position ändern) und nicht nur die Richtung zu drehen.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind auskommentierte Codeblöcke und Debug-Ausgaben (`System.out.println`) enthalten; das macht es schwerer, die tatsächliche Logik zu lesen.\n- Du verwendest gemischte Sprache bei Bezeichnern (`besucht`, `checkPath`); entscheide Dich konsistent für Deutsch oder Englisch.\n- `BacktrackingAlgorithm` speichert `Labyrinth labyrinth` als Feld, obwohl das Interface `navigate(Figure)` eine labyrinthen-unabhängige Implementierung nahelegt; das macht die Klasse unnötig stark gekoppelt.\n\n\n# Exercise: swissmap\n\n### Correctness\n- Deine verwendeten Bildpfade (z. B. `\"swissmap_img/Switzerland_map.png\"`, `\"swissmap_img/lake.png\"`, `\"swissmap_img/mountain.png\"`) entsprechen nicht den im Exercise-Code/Tipps erwarteten Ressourcenpfaden (dort wird z. B. `\"swissmap/Switzerland_map.png\"` verwendet). Wenn diese Dateien nicht genau so im `resources`-Ordner liegen, wird nichts gezeichnet.\n- In `Lake.draw` und `Mountain.draw` verwendest du als Skalierung `WIDTH * scale(gui) / BG_PIXEL_WIDTH` (die Hintergrund-Skalierung der Karte). Für die kleinen Icon-Bilder der Seen/Berge führt das typischerweise dazu, dass sie riesig bzw. falsch skaliert werden und nicht wie gefordert aussehen.\n- `ModeButton.getInteractiveArea` ist deutlich kleiner als das, was du zeichnest (du zeichnest ca. `65x25`, interaktiv ist aber nur `15x15`). Dadurch kann man den Button nur auf einem kleinen Teil wirklich anklicken/hovern, was die geforderte Bedienung verletzt.\n\n### Suggestion\n- Prüfe, welche Resource-Pfade im Projekt wirklich vorhanden sind (Ordnername, Gross-/Kleinschreibung) und verwende exakt diese Strings in `drawImage(...)`. Orientiere dich dabei an den Pfaden, die `SwissMap` im Ausgangscode schon benutzt.\n- Überlege dir bei Lake/Mountain, ob du wirklich die Karten-Hintergrund-Skalierung als *Icon-Grösse* verwenden willst. Sinnvoller ist meist: fixe Pixelgrösse oder eine eigene, viel kleinere Skalierung (und dann testen, ob es bei Resize noch gut aussieht).\n- Mach die `getInteractiveArea(...)` beim `ModeButton` so gross wie das Rechteck, das du im `draw(...)` malst (Position und Breite/Höhe sollten zusammenpassen), damit Hover/Klick zuverlässig funktionieren.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(satelliteMode);` in `SwissMap.draw` und `System.out.println(getInhabitants());` in `City.onMouseEnter()`, das spamt die Konsole bei jedem Frame/Mouse-Event.\n- In `ModeButton` sind die Felder `hovered` und `clicked` aktuell ohne Effekt (sie werden gesetzt, aber nirgends verwendet) – entweder verwenden (z. B. fürs Aussehen) oder weglassen.\n- In `Mountain` (und auch `SwissMap`) sind Imports wie `ImageIO`, `BufferedImage`, `IOException`, `Objects` unbenutzt – die solltest du löschen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface stellt nicht die Informationen bereit, die der `Visualizer` effektiv braucht: Es fehlen mindestens Werte für x/y-Koordinate (als `double`) sowie Strings für Gruppierung/Legende und die Highlight-Anzeige.\n- Die Methoden im `DataPoint`-Interface sind als `void` deklariert und wirken wie “Setter” (`title(...)`, `information(...)`), der `Visualizer` braucht aber “Getter”-Informationen, um zeichnen zu können.\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 `DataPoint` nicht, dadurch kannst du die geladenen Datensätze nicht als `DataPoint[]` an den `Visualizer` übergeben.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt einen geladenen Datensatz zu visualisieren; damit wird nichts angezeigt/ausgewertet.\n\n### Suggestion\n- Schau dir im `Visualizer` jede Stelle mit `DUMMY_DOUBLE` an und überlege: “Welche numerische Eigenschaft eines Datenpunkts wird hier benötigt?” (Min/Max finden, Punkte zeichnen, Mausdistanz berechnen) – daraus ergeben sich sehr direkt 2 Methoden im Interface.\n- Schau dir jede Stelle mit `DUMMY_STRING` an und überlege: “Ist das ein Text für die Legende/Farbgruppe oder der Titel/Details im Hover?” – typischerweise sind das getrennte Methoden (Gruppe vs. Tooltip/Label).\n- Gestalte die `DataPoint`-Methoden so, dass der `Visualizer` sie direkt abfragen kann (Rückgabewerte), statt Daten “hineinzuschreiben” (Parameter + `void`).\n- Sobald das Interface steht: implementiere es zuerst in **einer** Klasse (z.B. `Movie`) mit den Achsen wie in der Aufgabe beschrieben (x=Budget, y=Rating) und ersetze dann in `VisualizerApp` das leere Array durch den geladenen Movie-Datensatz.\n- Erst wenn Movies funktionieren, mappe analog `Country` (x/y laut Aufgabenstellung) und `Processor` (x aus Jahr+Monat kombiniert; y aus Taktfrequenz*cores, plus log-Skalierung falls im Visualizer vorgesehen).\n\n### Code Style\n- Die Namen `information` und `secondInfo` sind sehr unspezifisch; Interface-Methoden sollten fachlich klar ausdrücken, wofür sie gedacht sind (z.B. Achsenwert, Gruppierung, Titel, Detailtext).\n- `Map<String, Integer>` als Interface-Typ für Detailinfos macht das Interface unnötig komplex und unflexibel (und passt schlecht zu Werten wie `double`); ein formatierter String für die Anzeige ist oft die passendere, einfachere Schnittstelle für so einen Visualizer.\n",
"status" : "SUCCESS"
}
}