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

[Corti]

Ich habs bisher selbst nicht benutzt und hab jetzt auch grad keine Möglichkeit es zu testen daher mal blind gescriptet.

Code:

onEventCommand ( RPG::EventScriptLine *  scriptLine, RPG::EventScriptData *  scriptData, int  eventId,	int  pageId, int  lineId,	int *  	nextLineId 	) 	
{
// in scriptline ist enthalten welcher Befehl verwendet wurde. 
// scriptLine hat einen Member namens "command" vom Typ RPG::EventCommand, das ist ein enum, aus dem Namensraum RPG
// (http://rpg-maker.cherrytree.at/dynrp...ript_line.html)
if(scriptLine->command == RPG:: EVCMD_CHANGE_SWITCH) // darum hier der Vergleich mit dem Enumwert, der dem Switchbefehl entspricht
{

}

return true;
}

Und wenn ich schon dabei bin, ich verstehe nicht wann ich -> benutzen muss und wann ::

...

:: ist wenn du an einen Namensraum willst, z.B. RPG, kennst du von std::string, dort ist std der Namensraum.
-> wenn du auf Inhalte von etwas zugreifen willst, dass dir als Pointer vorliegt, wie hier scriptLine, siehe Sternchen ;-)

Schau dir am besten dies hier mal an:
http://www.youtube.com/watch?v=YurDkWSh41M
erklärt das einfach und schnell. Die insgesamt 20 Minuten sinds wert wenn man da noch unsicher ist.

[Morden]

Ich kann dich beruhigen Corti; es funktioniert genau so^^ Benutze das ziemlich viel, muss ich sagen.
Wobei man aber dazu sagen muss, dass die jeweiligen Parameter der einzelnen EventCommands nicht von Cherry dokumentiert sind, was heißt dass man die selbst herausfinden muss. Ich habe mir dafür schon den ein oder anderen enum geschrieben^^

[Nachtrag:]
Wobei deine Beschreibung zum "::" nicht *ganz* korrekt ist. Es ist der ScopeResolution-Operator, auch Geltungsbereichsauflösungsoperator, wie er im Deutschen ja auch so schön heißt und er dient allgemein dazu den Geltungsbereich aufzulösen und das nicht nur für NameSpaces, sondern z.B. auch für statische Member oder Methoden einer Klasse. Dieser werden üblicherweise auch durch Klassenname::StatischerKlassenmember aufgerufen
Der "->" hingegen dereferenziert einen Zeiger und greift auf den Member des dereferenzierten Objektes zu, alternativ könnte man dort nämlich auch schreiben (*scriptLine).command, was eben genau das Gleiche wie scriptLine->command bedeutet.

PeAcE
MorDen

[Corti]

Hört auf Morden, dessen Beschreibung ist genauer

[djeurissen]

Ist irgendwie blöd hier nochmal was zu fragen, aber ich habe eben noch ein letztes Problem XD...

Nun kann ich zwar "EVCMD_CHANGE_SWITCH" abfragen, aber wie kann ich nun herausfinden ob der Switch auf True oder False gesetzt wird. Ich dachte ja an Value, aber das funktioniert nicht ._.

Edit: Oder ich weiß welcher Switch überhaupt verändert wird...

[Morden]

Ich kann dir jetzt keine genaue Antwort geben, da ich nicht zu Hause bin, aber normalerweise solltest du diesen Wert bekommen, indem du auf scriptLine->parameters[1] zugreifst, denn scriptLine->parameters[0] sollte - wenn ich nicht ganz falsch liege - die SwitchID beinhalten (so, wie sie auch im Maker selbst indexiert wird, also beginnend bei "1").

Genaueres kann ich dir aber erst sagen, wenn ich zu Hause bin, wobei ich mir relativ sicher bin, dass das so hinhauen müsste.

Edit:
Hinweis: Bei onEventCommand ist jeder Eintrag im parameters[]-Array ein Zahlenwert und es gibt maximal einen String-Wert, welcher sich mit scriptLine->stringParameter auslesen und manipulieren lässt!

PeAcE
MorDen

[Corti]

Siehe Morden, die Paramter der einzelnen EventCommands sind nicht dokumentiert. Musst selber mal schauen was dir da als Parameter übergeben wird und was bei verschiedenen Aufrufen so drin ist.

