(NEU: Heilfunktion) RMSaveAnywhere - in jedem Spiel überall speichern & heilen

[Cherry]

Hallo,

mir ist bewusst, dass nicht alle Leute dieses Programm begrüßen werden. Manche werden aber sehr froh darüber sein.

Und zwar gibt immer wieder Leute wie mich, die es hassen, nicht jederzeit speichern zu können. Dieses Tool ermöglicht nun, in jedem beliebigen RM2k(3)-Spiel zu jeder beliebigen Zeit das Spiel zu speichern.

Einfach saveanyw.exe öffnen - es erscheint ein Disketten-Icon im Systemtray - und dann Spielen. Während des Spiels ruft F11 das Speichermenü auf. Mir ist bekannt, dass nach dem Speichern (oder beim nächsten normalen Speichern) ein schwarzer Bildschirm erscheinen kann - in diesem Fall einfach Shift+F11 drücken und das Problem ist beseitigt.

Update: Neue Features! Man kann jetzt mit Alt+F11 das Spielmenü aufrufen auch wenn es deaktiviert ist (auch hierfür gilt die Info mit Shift+F11 bei schwarzem Bildschirm), sowie eine komplette Heilung mit Strg+F11 durchführen!

Btw: Um eine andere F-Taste statt F11 zu belegen, einfach mit Parameter /F1, /F2, ... starten.

Download: http://cherrytree.at/downloads/saveanyw.rar

mfG Cherry

[G-Brothers]

Manche, wie ich, machen stationäre Speicherpunkte aber nicht, weil es "professioneller" wirken soll,
sondern weil es Bugs auslösen kann, wenn man die Möglichkeit hat, an jeder Position zu speichern. Bei mir ist das jedenfalls so
bei einer Map, in der sich an bestimmten Stellen das Chipset ändert: Speichert man dann einfach ab und verlässt
das Spiel, ist dann beim Laden des Speicherstandes das ursprüngliche Chipset drin, und man ist im schlimmsten Falle in einem
Mapbereich gefangen. "Chance Event Location" wird nach einem Neustart Blöderweise auch zurückgesetzt, was dann ähnliche Probleme
hervorruft.
Also wäre das bei meinem Spiel z.B. ziemlich Fehl am Platz, es sei denn es ist eine andere Möglichkeit zu speichern, also wie ein "Save State".

[netwarrior]

Hallo Cherry,
das Script funzt bei mir auf dem Rm2k. Klasse!
Nur erscheint danach bei mir dieser schwarze Bildschrim.
Kann man denn nicht immer nach dem Speichern die Shift+F11 abfrage machen?

Grüße
netwarrior

[Davy Jones]

Kann G-Brothers nur zustimmen, die Nutzung ist einfach zu fehlerintensiv.

Ich persönlich kann deshalb leider nichts damit anfangen.

[Cherry]

Hallo Cherry,
das Script funzt bei mir auf dem Rm2k. Klasse!
Nur erscheint danach bei mir dieser schwarze Bildschrim.
Kann man denn nicht immer nach dem Speichern die Shift+F11 abfrage machen?

Grüße
netwarrior

...

Nein, weil das Ding nicht weiß wann du mit Speichern fertig bist.

Manche, wie ich, machen stationäre Speicherpunkte aber nicht, weil es "professioneller" wirken soll,
sondern weil es Bugs auslösen kann, wenn man die Möglichkeit hat, an jeder Position zu speichern. Bei mir ist das jedenfalls so
bei einer Map, in der sich an bestimmten Stellen das Chipset ändert: Speichert man dann einfach ab und verlässt
das Spiel, ist dann beim Laden des Speicherstandes das ursprüngliche Chipset drin, und man ist im schlimmsten Falle in einem
Mapbereich gefangen. "Chance Event Location" wird nach einem Neustart Blöderweise auch zurückgesetzt, was dann ähnliche Probleme
hervorruft.
Also wäre das bei meinem Spiel z.B. ziemlich Fehl am Platz, es sei denn es ist eine andere Möglichkeit zu speichern, also wie ein "Save State".

...

Interessant. Eigentlich sieht es im Makercode so aus als würden einfach die aktuellen Mapdaten, inkl. Chipset und Positionen der Events gespeichert. Ich hatte keine Ahnung dass das nicht wirklich passiert O_o

EDIT: Vllt sollte ich mal wirklich eine andere Speichermöglichkeit bauen... wie die Leute im RMN vorgeschlagen haben: Savestate-like. Wobei ich jetzt nicht weiß wie kompliziert das würde...

[MagicMaker]

