+++ DynRPG - Das RM2k3-Plugin-SDK +++

[Kyuu]

Stehen schlecht.

Ich hab, wie man sicher merkt, einfach keine Zeit für den Maker. Ich hab eine Datei BUG2.txt, die sieht so aus:

Zensiert.

...ich hätte also genug zu tun.

...

Kein Problem. Deine Liste ist übrigens zu chaotisch und kann einen schlechten Eindruck von DynRPG vermitteln, wenn man wenig mit dem Inhalt anfangen kann (siehe Davy Jones). Und was machen getLowerLayerTileId, getUpperLayerTileId und getTerrainId in deiner BUG2.txt?

Ich hab dir jetzt hier aber mal mein MinGW mit DynRPG hochgeladen, d.h. da ist auch der Compiler dabei der garantiert funktioniert (ein relativ alter).

...

GCC 4.4.1 (die mit CodeBlocks 10.05 mitgeliefert wird) funktioniert eigentlich recht gut mit DynRPG, zumindest soweit ich getestet habe. Die GCC in deinem Paket ist auf Version 3.4.5, aus dem Jahr 2004. Ehrlich gesagt, so ein alter Compiler schreckt mich etwas ab, da die Compiler sich seit 2004 stark verbessert haben sollten. Ich bin schon mit GCC 4.4.1 (2009) nicht wirklich zufrieden.

Außerdem ist da eine DynLoader.dll die neuer ist als die die vom Patcher erzeugt wird (die hat den Bug gefixt dass wenn der letzte Parameter bei einem Comment ein String oder Token ist dass da zusätzliche Müll-Zeichen angehängt werden können).
http://share.cherrytree.at/showfile-9356/mingw_dynrp.7z

...

Cool, danke.

[Cherry]

@Kyuu: Ich dachte bisher, 4.6.1 ist okay, aber da gabs anscheinend ein Problem mit RPG:attler::getMaxHp, was mit 3.4.5 nicht vorhanden war. Keine Ahnung ob 4.4.1 da geht oder nicht. Ich weiß übrigens selber nicht warum mein Compiler so alt ist, weil 2004 hatte ich mit C++ noch null am Hut.

Ja, die Liste ist chaotisch, ist auch keine öffentiche. Und es sollte eher TODO.txt heißen, das stimmt. Einige Sachen sind nämlich auch einfach neue Ideen bzw. Details die ich erst nachher rausgefunden habe und integrieren müsste (wie RPG:BActor::_unknown_128).

[Kyuu]

@Kyuu: Ich dachte bisher, 4.6.1 ist okay, aber da gabs anscheinend ein Problem mit RPG:attler::getMaxHp, was mit 3.4.5 nicht vorhanden war. Keine Ahnung ob 4.4.1 da geht oder nicht.

...

Habe es gerade mit 4.4.1 getestet und es funktioniert einwandfrei. Eine Test Suite wäre natürlich optimal, mit der man automatisiert die Kompatibilität mit einem Compiler prüfen könnte.

Eine andere Frage: Sind die 2000 Pictures, die mit DynRPG zwangsläufig kommen wirklich so eine gute Idee? Zum einen bin ich mir ziemlich sicher, dass niemand (bei klarem Verstand) so viele Pictures brauchen wird und zum anderen, (das ist nur eine Vermutung, da ich die Interna nicht kenne) so eine große Menge an Pictureobjekten, die jeden Frame abgearbeitet werden müssen, könnte wertvolle Zeit verschwenden, die einem Plugin gerade fehlen könnte. Ich vermute, dass DynRPG noch weitere Änderungen im Programmablauf vornimmt, die Zeiteinbußen einbringen. Wäre vielleicht eine abgespecktere Version von DynRPG möglich, ohne die 2000 Pictures und eventuellen anderen Kram, den man nicht wirklich braucht, der aber wertvolle Zeit verschlingt?

[Cherry]

Möglich wärs schon, aber die Pictures verbrauchen, was ich so sehe, nicht wirklich viel Zeit (außer man zeigt auch wirklich alle an).

[Kyuu]

Ich halte eigentlich nichts von Mikrooptimierung, daher, wenn du sagst, dass inaktive Pictureobjekte schnell genug durchlaufen werden, habe ich im Moment nichts einzuwenden.

BTW: Ist es möglich mit DynRPG einen Tastendruck zu simulieren, oder gleich auf den internen Key Cache zuzugreifen? Ich würde gerne den Umweg über die WinAPI-Funktion SendMessage() vermeiden.

BTW²: Es scheint nicht zu funktionieren die Musik im RPG::system-Objekt zu ändern. Im RPG::dbSystem-Objekt funktioniert es allerdings. Bei den Sounds scheint es auch Probleme zu geben.

[Ghabry]

Was ist die beste Möglichkeit zu ermitteln auf welcher Karte man gerade spielt? Den Wechsel der Karte zu erkennen würde auch schon ausreichen

Und ist es irgendwie möglich das Lesen eines switches zu erkennen? (und den Rückgabewert zu ändern) Ja, brauch das wirklich beim Lesen, nicht beim Schreiben ^^

[MarcL]

Was ist die beste Möglichkeit zu ermitteln auf welcher Karte man gerade spielt? Den Wechsel der Karte zu erkennen würde auch schon ausreichen

...

Also ich weiß nicht ob es die beste Möglichkeit ist, aber du wirst mMn nicht daran vorbeikommen, auf jeder Map einen PP mit Erase Event zu packen, der vor dem Erase Event entweder selbst testet, ob die Map gewechselt wurde oder der einen Common Event callt, der das prüft. Funktionieren tut es dann so, dass du ein Set Variable mit der Map ID füllst. Dazu musst du dann wissen, welche Map ID welcher Map entspricht. Danach kannst du damit "rechnen"...

Und ist es irgendwie möglich das Lesen eines switches zu erkennen? (und den Rückgabewert zu ändern) Ja, brauch das wirklich beim Lesen, nicht beim Schreiben ^^

...

Ich verstehe nicht, was der Unterschied von lesen und schreiben eines Switches sein soll? Bzw. was du erreichen willst?
Das klingt so als willst du erkennen ob ein PP prüft ob ein Switch gesetzt ist? Wenn du das willst, dann kannst du doch gleich die im 2k3 enthaltene Funktion nutzen und suchen, welche Events auf den Switch zugreifen ^^; (hoffe ich hab das richtig verstanden)

[TwoFace]

Was ist die beste Möglichkeit zu ermitteln auf welcher Karte man gerade spielt? Den Wechsel der Karte zu erkennen würde auch schon ausreichen

...

Öh, lass immer bei Betreten einer Map eine Vari einen bestimmten Wert annehmen und frag den ab.

Und ist es irgendwie möglich das Lesen eines switches zu erkennen? (und den Rückgabewert zu ändern) Ja, brauch das wirklich beim Lesen, nicht beim Schreiben ^^

...

Conditional Branch: "Branch if Switch XXX is ON/OFF ..."

[MagicMaker]

Was ist die beste Möglichkeit zu ermitteln auf welcher Karte man gerade spielt?

...

Code:

<>SetVariable [0001:Map] = Object[Player]'s MapID

[Ghabry]

Ich frage schon absichtlich im DynRPG Thread, kommt mir nicht mit Maker-Eventcode. Will bisschen mit DynRPG rumspielen

Code:

<>SetVariable [0001:Map] = Object[Player]'s MapID

...

Hmm stimmt. Da muss ich wohl mal testen, ob man über RPG::hero->mapId die aktuelle Map ID bekommt.

Das klingt so als willst du erkennen ob ein PP prüft ob ein Switch gesetzt ist? Wenn du das willst, dann kannst du doch gleich die im 2k3 enthaltene Funktion nutzen und suchen, welche Events auf den Switch zugreifen ^^; (hoffe ich hab das richtig verstanden)

...

Den Satz versteh ich nicht.

Also geht wirklich darum, dass ich alle Switch-Leseversuche mitbekomme und so das Ergebnis des Lesevorgangs verändern kann (für Schreiben gibts nen Callback, das ist daher kein Problem)
Bei Events ist das einfach, da könnte ich über onEventCommand alle Events behandeln, die Switche lesen und schreiben können, z.B. EVCMD_CHANGE_SWITCH. Gibt aber noch einen weiteren Fall, wo Switche vorkommen: Die Überprufung, ob ein(e) Event(seite)/ein CommonEvent die Startbedingungen erfüllt hat. Da würde ich Switch lesen auch gerne behandeln.
Oder vielleicht weiß Cherry zufällig die Adressen im ASM-Code wo das passiert (Startbedingungen von Events überprüfen)? Die jmp-Anweisungen patch ich dann selber rein.

[Cherry]

RPG::hero->mapId ist korrekt.

Übrigens hatte DynRPG am Anfang onGetVariable und onGetSwitch Callbacks. Diese hab ich allerdings entfernt weil das Spiel einfach nur saulangsam wurde, sogar wenn keine Plugins das verwendet haben (rein durch den Aufruf der Funktion in dynloader.dll), weil das Auslesen von Switches und Variablen einfach extrem oft intern stattfindet.

Und warum willst du das Lesen des Switches abfangen? Willst du eine Art Selfswitch-Ding machen? Die Funktion zum Lesen eines Switches ist übrigens an VA 0x48B324, eax ist RPG::system, edx ist die Switch-ID. Rückgabewert ist 0 oder 1 in al.

Damit fängst du allerdings kein RPG::switches[xyz] von DynRPG-Plugins ab, weil diese direkt auf das Switcharray zugreifen (schau dir switches.h an).

Vielleicht kannst du einfach den Switch setzen, statt das Lesen abzufangen? Mit RPG::map->updateEvents() erreichst du dass die Startbedingungen neu evaluiert werden nachdem du den Switch geändert hast.

[Ghabry]

RPG::hero->mapId ist korrekt.
Übrigens hatte DynRPG am Anfang onGetVariable und onGetSwitch Callbacks. Diese hab ich allerdings entfernt weil das Spiel einfach nur saulangsam wurde, sogar wenn keine Plugins das verwendet haben (rein durch den Aufruf der Funktion in dynloader.dll), weil das Auslesen von Switches und Variablen einfach extrem oft intern stattfindet.

...

Wundert mich, dass das langsamer wurde, gehe mal davon aus, dass du einfach in eine Funktion der DLL reinjmpst?

Und warum willst du das Lesen des Switches abfangen? Willst du eine Art Selfswitch-Ding machen? Die Funktion zum Lesen eines Switches ist übrigens an VA 0x48B324, eax ist RPG::system, edx ist die Switch-ID. Rückgabewert ist 0 oder 1 in al.

...

Ja, genau sowas wollte ich mal versuchen

Damit fängst du allerdings kein RPG::switches[xyz] von DynRPG-Plugins ab, weil diese direkt auf das Switcharray zugreifen (schau dir switches.h an).

...

Ja, das ist dann Pech. Müssen die Pluginentwickler halt beachten.

Und ach stimmt ja, muss mit gcc compilen, die ihre Assembler-Syntax ist so hässlich :/

Edit: und __attribute__ ((naked)) funktioniert unter x86 nicht, toll, macht alles nur unnötig kompliziert -.-

[Cherry]

Vielleicht kannst du einfach den Switch setzen, statt das Lesen abzufangen? Mit RPG::map->updateEvents() erreichst du dass die Startbedingungen neu evaluiert werden nachdem du den Switch geändert hast.

...

Was spricht hiergegen?

[Corti]

Hey. Stichwort: "ShakeScreen", gibt es die Möglichkeit das per DynRPG zu verwenden/zu setzen?
Vom Makerbefehl her scheint das ein globales Setting zu sein, Shakestärke, Speed, Restdauer~ kriegt man das irgendwie zugegriffen?

[Morden]

@Corti
Eine Möglichkeit wäre wohl direkt auf die Pixel bzw. das Bitmap vom RPG::screen->canvas zuzugreifen und damit eine Art ShakeScreen zu erzeugen. Ansonsten würde mir keine Möglichkeit einfallen diesen Befehl per DynRPG zu erzeugen. Außerdem wirkt der ShakeScreen des Makers auf alles, außer die Font!

Du kannst direkt beim ausführen des EventCommands darauf zugreifen. In onEventCommand().
Edit: Dabei kannst du dann auch direkt auf die EventCommandParameter zugreifen und diese eben auch ändern und/oder dem Wert gewisser RPG::variables verpassen. Du kannst übrigens auch durch ein EventScript "springen", wenn du *nextScriptLine clever verwendest

Edit:
Weitere Idee: Z.B. Screenshottool (SFX.exe) per DynRPG aufrufen und einen Screen machen lassen und diesen dann shaken. Hätte aber den Nachteil, dass es dann ein fixes Bild wäre.

PeAcE
MorDen