[djeurissen]

Achso, ich dachte ich müsste über "EVCMD_CHANGE_SWITCH" auf das ganze zugreifen, aber das ist alles schon in nem Array drinne...
Jetzt habe ich es verstanden, danke XD

[Morden]

Du greifst quasi auf das SkriptKommando selbst zu! Dabei musst du dir das so vorstellen, dass du alle Parameter auslesen kannst, die du in diesem SkriptKommando im Maker selbst auch vergeben kannst! Diese Parameter kannst du aber nicht nur auslesen, sondern halt auch manipulieren.

PeAcE
MorDen

[djeurissen]

Okay, vielen dank^^

Hab mir auch ein Enum erstellt um den Überblick zu behalten, wobei es nicht gerade einfach war herauszufinden wo der unterschied zwischen parameters[1] und parameters[2] liegt XD

[Morden]

@djeurissen
Was wäre denn der Unterschied, den du herausfinden konntest?

@Topic
Um euch mal die Arbeit zu erleichtern herauszufinden, welche Parameter ein EventCommand hat möchte ich euch hier mal mein kleines »EventTracker« PlugIn zur Verfügung stellen.
Im Endeffekt ist es extrem billig und macht nichts weiter, als jedes einzelne EventCommand zu tracken und mit seinem Namen und Parametern in einen stream zu schreiben. Dieser wird beim Beenden dann in die Datei "dbg.txt" im root-Verzeichnis des Spieles gespeichert.

Hier mal ein Beispiel, wie ein solches EventCommand vom Tracker abgespeichert wird (hier im Beispiel das ShowPicture-Command):

Code:

Command: Show picture (11110)
EventID: 1
PageID: 6
lineID: 19
nextLineID: -1
Parameter-0 --> 15
Parameter-1 --> 0
Parameter-2 --> 160
Parameter-3 --> 224
Parameter-4 --> 0
Parameter-5 --> 100
Parameter-6 --> 100
Parameter-7 --> 1
Parameter-8 --> 100
Parameter-9 --> 100
Parameter-10 --> 100
Parameter-11 --> 100
Parameter-12 --> 0
Parameter-13 --> 100
Parameter-14 --> 100
Parameter-15 --> 68
StringParameter -->tb-facebox

Das tut der Tracker mit allen EventCommands, außer dem Comment - da ich das für nicht nötig hielt das mit zu tracken.

Hier der Download: EventTracker.dll

PeAcE
MorDen

[Corti]

Exzellente Arbeit, nice!

[Morden]

Das Teil schwirrt schon ewig in meinem TestProjekt rum^^ Und wenn ich damit jemanden helfen kann, dann bin ich schon froh =D

Ich möchte aber noch dazu sagen: Verwendet es bitte NUR für solche Einsatzzwecke, da es bei sehr vielen EventCommands doch schon eine beträchtliche Datenmenge erzeugt und diese ja auch im Speicher hält. Anfangs hatte ich noch sofort nach jedem EventCommand speichern lassen, das hat sich aber als sehr, sehr langsam erwiesen - deshalb entschloss ich mich die Datei erst beim Beenden speichern zu lassen.

Also: Zum rausfinden der Parameter -> PlugIn reinkopieren und wenn ihr eure Daten habt, schmeißt es wieder raus. Das PlugIn meldet ja, ob es geladen wurde oder nicht.
Ist nur eine Empfehlung von mir, was ihr natürlich macht ist eure Sache

PeAcE
MorDen

[Nachtrag:]
Vielleicht sollten wir mal irgendwie die EventCommands zusammentragen - ich denke das würde vielen von uns einiges an Zeit ersparen.
Deswegen fange ich mal an - hier meine enums zu ShowPicture und MovePicture, leider weiß ich nicht, was der letzte Zahlenparameter bei ShowPicture bedeutet; deshalb habe ich ihn als "UNKOWN" gekennzeichnet:

Code:

