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

[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