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

[Cherry]

Tippfehler bei Character::lockEquipment. Heißt momentan Character::lockEquipemnt.

...

Danke!

Ich finde, das Makro NOT_MAIN_MODULE sollte MAIN_MODULE heißen und genau umgekehrt funktionieren, d.h. in dem Modul, in welches das Zeug rein muss, sollte man auch das Makro definieren, anstatt in allen Modulen, in die es nicht rein soll, NOT_MAIN_MODULE definieren zu müssen. Momentan ist dieses Makro bei mehreren/vielen Modulen nicht nur ein Mehraufwand, sondern es macht auch Probleme, wenn man DynRPG.h aus Headern heraus einfügen will. Viel eleganter wäre es sowieso, wenn das Zeug, das an dem Makro hängt, in einen eigenen Header wandern würde, etwa PluginMain.h.

...

Notier ich mir, mal schauen.

Ich finde, es sollte dem Plugin-Autor überlassen werden, ob er Case Sensitivity bei Token braucht oder nicht und es gibt durchaus Situationen, in denen man Case Sensitivity brauchen kann. Anstatt jedes Token durch eine ToLower-Funktion zu jagen, ohne die Zustimmung des Plugin-Autors, wäre es eleganter, wenn du, für die, die es benötigen, eine Funktion zur Verfügung stellst, die einen Stringvergleich ohne Case Sensitivity durchführt, etwa:

Code:

if (RPG::CaseInsensitiveStringCompare(token, "foo") == 0) {
    // do something
}

...

DynRPG-Plugins sollen einheitlich funktionieren, und wenn der Pluginautor Case Sensitivity braucht, soll er doch einen String verwenden...

Ich sehe die automatische Auswertung von Token wie V<ID> als problematisch, weil du ungültige Indizes erlaubst und in dem Fall eine "0" übergibst. Ich finde, wenn ein Skript nicht existierende Indizes referenziert, ist das ein Fehler, der korrigiert werden sollte und nicht heimlich ignoriert. Am Besten wäre es, wenn du die Auswertung der Token dem Plugin-Autor überlässt und eine Hilfsklasse bereitstellst, die Token auswerten kann, etwa wie mein TokenParser.

...

Das ist Userschnittstelle und nicht Entwicklerschnittstelle. Und es soll daher nicht anders funktionieren als \v in Nachrichten, oder Change Variable mit Variablenpointer. Nach oben haben Variablen-IDs ja keine Grenze (die im Maker gesetzte ist ja nur für Variablennamen relevant), "ungültige" IDs, also <=0, ergeben 0. So verhält sich der Maker, so verhält sich also auch DynRPG aus Makerer-Sicht. Und ich überlasse da bewusst nix dem Plugin-Autor, damit ein einheitliches Verhalten entsteht (ich hab eh schon den Fehler gemacht, nicht festzulegen ob Commands Unterstriche verwenden sollen oder SoWasHier). Besonders dass alle Plugins automatisch (und auf gleiche Weise) Vxx, VVxx, Nxx, NVxx, etc. unterstützen, war für mich wesentlich.

Kann es sein, dass die Auswertung des Tokens N<ID> (für Actor Name) nicht funktioniert? Ich glaube, als ich's getestet habe, bekam ich damit immer einen leeren String.

...

Ich dachte eigentlich, das sei in 0.20 behoben... das Problem war (ist?), afair, dass er nur den aktuellen Heldennamen liest, nicht den aus der DB, und wenn der nie von einem Event geändert wurde, ist der leer. Oder so.

Ich musste auf die harte Tour lernen, dass der Stack nicht 16-Byte aligned ist, wenn der DynLoader den Plugin-Code aufruft. Bei SSE2 Intrinsics werden Stackvariablen mit 16-Byte Alignment verwendet und dummerweise nimmt GCC an, dass der Stack 16-Byte aligned ist -> Segfault sobald auf eine solche Variable zugegriffen wird. Ich konnte das Problem mit dem Compilerflag -mstackrealign umgehen, nur generiert GCC damit für alle Funktionen einen längeren Prolog und Epilog, nicht nur für die, die das Alignment voraussetzen: nicht optimal. Eine andere Lösung wäre es, Funktionen, die ein bestimmtes Alignment voraussetzen mit dem Attribut force_align_arg_pointer zu versehen, aber ich werde das Gefühl nicht los, dass das bereits im DynLoader geschehen sollte und nicht erst im Plugin-Code. Selbst wenn ein Plugin nicht explizit eine Befehlssatzerweiterung wie SSE2 nutzt, moderner Code sollte 16-Byte aligned sein, nicht zuletzt weil heutige Compiler eigenständig SIMD-Optimierungen am Code vornehmen können, die oft 16-Byte Alignment benötigen.

...

Wenn ich mal Zeit habe, bau ich das ein, ich müsste einfach nur so viele dwords pushen bis test esp, 0f zero ist, wenn ich das richtig verstehe (und natürlich nacher esp wiederherstellen).

Führt der Maker eine

Code:

while (CurrentTime() < time_until_next_frame) {
    // NO-OP
}

-Schleife aus? Wenn ja, wäre es möglich daraus

Code:

while (CurrentTime() < time_until_next_frame) {
    Thread.Sleep(10 /* milliseconds */ );
}

zu machen? Das hat mich schon immer beim Maker gestört, dass da unnötigerweise Rechenzeit belegt wird. Bei Laptops ist das sogar ein großes Problem, weil dadurch der Akku schnell entladen wird.

...

Der Maker macht da sleep(1).

Pack' endlich getLowerLayerTileId, getUpperLayerTileId und getTerrainId in DynRPG rein, die in deiner BUG2.txt gammeln.

...

...Ja...