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

[Stray]

Müssen die vier Einträge nicht unter das [keyboard_mouse_input]?

...

Nein, auch dann funktioniert es bei mir nicht. Ich finde das seltsam, bei Euch allen funktionieren die Tasten doch reibungslos, oder? Sonst wäre das Problem ja bekannt.

[Corti]

Fehler in 0.17:

Code:

bool onCheckEventVisibility ( RPG::Character *  character)
{
    if(character->id == 1)
    {
        return false;
    }

    return true;
}

bool onDrawEvent ( RPG::Character * character, bool isHero )
{

  if(character->id == 1)
    {
        fx::ShowRain();
    }

    return true;
}

Sollte bezwecken, dass Event 1 immer gezeichnet wird, auch wenn es nicht im Sichtbereich ist. Das funtioniert nur in der X-Achse. Sobald das Event in Y aus dem Bild wandert, wird onDrawEvent nicht mehr gerufen.

Was mögliche Fixes angeht, ich benutze noch 0.17 weil 0.20 bei mir damals irgendwas kaputt gemacht hat.

Edit: Die DrawEvent-Callbacks werden jeweils mehrfach aufgerufen. Wtf?

[MintJam]

Hi,
ich arbeite mich grad an dem DynRPG ein (bin eher ein mittelmäßiger Programmierer).
Einfach mal Frage: kann man mit den DynRPG ein eigenes Battle System bauen?

Beste Grüße

[Corti]

Das ist eine phänomenale Frage~ ja und nein.

Es ist eine vollewertige Programmiersprache dahinter, du kannst Eingaben abfragen, Grafiken anzeigen und Sound abspielen. In Theorie und Praxis kannst du mit DynRPG auch ein Echtzeitstrategiespiel einbauen. DynRPG ist noch nicht sooo gut darin umfassend auf die Datenbanken des Makers zuzugreifen, so praktisch wie in Ruby mit den neuen Makern ist es also nicht.

Was meinst du denn genau mit "eigenes Battle System"?

[MintJam]

Was meinst du denn genau mit "eigenes Battle System"?

...

Beispiel ich will den Battle-Commands-Fenster durch einen "Ring-System" ersetzen.

[bugmenot]

DynRPG ist noch nicht sooo gut darin umfassend auf die Datenbanken des Makers zuzugreifen

...

Ähm... wie ein content update aus heiterem Himmel(?)
rechts auf [Download ZIP] klicken
Doku

... es fehlen halt eine ganze Menge callbacks um Herumgefummel mit verschiedenen Sequenzen zu ersparen (für das Verarbeiten von Code zum passenden Zeitpunkt).
Wie viel bei "Herumfummeln mit der richtigen Sequenzierung" verbleiben soll kann ich nicht sagen. Ich kann neue Sachen testen, will aber nicht zu viel zumüllen.

[Corti]

Muss ich wohl mal testen.

Bugmenot, ist dir der SkillWindowDuration-Fix bekannt?

Im ersten DynRPG hatte die Cherry die Anzeigedauer dieses "Monster nutzt X skill" -Fensters erhöht. Das hat nahezu jede Form eines intelligenten Kampfsystems ruiniert, weil die Eventverarbeitung dadurch korrumpiert wurde. Es gab dafür einen Fix. also für 0.17. In 0.20 funktioniert der nicht mehr, weil es dort eine "bessere" Version gab, wenn ich mich recht entsinne. Besser war aber immer noch Mist, weshalb ich meine Plugins allesamt für 0.17 mache und 0.20 ignoriere.

Hier ist das Ding:
http://share.cherrytree.at/showfile-...w_duration.ips

Magst mal schauen, was das tut?

[bugmenot]

normal SkillWindowDuration-Fix

...

