{
"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 weder geradeaus noch links noch rechts ein Pfad existiert, soll die Figur „rechtsum kehrt machen“ (also umdrehen) – dieser Fall fehlt, dadurch kann der Algorithmus in einer Sackgasse stecken bleiben, ohne je das Ziel zu erreichen.\n- `TryStraightFirst` dreht in den Fällen „links“/„rechts“ nur, macht aber in diesem Schleifendurchlauf keinen Schritt nach vorne; gefordert ist: Wenn links oder rechts „versucht“ wird, soll die Figur dann auch tatsächlich dort hineingehen (also nach dem Drehen auch laufen), sonst kann es passieren, dass du unnötig viele Iterationen brauchst bzw. Logik nicht wie beschrieben ist.\n- In `BacktrackingAlgorithm` ist `besucht` als `new boolean[100][100][100]` dimensioniert; das ist nicht an die tatsächliche Labyrinth-Grösse gekoppelt und kann bei grösseren Maps zu Out-of-Bounds führen bzw. ist bei kleineren Maps unnötig. (Die Aufgabe erwartet einen allgemeinen Algorithmus für „alle diese Labyrinthe“.)\n- `BacktrackingAlgorithm` speichert `currentPath.add(besucht)` – du fügst dabei immer dasselbe 3D-Array-Objekt hinzu, nicht „den aktuellen Schritt“; das kann dein Backtracking-Konzept aushebeln, weil die Liste dadurch keine echte Pfadhistorie enthält.\n- In `LabyrinthApp` hast du die vorgegebenen `MAPS` verändert; damit erfüllst du die Übungsanforderung nicht, die Levels aus der Vorlage zu lösen (insbesondere „letzte Levels“ mit Backtracking).\n\n### Suggestion\n- Überlege bei `TryStraightFirst` eine klare Reihenfolge pro Schleifendurchlauf: prüfen → ggf. drehen → dann auch wirklich vorwärts gehen; und definiere explizit, was passiert, wenn alle drei Richtungen blockiert sind (U-Turn).\n- Für den U-Turn-Fall: denke daran, dass „rechtsum kehrt“ einer 180°-Drehung entspricht (zwei gleiche Drehungen), und dass danach der nächste Schritt wieder sinnvoll sein muss.\n- Für `BacktrackingAlgorithm`: dimensioniere „besucht“ anhand von `row/col`-Werten, die tatsächlich vorkommen (oder anhand der Map-Grösse, falls du sie irgendwoher bekommst), statt fix 100 zu nehmen.\n- Wenn du einen Pfad-Stack/`currentPath` nutzen willst, speichere darin Informationen, die sich pro Schritt unterscheiden (z.B. Position+Richtung oder die getroffene Entscheidung), nicht das gesamte `besucht`-Array.\n- Lass die vorgegebenen Maps unverändert und teste deinen Algorithmus genau damit; wenn es dann crasht oder hängt, ist das ein wertvoller Hinweis, an welcher Backtracking-Stelle deine Rückwärtsbewegung/Orientierung nicht korrekt wiederhergestellt wird.\n\n### Code Style\n- In `BacktrackingAlgorithm` sind mehrere `System.out.println` Debug-Ausgaben drin; die sollten für die Abgabe entfernt oder mindestens über einen Debug-Flag steuerbar sein.\n- `BacktrackingAlgorithm`: `ArrayList<Object>` ist sehr unspezifisch; wenn du wirklich etwas speichern willst, gib der Liste einen passenden Typ (damit man versteht, was drin ist).\n- Einrückung/Whitespace ist teils uneinheitlich (z.B. fehlende Einrückung bei Feldern/Methoden in `BacktrackingAlgorithm`), was das Lesen deutlich erschwert.\n- `currentPath` wird zwar manipuliert, aber sein Inhalt wird nicht sinnvoll genutzt; das wirkt wie „toter“ bzw. unfertiger Code.\n\n\n# Exercise: swissmap\n\n### Correctness\n- In `SwissMapApp` war in der Vorlage eine `main`-Methode mit Signatur `public static void main(String[] args)` gefordert; du hast zwar jetzt so eine, aber falls im restlichen Projekt noch die alte `void main()`-Variante existiert/benutzt wird, startet die App evtl. nicht wie erwartet.\n- `ModeButton` zeichnet einen Button mit `65x25`, aber `getInteractiveArea` ist nur `15x15` gross; dadurch ist ein grosser Teil des sichtbaren Buttons nicht anklick-/hoverbar.\n- Bei `City`, `Lake` und `Mountain` liegen Zeichnung und interaktive Fläche nicht wirklich deckungsgleich: du zeichnest z.B. den City-Kreis mit Radius `5`, aber das Rectangle startet genau bei `(x,y)` und geht `5x5` nach rechts/unten (der Kreis liegt aber um den Mittelpunkt). Dadurch wird Hovering/Klicken an der “sichtbaren” Stelle teilweise nicht ausgelöst.\n- Du verwendest für die Icons/Backgrounds Pfade wie `swissmap_img/...`, während in der Aufgabenbeschreibung explizit der `resources`-Ordner und in der vorhandenen `SwissMap`-Implementierung Pfade `swissmap/...` genutzt werden; wenn die Dateien in deinem Projekt nicht exakt so heissen/liegen, wird nichts angezeigt.\n\n### Suggestion\n- Prüfe, welche `main`-Signatur der Autograder/Startmechanismus erwartet, und stelle sicher, dass genau diese existiert und verwendet wird.\n- Leite die Breite/Höhe von `getInteractiveArea` direkt aus dem, was du in `draw` als Button-Fläche zeichnest, ab (gleiche Position und gleiche Dimensionen).\n- Überlege dir bei City/Lake/Mountain, ob dein `Shape` die gleiche Geometrie beschreibt wie das sichtbare Objekt (z.B. Mittelpunkt vs. linke obere Ecke; Radius vs. Rechteckbreite). Zeichne dir gedanklich das Koordinatensystem: Was bedeutet `(x,y)` bei `drawCircle` vs. bei `Rectangle`?\n- Vergleiche deine Ressourcenpfade mit den tatsächlich vorhandenen Dateien im Ressourcenordner und mit dem, was im bereitgestellten `SwissMap` schon funktioniert, und passe es konsistent an.\n\n### Code Style\n- Entferne Debug-Ausgaben wie `System.out.println(satelliteMode)` in `SwissMap.draw` und `System.out.println(getInhabitants())` in `City.onMouseEnter`, sonst spammt die Konsole bei jedem Frame/Mouse-Event.\n- In `ModeButton` sind die Felder `hovered` und `clicked` aktuell ohne Effekt (hovered wird nie fürs Zeichnen genutzt, clicked wird nirgends gebraucht) – entweder verwenden oder löschen.\n- In `Mountain` (und auch `SwissMap`) hast du Imports für `ImageIO`, `BufferedImage`, `IOException`, `Objects`, die nicht verwendet werden.\n- In `Lake`/`Mountain`: das `image`-Variable-Setzen könntest du klarer strukturieren (nicht erst zeichnen und dann im Hover-Fall nochmal zeichnen), damit weniger doppelte Logik entsteht.\n\n\n# Exercise: visualizer\n\n### Correctness\n- Das `DataPoint`-Interface enthält keine Methoden, mit denen der `Visualizer` die nötigen Werte für die Achsen (x/y) abfragen kann; damit können die `DUMMY_DOUBLE`-Stellen in `Visualizer` nicht sinnvoll ersetzt werden.\n- Das `DataPoint`-Interface enthält keine Methode für Gruppierung/Kategorie (für Farben & Legende); damit können die `DUMMY_STRING`-Stellen in `collectGroups()`, `plotData()` und `drawHighlighted()` nicht ersetzt werden.\n- In `Visualizer` wurden die `DUMMY_DOUBLE`/`DUMMY_STRING`-Platzhalter nirgends durch Aufrufe auf das jeweilige `DataPoint`-Objekt ersetzt (z.B. in `findMinMax`, Distanzberechnung, Plotten, Highlight-Text).\n- Keine der Datenklassen (`Movie`, `Country`, `Processor`) implementiert `DataPoint`; dadurch kannst du die geladenen Datensätze nicht als `DataPoint[]` an den `Visualizer` übergeben.\n- `VisualizerApp` verwendet weiterhin `new DataPoint[0]` statt einen echten Datensatz aus `loadMovies()` / `loadCountries()` / `loadProcessors()`.\n\n### Suggestion\n- Schau im `Visualizer` systematisch jede Stelle an, wo `DUMMY_DOUBLE` steht: Das sind genau die numerischen Informationen, die ein Punkt liefern muss (typischerweise x- und y-Wert). Überlege dir pro Stelle: „Welcher Wert des aktuellen `point`/`closest` gehört hier hin?“ und leite daraus passende *Getter*-Methoden im Interface ab.\n- Mach das gleiche für jede `DUMMY_STRING`-Stelle: Einmal geht es um die Gruppierung (Legende/Farbe), einmal um den Titel im Hover, und einmal um den mehrzeiligen Detailtext (`split(\"\\n\")`). Überlege dir, ob das Interface dafür getrennte Methoden braucht (z.B. „group“, „label/title“, „details“).\n- Deine aktuellen Interface-Methoden sind als `void` definiert und nehmen Daten entgegen; der `Visualizer` braucht aber Daten *vom* Datenpunkt. Denk also eher an Methoden, die Werte **zurückgeben**, statt Methoden, die etwas „setzen“.\n- Sobald das Interface steht, erweitere zuerst **eine** Klasse (z.B. `Movie`), damit sie `DataPoint` implementiert, und mappe dabei die in der Aufgabe geforderten Attribute auf x/y (Budget/Rating) sowie auf die Anzeige-Strings (Titel/Details/Gruppe).\n- In `VisualizerApp`: Überlege, wie du ein `Movie[]` (oder `Country[]`, `Processor[]`) als `DataPoint[]` verwenden kannst, sobald die Klassen `DataPoint` implementieren. Danach kannst du testweise erst Movies, dann Countries, dann Processors anschliessen.\n\n### Code Style\n- Das `DataPoint`-Interface importiert `Map`, und die Methoden nutzen `Map<String, Integer>`/`Map<String,Integer>` inkonsistent formatiert; zudem wirkt das für die Visualisierung unnötig kompliziert (und bleibt ungenutzt).\n- Methodennamen im Interface (`title`, `information`, `secondInfo`) sind sehr unspezifisch; bei Interfaces hilft es, wenn Namen genau ausdrücken, was geliefert wird (insbesondere weil der `Visualizer` sie an vielen Stellen verwendet).\n- Es fehlen die geforderten Javadoc-Kommentare auf den Interface-Methoden (erwartetes Verhalten/Format, z.B. ob der Detailtext Zeilenumbrüche enthält).\n",
"status" : "SUCCESS"
}
}