EDIT: Vllt sollte ich mal wirklich eine andere Speichermöglichkeit bauen... wie die Leute im RMN vorgeschlagen haben: Savestate-like. Wobei ich jetzt nicht weiß wie kompliziert das würde...

...

Im RPG_RT-Mod Fatal Mix gibt es neben dem ganzen anderen Gedöhns eine Savestate-Funktion,
mit der auf simplen Tastendruck sofort ein temporärer State geladen oder gespeichert werden kann.
Meinem Gedächtnis nach erfolgt das alles ohne irgendwelche Ladezeiten oder Ausblendungen.

Wie, wo und in welchem Umfang der nun genau angelegt wird und tauglich ist, das weiss ich nicht.

[Cherry]

Naja die funktioniert afaik genauso wie das normale Save/Load, oder?

[Das'O']

Für mich ist das Programm interessant. Es kommt öfters mal vor, dass ich ein Spiel schnell beenden muss, weil plötzlich etwas Wichtiges zu tun ist, was einen Reboot erfordert (der Fluch, ein Multi-Boot-System zu besitzen). Das ist auch der Grund dafür, dass ich keine Speicherpunkte mag. Wenn, wie von G-Brothers erwähnt, sich durch Verwendung dieses Programmes ein Bug ins Spiel einschleichen kann, kann ich ja einfach einen Speicherplatz für solche "Schnell-Saves" reservieren. Wenn dann etwas schiefgeht, habe ich ja immer noch die regulären Speicherstände.

Also: Ein nützliches Tool. Auch wenn es vielleicht in einigen Fällen nicht funktioniert. Danke schön, Cherry.

[[KoA-Angel]]

...
Interessant. Eigentlich sieht es im Makercode so aus als würden einfach die aktuellen Mapdaten, inkl. Chipset und Positionen der Events gespeichert. Ich hatte keine Ahnung dass das nicht wirklich passiert O_o

....

...

Tut es ja auch.
Das eigentliche Problem mit dem freien Speichern, das ich auch schon mal hatte ist, dass evtl parallel laufende Events oder Common Events nach dem Laden von vorne gestartet werden und nicht an der Stelle weiterlaufen, an der das speichern erfolgte, was zu Bugs führen kann.

[Das'O']

Tut es ja auch.
Das eigentliche Problem mit dem freien Speichern, das ich auch schon mal hatte ist, dass evtl parallel laufende Events oder Common Events nach dem Laden von vorne gestartet werden und nicht an der Stelle weiterlaufen, an der das speichern erfolgte, was zu Bugs führen kann.

...

Für mich klingt das erstmal nach Designfehler im Event, dem zB durch das Setzen/Ändern einer Variable an geeigneter Stelle abgeholfen werden könnte. Aber vielleicht denke ich auch einfach nur zu simpel. Hättest Du mal ein konkretes Beispiel?

[makenshi]

Für mich klingt das erstmal nach Designfehler im Event, dem zB durch das Setzen/Ändern einer Variable an geeigneter Stelle abgeholfen werden könnte. Aber vielleicht denke ich auch einfach nur zu simpel. Hättest Du mal ein konkretes Beispiel?

...

Nein, du denkst völlig richtig.
Wenn ein Eventablauf "zusammenbricht" oder auch der kombinierte Ablauf von mehreren Events, dann hat der Ersteller was falsch gemacht.
Das ist zumindestens keine gute Begründung dafür kein ständiges Speichern zu ermöglichen.

[[KoA-Angel]]

Für mich klingt das erstmal nach Designfehler im Event, dem zB durch das Setzen/Ändern einer Variable an geeigneter Stelle abgeholfen werden könnte. Aber vielleicht denke ich auch einfach nur zu simpel. Hättest Du mal ein konkretes Beispiel?

...

Nimm mal an, du hast ein Level geladen, darauf startet ein Parallel Event bestehend aus einem Initialisierungsteil für Variablen und einer Endlosschleife, die zB auf Eingaben wartet. Wird nun vom Ersteller nicht beabsichtigt gespeichert und neu geladen, dann startet das Event neu, die Initialisierung wird erneut durchgeführt und Variablen werden auf Anfangswerte gesetzt, obwohl sie das nicht sollten, da man sich mitten im Level befindet.
Natürlich kann man dieses Problem durch entsprechendes Scripten umgehen, aber damit rechnet der Ersteller ja nicht, da er dem Spieler das Speichern nur ausserhalb der Level ermöglichen will.
Ist jetzt nur ein aus der Luft gegriffenes Gedankenspiel.

