[DynRPG Plugin]Text Plugin

[Cherry]

Ich hab mal deine DLL in einen Debugger geladen und geschaut was an Adresse 6AB03309 passiert:

Code:

6AB032FB  |.  8B55 0C       MOV EDX, [ARG.2]
6AB032FE  |.  8B02          MOV EAX, [EDX]
6AB03300  |.  8B50 FC       MOV EDX, [EAX-4]
6AB03303  |>  8B8D A0FEFFFF MOV ECX, [LOCAL.88]
6AB03309  |.  803C08 5D     CMP BYTE PTR [EAX+ECX], 5D << Hier crasht es.
6AB0330D  |.^ 75 CD         JNZ SHORT DynTextP.6AB032DC
6AB0330F  |.  83E9 02       SUB ECX, 2
6AB03312  |.  898D A0FEFFFF MOV [LOCAL.88], ECX
6AB03318  |.  85D2          TEST EDX, EDX
6AB0331A  |.  78 1A         JS SHORT DynTextP.6AB03336

Nachdem in dieser Funktion Stringroutinen aufgerufen werden, gehe ich davon aus, dass ARG.2 (der zweite Parameter der Funktion) ein std::string ist. LOCAL.88 dürfte eine Indexvariable sein. Es crasht bei einem Vergleich eines Zeichens im String mit 0x5D, was, als ASCII interpretiert, eine schließende eckige Klammer ("]") wäre.

Kurz gesagt: Vermutlich bei einer Zeile mit if(string[index] == ']') o.ä. crasht es. Vermutlich durch einen zu hohen Wert in der Indexvariable (schaut mir nach Buffer Overflow aus - 01EA0000 war die Adresse im Screen, auf die ein Zugriff hätte stattfinden sollen. Das ist eine "runde" Adresse und legt nahe, dass über das Ende eines allozierten Speicherbereichs hinaus (der wohl bei 01E9FFFF geendet hat) Lesezugriffe stattfanden).
Falls dir das was hilft.

(Ich hab das Projekt jetzt nicht überprüft, wollte dich aber nur noch sicherheitshalber an diesen Teil der DynRPG-Dokumentation erinnern: "The maximum number of characters per parameter (or command name) is 200. You have to parse the comment yourself if you need more.")

EDIT: Der Befehl JNZ unter der crashenden Zeile ist ein bedingter Sprungbefehl, der auf eine Adresse oberhalb zeigt. D.h. in diesem Fall, wenn das Zeichen im String nicht ein "]"-Zeichen ist, wird im Programmablauf zurückgesprungen. Ich vermute also, es handelt sich um sowas wie do { ... } while(string[index] != ']'). Schaut mir nach irgendeinem Bug in einem der \X[...] Features aus.

EDIT2: Die Funktion, in der es crasht, wird in deinem ganzen Code nur einmal aufgerufen, und zwar nachdem irgendeiner Variablen der Wert 5 zugewiesen wurde (kann natürlich auch ein Enum-Wert sein).

EDIT3: Falls das nicht klar sein sollte: Ich habe da jetzt nichts getestet oder mir an deinem Sourcecode (den ich afaik gar nicht habe) angeschaut. Ich hab dir nur anhand von der Meldung in Fuxfell's Screenshot Hinweise gegeben, die dich zu der Stelle in deinem Code führen könnten, wo der Fehler passiert.

[Fuxfell]

Oh man, wie peinlich

Danke jedenfalls, jetzt klappts mit Skill und Itemnamen

Hab aber noch ein Problem mit den Makertextsymbolen:

Code:

@write_text "SkillID_Pfeil 1",V442,V443, "$s"
@write_text "SkillID_Pfeil 2",V442,V443, "$t"
@write_text "SkillID_Pfeil 3",V442,V443, "$u"
@write_text "SkillID_Pfeil 4",V442,V443, "$v"

Produziert komische Dinge:

Schreibe ich den Code so:

Code:

@write_text "SkillID_Pfeil 1",V442,V443, $s
@write_text "SkillID_Pfeil 2",V442,V443, $t
@write_text "SkillID_Pfeil 3",V442,V443, $u
@write_text "SkillID_Pfeil 4",V442,V443, $v

Funktioniert es beim ersten Mal und macht dann das, wenn ich das Spiel über F12 neu starte:



Ich war übrigens in der Lage eine neue Fehlermeldung zu produzieren, kann sie aber leider nicht rekonstruieren:


Oder ist das doch ein Fehler des Plugins? Gruß

[Kazesui]

Kurz gesagt: Vermutlich bei einer Zeile mit if(string[index] == ']') o.ä. crasht es.

...

Dass könnte stimmen. Wenn ein Befehl gefunden wird, fängt ein Funktion an das ganze zu parsen, was hiermit endet:

Code:

while(string[i] != ']') i++;
while(string[i+1]==']') i++;

Ich dachte dass std::string auch ein '\0' Terminator am ende hätte (wie ein typischer C string), damit das

Code:

string[i+1]