In Dyn0.14 wurden die Delays nach dem Einsatz von Items und den Monsteraktionen DoubleAttack / Defend / Observe / Charge / SelfDestruct / Escape von 40 Frames auf 90 Frames erhöt.
Der normal_skill_window_duration fix überschreibt das wieder mit 40.
Dyn0.20 nutzt wieder 40 Frames, nimmt diese Zahl aber aus einem call to function her << hier macht der normal_skill_window_duration fix alles kaputt, weil er in die Sprungweite der call-Anweisung schreibt >> dann wird eine falsche Adresse aufgerufen und die Applikation stürzt ab.

In Dyn0.14 wurde der Delay nach Skills von 30 auf 90 Frames erhöt. SkillWindowDuration macht 30 Frames daraus, Dyn0.20 macht 50 Frames daraus.

Dies hier sollte in Dyn0.20 wieder 30 Frames (nach einer Skillaktion) daraus machen:

[QuickPatches]
DefaultDelay(SkillAction)=49B9F8,1E,49B9FD,14

...

Dass das Abziehen der MP-Kosten und die Verarbeitung des Skills durch das bisschen mehr Wartezeit an anderer Stelle etwas kaputt macht, ist bedauerlich.

Alternativ kannst du ja das Schließen des Fensters mit dem SkillNamen über

Code:

    ( *reinterpret_cast<char *> (0x49BA08)) = 0xEB;
    ( *reinterpret_cast<char *> (0x49BA09)) = 0x06;

ausknipsen und an anderer Stelle mit einem eigenen Fix selber durchführen über:

Code:

        int eax = ( *reinterpret_cast<int ***> (0x4CDD38) )[0][16];   //window pointer = ActionMessageWindow
        asm volatile("call *%%esi"
                     :
                     : "S" (0x4C66E4), "a" (eax)
                     : "cc", "memory");
        //terminate Window (specified by window pointer)

[Sölf]

Wo ich das gerade mit den MP lese, im 2k3 KS wird ja keine MP Heilung/Schaden angezeigt. Könnte man das auch anzeigen lassen? Vielleicht in einer andersfarbigen Zahl als Grün (HP Heilung) bzw. dem standard Blau (Hp Schaden) - oder was auch immer für eine Farbe aus der Textbox genommen wird.

[bugmenot]

http://rpgmaker.net/engines/rm2k3/utilities/35/

[Sölf]

Ah, danke!

[Corti]

[QuickPatches]
DefaultDelay(SkillAction)=49B9F8,1E,49B9FD,14

...

hex 1E = 30
hex 14 = 20

Ich sehe wo die Framezahl sitzt, was ist der andere Wert?

[bugmenot]

Ich sehe wo die Framezahl sitzt, was ist der andere Wert?

...

Framezahl (wenn man eine Taste gedrückt hält, welche als "Enter" belegt wurde).



Attribute/Condition Resistance Control
download ResistControlBug-in

Erlaubt das Kontrollieren von Attribut- und Conditionresistenzen von Helden und Gegnern.


>> SET ATTRIBUTE RESIST

Nutzt einen Comment mit dem Inhalt:

@set_arc_hero [1], [2], [3]

[1] = Hero_ID (aus dem Reiter actor/hero in der F8-Database)
[2] = Attribute_ID
[3] = neuer Schadensfaktor (in Prozent) (min = -10000% | max = +10000%)

Ersetze [x] mit Zahlen oder einer Var_ID mit einem vorangestellten "V"
Bsp.
"@set_arc_hero V32, 5, -70"

ändert (vom Helden aus Var[0032]) den Schadensfaktor von Attribut 5 auf -70%

>> GET ATTRIBUTE RESIST
@get_arc_hero [1], [2], [3]

[1] = Hero_ID
[2] = Attribute_ID
[3] = Var_ID welche den momentanen Schadensfaktor ausgibt (in Prozent)

>> GET DEFAULT ATTRIBUTE RESIST
@get_adefault_hero [1], [2], [3]

