{
"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.main()` erzeugst du `BacktrackingAlgorithm` mit einem `Labyrinth l = new Labyrinth(MAPS[1]);`, aber gespielt wird danach jedes Level mit einem *anderen* `LabyrinthGame`/`Labyrinth`. Dein Algorithmus arbeitet dadurch mit der falschen Map (weil `BacktrackingAlgorithm` intern `labyrinth.goalAt(...)`, `labyrinth.rows()`, `labyrinth.cols()` nutzt), und kann für die meisten Levels nicht korrekt funktionieren.\n- `TryStraightFirst` erfüllt die Anforderung „Wenn alles nicht geht, rechtsum kehrt machen“ nicht: In deinem Code fehlt der Fall, in dem vorne/links/rechts kein Pfad ist (Umdrehen + weitergehen). So bleibt die Figur in Sackgassen stehen und das Ziel wird ggf. nie erreicht.\n\n### Suggestion\n- Mach `BacktrackingAlgorithm` unabhängig von einem extern gespeicherten `Labyrinth`: Du bekommst in `navigate` bereits alles, was du zur Steuerung brauchst, über das `Figure`-Objekt (inkl. `isGoalReached()` und Pfad-Abfragen). Überlege, wie du das Ziel erkennst und dein „besucht“-Konzept aufbauen kannst, ohne `goalAt(...)` auf einem separaten `Labyrinth` aufzurufen, das nicht zum aktuellen Level passt.\n- Ergänze in `TryStraightFirst` am Ende der `if/else if`-Kette einen `else`-Fall für Sackgassen, der die verlangte „rechtsum kehrt“-Bewegung ausführt (Umdrehen und dann weiter), damit die Schleife nicht ohne Bewegung weiterläuft.\n\n### Code Style\n- In `BacktrackingAlgorithm.navigate` sind `int col = labyrinth.cols(); int row = labyrinth.rows();` missverständlich benannt (das sind eher `cols/rows`) und die Variablen werden nur für das Array gebraucht – bessere Namen würden die Lesbarkeit stark erhöhen.\n- In `BacktrackingAlgorithm.navigate` ist viel auskommentierter Code; den solltest du entfernen, sobald du dich für eine Strategie entschieden hast, damit klar ist, was wirklich zur Lösung gehört.\n- In `checkPath` wiederholst du den Backtracking-Block (zweimal links drehen, zurück laufen, zweimal links drehen) mehrfach fast identisch; das wäre ein guter Kandidat für eine kleine Hilfsmethode, um Duplikation zu reduzieren.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `Lake`/`Mountain` (und auch `SwissMap`) verwendest du andere Resource-Pfade (`swissmap_img/...`) als in der Aufgabenstellung/Library-Beispielen erwartet (`swissmap/...`). Wenn diese Dateien im Projekt nicht genau so existieren, werden die Bilder nicht angezeigt.\n- `ModeButton.getInteractiveArea(...)` ist viel kleiner als das, was du in `draw(...)` als Button zeichnest (du zeichnest ca. 65x25, interaktiv sind aber nur 15x15). Damit ist ein grosser Teil des sichtbaren Buttons nicht klick-/hoverbar.\n- Bei `City.getInteractiveArea(...)` ist die interaktive Fläche (5x5) kleiner/anders als das gezeichnete Element (Kreis mit Radius 5 bzw. im Hover sogar 10). Dadurch triggert Hover/Klick nur in einem Teil des sichtbaren Punktes.\n\n### Suggestion\n- Prüfe, welche Ordner-/Dateinamen im mitgelieferten `resources`-Ordner tatsächlich vorhanden sind, und passe deine `drawImage(...)`-Strings exakt daran an (inkl. Gross-/Kleinschreibung und Unterordner).\n- Leite die Button-Interaktionsfläche aus den gleichen Werten ab, die du auch zum Zeichnen verwendest (gleiche Position, gleiche Breite/Höhe), damit “sichtbar” und “klickbar” zusammenpassen.\n- Wähle für `City` eine `Rectangle`-Fläche, die den gezeichneten Kreis realistisch abdeckt (z.B. rund um `(x,y)` mit passender Breite/Höhe), damit Hover zuverlässig funktioniert.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(...)` in `SwissMap.draw(...)` und `City.onMouseEnter(...)`; `draw()` wird sehr oft aufgerufen und spamt sonst die Konsole.\n- In `Mountain` und `SwissMap` hast du Imports für `ImageIO`, `BufferedImage`, `IOException`, `Objects`, die du nicht verwendest.\n- In `ModeButton` sind `hovered` und `clicked` zwar gesetzt, aber nirgends im Zeichnen/Verhalten genutzt – entweder verwenden (z.B. fürs Aussehen) oder entfernen, damit der Zweck klar bleibt.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface liefert dem `Visualizer` nicht die nötigen Informationen für die Darstellung (x/y-Koordinaten als Zahlen, Gruppierung für Farben/Legende, Titel und Detailtext fürs Hover). Mit `title(...)`, `information(...)` und `secondInfo(...)` kann `Visualizer` die DUMMY-Werte nicht ersetzen.\n- Die Methoden im `DataPoint`-Interface sind als Setter formuliert (`void ...` mit Parametern). Der `Visualizer` braucht aber Werte *vom* Datenpunkt, um zu zeichnen (also Rückgabewerte statt “reinstecken”).\n- In `Visualizer` wurden die `DUMMY_DOUBLE`/`DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt, dadurch bleibt die Visualisierung funktional “Dummy”.\n- `Movie`, `Country` und `Processor` implementieren das `DataPoint`-Interface nicht, daher 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 in der Aufgabenstellung geforderten Achsenbelegungen (Movies: Budget→x, Rating→y; Countries: Literacy→x, GDP per capita→y; Processors: Jahr+Monat→x und clockRate*cores (logarithmisch)→y) sind nirgends umgesetzt.\n- Die Aufgabe verlangt Javadoc zur Dokumentation des Verhaltens der Interface-Methoden; in deinem `DataPoint` fehlt diese Dokumentation.\n\n### Suggestion\n- Schau dir im `Visualizer` jede Stelle an, wo `DUMMY_DOUBLE` steht: dort wird jeweils ein konkreter Zahlenwert pro Punkt gebraucht (z.B. einmal x, einmal y). Überlege dir passende *Getter*-Methoden im Interface, die genau diese Werte liefern.\n- Schau dir jede Stelle an, wo `DUMMY_STRING` steht: einmal geht es um die Gruppierung (Legende/Farbe), einmal um den Titel im Highlight, und einmal um einen mehrzeiligen Detailtext (wird per `split(\"\\n\")` verarbeitet). Plane dafür getrennte String-Rückgaben im Interface ein.\n- Das Interface sollte vom `Visualizer` aus lesbar sein: also Methoden ohne Parameter, die einen Wert zurückgeben. Überlege dir, welche Rückgabetypen (double/String) an den jeweiligen Stellen im Code erwartet werden.\n- Sobald das Interface steht, implementiere es in `Movie`/`Country`/`Processor` so, dass deren Felder auf die Interface-Methoden abgebildet werden (bei Prozessoren auch der kombinierte Monatswert und der berechnete Speed).\n- Ersetze in `VisualizerApp` schrittweise `new DataPoint[0]` durch einen geladenen Datensatz. Falls du dabei an einem Typproblem hängenbleibst, ist das ein Hinweis, dass deine Loader-Arrays (`Movie[]` etc.) erst “kompatibel” werden, wenn die Klassen `DataPoint` implementieren.\n\n### Code Style\n- Die `DataPoint`-Methodennamen `information`/`secondInfo` sind sehr unspezifisch; für Lesbarkeit und Wartbarkeit wären Namen besser, die direkt die Rolle im `Visualizer` ausdrücken (z.B. Achsenwert, Gruppe, Titel, Detailtext).\n- `Map<String, Integer>` im Interface wirkt unnötig kompliziert für das, was der `Visualizer` tatsächlich zeichnet/anzeigt (dort wird mit `String` und `double` gearbeitet). Das erhöht Kopplung und macht Implementationen schwerer als nötig.\n",
"status" : "SUCCESS"
}
}