{
"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 **nicht** zu den Levels passt, die du danach in der Schleife spielst. Dadurch arbeitet dein Algorithmus intern mit einer anderen Map als die Figur, die er steuert.\n- `TryStraightFirst` erfüllt die Aufgabenbeschreibung nicht vollständig: Wenn weder vorne noch links noch rechts ein Pfad ist, soll die Figur **rechtsum kehrt machen** (180° drehen). Dieser Fall fehlt; aktuell würde die Figur dann in der Schleife hängen bleiben.\n- `BacktrackingAlgorithm` beendet die Navigation nicht zuverlässig, wenn das Ziel erreicht ist: Du prüfst in `checkPath` zwar auf das Goal und `return`, aber die aufrufenden Frames laufen danach weiter und führen ggf. noch weitere Bewegungen/Backtracking-Schritte aus (kann dazu führen, dass du nach dem Ziel wieder weg läufst oder unnötig weiter machst).\n- In `BacktrackingAlgorithm` verwendest du `labyrinth.goalAt(row, col)` statt `figure.isGoalReached()`. Damit umgehst du die vorgesehene Schnittstelle und bist zudem von dem (bei dir aktuell falschen) `labyrinth`-Objekt abhängig.\n- Dein Backtracking “zurückgehen” (`turnLeft(); turnLeft(); moveForward(); ...`) setzt voraus, dass hinter dir immer ein Pfad ist. Durch die Kombination aus `besucht`-Abbruch und dem fixen Zurücklaufen kann es passieren, dass du zurücklaufen willst, obwohl du an dieser Stelle nicht von dort gekommen bist (besonders wenn du zuerst `pathAhead`, dann `pathToTheLeft`, dann `pathToTheRight` in getrennten `if`s machst).\n\n### Suggestion\n- Sorge dafür, dass dein `BacktrackingAlgorithm` **nur** über das `Figure`-Objekt arbeitet (Position/Goal/Wege prüfen) und nicht über ein separat gespeichertes `Labyrinth`. Dann passt der Algorithmus automatisch zu jedem Level, das `game.play(navi)` ihm gibt.\n- Für `TryStraightFirst`: Ergänze am Ende der `if/else if`-Kette einen Fall für “nichts geht”, in dem du zweimal nach rechts drehst (oder äquivalent), bevor die Schleife weiterläuft.\n- Beim Backtracking brauchst du eine Möglichkeit, “Ziel gefunden” nach oben durchzureichen, sodass nach dem Fund **alle** weiteren rekursiven Schritte sofort aufhören. Überleg dir, ob `checkPath` dafür z.B. ein `boolean` zurückgeben sollte (gefunden/nicht gefunden), und nutze das dann, um keine weiteren Richtungen mehr zu testen.\n- Achte darauf, dass du nach dem Erkunden einer Richtung wirklich wieder exakt in den Zustand zurückkehrst, den du vor dem Erkunden hattest (gleiche Zelle, gleiche Blickrichtung). Überprüf das gedanklich für jede der drei Richtungen separat.\n- Statt drei unabhängigen `if`s (ahead/left/right) kann eine Struktur helfen, die klar “probier eine Richtung; wenn gefunden -> stop; sonst backtrack und probier nächste Richtung” ausdrückt, damit du nicht nach einem erfolgreichen Pfad trotzdem noch andere Zweige startest.\n\n3. Code Style:\n- In `BacktrackingAlgorithm.navigate` sind auskommentierte größere Codeblöcke und ein paar alte Debug-Ansätze (`System.out.println`) – das macht es schwerer, die finale Logik zu lesen; räum das am besten auf.\n- `BacktrackingAlgorithm` speichert `Labyrinth labyrinth` als Feld, obwohl der Algorithmus laut Interface nur mit `Figure` arbeiten sollte; das koppelt unnötig stark und führt (wie bei dir) leicht zu Inkonsistenzen.\n- Namen wie `besucht` sind ok, aber mische nicht unnötig Deutsch/Englisch innerhalb derselben Klasse/Methoden (z.B. `checkPath` + `besucht`).\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `Lake`, `Mountain` und `SwissMap` verwendest du andere Resource-Pfade (`swissmap_img/...`) als in der Aufgabenstellung/gegebenen `SwissMap`-Vorlage (`swissmap/...`). Wenn diese Dateien im Projekt so nicht existieren, werden die Bilder nicht angezeigt (Seen/Berge/Hintergrund fehlen).\n- `ModeButton.getInteractiveArea(...)` passt nicht zur gezeichneten Button-Fläche: Du zeichnest ein Rechteck mit `65x25`, aber der interaktive Bereich ist nur `15x15`. Dadurch ist ein grosser Teil des sichtbaren Buttons nicht klick-/hoverbar.\n\n### Suggestion\n- Prüfe, wie der Ressourcen-Ordner im Projekt heisst und welche Pfade `drawImage(...)` erwartet (und welche Pfade `SwissMap` im Ausgangscode schon nutzt). Richte die Bildpfade für Karte/Seen/Berge daran aus.\n- Verwende für `getInteractiveArea(...)` beim `ModeButton` dieselben Koordinaten und dieselbe Breite/Höhe wie beim `drawRect(...)`, damit “was man sieht” und “was klickbar ist” übereinstimmt.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(satelliteMode)` in `SwissMap.draw` und `System.out.println(getInhabitants())` in `City.onMouseEnter`, da sie bei jedem Frame/Mouse-Event unnötig die Konsole fluten.\n- In `Mountain` und `SwissMap` hast du Imports/Code für `ImageIO`, `BufferedImage`, `IOException`, `Objects`, die nirgends verwendet werden—aufräumen, damit die Klassen übersichtlich bleiben.\n- `ModeButton` speichert `hovered` und `clicked`, nutzt diese Zustände aber aktuell nicht im `draw` (wirkt wie “toter Zustand”). Entweder nutzen (z.B. anderes Aussehen) oder entfernen.\n- Die `toString()`-Ausgaben enthalten bei dir `\\n` und zusätzlich ein Leerzeichen vor der Klammer (`\"\\n (\"...`) — das wirkt im GUI-Text schnell “komisch” formatiert; besser ein einheitliches Format wählen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface liefert dem `Visualizer` nicht die Informationen, die er tatsächlich braucht: In `Visualizer` werden pro Punkt zwingend zwei numerische Werte (x/y), eine Gruppierung für die Farbe sowie Titel/Detailtext für die Hover-Ansicht benötigt; deine Methoden (`title(...)`, `information(...)`, `secondInfo(...)`) geben aber nichts zurück und passen damit nicht zu den Stellen, wo aktuell `DUMMY_DOUBLE`/`DUMMY_STRING` stehen.\n- In `Visualizer` wurden die Dummy-Werte noch nirgends durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt (z.B. in `findMinMax`, `plotData`, Hover-Erkennung, `drawHighlighted`, `collectGroups`).\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 geladenen Datensätze zu visualisieren.\n- Die Achsen-Zuordnung aus der Aufgabenstellung ist nicht umgesetzt (Movies: Budget als x, Rating als y; Countries: Literacy als x, GDP per Capita als y; Processors: Jahr+Monat als x, effektive Geschwindigkeit als y inkl. Log-Skalierung).\n\n### Suggestion\n- Schau dir in `Visualizer` jede Stelle mit `DUMMY_DOUBLE` an und überlege: „Von welchem `DataPoint` müsste ich hier x bzw. y bekommen?“ Daraus ergeben sich ganz natürlich 1–2 Getter-Methoden im Interface, die `double` zurückgeben.\n- Für `DUMMY_STRING` gibt es in `Visualizer` unterschiedliche Verwendungszwecke (Gruppierung/Farbe, Titel beim Hover, mehrzeiliger Detailtext). Überlege, ob das wirklich alles „ein String“ ist oder ob du dafür getrennte Methoden im Interface brauchst.\n- Ein Interface sollte hier beschreiben, was der Visualizer **abfragen** kann, nicht was er „setzen“ soll: Prüfe daher, ob deine Interface-Methoden eher Rückgabewerte liefern sollten statt Parameter entgegenzunehmen.\n- Damit `loadMovies()` als Datensatz für den Visualizer taugt, müssen die Elemente des Arrays als `DataPoint` behandelbar sein: Überlege, was du an `Movie` ändern musst, damit ein `Movie` als `DataPoint` verwendet werden kann (gleiches Prinzip für `Country`/`Processor`).\n- Für den Prozessor-Datensatz: Überlege, wie du „Jahr und Monat zu einem einzigen x-Wert kombinierst“ (so, dass die zeitliche Reihenfolge stimmt) und wie du „clockRate * cores“ als y-Wert ableitest; die Log-Skalierung betrifft dann, welchen y-Wert du dem Visualizer gibst bzw. wie er skaliert.\n\n### Code Style\n- Methodennamen im Interface wie `title`, `information`, `secondInfo` sind sehr unklar benannt und wirken wie „Setter“; üblich (und lesbarer) wären sprechende „Getter“-Namen, die den Zweck ausdrücken (z.B. x/y/gruppierung/titel/details).\n- `Map<String, Integer>` für „Information“ ist für die Ausgabe im Hover schwer handhabbar und erzwingt eine feste `Integer`-Welt (Ratings/Literacy sind aber `double`); zudem ist die Reihenfolge in einer `Map` nicht garantiert, was für eine schöne Anzeige ungünstig ist.\n",
"status" : "SUCCESS"
}
}