kein Problem ausmachen sollte, scheint aber nicht so zu sein hab ich gerade herausgefunden, also könnte es sehr wohl daran liegen (auch wenn ich selber der Fehlermeldung nicht kriegen könnte, nichtmal wenn ich kein ']' hatte, was eigentlich ein Overflow geben müsste).

Sollte nun kein Problem mehr sein

@Fuxfell

Könnte wohl etwas komisch erscheinen. V445 geht nur wenn es für sich selber steht, während die sonstige befehle sollten alle ein Text ausmachen, bzw. innerhalb " zeichen sein. Also ginge V445 oder auch "\v[445]" aber nicht "\i[V445]" oder \i[V445]. Man kann für Texte V445 als auch "\v[445]" benutzen, aber für alles andere (Koordinaten, farbe) geht nur V445 oder halt ein reines Zahl

[Fuxfell]

Das Beispielprojekt stürzt auch in Version 07 noch bei mir ab, diesmal mit dieser Fehlermeldung:

Übrigens besteht das Problem das ich in meinen vorherigen Post editiert habe auch noch bei
der neuen Version (falls du den Edit nicht gesehen hast )

[Kazesui]

Dann bin ich mir immernoch nicht ganz sicher @Fehlermeldung. Mal weiterschauen
Das mitm komischen zeug allerdings liegt daran dass du zur zeit das ganze mit einem "end" schliessen muss.
z.b.

Code:

@write_text "SkillID_Pfeil 1",V442,V443, "$s", end

Liegt daran dass es noch kleine Probleme geben könnte wenn das letzte Parameter ein Text ist. In das Testprojekt hab ich meistens einfach das ganze mit ,, beendet, ausser wenn ich die zwei letzen Parameter benutzen wollte.

[Fuxfell]

Danke für die Unterstützung klappt so weit

[Cherry]

@Fuxfell: Kleine Info: Die Fehlermeldung ist jedes Mal dieselbe, nur die Zieladresse ("offset") ist eine andere, was aber nur davon abhängt, wie der Arbeitsspeicher gerade aussieht bei dir. Das relevante ist die erste Zahl (das ist die Adresse, an welcher der Befehl steht, der den Fehler ausgelöst hat).

Das interessante dabei ist dass Fuxfell sagt es stürzt in der neuen Version auch ab, die Adresse aber dieselbe ist wie vorher, was eigentlich unwahrscheinlich ist wenn du in deinem Code was geändert hast. Kann aber auch ein Clue sein im Falle dass deine Änderung nur unterhalb der fehlerhaften Stelle erfolgt ist und dadurch die Adressen oberhalb nicht "verschoben" wurden.

[MrSerji]

Könnte man in dieses Plugin noch ein Update intergrieren?
Eine Funktion, die die Schrift ganz mit einem Schatten umrandet.
So:
Halt das der Schatten nicht so daneben aussieht wie er es im Standard schon ist^^

[Cherry]

Das Plugin verwendet die Makerinterne "Text anzeigen"-Funktion. Derartige "Zusatzsachen" sind also entsprechend aufwändig, weil die Standardfunktion des Makers sowas nicht bereitstellt.

[MrSerji]

Das Plugin verwendet die Makerinterne "Text anzeigen"-Funktion. Derartige "Zusatzsachen" sind also entsprechend aufwändig, weil die Standardfunktion des Makers sowas nicht bereitstellt.

...

Achso, schade :/
Dann muss ich für die Überschriften und dem ganzen Scheiß weiter Pics benutzen :/

Naja, dennoch klasse dieses Plugin^^
Hilft ungemein viel!

[Cherry]

Naja, man kann natürlich eine eigene Textengine einbauen, z.B. mit der FreeType Bibliothek. Ist aber halt mehr Arbeit als einfach die Funktion RPG::Image::drawText von DynRPG aufzurufen.

[Kazesui]

So ziemlich was Cherry gesagt hat. Es wäre um einiges umständlicher, und ich habe zur zeit etwas begränzt von Zeit.

[Cherry]

Achso, schade :/
Dann muss ich für die Überschriften und dem ganzen Scheiß weiter Pics benutzen :/

Naja, dennoch klasse dieses Plugin^^
Hilft ungemein viel!

...

Naja, ein Trick wäre wohl, den Text mehrfach anzuzeigen, ein paar mal mit einer komplett schwarzen Farbe im Systemset (als Rand) und als letztes mit der richtigen Farbe in der Mitte obendrauf.

[MrSerji]

Naja, ein Trick wäre wohl, den Text mehrfach anzuzeigen, ein paar mal mit einer komplett schwarzen Farbe im Systemset (als Rand) und als letztes mit der richtigen Farbe in der Mitte obendrauf.

...

xD
Das wär ne Idee

[RPG Hacker]

Setzt drawText denn nicht auch schon automatisch den Schatten unten rechts? Wenn ja, dann dürfte das schwer werden. Ansonsten geht das ganz gut. So habe ich das auch bei meinen Spielen immer gelöst.