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

[Kyuu]

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);
  }
   

  
  

________________________________________________________________________________________

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.

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.

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.

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.

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?