{
"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` erfüllt die Aufgabenbeschreibung nicht vollständig: Wenn vorne, links und rechts kein Pfad ist, soll die Figur „rechtsum kehrt“ machen (180° drehen). Dieser Fall fehlt bei dir, dadurch kann der Algorithmus in Sackgassen stecken bleiben bzw. nicht weiterkommen.\n- `BacktrackingAlgorithm` weicht von der geforderten Schnittstelle/Verwendung ab: Laut Interface bekommt `navigate` nur ein `Figure`-Objekt, dein Algorithmus hängt aber zusätzlich an einem extern übergebenen `Labyrinth` (Konstruktor + Feld) und nutzt `labyrinth.goalAt(...)`. Damit ist der Algorithmus nicht mehr unabhängig vom konkreten Labyrinth-Objekt, das im `LabyrinthGame` intern verwendet wird.\n- In `LabyrinthApp` erstellst du `BacktrackingAlgorithm` mit `new Labyrinth(MAPS[1])` (Level 2) und verwendest dieses `navi` dann für alle Levels. Das passt nicht: Jedes Level hat ein eigenes Labyrinth im `LabyrinthGame`, dein Algorithmus arbeitet aber mit dem separaten `Labyrinth l` aus MAPS[1] (für Ziel-Checks/Dimensionen). Das kann dazu führen, dass dein Backtracking das Ziel gar nie „erkennt“ oder falsche Dimensionen benutzt.\n- `BacktrackingAlgorithm.checkPath`: Wenn du in der Sackgasse bist, drehst du zweimal nach rechts und rufst direkt wieder `checkPath` auf, ohne einen Schritt zurück zu gehen. Dadurch änderst du die Position nicht und landest sofort wieder auf einem bereits-besucht Feld → Backtracking bricht ab, obwohl du eigentlich zurücklaufen müsstest.\n- `BacktrackingAlgorithm.checkPath`: Du markierst Zellen global als `besucht` und kehrst sofort zurück, wenn eine Zelle besucht ist. In Kombination mit Richtungsänderungen kann das verhindern, dass du von derselben Zelle aus andere Abzweigungen erkundest (klassischer Backtracking-Fall: Zelle ist besucht, aber es gibt noch „unprobierte Ausgänge“).\n- In `BacktrackingAlgorithm` endet `navigate` nach einem einzigen Aufruf von `checkPath`, ohne danach sicherzustellen, dass das Ziel tatsächlich erreicht wurde (kein Loop um „solange nicht am Ziel“ bzw. keine klare Erfolgskontrolle innerhalb des Algorithmus).\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir, was dein Code machen soll, wenn `pathAhead()`, `pathToTheLeft()` und `pathToTheRight()` alle `false` sind. Welche zwei Befehle ergeben eine 180°-Drehung?\n- Für `BacktrackingAlgorithm`: Versuche, dich strikt auf das `Figure`-API zu beschränken (Goal-Check über `figure.isGoalReached()` statt `labyrinth.goalAt(...)`). Dann bist du nicht vom „richtigen“ `Labyrinth`-Objekt abhängig.\n- Für `LabyrinthApp`: Dein `NaviAlgorithm` sollte für jedes Level auf der Figur arbeiten, die `game.play(...)` ihm gibt. Wenn dein Algorithmus intern ein eigenes Labyrinth braucht, ist das ein Warnsignal – prüfe, ob du diese Abhängigkeit eliminieren kannst.\n- Für Sackgassen im Backtracking: Backtracking heißt typischerweise „einen Schritt zurück gehen“, nicht nur umdrehen. Schau dir an, welche Bewegung/Rotation du nach der Rekursion brauchst, um garantiert wieder auf das vorherige Feld zu kommen.\n- Für das „besucht“-Konzept: Statt „Zelle einmal besucht = nie wieder betreten“, brauchst du evtl. eine feinere Information (z.B. welche Richtung(en) von dieser Zelle schon ausprobiert wurden), oder du musst sicherstellen, dass du beim Zurückkehren trotzdem noch andere Abzweigungen bearbeiten kannst.\n- Für die Terminierung: Stelle sicher, dass dein Algorithmus wirklich so lange läuft, bis `figure.isGoalReached()` true ist (oder alle Wege ausgeschöpft sind), und dass dein Abbruch in der Rekursion das auch sauber nach oben propagiert.\n\n3. Code Style:\n- In `BacktrackingAlgorithm.navigate` sind `int col = labyrinth.cols(); int row = labyrinth.rows();` verwirrend benannt (col/row als Dimensionen vs. aktuelle Position) und teilweise unnötig; klarere Namen wie `rows`, `cols` würden Missverständnisse vermeiden.\n- Auskommentierte Debug-/Altlogik (`System.out.println`, auskommentierte while/navigate-Aufrufe) macht den Code schwer lesbar; räume das auf, sobald du dich für einen Ansatz entschieden hast.\n- In `BacktrackingAlgorithm` wiederholst du den „zurücklaufen“-Block (zweimal links drehen, move, zweimal links drehen) mehrfach; das schreit nach einer kleinen Hilfsmethode, um Duplikation zu reduzieren.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMap` (und auch bei `Lake`/`Mountain`) verwendest du andere Resource-Pfade als in der Aufgabe/Template vorgesehen (`swissmap_img/...` statt `swissmap/...`). Wenn diese Dateien nicht exakt so im `resources`-Ordner liegen, wird der Hintergrund bzw. die Icons nicht angezeigt.\n- `ModeButton.getInteractiveArea(...)` passt nicht zur gezeichneten Button-Fläche: Du zeichnest ein Rechteck mit `65x25`, aber der interaktive Bereich ist nur `15x15`. Damit sind Klicks/Hover nur auf einem kleinen Teil des Buttons möglich.\n- Die `getInteractiveArea(...)` bei `City` ist sehr klein (`5x5`) im Verhältnis zum gezeichneten Kreis/Highlight; Hover wird dadurch schwer auszulösen sein und wirkt nicht wie “auf das Objekt zeigen” wie gefordert.\n\n### Suggestion\n- Prüfe, welche exakten Dateinamen und Ordnerstruktur im mitgelieferten `resources`-Ordner vorhanden sind, und nutze genau diese Pfade in `drawImage(...)` (so wie es `SwissMap` im Template vormacht).\n- Leite die Größe des `InteractiveArea` beim `ModeButton` direkt aus der Button-Geometrie ab, die du in `draw(...)` verwendest (gleiche Position, gleiche Breite/Höhe), damit Hover und Klick zuverlässig funktionieren.\n- Wähle für `City` (und analog für `Lake`/`Mountain`) einen interaktiven Bereich, der der sichtbaren Darstellung entspricht (z.B. um das Symbol herum), damit “darauf zeigen” in der Praxis gut funktioniert.\n\n3. 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 während des Renderns/Interagierens.\n- In `ModeButton` sind Felder (`hovered`, `clicked`) aktuell ohne Effekt auf das Verhalten/Rendering; entweder nutzen (z.B. für Darstellung) oder weglassen.\n- In `Mountain` und `SwissMap` hast du mehrere Imports (`ImageIO`, `BufferedImage`, `IOException`, `Objects`), die nicht verwendet werden – die solltest du entfernen.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface liefert nicht die Informationen, die der `Visualizer` braucht: Es fehlen insbesondere Werte für x/y (Koordinaten), eine Gruppen-Zuordnung (für Farben/Legende) sowie Text für Titel/Detailanzeige beim Hover.\n- Die Methoden im `DataPoint`-Interface sind als `void` definiert und wirken wie “Setter”. Der `Visualizer` muss aber Daten *auslesen* können (also Rückgabewerte bekommen), 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 kann die Visualisierung nicht wie gefordert funktionieren.\n- `Movie`, `Country` und `Processor` implementieren `DataPoint` nicht, dadurch 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 geforderten Achsen-Zuordnungen sind nicht umgesetzt (Movies: Budget→x, Rating→y; Countries: Literacy→x, GDP per capita→y; Processors: Veröffentlichungsmonat kombiniert→x, effektive Geschwindigkeit→y inkl. Log-Skalierung).\n\n### Suggestion\n- Schau dir im `Visualizer` jede Stelle mit `DUMMY_DOUBLE` an und überlege: “Welcher Wert muss hier vom aktuellen `point` kommen?” Daraus ergeben sich ziemlich direkt die Methoden, die im `DataPoint`-Interface fehlen (z. B. x/y).\n- Überlege bei `DUMMY_STRING` getrennt nach Kontext: Einmal wird es für die Legende/Farbgruppen gebraucht (also eine “Kategorie”), einmal für den fetten Titel beim Hover, und einmal für die mehrzeilige Detailbeschreibung (String mit `\\n`), die dann gesplittet wird.\n- Wenn `Visualizer` Informationen anzeigen soll, müssen die `DataPoint`-Methoden Rückgabewerte haben (z. B. `double`/`String`) statt `void`. Prüfe, welche Typen in `Visualizer` weiterverarbeitet werden (Mathe mit `double`, `split(\"\\n\")` mit `String`).\n- Sobald das Interface steht, implementiere es in *allen drei* Datensatzklassen so, dass jede Klasse ihre eigenen Felder passend auf x/y, Gruppe und Text abbildet.\n- Für `VisualizerApp`: Überlege, wie du ein `Movie[]` (bzw. `Country[]`, `Processor[]`) als `DataPoint[]` verwenden kannst, nachdem die Klassen das Interface implementieren.\n- Beim Prozessor-Datensatz: Stelle sicher, dass der x-Wert Jahr und Monat in einen einzigen fortlaufenden Wert übersetzt (sonst sortiert/streut es komisch), und dass die y-Werte für die Darstellung logarithmisch transformiert werden, bevor min/max und Punktposition berechnet werden.\n\n### Code Style\n- Methodennamen im Interface wie `title`, `information`, `secondInfo` sind sehr unspezifisch; außerdem ist unklar, was “secondInfo” bedeutet. Besser ist eine Benennung, die die Rolle in der Visualisierung ausdrückt (Achsenwert, Gruppe, Hover-Titel, Hover-Details).\n- `Map<String, Integer>` für “information” passt schlecht zur Anzeige im GUI, da dort letztlich Strings gezeichnet werden und sogar ein mehrzeiliger String erwartet wird (`split(\"\\n\")`). Das erzeugt unnötige Umwandlung/Unklarheit.\n- Es fehlen die geforderten Javadoc-Kommentare am `DataPoint`-Interface, die das erwartete Verhalten (z. B. Einheiten/Format, `null` erlaubt oder nicht) festhalten.\n",
"status" : "SUCCESS"
}
}