Results 1 to 20 of 232

Thread: DynRPG - Der Pluginwunschthread

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Wenn ich denn mal ein onDrawCharacter-Callback mache (was ich vorhabe), hoffentlich. Im Moment wirds wohl schwierig.

  2. #2
    Nun zu etwas eher Exzentrischen: Ich überlege seit längerem, ob es nicht eine Möglichkeit gibt, Monster in ihrem Level skalieren zu lassen. Das Feature würde ich gerne als Plugin lösen, ich bräuchte also ( mal wieder ) Speicheradressen-Knowhow.

    Ich bräuchte:
    - lesenden und schreibenden Zugriff auf die in der aktuellen Monsterguppe befindlichen Status-Werte ( Atk, Def, Int, Agi , Exp, Gold )
    - lesenden und schreibenden Zugriff auf die Monsterdatenbank und deren Werte. Ich gehe mal davon aus, dass die getMaxHp-Funktionen etc. der Monster auf die Einträge der Datenbank verweisen.

    Was ich tun würde:
    - Werte des Monsters aus der DB auslesen und in eigener Datenstruktur sichern
    - MonsterEintrag in DB und in Monstergruppe mit aktuellen Werten überschreiben
    - Nach Kampfende die Originalwerte zurückschreiben

    Was ich beisteuern kann: (weniger für Cherry als für bugmenot )
    static RPG::CatalogPtr<RPG::Monster *> &monsters = (**reinterpret_cast<RPG::CatalogPtr<RPG::Monster *> **>(0x4CDE64));
    Dort sind die aktuellen Monster.

    Monster (TLcfgMonsterItem) erbt von ( TLcfgUnitItem ), die Aufrufe von getMaxHp werden in DynRPG über die vTable gemacht. Was sind das, Funktionszeiger?

  3. #3
    Quote Originally Posted by Corti View Post
    lesenden [...] Zugriff auf die in der aktuellen Monsterguppe befindlichen Status-Werte

    Keine Ahnung, wie man den Zugriff von RT -(read)-> DB auf RT -(write)-> DB umdrehen kann.

    Quote Originally Posted by Corti View Post
    *> **>(0x4CDE64));
    Da steht mehr als nur die PartySize drin? Hm...

    Quote Originally Posted by Corti View Post
    Monster (TLcfgMonsterItem) erbt von ( TLcfgUnitItem ), die Aufrufe von getMaxHp werden in DynRPG über die vTable gemacht. Was sind das, Funktionszeiger?
    vTable? Nevermind...

    Unter TLcfgMonsterItem und TLcfgUnitItem befinden sich Funktionen zur Vergabe und Berechnung von Werten/Schaden/Logik:

    Last edited by bugmenot; 22.01.2014 at 18:02.

  4. #4
    Hey, danke für deine Mühen. So hardwarenahes entspricht nicht unbedingt meinem Metier, als verzeih, wenn ich blöde Sachen frage ;-)

    In deiner Tabelle gibt es
    481748(2k)|4BFB28(2k3) <>GetStr

    Die Adresse entspricht dabei der hier aus Cherrys Battler-Klasse.
    Quote Quote
    int Battler::getAttack() {
    int ret;
    asm volatile("call *%%esi" : "=a" (ret) : "S" (0x4BFB28), "a" (this) : "edx", "ecx", "cc", "memory"); // GetATK
    return ret;
    }
    D.h. eigentlich müsste ich mir analog dazu mit dem hier 4BD7AC(2k3) <>SetEnemy_Atk, eine setAttack-Funktion basteln können, wenn ich anstatt des this den Zeiger auf das Monsterobjekt übergebe, oder inwiefern irre ich mich da?

  5. #5
    Quote Originally Posted by Corti View Post
    [...]setAttack-Funktion basteln können, wenn ich anstatt des this den Zeiger auf das Monsterobjekt übergebe, oder inwiefern irre ich mich da?
    Also das this als Input ist eigentlich ein Verweis auf die Adresse, an der alle notwendigen Daten für die Kampfteilnehmer geschrieben stehen. Das Problem ist, dass die SetEnemy[XYZ]-Funktionen sich daraus nur die Enemy_ID rauspicken und anhand dieser den Eintrag aus der .ldb laden.

    Also:
    Basteln: ja (Den output hinter jedem call sub_482A80 <>GetEnemyParam mit einem zugewiesenen Wert multiplizieren)
    Aber eher: nein (Ich habe 86 byte Spielraum bei den ganzen SetEnemy[XYZ]-Funktionen. Ich schaue mal, was sich machen lässt. Gib mir einen oder besser zwei Momente.)



    +Post #137 nochmal in Ruhe durchles+

    Du brauchst also eine Funktion, die die gesamte RPG_RT.ldb ausliest und in eine RPG_RT.cdb schreibt, auf die du vollen Zugriff hast, und die Funktionen, die normalerweise aus der .ldb lesen, müssen auf die .cdb umgeleitet werden?

    An offset 0047DDB8 kann man auf den Dateinamen der Datenbank verweisen, aus der gelesen wird. Würde jetzt heißen, man müsste onStartUp "copy RPG_RT.ldb -> create RPG_RT.cdb" machen und dann halt Werte in der .cdb umschreiben. In der RM Interna stand irgendwas über die Struktur der LcfDataBase. Mehr kann ich nicht sagen, weil ich habe keine Ahnung von EDV und so...

  6. #6
    Das klingt jetzt plötzlich sehr umfangreich.

  7. #7
    download MonSca(fixed)
    Edit: (15.06.14)
    ...da ist wohl was schiefgelaufen. Sorry.






    Edit:
    Wer aus irgendeinem Grund FastFadeIn benutzt... well, don't use it.
    Ansonsten könnte ich mal schauen, wo ich den Code hinschieben kann.

    Last edited by bugmenot; 15.06.2014 at 17:30.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •