Integer aus Textdatei auslesen

[quote=FranzFerdinand]Also, mein Code an dieser Stelle sieht nun folgendermaßen aus:

      jListGastkartenModel.clear();
      Geschlecht.valueOf("männlich");
      Geschlecht.valueOf("weiblich");
      Land.valueOf("Deutscher");
      Land.valueOf("Franzake");
      Land.valueOf("Brite");
      Land.valueOf("Amerikaner");
      Land.valueOf("Türke");
      Land.valueOf("Inder");
      Land.valueOf("Chinese");
      Land.valueOf("Russe");
      Land.valueOf("Spanier");
      Land.valueOf("Kubaner");
      Land.valueOf("Afrikaner");
      Land.valueOf("Italiener");
      Land.valueOf("Joker");
      for (int n=0;n<restkartengast;n++) {
            String gastkartewiederhergestellt = spielstand.getProperty("gastkarten" + n);
            String[] einzelkarte = gastkartewiederhergestellt.split(":");
            System.out.println(einzelkarte[0]);
            System.out.println(einzelkarte[1]);
           
            for(Land land : Land.values()) {
                for(Geschlecht geschlecht : Geschlecht.values()) {
                    gastkarten.add(new Gastkarte(geschlecht, land));
                }
            }
      }
      for(int y=0;y<gastkarten.size();y++){
            jListGastkartenModel.addElement(gastkarten.get(y));
        }
      System.out.println("Ein altes Spiel wurde wiederhergestellt");```
[/quote]
Was bezweckst Du mit dem Code? Ist Dir bewusst was hier passiert?
Zeile 2 bis 17 sind eigentlich überflüssig, da sie nichts bewirken.
Die Information aus Zeile 19 und 20 wird auch nur dafür genutzt, um sie auf der Konsole auszugeben.

Mit den drei ineinander verschachtelten Schleifen erzeugst Du restkartengast * Land.values().length * Geschlecht.value().length Gastkarten. Das ist zumindest ein Grund warum die Liste soviele Elemente enthält.

(Beitrag vom Verfasser gelöscht)

[quote=FranzFerdinand]Und ich habe ehrlich gesagt nach wie vor keine Idee, wie ich der list Gastgarten die Info übergeben kann, dass diese 100 Karten aus der Speicherdatei wiedereingefügt werden sollen.[/quote]Darüber hatten wir doch schon gesprochen und Du hast behauptet, dass Du die Karten programmatisch erzeugts.

Also sind nicht die Karten aus der Datei zu laden, sondern deren Zuordnung zu den Spielern.

Leider konnte ich Deinen Codegewirr nicht entnehmen, wie Du diese Zuordnug in Deinem Programm realisierst. Und ich denke, dass hier auch Dein Haupt-Problem liegt: Du hast eine Vorstellung davon, wie Dein Spiel auf dem Bildschirm aussehen soll. Was Du nicht hast ist ein Plan, welche Objekte in Deinem Spiel existieren und wie diese miteinander in Beziehung stehen.

Momentan bist Du in Deiner “Lösung” festgefahren. Wenn Du so weiter machst wirst Du Dein Projekt nicht fertig bekommen.

Auch wenn es hart ist: Vergiss was Du bisher hast und fang noch mal sauber mit den Grundlagen an. Konzentriere Dich zunächst auf das Modell (also die Spieler und die Karten und deren Interaktionen) ohne an die GUI zu denken.

Wenn die “Engine” funktioniert kannst Du an Speichern/Laden und Visualisierung arbeiten.

bye
TT

denke nicht in abstrakten Zauber-Sphären, sondern ganz ordinär, was leisten diese Zeilen?
was ist der Unterschied von vorher zu nachher?
direkt eine lokale Variable ist ja nicht beteiligt,
sollte sich in der Enum-Klasse was ändern, die Enum-Werte initialisiert werden oder so?
nein, es passiert exakt nichts dauerhaftes

an der Stelle, an der du Strings einliest und Enum-Werte für den Konstruktor haben willst, da machst du dagegen nichts,
was haben Codezeilen irgendwo anders im Programm damit zu tun? (außer mal wichtiges wie überhaupt Definition der Klassen)

es würde dir in der Schleife ja auch nicht helfen wenn du irgendwo anders einmal String.split() ausprobierst…
einfaches Bauen: dort wo du den String hast, dort musst du diesen konkreten String umwandeln in einen Enum-Wert, diesen für den Konstruktor verwenden

            String gastkartewiederhergestellt = spielstand.getProperty("gastkarten" + n);
            String[] einzelkarte = gastkartewiederhergestellt.split(":");
            System.out.println(einzelkarte[0]);
            System.out.println(einzelkarte[1]);
            Geschlecht g = Geschlecht.valueOf(einzelkarte[0]);
            Land l = Land.valueOf(einzelkarte[1]);
            gastkarten.add(new Gastkarte(g, l));
      }

die inneren Schleifen waren genauso verrückt, über so einfache Dinge musst du einen klaren Kopf behalten,
eine Schleife ist natürlich nicht undenkbar wenn sie einen Zweck hat:
gäbe es etwa die valueOf-Methode nicht, dann könntest du tatsächlich über alle Enum-Werte iterieren,
Strings vergleichen und so den Enum-Wert heraussuchen, der aktuell benötigt wird,
die valueOf-Methode macht das intern auf falls nicht mit Map noch besser gelöst

das wäre eine Schleife mit klarer Aufgabe und klarem Code (oder mit Fehler und dran zu arbeiten),
aber eine Schleife über alle bekannten Werte und damit Gastkarte-Objekte zu erstellen, ohne Bezug auf aktuellen Property, das ist Unsinn,

passiert natürlich, nicht schlimm, aber bitte den Unterschied zu normalen Programmierfehlern erkennen,
beliebig Code aneinanderreihen ist kein erlaubtes Konzept

(Beitrag vom Verfasser gelöscht)

[quote=FranzFerdinand]Das ist mein Endcode, den ich noch dahinter gebastelt habe:

    jListGastkartenModel.addElement(gastkarten.get(y));
}```