Versteht mich nicht falsch, ich will damit keinesfalls ein Gamedesign begründen, das kein freies Speichern erlaubt.
Alles, was ich sage, ist dass es zu Bugs führen kann, wenn man an Stellen speichert, an denen komplexe Scripte im Hintergrund laufen, da der RPGMaker zwar alle Variablen und Event Positionen sichert, leider aber nicht die Ausführungsposition der Scripts.

Tatsache ist aber, dass du den Ersteller eines Spiels nicht für Bugs verantwortlich machen kannst, die durch Cheaten ( und das ist das Speichern an ungeplanten Stellen) auftreten.
Ein Designfehler liegt hier also keinesfalls vor.

[Mr.Räbbit]

Steinigt mich bitte mit rostigen Nägeln wenn ich mich irre, aber ist es nicht eigentlich immer möglich zu speichern, wann und wo man will?
(ja ich habe mir alle Kommentare durchgelesen)
Also ich muss das "Überall Speichern" immer ausschalten, wenn ich es nicht benötige... Bin deswegen etwas verwirrt wozu der Patch gut sein soll...

lg Räbbit!

[elvissteinjr]

Das ist ein Tool und kein Patch. Damit kann der Spieler eines RM Spiels überall speichern, egal was der Ersteller vorschreibt. Das beinhaltet auch Titlescreen, GameOver und Kampf. Wobei ersteres beim Laden natürlich abstürzt und die anderen beiden die Sachen danach abbrechen.
Prinzipiell funktioniert das Tool aber und kann lästige Makerfummellei und die damit verbundene Spoilergefahr unnötig machen.

Ich selber werds nur benutzen wenn mir Speicherpunktverteilung wirklich auf den Senkel geht.

[Mr.Räbbit]

@evilsteinjr:
Danke für das Lüften des Unwissenheits-Schleiers, jetzt kann ich mich wieder weniger nervenaufreibenden Gedanken widmen. :]
Der Steinigung gerade noch entkommen:
Räbbit!

ERZITTERT!!

[Cherry]

Das ist ein Tool und kein Patch. Damit kann der Spieler eines RM Spiels überall speichern, egal was der Ersteller vorschreibt. Das beinhaltet auch Titlescreen, GameOver und Kampf. Wobei ersteres beim Laden natürlich abstürzt und die anderen beiden die Sachen danach abbrechen.
Prinzipiell funktioniert das Tool aber und kann lästige Makerfummellei und die damit verbundene Spoilergefahr unnötig machen.

Ich selber werds nur benutzen wenn mir Speicherpunktverteilung wirklich auf den Senkel geht.

...

Hmm, das mit Game Over war eigentlich gar nicht geplant. Ist aber ein netter Nebeneffekt dass man damit quasi unsterblich wird!

[Das'O']

Nimm mal an, du hast ein Level geladen, darauf startet ein Parallel Event bestehend aus einem Initialisierungsteil für Variablen und einer Endlosschleife, die zB auf Eingaben wartet. Wird nun vom Ersteller nicht beabsichtigt gespeichert und neu geladen, dann startet das Event neu, die Initialisierung wird erneut durchgeführt und Variablen werden auf Anfangswerte gesetzt, obwohl sie das nicht sollten, da man sich mitten im Level befindet.
Natürlich kann man dieses Problem durch entsprechendes Scripten umgehen, aber damit rechnet der Ersteller ja nicht, da er dem Spieler das Speichern nur ausserhalb der Level ermöglichen will.
Ist jetzt nur ein aus der Luft gegriffenes Gedankenspiel.

Versteht mich nicht falsch, ich will damit keinesfalls ein Gamedesign begründen, das kein freies Speichern erlaubt.
Alles, was ich sage, ist dass es zu Bugs führen kann, wenn man an Stellen speichert, an denen komplexe Scripte im Hintergrund laufen, da der RPGMaker zwar alle Variablen und Event Positionen sichert, leider aber nicht die Ausführungsposition der Scripts.

...

Danke für die Erklärung.

Tatsache ist aber, dass du den Ersteller eines Spiels nicht für Bugs verantwortlich machen kannst, die durch Cheaten ( und das ist das Speichern an ungeplanten Stellen) auftreten.

...

Das tue ich aber doch auch gar nicht. Wie ich bereits sagte:

... kann ich ja einfach einen Speicherplatz für solche 'Schnell-Saves' reservieren. Wenn dann etwas schiefgeht, habe ich ja immer noch die regulären Speicherstände.

...

Die Verantwortung für eventuell daraus resultierende Bugs liegt also selbstverständlich bei mir.

