{
"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- Du hast die geforderten Klassen `StupidAlgorithm` und `TryStraightFirst` nicht implementiert; damit sind Teil (a) und (b) der Aufgabe nicht erfüllt.\n- In deinem `BacktrackingAlgorithm` wird beim „Zurückgehen“ nach einem rekursiven Aufruf (wenn das Ziel nicht erreicht wurde) `moveForward()` aufgerufen, ohne vorher die Richtung um 180° zu drehen; damit bewegst du dich typischerweise weiter vorwärts statt zurück und riskierst so „Pfad verlassen!“ bzw. falsches Backtracking-Verhalten.\n- Dein `BacktrackingAlgorithm` prüft beim Ausprobieren von Richtungen effektiv nur bis zu 3 Orientierungen und macht keine saubere „alle Möglichkeiten probieren“-Logik inkl. korrektes Zurücksetzen von Position *und* Richtung nach einem fehlgeschlagenen Zweig; dadurch ist es nicht garantiert, dass er „für alle diese Labyrinthe funktioniert“ wie gefordert.\n\n### Suggestion\n- Für (a) und (b): Schau dir die Beschreibung genau an: Ein Algorithmus soll stumpf nur geradeaus laufen bis zum Ziel; der andere soll in jeder Iteration in der Reihenfolge „ahead, left, right, sonst umdrehen“ entscheiden. Implementiere diese beiden wirklich als eigene Klassen, auch wenn du am Ende in der App den besseren Algorithmus verwendest.\n- Für Backtracking: Überlege dir, was „zurückgehen“ im Labyrinth konkret bedeutet: Du musst nach dem Rekursions-„Versuch“ wieder **auf das vorherige Feld** zurück und dabei auch die **Ausrichtung** wieder in einen konsistenten Zustand bringen, bevor du die nächste Richtung testest.\n- Für „alle Richtungen testen“: Eine robuste Strategie ist, an einer Kreuzung systematisch jede mögliche Abzweigung auszuprobieren und nach jedem Fehlschlag exakt zum Ausgangszustand (Feld + Blickrichtung) zurückzukehren, bevor du die nächste Option nimmst.\n\n### Code Style\n- Du hast mehrere auskommentierte „Versionen“ im Code gelassen; entscheide dich für eine Variante und entferne den Rest (oder nutze Versionskontrolle/Git für Historie).\n- In `navigate` ist die Logik durch verschachtelte `if`/`while` plus Rekursion schwer nachzuvollziehen; benenne Teilschritte (z.B. „tryDirection“, „turnAround“, „stepBack“) als Hilfsmethoden, damit klarer wird, was passiert.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp`, deine `main`-Methode hat die Signatur `void main()`. So wird sie als Programmeinstieg typischerweise nicht aufgerufen; gefordert ist eine `main`-Methode als Einstiegspunkt.\n- In Teil c) sollen beim Hover *die Beschreibung(en)* angezeigt werden; in `City`, `Lake` und `Mountain` änderst du beim Hover nur die Darstellung (Grösse/Bild), aber zeichnest nirgends den Text (z. B. `toString()`).\n- Deine `getInteractiveArea(...)`-Implementationen verwenden `area` (bei `City`/`Lake`) bzw. `height` (bei `Mountain`) direkt als Breite/Höhe eines `Rectangle`. Diese Werte sind in km² bzw. Metern und passen nicht als Pixel-/GUI-Grössen; dadurch wird die Hover-Fläche sehr wahrscheinlich völlig falsch gross.\n- Bei `City.draw(...)` verwendest du `gui.getWidth()` zur Radius-Berechnung. Dadurch hängt die Punktgrösse vom Fensterformat ab, nicht von der Karten-Skalierung (und wird bei breiten Fenstern extrem gross).\n\n### Suggestion\n- Schau dir an, welche `main`-Signatur Java als Einstiegspunkt erwartet (inkl. `static` und Parameter) und passe deine Methode entsprechend an.\n- Du hast bereits ein `hovering`-Flag und sinnvolle `toString()`-Texte: nutze `hovering` in `draw(...)`, um bei Hover zusätzlich Text in der Nähe des Objekts zu zeichnen (z. B. leicht versetzt zur Koordinate).\n- Überlege dir für `getInteractiveArea(...)` eine sinnvolle *konstante GUI-Grösse* (oder eine, die mit `SwissMap.scale(gui)` skaliert), statt reale Weltgrössen (km²/m) direkt zu verwenden.\n- Für die Grösse von Stadtpunkten: orientiere dich eher an der Karten-Skalierung (`SwissMap.scale(gui)`) oder einer festen Pixelgrösse statt an `gui.getWidth()`.\n\n### Code Style\n- Verwende konsistent `private final` für Konstanten: In `ModeButton` sollten `WIDTH` und `HEIGHT` als `private static final` Konstanten deklariert werden (und typischerweise Grossbuchstaben sind ok, aber dann auch wirklich konstant).\n- In `ModeButton` ist `swissMap` nie neu zugewiesen: markiere es als `final`, das macht die Absicht klarer.\n- Vermeide Wildcard-Imports (`import ch.trick17.gui.component.*;`) in `ModeButton`; importiere nur die Klassen, die du wirklich brauchst, für bessere Lesbarkeit.\n\n\n# Exercise: visualizer\n\nLlm Evaluation ist für diese Aufgabe deaktiviert. Entferne die .llmignore Datei vom Package der Aufgabe.\n",
"status" : "SUCCESS"
}
}