Der ist auch schon generell beim Gastkarten mischen dabei, der fügt das Zeuchs aus der List einfach in Reihenfolge in die jList ein. So läuft das ganze nun.[/quote]
Auch wenn's jetzt läuft noch ein Hinweis zum obigen Code:
Wenn Du das direkt beim Befüllen der ArrayList machst, kannst Du Dir die zweite Schleife sparen. Wenn Du die ArrayList in dem Fall nur zum Befüllen benötigst, könnte man sich auch die ArrayList bzw. deren Befüllen sparen.

(Beitrag vom Verfasser gelöscht)

allgemein ist die längere Variante aber auch nicht zu verachten:
Aufgaben trennen, das Einlesen von der Datei muss nicht mit der GUI verknüpft sein,
gerade zum Testen kann der Aufrufer einer solchen Methode System.out.println() verwenden :wink: oder eine Test-Klasse sein

an das JList-Model will man vielleicht nicht nur Daten aus Datei sondern auch direkt generierte Liste übergeben,
in solch aufgeräumten Fällen mit getrennten Methoden kommt es auf eine Schleife mehr oder weniger nicht an,
einfache Listen zur Übertragung eine gute Sache dann

(Beitrag vom Verfasser gelöscht)

Dass die Klasse von CafeRoot erbt und dann nur statische Methoden besitzt, schaut ganz schon gefährlich aus. Da müsste einiges aufgeräumt werden.
Direkte Hilfestellung kann ich so spontan nicht geben, außer den Hinweis, dass wenn eine Variable nicht aufgelöst werden kann, dann liegt es daran, dass die Variable im Gültigkeitsbereich des Codes nicht bekannt ist. Das war bei Deinem Code bereits mehrfach der Fall. Vielleicht mal grundsätzlich mit dem Thema beschäftigen?

