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

**G-Brothers** · 24.03.2014, 00:34

Was mir neulich aufgefallen ist: Seit der neusten Version vom DynRPG werden manchmal (sogar recht selten) Sounds im Spiel nicht vollständig abgespielt. Vor allem längere Sounds sind betroffen.

**Cherry** · 27.03.2014, 19:13

OK, das ist strange; das Problem ist nur: Ich kann da nix dagegen tun wenn ich nicht mal ein Testprojekt habe wo das *reproduzierbar* passiert. Ich hab nämlich spontan nicht die geringste Idee wie das verursacht werden könnte...

**Kyuu** · 08.04.2014, 19:38

Zitat von Kyuu

Coming soon...

I suck...

Code:

function onInit()
    font = graphics.newFont("Picture/font1.png")
    windowSkin = graphics.newWindowSkin("Picture/windowskin2.png")
    windowSkin.topLeftColor     = graphics.packColor(0, 90, 180)
    windowSkin.topRightColor    = graphics.packColor(0,  0, 100)
    windowSkin.bottomLeftColor  = graphics.packColor(0,  0, 150)
    windowSkin.bottomRightColor = graphics.packColor(0,  0,  50)
end

function onEventDrawn(event, isHero)
    local text = event.name
    local x, y = event:getScreenPosition()
    local text_width = font:getStringWidth(text)
    game.screen.drawWindow(windowSkin, x - text_width / 2, y - 40, text_width, font.maxCharHeight, 150)
    game.screen.drawText(font, x - text_width / 2, y - 40, text)
    return true
end

function onBattlerDrawn(battler, isMonster, id)
    local x, y = battler:getScreenPosition()
    x = x - 20
    y = y - 60
    
    -- draw background
    game.screen.drawRectangle(true, x - 5, y - 5, 80, 40, graphics.packColor(0, 0, 0, 150))
    
    -- draw battler name
    game.screen.drawText(font, x, y, battler.name)
    
    y = y + font.maxCharHeight
    
    -- draw hp text
    game.screen.drawText(font, x, y, "HP: " .. battler.hp .. "/" .. battler.maxHp)
    
    y = y + font.maxCharHeight
    
    -- draw hp bar
    local hp_bar_len = battler.hp / battler.maxHp * 60
    game.screen.drawLine(x + 1, y + 1, x + 1 + 60, y + 1, graphics.packColor(0, 0, 0)) -- shadow
    game.screen.drawLine(x, y , x + hp_bar_len, y, graphics.packColor(0, 128, 0))
    
    return true
end

Fun!

**Davy Jones** · 09.04.2014, 01:50

Meine Fresse!

**IndependentArt** · 09.04.2014, 16:52

ehm, okay? xD explanation and stuff? ^^

**Kyuu** · 09.04.2014, 17:53

Ach, nur eine kleine Rückmeldung um zu zeigen, ~~wie cool das wird~~ dass ich vorwärts komme. Nichts Spezifisches.

**Cherry** · 13.04.2014, 23:14

Kyuu, ich finds immer noch total cool dass du das in Lua umsetzt. As said, ich dachte es wäre zu langsam. Aber du scheinst das wunderbar hinzukriegen.

**Kyuu** · 14.04.2014, 11:51

Hey, danke, das spornt mich jetzt noch mehr an, das Ding fertigzubekommen. Ja es läuft erstaunlich schnell (sogar mit Vanilla Lua). Ich bin jetzt übrigens auf LuaJIT umgestiegen, wegen dem zusätzlichen Performanceboost durch JIT-Kompilierung und der FFI-Bibliothek.

An dieser Stelle Kudos an dich, DynRPG hat wirklich viel Potential. Ich hoffe du machst da irgendwann mal weiter! *dräng*

**Cherry** · 14.04.2014, 12:40

Mich würd allerdings interessieren wieso ich auf deinem Screen ein Mädchen bin

**Kyuu** · 14.04.2014, 13:26

Das muss ein Bug sein.

**Kyuu** · 06.05.2014, 20:03

Hey Cherry, ein paar Sachen, die mir während der Arbeit an RPGSS auf-/eingefallen sind:

