{
"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 in der Aufgabe geforderten Klassen `StupidAlgorithm` und `TryStraightFirst` nicht implementiert (es ist nur `BacktrackingAlgorithm` vorhanden).\n- Dein `BacktrackingAlgorithm` macht beim „Zurückgehen“ nach einem fehlgeschlagenen rekursiven Versuch `figure.moveForward();` ohne vorher zu drehen – dadurch versuchst du weiter vorwärts zu laufen statt auf dem gleichen Pfad zurückzugehen; das kann sehr schnell in ein `GameOver` („Pfad verlassen!“) laufen.\n- Durch `figure.turnLeft()` direkt am Anfang von `navigate` veränderst du die Orientierung bei jedem rekursiven Aufruf zusätzlich; damit ist nicht garantiert, dass du systematisch alle Abzweigungen prüfst bzw. in eine konsistente Ausgangsrichtung zurückkehrst.\n- Deine Schleifenlogik `while (i < 3 ...)` prüft effektiv nur drei Richtungen und enthält keine klare Behandlung für den „vierten Fall“ (bzw. dass du nach dem Durchprobieren wieder in den ursprünglichen Zustand zurückkommst); dadurch kann es passieren, dass nicht alle möglichen Wege korrekt exploriert werden und das Ziel in manchen Levels nicht gefunden wird.\n\n### Suggestion\n- Implementiere zuerst wirklich die zwei einfacheren Algorithmen separat: einer, der nur geradeaus läuft, und einer, der „geradeaus, sonst links, sonst rechts, sonst umdrehen“ macht. Das hilft dir auch, dein Verständnis der Figure-API zu testen.\n- Beim Backtracking: Überlege dir ganz explizit, welche Schritte nötig sind, um nach einem rekursiven „Vorwärts-Schritt“ wieder exakt auf das vorherige Feld zurückzukommen (inkl. Blickrichtung). Prüfe dabei, ob du vor dem Rückweg eine 180°-Drehung brauchst.\n- Achte darauf, dass ein rekursiver Aufruf die Orientierung nicht „kaputt“ macht: Speichere gedanklich (oder strukturell) den Zustand „vor dem Ausprobieren einer Richtung“ und stelle ihn nach dem Versuch wieder her, bevor du die nächste Richtung testest.\n- Statt „3-mal drehen und schauen“: Formuliere für dich eine klare Reihenfolge, in der du alle möglichen Ausgänge eines Feldes testest, und stelle sicher, dass du danach wieder in der Startausrichtung bist (sonst verschiebt sich die Reihenfolge bei jedem Rekursionslevel).\n\n### Code Style\n- Du hast zwei alte Versionen der Methode komplett auskommentiert in der Klasse stehen; das macht die Abgabe unnötig unübersichtlich. Besser: eine finale Version drin lassen, ältere Varianten löschen (oder in Git-History behalten).\n- In deiner Abgabe sind viele Klassen (Figure/Labyrinth/…) nochmals komplett kopiert, obwohl sie zur Vorlage gehören. Üblicherweise gibst du nur die neu erstellten/angepassten Klassen ab (hier v.a. die Algorithmus-Klassen und die kleine Änderung in `LabyrinthApp`).\n- Die Logik in `navigate` ist schwer nachzuvollziehen (z.B. `turnLeft` am Anfang + `i < 3` + Drehen innerhalb der Fälle). Hilfreich wäre, die Schritte in kleinere, klar benannte Hilfsmethoden aufzuteilen (z.B. „tryDirection“, „goBack“), damit man die Invarianten (Position/Richtung) besser überprüfen kann.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` ist die `main`-Methode nicht als Java-Entry-Point deklariert (`public static void main(String[] args)`); so startet das Programm typischerweise nicht automatisch.\n- Aufgabe c) verlangt, dass beim Hover die **Beschreibung angezeigt** wird; in `City`, `Lake` und `Mountain` ändert sich aktuell nur die Darstellung (Grösse/Bild), aber es wird nirgends ein Text mit `toString()` (oder Name/Infos) eingeblendet.\n- Die interaktiven Bereiche (`getInteractiveArea`) sind bei `City`/`Lake`/`Mountain` mit `area` bzw. `height` als Breite/Höhe definiert; diese Werte sind in km² bzw. Metern und passen nicht zu GUI-Pixeln/Skalierung, dadurch ist der Hover-Bereich auf der Karte sehr wahrscheinlich völlig falsch dimensioniert.\n- In `ModeButton.onLeftClick(...)` wird nur umgeschaltet, wenn `onButton` bereits `true` ist; der Click-Handler bekommt aber Koordinaten und die Library entscheidet üblicherweise über `getInteractiveArea`, ob überhaupt geklickt wurde. Das zusätzliche Gate über `onButton` kann dazu führen, dass Klicks nicht reagieren (z.B. wenn nie ein `onMouseEnter` passiert oder die Events anders getriggert werden).\n\n### Suggestion\n- Schau dir an, welche Methodensignatur Java für den Programmeinstieg erwartet, und passe `main` entsprechend an.\n- Nutze deinen `hovering`-Status in `draw(...)`, um beim Hover zusätzlich Text zu zeichnen (z.B. in der Nähe des Objekts oder an einer festen Stelle) – dafür eignet sich die vorhandene `toString()`-Beschreibung.\n- Überlege dir für `getInteractiveArea(...)` eine Grösse in **Pixeln** (und ggf. abhängig von `SwissMap.scale(gui)`), statt Realweltwerte wie km² oder m direkt zu verwenden; orientiere dich an der tatsächlich gezeichneten Marker-/Icon-Grösse.\n- Beim `ModeButton`: Teste, ob das Umschalten auch funktioniert, wenn du dich nur auf die Clickable-Logik mit `getInteractiveArea` verlässt (ohne zusätzliche Abhängigkeit davon, ob gerade `onMouseEnter` war).\n\n### Code Style\n- `ModeButton`: `WIDTH`/`HEIGHT` sollten als `static final` Konstanten benannt werden (z.B. `BUTTON_WIDTH`) und nicht als Instanzfelder, wenn sie sich nie ändern.\n- `ModeButton`: Feld `swissMap` kann `final` sein, weil es nach dem Konstruktor nicht neu gesetzt wird.\n- `City`/`Lake`/`Mountain`: In allen drei Klassen ist sehr ähnliche Hover-Logik dupliziert; langfristig könnte man überlegen, gemeinsame Teile zu kapseln (ist hier aber optional).\n- `SwissMap`: Import `Component` ist vorhanden, wird aber nicht verwendet.\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"
}
}