Ein Designfehler liegt hier also keinesfalls vor.

...

Doch. Die Tatsache, dass dieser Designfehler sich im Normal-Fall nicht auswirken kann, lässt ihn nicht verschwinden. Ja, ich mache selbst oft solche Designfehler in meinen Programmen, wenn ich zu faul bin, wirklich _alle_ Fehler-Möglichkeiten korrekt abzufangen und wenn die Chance, dass ein solcher Fehler jemals auftritt, im "Normalfall" gegen 0 geht. Aber ich denke, diese Diskussion würde nirgendwo hin führen.

Jedenfalls würde ich als Entwickler auch nicht überprüfen, ob Variablen beim erneuten Script-Start bereits belegt sind, sondern würde sie einfach intialisieren. Vom Design-Standpunkt her wäre es allerdings besser, Initialisierung und Aktualisierung von einander zu entkoppeln. Damit würde doch auch der aktuelle Variablen-Inhalt im Moment des Speicherns erhalten bleiben, oder nicht?

[[KoA-Angel]]

...
Doch. Die Tatsache, dass dieser Designfehler sich im Normal-Fall nicht auswirken kann, lässt ihn nicht verschwinden. Ja, ich mache selbst oft solche Designfehler in meinen Programmen, wenn ich zu faul bin, wirklich _alle_ Fehler-Möglichkeiten korrekt abzufangen und wenn die Chance, dass ein solcher Fehler jemals auftritt, im "Normalfall" gegen 0 geht. Aber ich denke, diese Diskussion würde nirgendwo hin führen.
...

...

Es ist ein Unterschied, ob man als Entwickler alle Fehler abfängt, die eventuell auch in unwahrscheinlichen Fällen im Programm selbst auftreten können, oder ob man alle Fehler abfangen will, die durch Manipulation von Drittprogrammen am Spiel entstehen.
Ersteres ist gewissenhaft. Letzteres ist einfach unmöglich.

[MajinSonic]

Gut, es ist ein recht nützliches Tool. Doch meiner Meinung nach macht es teilweise den Spielspaß kaputt.
Lasst uns mal VD hernehmen. Es hat schon einen Sinn, wieso man auf NORMAL und SCHWER nicht immer speichern kann. Es soll das Spiel halt schwerer machen. Wem das zu schwer/nervig ist, der solls halt auf LEICHT spielen.

Das Gleiche gibt es ja auch bei kommerziellen Spielen wie Secret Of Mana usw.

Ich verwende nie savestates, da sich der Spieler im Endeffekt selbst betrügt. Aber das muss jeder für sich selber entscheiden.

[[KoA-Angel]]

Gut, es ist ein recht nützliches Tool. Doch meiner Meinung nach macht es teilweise den Spielspaß kaputt.
Lasst uns mal VD hernehmen. Es hat schon einen Sinn, wieso man auf NORMAL und SCHWER nicht immer speichern kann. Es soll das Spiel halt schwerer machen. Wem das zu schwer/nervig ist, der solls halt auf LEICHT spielen.

Das Gleiche gibt es ja auch bei kommerziellen Spielen wie Secret Of Mana usw.

Ich verwende nie savestates, da sich der Spieler im Endeffekt selbst betrügt. Aber das muss jeder für sich selber entscheiden.

...

Ob Savestates den Spielspaß zerstören, darüber liesse sich bestimmt noch jahrelang diskutieren.
Ich selbst bin bekennender Retro Fan und spiele sehr gerne alte SNES und N64 Games (zur Zeit Jet Force Gemini) und verwende eigentlich immer Savestates.
Ich finde, die Spiele werden dadurch nicht einfacher, es wird lediglich der Weg verkürzt, den man nach einem Tod vom letzten Speicherpunkt an wieder zurückzulegen hat. Es reduziert sich also die Spiellänge, aber wohl nicht der Schwierigkeitsgrad.

Ich habe noch nie etwas davon gehalten, Spiele künstlich in die Länge zu ziehen, indem man den Spieler nur an bestimmten Punkten speichern lässt, die auch noch ewig weit auseinanderliegen - ein Extrembeispiel hierfür war damals Turok 2, falls das jemand noch als N64 Original gespielt hat, der weiss, wovon ich rede. Es war keine Seltenheit, Stunden (!) zu spielen, bis man am nächsten Speicherpunkt angelangt war.

Ein Spiel so zu designen, dass man in den höheren Schwierigkeitsgraden seltener speichern kann, halte ich für sehr fragwürdig, aber das ist nur meine Meinung.