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

[Kyuu]

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]

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

[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?

[Cherry]

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.

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.

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.

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.

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

Code:

Function GetHeroName(id As Integer) As String
	Dim s As ZString Ptr
	Asm
		mov eax, [&h4cddc8]
		mov eax, [eax]
		mov edx, [id]
		call [GetFromList]
		test eax, eax
		jz Cont
		mov ecx, [eax]
		lea edx, [s]
		call [ecx+24]
		Cont:
	End Asm
	
	If s = 0 Then Return ""
	
	Function = *s
	
	Asm
		lea eax, [s]
		call [LStrClr]
	End Asm
End Function

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

...

46BD4B