[quote=FranzFerdinand]Explizit überall wo neuesspiel.getProperty steht, da kann er neuesspiel nicht auflösen.
Dieses ist aber in der Methode eigentlich so definiert.[/quote]
Methoden sind keine direkt einzufügenden Codezeilen die nur im Moment woanders stehen,
da sähe man ja überhaupt nicht durch, vielleicht noch

double betrag = 100;
updateGUI();
ueberweiseAnXy(betrag); // Methode hat betrag auf 300.000 geändert..

ok, in gewisser Form gibt es das, mit Instanzattributen,
wäre betrag ein solches statt lokaler Variable, dann änderbar,
sogar nicht nur durch eigene Untermethodenaufrufe sondern beliebig nebenläufig durch andere Threads,

naja, eins nach dem anderen, Instanzattribute hast du gar nicht, auch ok sofern noch nicht benötigt

die Untermethode kann Zeile 27-35 haben und Properties statt void als Rückgabewert definieren und return neuesspiel;
und der Aufrufer schreibt Properties neuSpiel = readNeuesSpiel();

Methoden gleich sinnvoll benennen,
und je nach Gesschmack gibt es mehr oder weniger Verwirrung, wenn man in verschiedenen Methoden unterschiedliche Variablennamen vergibt statt alles ‘neuesspiel’ zu nennen,
lokale Variablen sind jeweils eigenständig, auch wenn sie auf dieselben Objekte im Speicher zeigen sollten

(Beitrag vom Verfasser gelöscht)

wie du die Methoden aufrufst schreibst du nicht eindeutig, daher unbekannte Fehlerursache, die durch Code vollkommen bekannt wäre…

den Andeutungen nach ist aber zu vermuten, dass du als Aufruf-Codezeile tatsächlich nur reader(); hast,
also das komplette aktuelle Thema, Implementierung und auch NUTZUNG des Rückgabewertes ignorierst,
ebenso wie die von mir gepostete FERTIGE Code-Zeile beim Aufrufer

→ nur dann nämlich ist beim Aufrufer eine Properties-Variable mit dem dort gewählten Namen bekannt

wenn real, dann bemerkenswert unproduktiv,
meine allgemeinen Befürchtungen gehen bei sowas immer Richtung Troll…,
nimm es als Feedback hin und gelobe insgeheim Besserung wenn nicht Troll

SlaterBs Anmerkungen ist eigentlich nichts hinzuzufügen, da potentiell Fehler verursachender Code nicht gepostet.

Ich gehe mal von Nicht Troll aus.
Zum geposteten Code:
Es ist eigentlich Blödsinn zwei Methoden zu schreiben, die dasselbe machen. Doppelten Code solltest Du nach Möglichkeit vermeiden.
Definiere eine wiederverwendbare Methode:

        Reader reader = new BufferedReader(new FileReader(filename));
           Properties prop = new Properties();
           try {
             prop.load(reader);
           }catch(FileNotFoundException ex){
              ex.printStackTrace();
              System.out.println("Die Datei " + filename + " existiert nicht!");
           }
           reader.close();
           return prop;
    }```

Und nutze sie an passender Stelle z.B. `Properties neuesSpiel = loadProperties("neuesspiel.txt");` bzw. `Properties spielstand = loadProperties("spielstand.txt");`

Dann noch allgemein: Ist es das Ziel das Spiel "Cafe International" komplett in Java abzubilden? Das wäre nach drei Monaten Schulunterricht Java mehr als wagemutig. Zumal es schon mit so einfachen Sachen Probleme gibt und sofern Schulunterricht überhaupt Wissen vermitteln kann, das Wissen für so ein Spiel nach drei Monaten nicht vorhanden sein kann.

Warum nicht etwas einfachere Spiele z.B. Tic Tac Toe?

(Beitrag vom Verfasser gelöscht)

Lebt @SlaterB noch? Und wer war @_Michael? Ich doch nicht.