Huh? Nein. Du sollst die Methode abbrechen solange die Wartezeit nicht um ist. Lies dir am besten mal den in meiner Signatur verlinkten Rubykurs durch.
Huh? Nein. Du sollst die Methode abbrechen solange die Wartezeit nicht um ist. Lies dir am besten mal den in meiner Signatur verlinkten Rubykurs durch.
Ich benutze mal diesen Thread für ein paar kleine Fragen. Gesetzt den Fall ich möchte anstelle des Standardsystems ein eigenes benutzen. Mir wurde empfohlen, die eigenen Variablen als Instanzvariablen einer der bestehenden globalen Variablen (z.B. Game_Party) einzutragen, da diese sowieso schon als Objekt abgespeichert werden und man dadurch Chaos beim Speichern und Laden vermeidet. D.h. also ich müsste nur den Konstruktor von Game_Party etwas umschreiben, oder?
Mal angenommen ich würde ein eigenes Array für das Inventar benutzen. Es liegt ja nahe neue Gegenstände per Push einzufügen (und mit Delete_at zu löschen). Stört das Ruby (in Hinblick auf das Speichern und Laden), wenn ein Objekt im Laufe des Spieles immer weiter anwächst?
Die Charaktere können natürlich auch nicht aus der Datenbank ausgelesen werden, es gibt also eine neue Klasse für sie. Die Gruppe soll aus 3 Charakteren + einem NPC bestehen. Positionen sind immer fest (sprich der erste Charakter ist immer der gleiche usw.) Wie könnte ich nun diese 4 Instanzen der neuen Klasse in Game_Party einbauen?
Nein. Es wird beim Speichern einfach der aktuelle Zustand des Objektes, in deinem Fall ein Array, in die Datei serialisiert. Wenn das Objekt nach dem Laden verändert wird, ist egal. Du musst dir aber im klaren sein, dass beim Deserialisieren eines Objektes (wie z.B. aus einer Datei) der Konstruktor nicht erneut aufgerufen wird.
Wenn du eigene Klassen für die Aktuere erstellst, dann kannst du doch diese einfach fest in das Array der Party speichern. Ich hab den RMXP jetzt gerade nicht bei der hand, also kann ich keine genauen namen Nennen. Aber so etwas in der Art wäre kein Problem
@party bezieht sich dabei auf die Membervariable von Game_Party welche das Array mit den Partymitgliedern beinhaltet. Und NeueActorKlasse ist dann halt einfach die neue Klasse, die du dafür erstellt hast. Stellt sich natürlich die Frage, warum du eine ganz neue Klasse dafür erstellst, und nicht einfach die bestehende erweiterst. Der << Operator für Arrays ist übrigens einfach nur ne andere Schreibweise für Array.push.
--
Was für Probleme könnten dadurch denn entstehen? Wenn ich mir so die Scene_Load-Methode anschaue, werden dort die Objekte ja auch nicht wieder neu initialisiert. Die Initialisierung findet ja nur in Scene_Title statt.Zitat
Ich brauche deren Variablen und Methoden eigentlich nicht. Außerdem möchte ich auf die Objekte ganz anders zugreifen, also die üblichen Makerfunktionen wie Gruppenmitglieder rein/raus usw. werde ich anders lösen. Ok, hauptsächlich weil meine Rubykenntnisse sich arg in Grenzen halten. Andererseits habe ich aber auch keine Lust alles mit den normalen Makervariablen zu lösen, weil es mich stört immer wieder überlegen zu müssen, ob Variable 132 nun die HP oder MP sind.Zitat
Das ist richtig. Beim Deserialisieren (oder unmarshaling, wie Ruby es nennt), werden lediglich die Daten aus einer Datei gelesen, und wieder in ein Objekt gesteckt. In der Regel hat es keinerlei auswirkungen darauf, ob der Konstruktor aufgerufen wird oder nicht, denn die Inhalte stehen ja nun drin, wie sie waren, als sie in die Datei serialisiert wurden. Solltest du jedoch irgendwelche Funktionalität im Konstruktor haben, die über das pure Initialisieren der Werte hinausgeht, und die immer ausgeführt werden soll, wenn ein Objekt erstellt wird, so wird sie beim deserialisieren nicht ausgeführt, da der Konstruktor ja nicht aufgerufen wird. Das stört in den meisten Fällen nicht wirklich, aber ich dachte nur, ich erwähne es einmal.
--