ich habe länger nicht mit dem RPG-Maker gearbeitet und nun stellt sich mir folgende Frage, die ich mir aus der Erinnerung leider nicht mehr selbst beantworten kann: Ist es möglich, eine bestimme Stelle in einer Variablen selektiv anzusprechen, d.h. eine der sechs möglichen Ziffer einzeln abzufragen?
Sowohl über "Input", als auch über den Testmodus erkennt man ja, dass sich die Zahlen einzeln verändern lassen - kann man diese auch individuell abfragen/ausgeben/in einer neuen Variablen speichern?
Wenn ich nur "geschielt" haben sollte, bitte kurzen Hinweis, wo ich diese Funktion finde.
Falls es die Frage schon gab, gerne den Verweis einfügen und Thema schließen.
Zur Vereinfachung dieser eher abstrakten Frage mal EIN mögliches Anwendungsbeispiel für ein Kampfsystem:
Zitat
Var[0001] = HP Held (z.B. 000437)
Var[0002] = Digit#3 Var[0001] (grafische Darstellung der Lebenspunkte für 100er-Schritte, Ziffern 0 - 9, wäre dann Wert "4")
Var[0003] = Digit#2 Var[0001] (grafische Darstellung der Lebenspunkte für 10er-Schritte, Ziffern 0 - 9, wäre dann Wert "3")
Var[0004] = Digit#1 Var[0001] (grafische Darstellung der Lebenspunkte für 1er-Schritte, Ziffern 0 - 9, wäre dann Wert "7")
...
Ist das überhaupt möglich? Falls nicht, gibt es dazu eine elegante Lösung?
Ich habe alternativ einen eher statischen "Holzfäller-Algorithmus" gebastelt, der mit Konstanten über "Fork Conditions" arbeitet.
fork
if Var[0005/Abrechnung] >= 900
then Var[0005/Abrechnung] -900
Var[0005/Abrechnung] = Var[0003] (grafische Darstellung der Lebenspunkte für 10er-Schritte, Ziffern 0 - 9, Abfrage > 10, 20, 30, ...)
else
if Var[0005/Abrechnung] >= 800
then Var[0005/Abrechnung] -800
Var[0005/Abrechnung] = Var[0003] (grafische Darstellung der Lebenspunkte für 10er-Schritte, Ziffern 0 - 9, Abfrage > 10, 20, 30, ...)
else
(... bis größer/gleich 100 ...) end
fork
if Var[0005/Abrechnung] >= 90
then Var[0005/Abrechnung] -90
Var[0005/Abrechnung] = Var[0004] (grafische Darstellung der Lebenspunkte für 1er-Schritte, Ziffern 0 - 9, Abfrage > 1, 2, 3, ...)
else
if Var[0005/Abrechnung] >= 80
then Var[0005/Abrechnung] -80
Var[0005/Abrechnung] = Var[0004] (grafische Darstellung der Lebenspunkte für 1er-Schritte, Ziffern 0 - 9, Abfrage > 1, 2, 3, ...)
else
(... bis größer/gleich 10 ...) end
...
Das sieht wegen der Fixwerte und der Schachtelbedingungen im Code schlicht hässlich, klobig und schwerfällig aus. Funktioniert zwar und bleibt als Ansatz bestehen, aber mir wär's schon recht, wenn's dafür eine geschicktere Variante gäbe.
Besten Dank im Voraus für eure Hilfe und Hinweise!
Boah ...
Wenn man's direkt vor Augen hat und entschlüsselt, ist die Funktionsweise eigentlich echt simpel und logisch.
Die Zehnerpotenz einfach wegzudividieren, hatte ich anfangs ebenfalls im Hinterkopf, aber das war's dann auch schon; die Ausgangs-Variable über die Mod.-Funktion weiterzuverarbeiten, kam mir irgendwie gar nicht in den Sinn, weil ich die Möglichkeit vollständig aus meinem Gedächtnis getilgt hatte. Und ich war mir auch nicht sicher, ob und wie der RM2k rundet.
Besten Dank nochmals, damit ist mir bereits vollumfänglich geholfen!
Wenn ich also diesem Script folge, werden die aktuellen HP Werte meines Helden angezeigt?
Ich frage dass weil ich fragen muss, da ich es jetzt in dieser Sekunde erst umsetze zum Test xD und auch weil ich nicht weiß ob noch irgendwas fehlt, oder ich vielleicht etwas missverstanden habe
EDIT: So sieht es bei mir umgesetzt aus...
Und es funktioniert nicht xD (ist auf Parralel Process ...daran kanns also nicht liegen xD).
Die Events sind alle richtig eingestellt...denke ich xD
Halt dir auch beim (bzw. gerade) beim Nachbauen von Scripten immer vor Augen, was die jeweiligen Befehle tun bzw. tun sollen. Wenn du die Hunderterstelle einer Zahl möchtest, macht mod 100 keinen Sinn. Wenn du 237 als Ausgangszahl hast, gibt dir mod 100 die 37 aus (237/100=2, Rest=37).
Darüber hinaus brauchst du bei diesem Script weder die Variablen auf Null setzen, noch die Abfrage, wie groß die Ausgangszahl ist: Wenn die Zahl zu klein ist, gibt ein mod 100 (/mod 10/ ...) eh Null aus (sofern du dir bei sowas nicht sicher bist, ist es aber immer eine gute Idee, Variablen am Anfang auf 0 zu setzen, damit keine Unfälle passieren, wenn du die selbe Variablen für mehrere Scripte verwendest), ist die Zahl groß genug, wird die Variable auf einen anderen Wert gesetzt. Und selbst wenn durch einen Zufall die Variable von Anfang an einen anderen Wert haben sollte, setzt du sie ja eh dann zuerst mit der Ausgangszahl gleich.
Wenn du Werte übrigens einfach nur anzeigen möchtest, würde ich dir auf Dauer davon abraten, an der Variable mit der Ausgangszahl etwas zu ändern, zumindest, sofern du nicht auf Zahlen aus der Database zurückgreifst (bspw. Statuswerte oder HP, sofern du die nicht durch eigene Scripte ersetzt). So kannst du nämlich später mit der selben Variable weiterarbeiten und riskierst nicht, dass du durch ein vorheriges Script den Wert verfälscht hast. Wenn du irgendwelche Variablen hast, die Werte speichern, die du nicht im Nachhinein einfach wieder abrufen kannst, kann das sonst sehr ärgerlich werden.
Wenn Variable 1 deine Ausgangszahl hat und du in den Variablen 2, 3 und 4 die einzelnen Stellen haben möchtest (danke an Leana für die Korrektur!):
fertig. Wenn du jetzt 945 für V1 da reinwirfst, kommt V2=9, V3=4 und V4=5 da raus. Setzt du V1 nur auf 3, sind V1 und V2=0 und V3=3.
Wenn Variable 1 deine Ausgangszahl hat und du in den Variablen 2, 3 und 4 die einzelnen Stellen haben möchtest:
fertig. Wenn du jetzt 945 für V1 da reinwirfst, kommt V2=9, V3=4 und V4=5 da raus. Setzt du V1 nur auf 3, sind V1 und V2=0 und V3=3.
...
Bei deiner Version ergibt das aber für V3 = 0 und für V4 = 45. Korrigierte Version:
Also das Variable Array vom RPG Maker benutzt ausschließlich Integers (ganze Zahlen), aber weiß ja hier jeder ^^
Soweit ich weiß, werden bei Integern potentielle Nachkommastellen einfach abgehackt bzw. ignoriert, somit wird immer abgerundet. Und somit wäre diese Modoloberechnung in Kombination mit der Division nicht möglich.
Beispiel, nehmen wir die Zahl 145.
CurrentDigit=145 % 10 = 5. Erste Ziffer
CurrentDigit=145 / 10 = 14 (die 0.5 am Ende hackt er ab)
CurrentDigit=14 % 10 = 4. Zweite Ziffer
CurrentDigit=145 / 100 = 1 (.45, jedoch auch hier wieder abegehackt, weil Integer) Dritte Ziffer.
Man braucht für die Modoloberechnung einzelner Ziffern keine extra Variablen. Ich habe bei meinem Custommenü gewiss 40 bis 50 Ziffern geskriptet und für alle eine einzige Variable benutzt! Beispiel:
CurrentDigit wird berechnet, dann über Conditions entsprechend die Ziffer dargestellt und dann wird erst die nächste Ziffer berechnet, aber auch wieder mit derselben Variable. Das analog für jede Ziffer.
Die Variable wird nur zur kurzen Berechnung gebraucht, es wird ja so oder so alles der Reihe nach berechnet und angezeigt, somit auch bei einer regelmäßigen Aktualisierung nur eine Variable. Aber es empfiehlt sich, die Zahlen per Aufruf zu aktualisieren, wenn sie sich verändern und nicht per Parallel Process. :) Bei schwächeren Rechnern kann das immernoch zu Performanceproblemen führen!
Funktioniert somit nicht anders, aber (!) somit behält man Übersicht und kann besser copy-pasten, in dem Beispiel mit individuell zugeordneten Variablen muss man im worst case quasi immer neu skripten, hier kann man den shit kopieren und muss nur die V[0002] ändern. Wenn man sich dann noch leere Condition-Zweige in irgendeinem Event Zwischenspeichert, dann muss man die auch nicht jedes Mal neu skripten. Nur ein kleiner stilistischer Tipp am Rande ;)
Soweit ich weiß, werden bei Integern potentielle Nachkommastellen einfach abgehackt bzw. ignoriert, somit wird immer abgerundet. Und somit wäre diese Modoloberechnung in Kombination mit der Division nicht möglich.
...
Welche meinst du denn genau? Das Beispiel von BDraw sollte funktionieren.
Zitat
Man braucht für die Modoloberechnung einzelner Ziffern keine extra Variablen. Ich habe bei meinem Custommenü gewiss 40 bis 50 Ziffern geskriptet und für alle eine einzige Variable benutzt!
...
In deinem Beispiel ist die Anzeige der Ziffern aber in den Code integriert. Die kann von Zahl zu Zahl wechseln: Manchmal gibt es mehr Ziffern, die Positionen unterscheiden sich und vielleicht auch die Picture-IDs. Ich finde es praktischer, die Zerlegung der Zahl in ein Common Event (in eine eigene "Methode") zu packen. Dort braucht man dann aber für jede Stelle eine Variable und außerdem noch eine für die Zahl, die zerlegt werden soll.
Das ist jetzt etwas OT, aber wenn ich mal eine Alternative in den Raumen werfen darf, die Zahlen anzuzeigen:
Packt alle Zahlen auf ein einziges Picture, jeweils mit ordentlich Leerraum dazwischen, sodass immer nur eine Zahl aufs Bild passt. Dann könnt ihr mit zwei weiteren Variablen, die x und y beinhalten, das Bild so verschieben, dass immer nur die jeweilige Zahl angezeigt wird. Der "neue" (a.k.a. offizielle) 2k3 kann das meine ich sogar Problemlos importieren, bei den alten Versionen muss man tricksen, indem man erst ein kleineres Bild mit den selben Farben importiert und das dann einfach im Ordner austauscht.
Wenn zwischen den Zahlen bspw. immer horizontal 320px Leerraum sind und die Ausgangsposition bei... was weiß ich, (-640|-480) liegt, braucht ihr nur das Bild (das ihr natürlich vorher bereits mit Show Picture geladen habt, bspw. 100% Transparenz) entsprechend verschieben:
Das ist etwas Friemelsarbeit, zu Beginn die passenden Ausgangskoordinaten zu finden, aber danach deutlich simpler. Man erspart sich die ganzen Show Picture-Befehle und noch dazu ist es afaik schonender für die Performance (auch wenn das fast nie wirklich was ausmacht). Auch das erstellen des Zahlenpictures ist etwas aufwendiger (gibt eben Bilder mit Abmessungen von 3200x240px oder so), aber dafür ist der Code bedeutend kürzer. Denn wenn es hier schon darum geht, den Code möglichst wiederverwendbar zu machen, würden mich die Mod-Rechenfunktionen hier bei weitem weniger nerven als diese Massen an drögem Code, der nur aus immer der selben Abfrage plus Show Picture besteht.
Das ist zwar immer noch bei weitem nicht so komfortabel wie der DynPatch, aber auf jeden Fall angenehmer als "if V[1]=0 then Show Picture 0; if V[1]=1 then Show Picture 1; ..." und das für eine Zahl mit 3 Ziffern von 0-9 insgesamt 30x.
@Drakee:
Stimmt das funktioniert auch alles mit einer bzw. sogar zwei Variablen. Allerdings hat man mittlerweile über 5000 davon zur Verfügung und wenn man evtl. noch etwas weiter mit den einzelnen Ziffern im Nachhinein rumhantieren möchte, halte ich es für simpler, die einfach direkt einzeln zu speichern anstatt dann wieder neu zu berechnen. Zumal, wie Kelven schon erwähnte, dann die Ziffern-Zerlegung im Wechsel mit der Bildanzeige passieren muss und das daher so aus dem Kontext gerissen eher ungünstig ist.
Wenn man natürlich weiß, dass man die nur einmal berechnet und gut ist, würde ich das auch zusammenstauchen.
Welche meinst du denn genau? Das Beispiel von BDraw sollte funktionieren.
...
Das war einfach nur eine allgemeine Erklärung zu der Funktionsweise dieses Skripts.
@BDraw
Ich liebe dich. Diesen Vorschlag werde ich ab sofort immer so umsetzen! :D #nohomo
Ein Tipp noch allgemein dazu: Die Ausgangskoordinaten kann man sich mehr oder weniger errechnen, indem man die Bildmitte von dem Bitmap der Zahlen nimmt (also Bildgröße/2) und dann von 160 abzieht... oder so. Irgendwie so ^^ Auf jeden Fall nimmt der Maker immer die Bildmitte als Referenzpixel, wenn die Bildmitte aus 2 Pixeln besteht, nimmt er immer den größeren. Die Verschiebung von 320 muss noch um die Länge der Zahl in Pixeln (z.B. 7px) erweitert werden. (EDIT: Nein, muss sie nicht :D)
EDIT: Ich hab das mal umgesetzt. Hier ist ein konkretes Beispiel. Die Grafik hat eine Breite von 3270, bei der neun hängen allerdings noch Pixel hintendran, aber wenn ich da noch 313 Px abziehen würde, würde es die Berechnung etwas verkomplizieren. Die Länge setzt sich zusammen aus: 10 Ziffern mal Bildschirmbreite 320 plus 10 mal Zahllänge 7. Das Skript generiert eine zufällige dreistellige Nummer jede Zehntelsekunde und aktualisiert. Ich weiß, dass ich das noch optimieren kann und mir vor allem über ein Call Event mehr oder weniger Arbeit sparen kann, aber das hab ich auf die Schnelle hingeklatscht, nur um schnell dahinter zu kommen wie das funzt.
Und auf die selbe Weise werde ich für die Darstellung der Items auf If-Verschachtelungen verzichten, denn das geht auch mit einer Item ID * Y-Shift Verschiebung :D
Muss man allerdings auch nicht 30 Items in ein Bitmap packen. Vertikal ist sogar besser, weil das Bitmap weniger Höhe als Breite hat. 240 < 320. Easy.
Zitat
Zitieren