[1] = Hero_ID
[2] = Attribute_ID
[3] = Var_ID welche den Standard-Schadensfaktor ausgibt (in Prozent; einschließlich JobClass und Attributeresistenz durch Ausrüstung)





>> SET CONDITION RESIST
@set_crc_hero [1], [2], [3]

[1] = Hero_ID (aus dem Reiter actor/hero in der F8-Database)
[2] = Condition_ID
[3] = neue Anfälligkeit (in Prozent) (min = -10000% | max = +10000%)

>> GET CONDITION RESIST
@get_crc_hero [1], [2], [3]

[1] = Hero_ID
[2] = Condition_ID
[3] = Var_ID welche die momentane Anfälligkeit ausgibt (in Prozent)

>> GET DEFAULT CONDITION RESIST
@get_cdefault_hero [1], [2], [3]

[1] = Hero_ID
[2] = Condition_ID
[3] = Var_ID welche die Standard-Anfälligkeit ausgibt (in Prozent; einschließlich JobClass und Conditionresistenz durch Ausrüstung)







>> SET ATTRIBUTE RESIST (monster)
@set_arc_monster [1], [2], [3]

[1] = Enemy_Party_ID (#1 .. #8 anhand der Nummer innerhalb der MonsterGoup)
[2] = Attribute_ID
[3] = neuer Schadensfaktor (in Prozent) (min = -10000% | max = +10000%)

>> GET ATTRIBUTE RESIST (monster)
@get_arc_monster [1], [2], [3]

[1] = Enemy_Party_ID
[2] = Attribute_ID
[3] = Var_ID welche den momentanen Schadensfaktor ausgibt (in Prozent)

>> GET DEFAULT ATTRIBUTE RESIST (monster)
@get_adefault_monster [1], [2], [3]

[1] = Hero_ID
[2] = Attribute_ID
[3] = Var_ID welche den Standard-Schadensfaktor ausgibt (in Prozent)





>> SET CONDITION RESIST (monster)
@set_crc_monster [1], [2], [3]

[1] = Enemy_Party_ID (#1 .. #8 anhand der Nummer innerhalb der MonsterGoup)
[2] = Condition_ID
[3] = neue Anfälligkeit (in Prozent) (min = -10000% | max = +10000%)

>> GET CONDITION RESIST (monster)
@get_crc_monster [1], [2], [3]

[1] = Enemy_Party_ID
[2] = Condition_ID
[3] = Var_ID welche die momentane Anfälligkeit ausgibt (in Prozent)


>> GET DEFAULT CONDITION RESIST (monster)
@get_cdefault_monster [1], [2], [3]

[1] = Enemy_Party_ID
[2] = Condition_ID
[3] = Var_ID welche den Standard-Schadensfaktor ausgibt (in Prozent)

Allows to control attribute and condition resistances of heroes and enemies.


>> SET ATTRIBUTE RESIST

Use a comment with the contents:

@set_arc_hero [1], [2], [3]

[1] = Hero_ID (from actor/hero tab in F8-database)
[2] = Attribute_ID
[3] = new damage multiplier (in percent) (min = -10000% | max = +10000%)

Substitute [x] with numbers or a Var_ID with a "V" in front
e.g.
"@set_arc_hero V32, 5, -70"

will have the hero from Var[0032] change his/her damage multiplier of Attribute 5 into -70%

>> GET ATTRIBUTE RESIST
@get_arc_hero [1], [2], [3]

[1] = Hero_ID
[2] = Attribute_ID
[3] = Var_ID to store current damage multiplier (in percent)

>> GET DEFAULT ATTRIBUTE RESIST
@get_adefault_hero [1], [2], [3]

[1] = Hero_ID
[2] = Attribute_ID
[3] = Var_ID to store default damage multiplier (in percent; includes JobClass and AttributeResistance from equipment)





>> SET CONDITION RESIST
@set_crc_hero [1], [2], [3]

[1] = Hero_ID (from actor/hero tab in F8-database)
[2] = Condition_ID
[3] = new susceptibility (in percent) (min = -10000% | max = +10000%)

>> GET CONDITION RESIST
@get_crc_hero [1], [2], [3]

[1] = Hero_ID
[2] = Condition_ID
[3] = Var_ID to store current susceptibility (in percent)

>> GET DEFAULT CONDITION RESIST
@get_cdefault_hero [1], [2], [3]

[1] = Hero_ID
[2] = Condition_ID
[3] = Var_ID to store default susceptibility (in percent; includes JobClass and ConditionResistance from equipment)







>> SET ATTRIBUTE RESIST (monster)
@set_arc_monster [1], [2], [3]

[1] = Enemy_Party_ID (#1 .. #8 by number in MonsterGoup)
[2] = Attribute_ID
[3] = new damage multiplier (in percent) (min = -10000% | max = +10000%)

>> GET ATTRIBUTE RESIST (monster)
@get_arc_monster [1], [2], [3]

[1] = Enemy_Party_ID
[2] = Attribute_ID
[3] = Var_ID to store current damage multiplier (in percent)

>> GET DEFAULT ATTRIBUTE RESIST (monster)
@get_adefault_monster [1], [2], [3]

[1] = Hero_ID
[2] = Attribute_ID
[3] = Var_ID to store default damage multiplier (in percent)





>> SET CONDITION RESIST (monster)
@set_crc_monster [1], [2], [3]

[1] = Enemy_Party_ID (#1 .. #8 by number in MonsterGoup)
[2] = Condition_ID
[3] = new susceptibility (in percent) (min = -10000% | max = +10000%)

>> GET CONDITION RESIST (monster)
@get_crc_monster [1], [2], [3]

[1] = Enemy_Party_ID
[2] = Condition_ID
[3] = Var_ID to store current susceptibility (in percent)


>> GET DEFAULT CONDITION RESIST (monster)
@get_cdefault_monster [1], [2], [3]

[1] = Enemy_Party_ID
[2] = Condition_ID
[3] = Var_ID to store default susceptibility (in percent)

Und nochmal alle pseudo-Callbacks bisher:
download ExtBug-in.cpp

int onGetLevelEXP ( int HeroId, int Level )
int onGetAttributeResist ( int AttributeId, int DefaultABCDE, int TargetPartyId, bool TargetIsMonster )
int onGetConditionResist ( int ConditionId, int DefaultABCDE, int TargetPartyId, bool TargetIsMonster )

[Corti]

Das Attribute/Condition Resistance Control-Ding, kann das irgend etwas, dass man mit DynRPG v0.30 noch nicht machen kann?

[bugmenot]

Das Attribute/Condition Resistance Control-Ding, kann das irgend etwas, dass man mit DynRPG v0.30 noch nicht machen kann?

...

Kopfschmerzen ersparen.
Du müsstest dir die default-Werte irgendwo abspeichern, dann die richtige Sequenz herausfinden, wer/was angegriffen wird, unter RPG:: Attribute oder RPG:: Condition die entsprechenden Werte abändern und wieder die default-Werte wiederherstellen bevor jemand anderes angegriffen wird. Vorallem muss man dann nicht noch extra herausfinden ob A, B, C, D oder E gilt mit Equipment und JobClasses.

Ansonsten kann man auch mit der Ext.dll als Grundlage entsprechende pseudo-Callbacks nutzen. Dann erspart man sich dieses "Wiederherstellen des Defaults".


Und der Spielordner wird nicht zugemüllt, weil die Werte allesamt in die RPG:: Battler eingebunden wurden (liegen im erweiterten DArray<short, 1> RPG:: Battler:: attributes bzw. conditions von einzelnen Helden innerhalb/außerhalb der Party und von einzelnen Monster-Objekten im Kampf). Mir fällt jetzt kein anderer temporärer Speicher ein, kann mich aber gerne eines Besseren belehren lassen.