[DynRPG Plugin]Text Plugin

[Cherry]

Vorschlag: Fenster zusammenbauen lassen, entweder auf Basis von Pictures oder des Systemsets: http://rpg-maker.cherrytree.at/dynrp...3d675320eb26c3

[Kazesui]

http://rpg-maker.cherrytree.at/dynrp...3d675320eb26c3

...

Ah, da ist doch die Load Font Methode, die ich sicher war daß ich mal gesehen hatte, aber halt nicht mehr finden konnte als ich an dem Text Plugin anfing.
Und @Fenster zusammen zubauen, will ich auch noch, nur nicht sicher wann

[Cherry]

Dieses LoadFont ist aber mit Vorsicht zu genießen. Das Textsystem des Makers hat immer nur eine Font geladen und eine Font zu laden ist eine (vergleichsweise) langsame Methode weil die Buchstaben mit dem Systemset und dem Glyph kombiniert und zwischengespeichert werden, wenn mich nicht alles täuscht. Das heißt die Methode dann irgendwie 100x pro Sekunde aufzurufen oder so ist eine ganz schlechte Idee.

Ich hatte das verlinkt wegen des systemImage Members.

[Kazesui]

Schon klar @systemImage Members, halt hatte ich nach dem loadFont methode schonmal gesucht.
Werde natürlich ausprobieren müssen wie gut es sich benutzen lässt, und sollte ja eigentlich nur 2 mal pro Befehl gerufen werden, bzw. einmal vor das schreiben des Textes an einem Image, und dannach wieder zurück zum default (was wohl möglicherweise auch ärger bereiten kann im falle vom schon geänderten Font je nachdem).

[Cherry]

Das Problem ist man kann zurzeit die Defaultfont nicht auslesen. Speed: Für einmaliges Textgeschreibe gehts ja, aber wenn das z.B. eine Zahlenanzeige ist die der Benutzer in jedem Frame aktualisieren will - ich sehe die Lagprobleme schon kommen.

EDIT: Hm, ich hätte sogar einen Workaround für das Auslesen der Defaultfont:

Code:

char * getDefaultFont() {
    return reinterpret_cast<char *>(RPG::system->systemFont == RPG::SYSF_MSGOTHIC ? 0x4884D4 : 0x4884EC);
}

[Kazesui]

Kewl @workaround.

Wo wir schon dabei sind, hast du irgendein besonderen weg die Speicher Adressen zu finden? Und weiß du ob evt. die sonstige Item Optione möglicherweise nahe an die Selbe Addresse von dem du der Name holst? Ich könnte dank deinem Chipset pointer schon die Terrain ID's und "Passbarkeigt" finden, und wurde gern sehen ob ich dasselbe noch für die Items und Skills tun könnte, wenn ich irgendein Referenz Punkt hätte.

[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.

[Kazesui]

Vielen dank!
Da werd ich mal sehen was ich noch so finden kann

[Cherry]

Ich hab vorhin den Post nochmal editiert, falls du es nicht gesehen hast...

[Oktorok3]

@Cherry
Um nochmal auf die Sache mit dem Item-Pointer zurückzukommen,
so wie du das sagst, klingt das ja recht einfach

...nur dass es noch keinen Item-Pointer für den 2k3 gibt.

Wobei das in DynRPG auch zu lösen wäre. Man könnte z.B. ein Item als "Magic Value" verwenden, was in der DynRPG.ini festlegbar ist, sagen wir mal Item #666.
Wenn dieses Item in einem der Item-Eventbefehle ausgewählt ist, wird stattdessen die Item ID aus einer Variable (auch in der INI festzulegen) gelesen.

onEventCommand wäre das richtige Callback, man kann da nämlich auch die Parameter zur Laufzeit umschreiben.

...

Kannst du das nicht locker machen, also ein kleines Plugin dazu? Würde mir eine Menge Arbeit ersparen.
Solche Sachen schiebe ich momentan auf (alles Manuell im Maker ohne derartige Stützen einzustellen), weil bestimmte Dinge mit den bisher vorhandenen Möglichkeiten nicht mehr wirklich übersichtlich oder einfach zu umständlich zu Scripten sind.

Falls das kein Problem für dich ist und du das machst, wäre ich wirklich dankbar!

@Kazesui, Cherry
Da ich wie bereits bekannt ein Menü mit dem Plugin erstelle, wäre es natürlich umso hilfreicher, wenn auch z.B. Die Heldenklassen abgefragt werden können. ->möglich?
Nochmal nachgefragt: Ist es wirklich ein so großes Problem noch die Heldenwerte hinzuzufügen?
Ich weiß, das man die meisten auch schon im Maker speichern kann, nur will ich es so machen, das die Helden nicht auf vorbestimmten Plätzen sein müssen ->Held 1 Platz1, Held 2 Platz 2 usw.
Set Var 2000->Held ID1 LV, Set Var 2001->Held ID1 EXP, Set Var 2002->Held ID1 HP usw.
Diese Methode für 10 Werte und sagen wir 40 Heldenplätze in der Datenbank anzuwenden, wenn man Heldenplätze auch noch für andere Dinge (z.B. Namenspeicherungen aller Art) verwendet, ist dann ja um einiges umständlicher und Variablenfressender als einfach in einem Comment einzugeben:
@write_text "lv1", 0, 30, "\(levelHeld)[1]"
@write_text "lv1", 0, 30, "\(levelHeld)[367]"
@write_text "hp1", 0, 30, "\(hpHeld)[367]" usw.

[Cherry]

Naja du kannst derweil ja einfach RMEventFactory nehmen und dir damit ein Common Event erstellen lassen was wie z.B. ein Heldpointer funktioniert.

Also du machst sowas:

<> Conditional Branch: If Var[HeldID] == 99
....<> Change Variable [HeldHP] = HP von Held #99
: End Case

Und dann lässt du dir von RMEventFactory das z.B. 20x kopieren und statt "99" eben von 1 bis 20 durchlaufen lassen.
Das verwendest du dann als Common Event, etwa so:

<> Change Variable [HeldID] = 4
<> Call Event: Helden-HP abfragen
<> Message: Held 4 hat \v[HeldHP] HP!

@Kazesui:
Wäre natürlich toll wenn du das irgendwann so erweitern könntest dass es nicht mehr (nur) das Standardtextsystem nutzen kann sondern eigene Fonts aus Bildern (wie das Textbox-Skript für den 2k mit Destiny). Zu Beachten ist dabei die Palette - am performantesten wäre es wenn man festlegt dass alle Fontbilder die im selben RM-Picture gezeigt werden, dieselbe Palette haben müssen.

@all:
Hab ich jetzt nicht getestet, aber wenn ich mich richtig erinnere, müsste mit dem Plugin auch $A und dergleichen gehen, weil die Makerengine das automatisch richtig anzeigt!

[Oktorok3]

Danke Cherry, sehr gute Methode!
Auf diese Idee bin ich bisher nicht gekommen -
sehr simple Lösung, bei diesem scheinbar komplizierten Problem.
Süperb!