//  Event parameter list for "Show Picture" command  //
//  Filename saved as string parameter!
enum EVPRM_SHOW_PICTURE {
    EVPRM_SHOW_PICTURE__PICTURE_ID,
    EVPRM_SHOW_PICTURE__COORDINATE_OR_VARIABLE,
    EVPRM_SHOW_PICTURE__POSITION_X,
    EVPRM_SHOW_PICTURE__POSITION_Y,
    EVPRM_SHOW_PICTURE__PICTURE_SCROLLS_WITH_MAP,
    EVPRM_SHOW_PICTURE__MAGNIFICATION,
    EVPRM_SHOW_PICTURE__TRANSPARENCY_TOP,
    EVPRM_SHOW_PICTURE__TRANSPARENCY_BOTTOM,
    EVPRM_SHOW_PICTURE__USE_MASK_COLOR,
    EVPRM_SHOW_PICTURE__COLOR_RED,
    EVPRM_SHOW_PICTURE__COLOR_GREEN,
    EVPRM_SHOW_PICTURE__COLOR_BLUE,
    EVPRM_SHOW_PICTURE__COLOR_SATURATION,
    EVPRM_SHOW_PICTURE__EFFECT,
    EVPRM_SHOW_PICTURE__EFFECT_VALUE,
    EVPRM_SHOW_PICTURE__UNKNOWN_1
};

Code:

//  Event parameter list for "Move Picture" command  //
//  There's no filename parameter for the "Move Picture" command
enum EVPRM_MOVE_PICTURE {
    EVPRM_MOVE_PICTURE__PICTURE_ID,
    EVPRM_MOVE_PICTURE__TRANSITION_TIME,
    EVPRM_MOVE_PICTURE__COORDINATE_OR_VARIABLE,
    EVPRM_MOVE_PICTURE__POSITION_X,
    EVPRM_MOVE_PICTURE__POSITION_Y,
    EVPRM_MOVE_PICTURE__MAGNIFICATION,
    EVPRM_MOVE_PICTURE__TRANSPARENCY_TOP,
    EVPRM_MOVE_PICTURE__TRANSPARENCY_BOTTOM,
    EVPRM_MOVE_PICTURE__COLOR_RED,
    EVPRM_MOVE_PICTURE__COLOR_GREEN,
    EVPRM_MOVE_PICTURE__COLOR_BLUE,
    EVPRM_MOVE_PICTURE__COLOR_SATURATION,
    EVPRM_MOVE_PICTURE__EFFECT,
    EVPRM_MOVE_PICTURE__EFFECT_VALUE,
    EVPRM_MOVE_PICTURE__WAIT
};

[djeurissen]

Wäre dafür nicht ein eigener Thread besser geeignet, der dann alle Enum(s?) im Hauptthread zussammenfasst?

Naja, ich zeig hier einfach mal meinen Enum(Und wer die hier besser bennenen kann, kann das gerne tun ._.):

enum EVCMD_CHANGE_SWITCH {
EVCMD_CHANGE_SWITCH_Switch_to_Change,
EVCMD_CHANGE_SWITCH_SwitchID_Beg,
EVCMD_CHANGE_SWITCH_SwitchID_End,
EVCMD_CHANGE_SWITCH_Operation};

So, wo liegt jetzt der Unterschied zwischen "SwitchID_Beg" und "SwitchID_End", beide geben die SwitchID aus. Sollte man jedoch "Switch Range" benutzen, kann man mit diesen beiden Variablen die Range festlegen. Das habe ich leider ohne dein Plugin herausfinden müssen, Gott war das eine Qual...

PS: Wie macht ihr das mit dem "Codefenster"
Edit: Den String habe ich jetzt nicht rausgesucht, kann mir aber gut vorstellen das es der Name des Switches ist...

[Morden]

Ich denke, wenn das gerechtfertigt ist dafür einen eigenen Thread aufzumachen, wäre das wohl angebracht^^

Dann wirst du ja beim nächsten Mal hoffentlich nicht mehr solch eine Qual beim rausfinden erleiden müssen xD Und ich habe gerade nachgeschaut: Das Change Switch Command hat keinen StringParameter. Dieser wäre dann beim abfragen einfach leer.

Das Code-Fenster erzeugst du, wenn du in eckigen Klammern <CODE></CODE> schreibst. Also anstatt der spitzen Klammern die eckigen []. Dazwischen denn den Code^^

PeAcE
MorDen