{
"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 `TryStraightFirst` fehlt der geforderte Fallback: Wenn weder vorne noch links noch rechts ein Pfad ist, soll die Figur „rechts um kehrt machen“ (180° drehen) – dieser Fall wird bei dir nicht behandelt, wodurch die Schleife in Sackgassen hängen bleibt.\n- In `TryStraightFirst` machst du beim Ausweichen nach links/rechts nur einen `turnLeft()`/`turnRight()`, aber keinen Schritt nach vorne im selben Schleifendurchlauf; die Aufgabenbeschreibung verlangt in diesen Fällen explizit „wird links oder rechts versucht“ (also i.d.R. drehen *und* gehen).\n- Dein `BacktrackingAlgorithm` ist nicht an die tatsächliche Labyrinth-Grösse gekoppelt: `besucht` ist fix auf `[100][100][100]` dimensioniert; bei grösseren Maps würde das brechen und bei kleineren ist es willkürlich. Aus den Requirements folgt zwar keine konkrete Maximalgrösse, aber „allgemein für alle diese Labyrinthe“ impliziert, dass du dich an den Map-Dimensionen orientieren solltest.\n- In `BacktrackingAlgorithm` ist die Logik im `else`-Fall (wenn kein Pfad ahead/left/right) widersprüchlich: Du prüfst dort `if(figure.pathAhead())` und bewegst ggf. vorwärts, obwohl du gerade in dem Zweig bist, der impliziert, dass `pathAhead()` zuvor `false` war; das deutet darauf hin, dass dieser Rückwärts-/Backtracking-Schritt so nicht zuverlässig ausgeführt wird.\n- In `BacktrackingAlgorithm` kann das Backtracking die Orientierung/Position nach einem rekursiven Aufruf inkonsistent wiederherstellen (z.B. du drehst manchmal zweimal links, bewegst, drehst wieder zweimal – aber nicht klar abhängig davon, wie du vorher in den Ast reingegangen bist). Damit ist nicht garantiert, dass du nach dem Erkunden eines Astes wieder exakt am selben Knoten mit derselben Blickrichtung bist (was für korrektes Backtracking zentral ist).\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir eine vollständige `if/else-if/else`-Kette mit genau vier Fällen: vorne, sonst links, sonst rechts, sonst 180° drehen. Achte darauf, dass du in den Fällen „links“ und „rechts“ nach dem Drehen auch wirklich einen Schritt ausführst.\n- Für `TryStraightFirst`: Stell sicher, dass in jedem Schleifendurchlauf mindestens eine Aktion passiert (gehen oder drehen), sonst riskierst du Endlosschleifen in Situationen ohne gültige Bewegung.\n- Für `BacktrackingAlgorithm`: Statt ein fixes `100x100x100`-Array zu verwenden, leite die benötigten Dimensionen aus dem Spielfeld ab (Reihen, Spalten und Anzahl Richtungen ist konstant 4). Dazu brauchst du irgendwo Zugriff auf die Map-Grösse oder eine alternative Strategie, die ohne feste Bounds auskommt.\n- Für `BacktrackingAlgorithm`: Formuliere das Backtracking als „Aktion wählen → rekursiv erkunden → Aktion zum Rückgängigmachen“. Dazu hilft es, pro gewählter Bewegung explizit zu speichern/kennen, wie du wieder zurückkommst (z.B. nach `moveForward()` ist „umdrehen, vorwärts, umdrehen“ eine Invers-Operation – aber nur, wenn du davor/danach die Drehungen symmetrisch behandelst).\n- Für `BacktrackingAlgorithm`: Prüfe die Sackgassenbehandlung: In einer echten Sackgasse musst du dich umdrehen und zurückgehen (wenn möglich), nicht nochmal `pathAhead()` erwarten. Ein guter Test ist: Was passiert, wenn du in einer Zelle stehst, wo nur der Weg zurück offen ist?\n\n### Code Style\n- In `BacktrackingAlgorithm` ist `System.out.println(figure.isGoalReached());` Debug-Ausgabe und gehört in der Abgabe typischerweise nicht hinein (und triggert zudem unnötig die GUI-„goal check“-Animation).\n- Einrückungen/Spacing sind teils uneinheitlich (z.B. Klassendeklaration, Blockeinrückungen, Leerzeilen) – ein konsistentes Format macht die Kontrollflusslogik (besonders bei Backtracking) deutlich leichter nachvollziehbar.\n- Variablennamen wie `besucht` sind ok, aber bei einem 3D-Array wäre ein Name, der die Dimensionen klar macht (z.B. visitedByRowColDir), lesbarer.\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/den vorhandenen Ressourcen erwähnt (`resources`-Ordner, z. B. `swissmap/...`). Wenn diese Dateien/Pfade im Projekt nicht genau so existieren, werden die Bilder nicht angezeigt.\n- `ModeButton` zeichnet einen Button mit `65x25`, aber dein `getInteractiveArea` ist nur `15x15` gross. Damit ist ein grosser Teil des gezeichneten Buttons nicht klick-/hoverbar, obwohl er so aussieht, als wäre er interaktiv.\n\n### Suggestion\n- Prüfe, wie die Bilddateien im Projekt wirklich heissen und in welchem Ordner sie liegen (und wie `SwissMap` die Hintergrundbilder lädt). Übernimm für Seen/Berge konsequent denselben Pfad-/Ordnerstil, den die Aufgabe/Map bereits nutzt.\n- Mach die interaktive Fläche des `ModeButton` deckungsgleich mit dem Bereich, den du in `draw` als Button darstellst (Position und Breite/Höhe sollten zusammenpassen).\n\n### Code Style\n- In `Mountain` und `SwissMap` sind Imports/Variablen für `ImageIO`, `BufferedImage`, `IOException`, `Objects` unbenutzt – entfernen.\n- `System.out.println(...)` in `SwissMap.draw` (und `City.onMouseEnter`) ist Debug-Output und sollte für die finale Abgabe weg.\n- `ModeButton` speichert `hovered` und `clicked`, nutzt sie aber nirgends zum Zeichnen/Verhalten; entweder nutzen (z. B. visuelles Feedback) oder entfernen.\n- In `City/Lake/Mountain` ist `toString()` absichtlich menschenlesbar; das Einfügen von `\"\\n\"` macht die Darstellung abhängig davon, ob `drawString` überhaupt Zeilenumbrüche unterstützt. Wenn das GUI keine Multiline-Strings kann, wirkt das wie “kaputtes” Layout.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Dein `DataPoint`-Interface liefert dem `Visualizer` keine Werte für die x- und y-Positionen; ohne solche Methoden kann `findMinMax()`, `plotData()` und die Hover-Erkennung nicht die echten Koordinaten verwenden.\n- `DataPoint` definiert Methoden als Setter (`void title(...)`, `void information(...)`, `void secondInfo(...)`), aber der `Visualizer` braucht Informationen zum Anzeigen/Plotten als Rückgabewerte (Titel/Details/Gruppe/Koordinaten), nicht umgekehrt.\n- In `Visualizer` hast du keine einzige `DUMMY_DOUBLE`/`DUMMY_STRING`-Stelle durch Aufrufe auf das jeweilige `DataPoint point` bzw. `closest` ersetzt; damit bleibt die Visualisierung funktional auf Dummy-Werten stehen.\n- `Movie` implementiert das `DataPoint`-Interface nicht; damit kannst du die geladenen Filme nicht als `DataPoint[]` an den `Visualizer` übergeben, wie es die Aufgabe verlangt.\n- `VisualizerApp` verwendet weiterhin `new DataPoint[0]` statt einen der Loader (`loadMovies()`, später `loadCountries()`, `loadProcessors()`), d.h. es wird nichts visualisiert.\n- `Country` und `Processor` wurden ebenfalls nicht an das `DataPoint`-Interface angepasst/angebunden, obwohl die Aufgabe am Ende verlangt, alle drei Datensätze integrierbar zu machen.\n\n### Suggestion\n- Schau dir im `Visualizer` jede Stelle mit `DUMMY_DOUBLE` an und überlege: Ist das hier die x-Koordinate oder die y-Koordinate des aktuellen `point`? Daraus ergeben sich sehr direkt die benötigten Getter-Methoden im `DataPoint`-Interface.\n- Für jede Stelle mit `DUMMY_STRING` überlege: Wird hier ein Gruppenname (für Farbe/Legendeneintrag), ein Titel (fett beim Hover) oder ein mehrzeiliger Detailtext (split auf `\\n`) gebraucht? Plane dafür passende Rückgabemethoden im Interface.\n- Dein Interface sollte eher “Fragen beantworten” als “Daten gesetzt bekommen”: Entwirf Methoden, die der `Visualizer` aufrufen kann, um Werte zu erhalten.\n- Wenn du `loadMovies()` nutzen willst: Überlege, wie du ein `Movie[]` überhaupt an eine Variable vom Typ `DataPoint[]` zuweisen kannst. Das führt dich direkt dazu, was du an `Movie` ändern musst.\n- Für die Länder/Prozessoren: Leite aus der Aufgabenbeschreibung ab, welche Felder jeweils auf x und y abgebildet werden sollen (und beim Prozessor ggf. die Kombi Jahr/Monat sowie die Rechengeschwindigkeit). Diese Logik gehört in die jeweilige `DataPoint`-Implementierung, nicht in den `Visualizer`.\n\n### Code Style\n- Methodennamen im Interface wie `title(...)`, `information(...)`, `secondInfo(...)` sind semantisch unklar (klingen wie Setter, liefern aber keinen Mehrwert im aktuellen Design); benenne Methoden so, dass klar ist, was zurückgegeben wird.\n- `information(Map<String, Integer> ...)`/`secondInfo(...)` ist als Interface-Vertrag sehr schwer stabil zu halten (Key-Namen, Reihenfolge, Format). Für den `Visualizer` wirkt ein klarer String (z.B. mehrzeilig) oder klar benannte einzelne Werte deutlich wartbarer.\n- Der `import java.util.Map;` in `DataPoint` zwingt alle Implementierer zu dieser Map-Struktur, obwohl der `Visualizer` aktuell gar nicht mit Maps arbeitet (er arbeitet mit Strings und Zahlen).\n",
"status" : "SUCCESS"
}
}