[DynRPG Plugin]Text Plugin

[Oktorok3]

Zuerst hab ich mal die neue @remove_all Funktion getestet->
Resultat: Erst kommt für jeden Text, der gelöscht werden soll eine allgemeine Meldung mit dem Namen des Textes, die man wegklicken muss z.B.

(Meldung vom Namen des Textes

Dann musste ich den Char ein weiteres mal anklicken, bis seine Texte removed wurden :/

Ich habe ich bei mir noch zwei weitere Funktionen hinzugefügt,
die du deinem Source-Code auch noch hinzufügen solltest:

case 'N':
{
int n = atoi(parseText(s.substr(2, size)).c_str());
return RPG::actors[n]->getDegree();
}
case 'c':
{
int n = atoi(parseText(s.substr(2, size)).c_str());
return RPG::getConditionName(n);
}


Fürs Readme:
\c[number] Returns the name of a condition with ID equal to chosen number.
\N[number] returns the degree of a hero given by the chosen number

Einen Fehler im readme bitte ich dich auch noch zu verbessern-> \v[number] kann man so nicht verwenden, sondern nur-> Vnumber returns the value stored in variable with ID equal to the chosen number
also bitte nur das so geschriebene zum neuen ändern, nicht die Funktion zum vorher geschriebenen...

Bitte auch die Buchstaben behalten, da ich diese schon verwendet habe.
Wäre außerdem hilfreich, wenn du jedesmal den neuen source-code mit hochladen würdest!

Ich bitte dich außerdem noch->
Current level,
Current experience points,
getMaxHp,
getMaxMp,
getAttack,
getDefense,
usw...
für alle Maximalwerte und dasselbe noch für die aktuellen HP
und MP Werte hinzuzufügen, da ich diese Dinge gerne mit dem Textplugin benutzen würde und ich keine Ahnung habe, wie man diese hinzufügen kann, ohne das Fehler (Errors beim Compile- und Build Befehl von devcpp) autauchen.

Und natürlich freue ich mich über die neue Funktion
Es ist wie ich gemerkt habe möglich, beliebig viele Zeilen damit hinzuzufügen, (sehr gut!) nur wäre es besser, wenn man schreiben könnte z.B. @append_line(15) und später dann einzelne Zeilen mit @remove_line(15) wieder zu löschen.

[Kazesui]

Zuerst hab ich mal die neue @remove_all Funktion getestet->
Resultat: Erst kommt für jeden Text, der gelöscht werden soll eine allgemeine Meldung mit dem Namen des Textes, die man wegklicken muss z.B.

...

Hab ich für das debuggen benutzt, und anscheinend ganz schnell vergessen wieder weg zu tun. Sollte jetzt weg sein.

Ich habe ich bei mir noch zwei weitere Funktionen hinzugefügt,
die du deinem Source-Code auch noch hinzufügen solltest:

case 'N':
{
int n = atoi(parseText(s.substr(2, size)).c_str());
return RPG::actors[n]->getDegree();
}
case 'c':
{
int n = atoi(parseText(s.substr(2, size)).c_str());
return RPG::getConditionName(n);
}

...

Sind jetzt auch drin, nur wird \a (wie in ailment) statt \c benutzt. Das ist weil beim Normalen Nachrichten werden \c für die Farbe des Textes benutzt, und um es so Intuitiv wie möglich zu halten, werde ich da nicht \c benutzen. Zudem kann es auch sein dass ich später irgendwann mal \c für ein ähnliches Farben befehl machen werde (damit nicht das ganze Text der selbe Farbe kriegen muss).

Verstehe aber nicht was du meinst mit damit dass es im Readme ein Fehler gibt bezuglich \v[number]. Entweder hast du einem Bug gefunden, was nichts mit dem readme zu tun hat, oder du hast den Readme nicht klar genug gelesen, bzw.
"It's possible to use 9 special commands within the text string itself",
was so viel heisst dass der \v[nummer] innerhalb Quotations Zeichen sein muss damit es funktioniert, und es auch nur dort funktionieren wird, wo man auch ein Text als Parameter reinschrieben kann (z.b. nicht für dem Position des Textes weil der Parameter dafür nur ein Nummer sein kann).

Ich bitte dich außerdem noch->
Current level,
Current experience points,
getMaxHp,
getMaxMp,
getAttack,
getDefense,
usw...
für alle Maximalwerte und dasselbe noch für die aktuellen HP
und MP Werte hinzuzufügen, da ich diese Dinge gerne mit dem Textplugin benutzen würde und ich keine Ahnung habe, wie man diese hinzufügen kann.

...

Die Werte holst du dir ganz einfach indem du sie in einem Variabel einliest, und dann das Variabel als Text anzeigst. Habe da nicht vor extra Funktionen dafür in dem Plugin einzubauen da es kein Problem sein sollte es einfach innerhalb der Maker selbst zu lösen.

wäre es besser wenn man schreiben könnte z.B. @append_line(15) und später dann einzelne Zeilen mit @remove_line(15) wieder zu löschen.

...

Da hast du mir aber neugierig gemacht. Wofür willst du das benutzen?

[Oktorok3]

Okay, funktioniert nun tadellos damit, danke!

Die Werte holst du dir ganz einfach indem du sie in einem Variabel einliest, und dann das Variabel als Text anzeigst. Habe da nicht vor extra Funktionen dafür in dem Plugin einzubauen da es kein Problem sein sollte es einfach innerhalb der Maker selbst zu lösen.

...

Schade das du das nicht auch mit den anderen Werten vorhast, die man auch im Maker in Variablen speichern kann, denn gerade wenn diese im Plugin wären, würdest du mir einen großen Gefallen tun, da...spekulieren wir einfach mal, ich würde gerade zufälligerweise an einem eigenen Menü mit mehr als vier Helden arbeiten, dann wäre es zwar freilich auch kein Problem all das mit dem Maker einzustellen...jedoch wenn ich da für jeden einzelnen Helden jeden Wert in einer Variable speichere, dann komme ich bei einem Helden auf mindestens 10 Variablen, bei 8 Helden auf 80 Variablen usw.
Du siehst, damit kann man eben eine Menge Variablen einsparen.

Und ebenfalls würde es mir eine bedeutend große Hilfe darstellen, wenn du (das vorhergende zwar nicht machen solltest) aber dennoch (und darum bitte ich dich außerordentlich) einstellst, das man durch eine Item ID zusätzlich auch die davon im eigenen Besitz vorhandenen anzeigen lassen kann! (Ich weiß, auch das ist im Maker einstellbar, aber sagen wir mal ich habe 400 Items (400 Variablen) und entscheide mich irgendwann dazu noch zusätzliche 541 möglich zu machen (nun insgesamt 941 Variablen einzustellen), oder will mal in der Itemdatenbank ein bisschen umordnen,
wäre besonders diese neue Funktion eine extrem Variablen-, Zeit- und Arbeitsaufwand sparende Methode!
(Ich will dir nicht zuviel aufhalsen und ich würde es ansonsten einfach selber machen, aber ich kann leider nunmal diese Programmiersprache nicht...)

wäre es besser wenn man schreiben könnte z.B. @append_line(15) und später dann einzelne Zeilen mit @remove_line(15) wieder zu löschen.

...

Da hast du mir aber neugierig gemacht. Wofür willst du das benutzen?

...

Das wäre sicherlich für das Menue an dem ich gerade arbeite von Vorteil.
Eine Erkennung der Nummer der hinzugefügten Zeile ist aber ja auch allgemein äußerst nützlich!

Ein großes Problem jedoch stellt für mich aber derzeit die Tatsache dar, dass es bisher nicht möglich ist, mehrere Textebenen zu erstellen, sprich:
den Text z.B. erst mit der Picture ID 30 und später mit der ID 32 , 34 usw. (eben wie man es gerade benötigt) anzuzeigen, sondern das der gesamte mit dem Plugin geschriebene Text mit ein und derselben PictureID angezeigt und gelöscht werden kann. Mehrere "Ebenen" wären mir von großem Vorteil!
Also das man sagen wir: den Text, der mit der ID30 erstellt wurde kann man per Move Picture sanft verschwinden lassen, die Texte mit PicID32, 34 usw. sollen bleiben.

(Das man sozusagen mehrere Ebenen erstellen kann, indem man bei @write_text verschiedene Zahlen (z.B.@write_text"boy1" @write_text"boy2" usw. verwenden kann weiß ich)

Weitere Frage:
Ist es auch mögich, da der Text über ein Picture angezeigt wird, noch einzustellen, das man ihn sowohl verkleinern, oder vergrößern kann, sprich z. ShowPicture34, Magnification 200% ?

Und pleeeeease dann den neuen source code auch hochladen *anfleh und bettel* !!

[djeurissen]

Wartemal, du brauchst doch nicht für 400 Items 400 Variablen...
Du brauchst gerademal 1...
Du machst eine Unendlichkeitsschleife und fragst jedes Item ab und lässt es dann anzeigen oder nicht und erhöhst dann die Variable, die das Item abfragt um 1...

[Cherry]

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

[djeurissen]

Hups, sry war was müde XD...

Habe nicht richtig nachgedacht was ich geschrieben habe :/...
Ich meinte eigentlich das man nach und nach die 400 Items selber abfragt, das mag zwar total nervig sein braucht aber auch nur 1 Variable.

[Cherry]

Mit RMEventFactory lässt sich da extrem Arbeit sparen.

[Kazesui]

@Oktorok:

Wie hier oben noch erwähnt wurde, brauchst du nicht ein neues Variabel für jedem "Stat".
Einfach ein call event für jedem Held machen wo der wert in einem Temporären Variabel gelesen wird, und dann innerhalb ne Schleife mit dem Plugin raus schreiben. Ist echt kein Problem.
Das es etwas aufwänder für dem Items wäre stimmt schon, kenne da aber auch nicht gerade wo sich diesem wert sich befindet.

Da wäre wohl Cherry's Alternativ dafür eine lösung, aber gehört eher in ein seperates Plugin als noch in diesem einzubauen. So bis das gemacht wäre, bist du da auch noch auf dem Maker Befehle angewiesen.
Die grösse zu ändern wäre zwar möglich, allerdings sieht es ziemlich grausaum aus wenn wenn du was anderes als 100% oder so ab 200% wählen wurdest, und ab 200% wirds schon ziemlich gross.
Da bin ich auch noch ein bisschen faul, weil ich dann den Save und Load Funktionen noch umschreiben muss, und ich denke 200%+ geht auch locker mit Bilder (Kannste ja sogar ein andere font benutzen), da sie nicht zu häufig sein sollten. Kann aber sein dass ich da noch was machen werde.

Das mit dem ebenen ist allerdings ein guter Punkt an dem ich selber auch schon gedacht habe. Ich habe das mit nur einem Picture gelöst weils einfacher und ein bisschen effektiver ist. Ich erkenne aber dass es schon recht nützlich wäre mehrere Ebenen haben zu können, und da es ja jetzt nachegefragt wurde, werde ich mal dran gucken schätz ich.

Dein antwort zu meine Frage bezuglich das entfernen von bestimmten Zeilen, hat aber wenig gebracht. Wenn ich neugierig wozu es gut sein soll und du so ziemlich einfach sagst dass es halt äusserst nützlich wäre (du erwähntest nix Konkretes), dann glaub ich schnell dass es eher nicht nötig ist, und dass man es statt dessen mit mehrere @write_text stattdessen lösen kann, da du ja \v in dem Name des Textes reinmachen kann, und somit selber die Zeilen selbst entfernen.

+ Source

[Oktorok3]

Okay,
das ist schön das du diese Verbesserungen auch einbauen wirst!
Zu der Schriftvergrößerung-> ich habe da allerdings auch an eine mögliche Verkleinerung z.B. 50% (optimal wäre natürlich wenn man einfach eine beliebige Prozentzahl eingeben könnte) gedacht, was auch praktisch wäre, ist jetzt aber nicht so dringend, das du dich damit beeilen musst.
Am wichtigsten sind mir vorerst die Textebenen.
Jetzt heißt es für mich also erstmal brav warten und ich wende mich derweil anderen Punkten zu.

Achja, danke für den aktuellen source-code!

[Kazesui]

Hab ich auch gemeint @50%
Ist kleiner als 100% und sieht wie oben gesagt schon recht grausam aus. Ist auch nicht so komisch, denn du muss ja bedenken dass der schrift meistens 1 pixel weit ist bei 100%, und ist ja etwas schwierig etwas kleiner als 1 Pixel zu kriegen. Ist auch der Grund wieso es erst ab 200% etwas besser aussieht grösse Werte spielen willst, aber dann ist es eh gleich zu groß.

[Oktorok3]

Du hast recht, habe ich inzwischen auch gemerkt!
Naja, schau einfach mal wie und ob du das machen willst.
Vergrößerung ginge ja theoretisch, nur ist wie gesagt jetzt auch nicht so dringend.

[Kazesui]

Und wieder ein update:



bei "@write_text" es jetzt ein 7. Parameter. Dieser lässt dich ein Picture ID auswählen, der das Ebene vom Text entscheiden will. Wichtig ist nur zu beachten dass es dem Picture mit diesem ID schon angezeigt werden muss damit der Text auch angezeigt wird. Der Alpha wert sind immernoch von das gewählte Bild abhängig.

Wichtig zu beachten ist das Save Dateien die mit dem alten mit einem älteren version des Plugin gemacht wurde sind nicht mehr mit dem neuen Kompatibel. Sprich, nur wenn man mit dem neusten Version speichert, kann man dem Speicherstand auch richtig laden.

Dazu wurde auch ein paar kleine Bugs behoben (Weitere zeile wurde nicht angezeigt wenn neu geladen, und weitere zeile + append_text waren nicht gerade Kompatibel mit einander).

[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