[DynRPG Plugin]Text Plugin

[Cherry]

Naja, ich hab eine über mehr als 5 Jahre aufgebaute Datenbank, im Prinzip ist das der Assemblycode des Makers, aber kommentiert und die diversen Adressen und Funktionen mit Namen versehen, etc.

Dann hilft dir wohl der Sourcecode der DynRPG-Funktionen weiter:

Code:

	std::string getSkillName(int id) {
		DStringPtr *p = (**reinterpret_cast<NamedCatalogPtr<DStringPtr *> **>(0x4CDBC4))[id];
		if(!p) return "";
		return p[2];
	}

	std::string getSkillDescription(int id) {
		DStringPtr *p = (**reinterpret_cast<NamedCatalogPtr<DStringPtr *> **>(0x4CDBC4))[id];
		if(!p) return "";
		return p[3];
	}

	std::string getItemName(int id) {
		DStringPtr *p = (**reinterpret_cast<NamedCatalogPtr<DStringPtr *> **>(0x4CDB14))[id];
		if(!p) return "";
		return p[2];
	}

	std::string getItemDescription(int id) {
		DStringPtr *p = (**reinterpret_cast<NamedCatalogPtr<DStringPtr *> **>(0x4CDB14))[id];
		if(!p) return "";
		return p[3];
	}

	std::string getConditionName(int id) {
		DStringPtr *p = (**reinterpret_cast<NamedCatalogPtr<DStringPtr *> **>(0x4CDE84))[id];
		if(!p) return "";
		return p[2];
	}

(Die Funktionen gibts ja nur weil ich noch keine RPG::Skill und RPG::Item Klassen gemacht habe aber trotzdem schon Zugriff auf diese wesentlichen Teile ermöglichen wollte.)

Die Adressen da sind also genauso zu verstehen wie etwa die Adresse von RPG::actors, was z.B. so deklariert ist:

Code:

static RPG::NamedCatalogPtr<RPG::Actor *> &actors = (**reinterpret_cast<RPG::NamedCatalogPtr<RPG::Actor *> **>(0x4CDDC8));

Du kannst dir also RPG::skills, RPG::items und RPG::conditions so denken:

Code:

static RPG::NamedCatalogPtr<RPG::Skill *> &skills = (**reinterpret_cast<RPG::NamedCatalogPtr<RPG::Skill *> **>(0x4CDBC4));
static RPG::NamedCatalogPtr<RPG::Item *> &items = (**reinterpret_cast<RPG::NamedCatalogPtr<RPG::Item *> **>(0x4CDB14));
static RPG::NamedCatalogPtr<RPG::Condition *> &conditions = (**reinterpret_cast<RPG::NamedCatalogPtr<RPG::Condition *> **>(0x4CDE84));

...nur dass die Klassen dazu noch nicht definiert wurden.

Wenn du jetzt beispielsweise RPG::Skill so beginnst zu definieren:

Code:

	class Skill {
		public:
			void **vTable;
			int id;
			DStringPtr name;
			DStringPtr description;
			
			// Hier kommt noch mehr, was ich aber noch nicht analysiert und dokumentiert habe
	}

...kannst du das schon so verwenden:

Code:

RPG::skills[123]->name

Das ganze SDK baut ja auf einem riesigen Hack auf, der nur durch Variablenreferenzen und der Zuweisung durch direkt derefernzierte, zu einem Pointer gecastete Konstatadressen funktioniert, dazu Wrapperklassen wie NamedCatalogPtr die einfache Array-Syntax für komplexe Delphi-Datenstrukturen erlauben und in C++ "nachgebaute" Delphi-Klassen. Dadurch sind meine Klassen binärkompatibel mit denen des Makers, die Variablenreferenzen verweisen direkt auf die Objekte des Makers und dein Compiler erzeugt dann Code der direkt diese Objekte manipuliert, ohne einen "Zwischenlayer". Das meiste von DynRPG wird ja "wegkompiliert", d.h. wenn du z.B. "RPG::system->saveAllowed = false;" schreibst, erzeugt dein Compiler Code der wirklich nur den Wert einer Variablen ändert, als wenn der Maker es selbst getan hätte. Dadurch ist DynRPG ja auch viel schneller als etwa der DestinyPatch.