Tippfehler bei Character::lockEquipment. Heißt momentan Character::lockEquipemnt.
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.
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
}
```
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.
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 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.
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.
Pack' endlich getLowerLayerTileId, getUpperLayerTileId und getTerrainId in DynRPG rein, die in deiner BUG2.txt gammeln. :)

**Cherry** · 07.05.2014, 08:20

Zitat von Kyuu

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

Danke!

Zitat von Kyuu

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.

Zitat von Kyuu

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...

Zitat von Kyuu

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.

Zitat von Kyuu

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.

Zitat von Kyuu

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).

Zitat von Kyuu

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).

Zitat von Kyuu

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

...Ja...

**Kyuu** · 07.05.2014, 16:17

Vergessen gestern zu erwähnen:

Map::moveCamera: Positive Offsets bewegen die Kamera nach links-oben, negative nach rechts-unten. Erwartet hätte ich genau das umgekehrte Verhalten, also positive Offsets bewegen die Kamera nach rechts-unten und negative nach links-oben. Habe ich die Dokumentation falsch verstanden, oder doch Bug? (Übrigens, mir ist aufgefallen, dass mit der Bewegung (auf beiden Achsen unabhängig) so lange gewartet wird, bis die Bewegung möglich ist. Das ist zwar logisch, wenn man es überdenkt, aber zumindest für mich war das überraschend, da in der Dokumentation zu Map::moveCamera nichts davon steht.)
DynRPG muss Plugins auch aus Unterordnern laden können: Im Moment müssen alle Bibliotheken, gegen die Plugins gelinkt sind, direkt in den Spielordner. Das hat zur Folge, dass jeweils nur eine Version einer Bibliothek existieren kann. Angenommen zwei Plugins sind dynamisch gegen dieselbe Bibliothek gelinkt, nur jeweils eine andere Version, mit gravierenden Änderungen in der neueren Version -> nur eins der Plugins kann geladen werden. Mit Unterordnern ließe sich sowas umgehen, wobei du vor dem Laden eines Plugins die Current Working Directory entsprechend ändern musst (und danach wiederherstellen), damit die Windowsroutine die Dependencies finden kann. Ich stelle es mir so vor:
Code (Pseudo):
```
 
foreach (String subdir in GetDirectoryList("DynPlugins")) {
    String gamedir = GetCurrentWorkingDirectory();
    SetCurrentWorkingDirectory(gamedir + "/DynPlugins/" + subdir);
    LoadPlugin(subdir + ".dll"); // plugin DLL is in a sub-directory with the same name
    SetCurrentWorkingDirectory(gamedir);
}
 
```

________________________________________________________________________________________

Zitat von Cherry

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

Ich sehe gerade nicht, warum Plugins nicht einheitlich funktionieren würden, wenn man es dem Plugin-Autor überlässt, ob er Case Sensitivity bei Token braucht, oder nicht. Es geht mir hier nur um Token und nach meiner Auffassung sind Token äußerst pluginspezifisch, heißt: Plugin-Autor weiß besser was er mit den ihm übergebenen Token anfangen will (soll nicht heißen, dass es keine einheitlichen Standardtoken geben darf). Ich finde das Konzept der Token übrigens ziemlich genial, nur nimmst du mit der aufgezwungenen Case Insensitivity dem Ganzen unbegründeterweise etwas den Wind aus den Segeln. Wie gesagt, ich fände es besser, wenn du das Parsen der Token dem Plugin-Autor überlassen würdest und einfach entsprechendes Werkzeug zur Verfügung stellst, womit er deine Standardtoken (Vxx, Nxx) parsen kann und Case Insensitive Vergleiche machen kann -> du bist glücklich, weil Plugins einheitlich funktionierende Standardtoken verwenden und Plugin-Autoren sind glücklich, weil sie Folgendes machen können:

Code:

@do_something I1, i1

Wenn du Zeit sparen willst, kannst du auch gerne meinen TokenParser verwenden. Dieser kann bereits mehr als nur deine Standardtoken, ist schnell, zuverlässig und lässt sich leicht erweitern/ändern.

Zitat von Cherry

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.

Du hast also absichtlich den Makerbug in DynRPG nachempfunden, wegen... der User Experience? Du bist doch sonst nicht zimperlich bei Makerbugs. :/ Ich finde übrigens überhaupt nicht, dass DynRPG hier den Maker nachäffen muss, mit seinen dämlichen Eigenarten. Wenn der Maker in seiner degenerierten Klicksprache ungültige Indizes heimlich ignoriert ist das seine Sache, DynRPG sollte da konsequent sein und Fehlermeldungen raushauen, denn das führt sonst zu subtilen Plugin-Bugs, die schwer zu debuggen sind. Ich finde übrigens, dass Indizes, die über die Arraylänge hinausgehen genauso als ungültig zu betrachten sind, wie Indizes <= 0. Der Maker vergrößert da heimlich die Arrays, macht DynRPG das auch? Das sollte IMO auf keinen Fall passieren, zumindest nicht in DynRPG, weil... unvorgesehene Speicherallokation schlecht ist. Im Maker kann man höchstens ein Array auf die Länge 9999999 (entspricht beim Variablenarray etwa 38 MB) vergrößern, in DynRPG geht da vieeeel mehr. In RPGSS habe ich genau aus diesem Grund ein "sane array limit" von 999999, um die Makerarrays nicht ungewollt in die Höhe schnellen zu lassen. (Ich merke übrigens gerade, dass ich noch gar nicht dokumentiert habe, dass man die Makerarrays in RPGSS vergrößern/verkleinern kann...)

Edit: Ich würde das mit den Naming Conventions nicht so eng sehen, wenn ich an deiner Stelle wäre. Es handelt sich bei den Plugins schließlich fast schon um eigenständige Programme und nicht um ein ganzes. Bei einem Team, das an einer Software mit einem gemeinsamen Qualltext arbeitet, sollte man versuchen Einheitlichkeit mit Naming/Coding Conventions durchzusetzen, aber bei eigenständigen Programmen mit unabhängigen Quelltexten sehe ich keine besondere Notwendigkeit dafür. Dass die Commands mal camelCase, mal PascalCase und mal snake_case sind, ist in meinen Augen OK, und in der C/C++-Welt gang und gäbe. Wichtig ist nur, dass die jeweilige Convention konsequent innerhalb des Plugins angewandt wird, also dass nicht ein paar Commands snake_case und ein paar PascalCase sind, oder so. Und noch wichtiger ist, dass die Plugins stabil und schnell laufen.

Zitat von Cherry

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.

(Hab's gerade nochmal getestet und zumindest bei meiner Dyn 0.20 wird immer ein leerer String zurückgegeben.) Also, d.h. du verwendest das Actor::name-Feld? In meinem TokenParser verwende ich die Battler::getName-Methode, was sehr gut zu funktionieren scheint.

Zitat von Cherry

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).

Ich denke das würde funktionieren, solange man davon ausgehen kann, dass der Stack nicht niedriger aligned ist als 4 Byte, aber ich glaube diese Annahme kann man heute ruhig machen.

Zitat von Cherry

Der Maker macht da sleep(1).

Eigenartig, warum belegt dann die RPG_RT immer den kompletten CPU-Kern? Kannst du mir den Speicheroffset nennen, wo sleep(1) aufgerufen wird?

**Cherry** · 08.05.2014, 13:28

Zitat von Kyuu

Map::moveCamera: Positive Offsets bewegen die Kamera nach links-oben, negative nach rechts-unten. Erwartet hätte ich genau das umgekehrte Verhalten, also positive Offsets bewegen die Kamera nach rechts-unten und negative nach links-oben. Habe ich die Dokumentation falsch verstanden, oder doch Bug? (Übrigens, mir ist aufgefallen, dass mit der Bewegung (auf beiden Achsen unabhängig) so lange gewartet wird, bis die Bewegung möglich ist. Das ist zwar logisch, wenn man es überdenkt, aber zumindest für mich war das überraschend, da in der Dokumentation zu Map::moveCamera nichts davon steht.)

Ich rufe da direkt eine Makerfunktion auf (bzw. ändere ein paar Werte die den Maker zur Bewegung veranlassen, so wie es auch der entsprechende Eventbefehl tut), das Verhalten mit dem Warten war mir jetzt auch nicht bewusst. Die Offsets ergeben für mich eigentlich so Sinn: Die "Kamerakoordinaten" sind die Koordinaten die der oberste linke Pixel des Screens in Bezug auf den obersten linken Pixel der Map hat.

Zitat von Kyuu

DynRPG muss Plugins auch aus Unterordnern laden können: Im Moment müssen alle Bibliotheken, gegen die Plugins gelinkt sind, direkt in den Spielordner. Das hat zur Folge, dass jeweils nur eine Version einer Bibliothek existieren kann. Angenommen zwei Plugins sind dynamisch gegen dieselbe Bibliothek gelinkt, nur jeweils eine andere Version, mit gravierenden Änderungen in der neueren Version -> nur eins der Plugins kann geladen werden. Mit Unterordnern ließe sich sowas umgehen, wobei du vor dem Laden eines Plugins die Current Working Directory entsprechend ändern musst (und danach wiederherstellen), damit die Windowsroutine die Dependencies finden kann. Ich stelle es mir so vor:

Code (Pseudo):

 
foreach (String subdir in GetDirectoryList("DynPlugins")) {
    String gamedir = GetCurrentWorkingDirectory();
    SetCurrentWorkingDirectory(gamedir + "/DynPlugins/" + subdir);
    LoadPlugin(subdir + ".dll"); // plugin DLL is in a sub-directory with the same name
    SetCurrentWorkingDirectory(gamedir);
}

Das Problem ist nur, dass im Moment festgelegt ist, dass das Workingdirectory immer das Projektverzeichnis ist. Ich notier mir mal das Problem, vermutlich kann man den DLL-Loadpfad ändern bevor man ein Plugin lädt.

Zitat von Kyuu

Ich sehe gerade nicht, warum Plugins nicht einheitlich funktionieren würden, wenn man es dem Plugin-Autor überlässt, ob er Case Sensitivity bei Token braucht, oder nicht. Es geht mir hier nur um Token und nach meiner Auffassung sind Token äußerst pluginspezifisch, heißt: Plugin-Autor weiß besser was er mit den ihm übergebenen Token anfangen will (soll nicht heißen, dass es keine einheitlichen Standardtoken geben darf). Ich finde das Konzept der Token übrigens ziemlich genial, nur nimmst du mit der aufgezwungenen Case Insensitivity dem Ganzen unbegründeterweise etwas den Wind aus den Segeln. Wie gesagt, ich fände es besser, wenn du das Parsen der Token dem Plugin-Autor überlassen würdest und einfach entsprechendes Werkzeug zur Verfügung stellst, womit er deine Standardtoken (Vxx, Nxx) parsen kann und Case Insensitive Vergleiche machen kann -> du bist glücklich, weil Plugins einheitlich funktionierende Standardtoken verwenden und Plugin-Autoren sind glücklich, weil sie Folgendes machen können:

Code:

@do_something I1, i1

Wenn du Zeit sparen willst, kannst du auch gerne meinen TokenParser verwenden. Dieser kann bereits mehr als nur deine Standardtoken, ist schnell, zuverlässig und lässt sich leicht erweitern/ändern.

Es wird alles deswegen vorgeparst damit nicht jedes Plugin hergeht und irgendwie (vielleicht dann noch unoptimiert) den String parst und alles unglaublich verzögert wird.

[QUOTE=Kyuu;3170703]Du hast also absichtlich den Makerbug in DynRPG nachempfunden, wegen... der User Experience? Du bist doch sonst nicht zimperlich bei Makerbugs. :/ Ich finde übrigens überhaupt nicht, dass DynRPG hier den Maker nachäffen muss, mit seinen dämlichen Eigenarten. Wenn der Maker in seiner degenerierten Klicksprache ungültige Indizes heimlich ignoriert ist das seine Sache, DynRPG sollte da konsequent sein und Fehlermeldungen raushauen, denn das führt sonst zu subtilen Plugin-Bugs, die schwer zu debuggen sind. Ich finde übrigens, dass Indizes, die über die Arraylänge hinausgehen genauso als ungültig zu betrachten sind, wie Indizes <= 0. Der Maker vergrößert da heimlich die Arrays, macht DynRPG das auch? Das sollte IMO auf keinen Fall passieren, zumindest nicht in DynRPG, weil... unvorgesehene Speicherallokation schlecht ist. Im Maker kann man höchstens ein Array auf die Länge 9999999 (entspricht beim Variablenarray etwa 38 MB) vergrößern, in DynRPG geht da vieeeel mehr. In RPGSS habe ich genau aus diesem Grund ein "sane array limit" von 999999, um die Makerarrays nicht ungewollt in die Höhe schnellen zu lassen. (Ich merke übrigens gerade, dass ich noch gar nicht dokumentiert habe, dass man die Makerarrays in RPGSS vergrößern/verkleinern kann...)
Ich sehe das nicht als Bug sondern als expected behavior, und wie gesagt: Plugins sollen sich möglichst einfach in den Rest der Maker-"Experience" einfügen, und das heißt auch dass man sagen kann "Vxx funktioniert wie \v[xx] in Messages" und der User kennt sich aus.

Zitat von Kyuu

Edit: Ich würde das mit den Naming Conventions nicht so eng sehen, wenn ich an deiner Stelle wäre. Es handelt sich bei den Plugins schließlich fast schon um eigenständige Programme und nicht um ein ganzes. Bei einem Team, das an einer Software mit einem gemeinsamen Qualltext arbeitet, sollte man versuchen Einheitlichkeit mit Naming/Coding Conventions durchzusetzen, aber bei eigenständigen Programmen mit unabhängigen Quelltexten sehe ich keine besondere Notwendigkeit dafür. Dass die Commands mal camelCase, mal PascalCase und mal snake_case sind, ist in meinen Augen OK, und in der C/C++-Welt gang und gäbe. Wichtig ist nur, dass die jeweilige Convention konsequent innerhalb des Plugins angewandt wird, also dass nicht ein paar Commands snake_case und ein paar PascalCase sind, oder so. Und noch wichtiger ist, dass die Plugins stabil und schnell laufen.

Makerer sind aber im Allgemeinen nicht aus der C++-Welt.

Zitat von Kyuu

(Hab's gerade nochmal getestet und zumindest bei meiner Dyn 0.20 wird immer ein leerer String zurückgegeben.) Also, d.h. du verwendest das Actor::name-Feld? In meinem TokenParser verwende ich die Battler::getName-Methode, was sehr gut zu funktionieren scheint.

Hm, sollte eigentlich auch getName aufrufen, aber vielleicht mach ich was falsch, ich schau mal.

Zitat von Kyuu

Eigenartig, warum belegt dann die RPG_RT immer den kompletten CPU-Kern? Kannst du mir den Speicheroffset nennen, wo sleep(1) aufgerufen wird?

46BD4B

**Corti** · 09.05.2014, 10:45

Ich stelle fest, dass ich Daten brauche, die ich nicht finde und nur Daten finde, die ich nicht brauche und Daten habe von denen ich nicht weiß woher ich sie habe.

DynRPG SDK 0.14 -> DynRPG Website
DynRPG Patch 0.14 -> DynRPG Website
DynRPG Patch 0.17 -> Hab ich irgendwo her
DynRPG Patch 0.17 Verbesserter DynLoader -> Hab ich irgendwo her
DynRPG Patch 0.20 -> Keine Ahnung wo man das bekommt
DynRPG Patch 0.20 Verbesserter DynLoader -> Keine Ahnug wo man den bekommt
DynRPG SDK neue Versionen -> Keine Ahnung ob es das gibt und wo

Wollen wir das mal zusammen tragen?

**Cherry** · 09.05.2014, 17:01

Chaos, wie alles hier. Ich weiß. Ich baue gerade an einer neuen Webseite und werde da alles mal archivieren und ordentlich katalogisieren.

**Quetschi** · 10.05.2014, 09:41

Ist es mit DynRPG möglich auch auf Event-Befehle wie "Recall to memorized Position" zuzugreifen? Hab da nichts gefunden.

**Cherry** · 10.05.2014, 10:15

Nicht direkt, aber du kannst natürlich händisch teleportieren mit.......waaaait, gerade festgestellt dass das noch gar nicht eingebaut ist O_o

Geht aber händisch so:

Code:

void teleport(int mapId, int x, int y) {
    int *mapParamPtr = RPG::sceneObjects[RPG::SCENE_MAP];
    mapParamPtr[4] = mapId;
    mapParamPtr[5] = x;
    mapParamPtr[6] = y;
    ((char *)mapParamPtr)[13] = 1;
}

"Aus dem Kopf", nicht getestet.

**Quetschi** · 10.05.2014, 14:03

Hey,

erst mal danke für die Antwort.

Zitat

int *mapParamPtr = RPG::sceneObjects[RPG::SCENE_MAP];

Da kam die Fehlermeldung "cannot convert 'void***' to 'int*' in initialization"
Also mal schnell abgeändert zu:

Zitat

int* mapParamPtr = (int*) RPG::sceneObjects[RPG::SCENE_MAP];

Und es kompiliert und funktioniert... dachte ich zumindest.

Jetzt kriege ich allerdings folgende Fehlermeldung sobald der Teleport kommen soll.

**Kyuu** · 10.05.2014, 15:25

Zitat von Quetschi

Da kam die Fehlermeldung "cannot convert 'void***' to 'int*' in initialization"

Da sind drei level of indirection, d.h. du musst zwei mal dereferenzieren um ein int* zu bekommen. Probier mal das:

Code:

int* mapParamPtr = **((int***)RPG::sceneObjects[RPG::SCENE_MAP]);

Thema: +++ DynRPG - Das RM2k3-Plugin-SDK +++

Themen-Optionen

Anzeige

Berechtigungen