{
"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 Fall, wenn weder vorne noch links noch rechts ein Weg ist: Laut Aufgabe soll die Figur dann „rechtsum kehrt“ machen (180° drehen).\n- In `TryStraightFirst` drehst du bei `pathToTheLeft()`/`pathToTheRight()` nur, gehst danach aber nicht vorwärts; gefordert ist, dass links/rechts „versucht“ wird, d.h. nach dem Drehen auch ein Schritt gemacht wird.\n- `BacktrackingAlgorithm`: Du legst `besucht` als `new boolean[100][100]` an; das ist nicht an die tatsächliche Labyrinth-Grösse gekoppelt und kann bei grösseren Maps zu einem Fehler führen (oder bei kleineren Maps unnötig sein). Aus der Aufgabe folgt, dass es „allgemein“ für die gegebenen Labyrinthe funktionieren soll.\n- `BacktrackingAlgorithm`: Durch das `besucht[row][col]`-Konzept ohne Berücksichtigung der Blickrichtung kann es passieren, dass du Zustände zu früh abschneidest. In einem Labyrinth kann „gleiche Zelle, andere Richtung“ für das weitere Vorgehen relevant sein, du behandelst aber alles als bereits erledigt.\n- `BacktrackingAlgorithm`: Nach einem rekursiven Abzweig führst du immer ein „zurücklaufen“ aus (`turn...`, `moveForward()`, ...), auch wenn in der Rekursion das Ziel bereits gefunden wurde. Dadurch kannst du nach dem Finden des Ziels wieder vom Ziel weggehen und am Ende nicht mehr auf dem Ziel stehen, obwohl `found == true` ist.\n- `BacktrackingAlgorithm`: Die Backtracking-Bewegungen sind nicht in allen drei Fällen symmetrisch korrekt (z.B. im Right-Fall verwendest du zum Zurücklaufen zweimal `turnLeft()`, obwohl du vorher `turnRight()` gemacht hast). Das kann dazu führen, dass du nach dem Zurücksetzen nicht in der ursprünglichen Orientierung/Position landest und der weitere Suchablauf falsch wird.\n\n### Suggestion\n- Für `TryStraightFirst`: Überlege dir eine vollständige `if/else-if/else`-Kette mit genau einem „Zug“ pro Schleifendurchlauf: vorne wenn möglich, sonst links+vor, sonst rechts+vor, sonst 180° drehen.\n- Für `BacktrackingAlgorithm` (Besucht-Struktur): Statt eine fixe 100x100-Matrix zu nehmen, leite die benötigte Grösse aus dem konkreten Labyrinth ab (du kommst über das `Figure`-Interface zwar nicht direkt an `rows/cols`, aber du kannst dir eine andere Strategie überlegen, z.B. eine dynamische Struktur wie `Set` für besuchte Zustände).\n- Für `BacktrackingAlgorithm` (Zustand): Denk darüber nach, ob „besucht“ nur von `(row,col)` abhängen sollte oder ob du `(row,col,dir)` speichern musst, um nicht legitime Wege zu früh zu verwerfen.\n- Für `BacktrackingAlgorithm` (nach Ziel gefunden): Baue an den Stellen direkt nach dem rekursiven Aufruf einen frühen Ausstieg ein (oder prüfe `found`), damit du nach erfolgreichem Finden nicht mehr zurückläufst.\n- Für `BacktrackingAlgorithm` (Zurücksetzen): Prüfe pro Abzweig genau: „Welche Drehung habe ich vor dem Schritt gemacht?“ und „Welche Drehungen brauche ich danach, um wieder exakt die alte Richtung zu haben?“; am einfachsten ist es, eine einheitliche Backtrack-Sequenz zu verwenden: umdrehen, einen Schritt zurück, wieder umdrehen (und ggf. die ursprüngliche Richtung wiederherstellen, wenn du vorher links/rechts gedreht hast).\n\n### Code Style\n- In `BacktrackingAlgorithm` sind Einrückungen/Abstände uneinheitlich (z.B. Klassendeklaration, Felder, Methoden); formatiere konsequent, das macht die Backtracking-Logik deutlich leichter zu prüfen.\n- `System.out.println(figure.isGoalReached());` ist Debug-Ausgabe und gehört in der finalen Abgabe typischerweise nicht in den Algorithmus.\n- Die Variable `besucht` ist deutsch benannt, der Rest ist eher englisch; wähle eine Sprache konsequent (auch Methodennamen wie `checkPath` vs. `besucht`).\n- Mehrfach wiederholte Sequenzen zum Zurücklaufen (zweimal drehen, laufen, zweimal drehen) schreien nach einer kleinen Hilfsmethode (z.B. „goBackOneStep“), damit du Logik nicht an drei Stellen duplizierst und Fehler leichter vermeidest.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `ModeButton.getInteractiveArea(...)` stimmt die interaktive Fläche nicht mit dem gezeichneten Button überein (du zeichnest `65x25`, aber die `Rectangle`-Fläche ist nur `15x15`), dadurch ist der Button nur in einem kleinen Bereich klick-/hoverbar.\n- In `City.getInteractiveArea(...)` ist die interaktive Fläche sehr wahrscheinlich falsch positioniert/grössenmässig unpassend zur gezeichneten Stadt-Markierung (du zeichnest einen Kreis mit Radius `5` um `(x,y)`, aber dein `Rectangle` startet bei `(x,y)` statt um den Mittelpunkt herum zu liegen).\n- Die verwendeten Resource-Pfade für Bilder (`swissmap_img/...`) weichen von den in der Aufgabe/Grundgerüst verwendeten Pfaden ab (`swissmap/...`). Wenn dieser Ordner/ diese Dateien nicht exakt so existieren, werden die Bilder nicht angezeigt.\n\n### Suggestion\n- Mach die `getInteractiveArea(...)` beim `ModeButton` so gross und so positioniert, dass sie exakt den Bereich abdeckt, den du in `draw(...)` als Button zeichnest.\n- Überlege bei `City`: Wenn dein Marker ein Kreis um den Mittelpunkt ist, wie muss dann ein Rechteck liegen (x/y und Breite/Höhe), damit es den Kreis umschliesst statt nur “unten rechts” vom Punkt zu starten?\n- Prüfe, welche Bilddateien im `resources`-Ordner wirklich vorhanden sind und welche Pfade `SwissMap` im Grundgerüst benutzt; passe deine Strings so an, dass sie zu diesen Ressourcen passen.\n\n3. Code Style:\n- In mehreren Klassen sind Imports drin, die du nicht verwendest (z.B. in `Mountain` und `SwissMap`: `ImageIO`, `BufferedImage`, `IOException`, `Objects`; in `SwissMap`: auch `Component` wird nicht gebraucht). Entferne unbenutzte Imports.\n- Vermeide `System.out.println(...)` in GUI-Callbacks/`draw(...)` (z.B. `SwissMap.draw` und `City.onMouseEnter`), das spammt die Konsole und macht das Verhalten unnötig noisy.\n- `clicked` und `hovered` im `ModeButton` werden gesetzt, aber in `draw(...)` nicht genutzt; entweder visuell verwenden (z.B. anderer Look) oder entfernen, damit der Zustand nicht verwirrt.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface liefert dem `Visualizer` nicht die nötigen Informationen: Es fehlen Methoden für die x-/y-Werte (als `double`), die Gruppierung (für Farben/Legende) sowie Titel/Detailtext (für Hover-Anzeige).\n- Die Methoden im `DataPoint`-Interface sind als `void` deklariert und wirken wie “Setter”; der `Visualizer` braucht aber “Getter”-Informationen vom Datenpunkt, um zeichnen zu können.\n- In `Visualizer` wurden die `DUMMY_DOUBLE`/`DUMMY_STRING`-Stellen nicht durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt; damit kann keine korrekte Visualisierung (Min/Max, Punkte, Hover, Legende) entstehen.\n- `Movie`, `Country` und `Processor` implementieren das `DataPoint`-Interface nicht; dadurch kannst du die geladenen Datensätze nicht als `DataPoint[]` an den `Visualizer` übergeben.\n- In `VisualizerApp` wird weiterhin `new DataPoint[0]` verwendet statt einen der Loader (`loadMovies()`, `loadCountries()`, `loadProcessors()`) tatsächlich als Datensatz zu übergeben; so bleibt die Darstellung leer.\n\n### Suggestion\n- Schau dir in `Visualizer` jede Stelle mit `DUMMY_DOUBLE` an und überlege: “Welche Zahl braucht der Visualizer hier konkret?” (z.B. fürs Min/Max die Koordinaten, fürs Plotten die Koordinaten, für Mouse-Hit-Test wieder die Koordinaten). Daraus ergibt sich ziemlich direkt, welche Methoden `DataPoint` anbieten muss.\n- Für jede Stelle mit `DUMMY_STRING` überlege: “Ist das die Gruppenbezeichnung (Legende/Farbe) oder Text für die Hover-Box (Titel + mehrere Zeilen Details)?” Daraus kannst du 2 unterschiedliche String-Lieferanten im Interface ableiten.\n- Wenn du deine `DataPoint`-Methoden formulierst, denke in “Datenpunkt beschreibt sich selbst” (Rückgabewerte), nicht in “Visualizer setzt etwas am Datenpunkt”.\n- Implementiere dann das Interface schrittweise: zuerst nur für `Movie` (x=Budget, y=Rating, Gruppe und Text gemäss Screenshot), dann `VisualizerApp` auf Movies umstellen, erst danach `Country` und `Processor`.\n- Bei Prozessoren: plane für x einen kombinierten Monatswert (Jahr/Monat) und für y eine berechnete Geschwindigkeit; das sind wieder Rückgabewerte aus `DataPoint`, nicht Logik im `Visualizer`.\n\n### Code Style\n- Die Methodennamen im Interface (`title`, `information`, `secondInfo`) sind semantisch unklar und mischen außerdem unterschiedliche Konzepte (Titel vs. Maps). Besser wäre eine kleine, klar benannte Menge an Methoden, die genau das liefern, was der Visualizer an den Dummy-Stellen braucht.\n- `Map<String, Integer>` im Interface ist sehr starr (z.B. Ratings sind `double`, Budgets `long`, Literacy `double`); das führt schnell zu unnötigen Umwandlungen/Informationsverlust und passt nicht gut zur Anzeige-Logik (die eher Strings zeichnet).\n",
"status" : "SUCCESS"
}
}