Okay, wtf stellst du dort da?
Druckbare Version
Okay, wtf stellst du dort da?
Ich bastel an einer JnR-Basis, die nach einem halben Jahr in Ruhe lassen und nochmal durchschauen
auch halbwegs funktioniert (bis auf das regelmäßige Steckenbleiben in Decken bei Sprüngen), die aber
noch Shoot'n'Run-tauglich werden soll. Und das mit einem möglichst umfangreichen "Buffer" für Zeug,
das durch die Gegend geschossen wird, es sind noch nichtmal Gegner derzeit einbezogen.
Mal dran gedacht, einen PP als "Gameloop" zu benutzen und darin die zyklischen Sachen sequenziell zu machen?
Hallo, ich habe einen Wunsch!
In dem Revolution-Previewpatch in dem ATB rausgenommen wurde, sind die Anzeigen für HP und MP um ein Stück nach unten verlegt.
Ich würde dies gerne auch in meinem CortiCombatVisu-Plugin möglich machen, daher hätzte ich gerne die Adressen, der Y-Position von Helden-HP/MP/ATB, Leisten und Zahlen.
Die kurze Antwort:
49681D = PartyWindow_y-Pos
496820 = PartyWindow_x-Pos
4968C0 = GaugeInterface y-Correction (large windows)
4968CE = GaugeInterface y-Correction (small windows)
4968C5 = GaugeSegments delta-y (large windows)
4968D3 = GaugeSegments delta-y (small windows)
Die ausführliche Antwort:
Danke :-D
Btw. was sind diese 909090909090**** - Sachen?
9090 = x86 Tipp-Ex
Oder das, was da noch dahinter steht?
Direkte Vergabe von x|y-Positionen.
Und kleinere Fehler, die mir vielleicht noch vor dem Posten auffallen sollten.
Irgendwas ist immer...
Edit:
http://i.imgur.com/M1wNnSa.png
Der DynLoader will irgendwie nicht wie er soll/kann. Ist die Zeichenkette zu lang?
Edit²
Die Set#4Byte-Funktion scheint Probleme zu haben, wenn die zu überschreibenden Bytes 2-4 ungleich 00 sind. (Dyn v0.20)
Edit³
Es überschreibt die Bytes 2-4 gar nicht, wenn der Wert über 256 hinausgeht.
VertiGauge
Und: VisuGauge
Zu den QuickPatches und den bunten Farben:
Für % ist die maximal zulässige Zahl = 127. (Alles, was sich in dem Bereich befindet, schiebt die anderen Partymitglieder sowieso aus dem Bild)Für die x-Position der HP|MP-Zahlen wird in der RPG_RT zwischen 1|2|3|4-stelligen Zahlen unterschieden. Deswegen sollte man den 8 Pixel-Abstand einhalten (%40, %48, %56, %64).
x-Positionen im horizontalen Interface orientieren sich anhand des vordersten Heldens in der Party. (Wird im vertikalen Gauge umgedreht auf y-Positionen)
"NoShift" ignoriert das Hin- und Herscrollen, wenn man das Ding, was durch NoAutoBattle beseitigt wird, auf/zu macht.
Das %60 beim vertikalen Interface ist der y-Abstand zwischen den Helden.
Edit:
Das Problem mit den Farben der HP/MP/ATB-Leisten wieder beheben:
Angabe in Breite -1 (Und ja: man muss dafür HPB/MPB/ATB auf der selben Breite eingestellt haben)Zitat:
Zitat von DynRPG.ini
Und noch das Problem mit überlangen HP/MP/ATB-Leisten beheben:
Verzerrt die 16x16 Pixel großen Grafiksegmente in System2 (mittlerer Grafikabschnitt, x-Pos = 16) auf die eingestellte Breite.Zitat:
Zitat von DynRPG.ini
Stimmt...
http://share.cherrytree.at/showfile-12644/dynloader.dll << gefixter 0.20-Loader - der ist aber jetzt nicht mit dem alten Patch kompatibel, und das ist jetzt zu umständlich da zu fixen; es gibt sowieso bald 0.20 (in der Testversion gabs ja noch Probleme)
Also: Deine VertiGauge.ips baut die Anzeige um auf die vertikale Ausrichtung. Wenn man das getan hat, kann man die Quickpatch-Zeilen benutzen um sie zu konfigurieren. Right?
Und was tut VisuGauge.ips? Den Quickpatch-Zeilen nach ist die Ausrichtung noch immer wie sie war.
Richtig. Ist nur so ein Experiment, weil: man kann sowas machen... verdeckt nur leider zu viel vom Kampfgeschehen. (die Platzierung aller Battler ist sowieso seltsam)
Ausrichtung in der Horizontalen, mit etwas mehr Flexibilität im vertikalen Strecken/Stauchen. Ist auch unabhängig vom (unsichtbaren (noch weiter drunter ist übrigens das Fenster mit der Zielwahl...)) Party-Fenster unten. Also könnte man das HUD an den oberen Bildschirmrand packen.
Edit:
Wegen den Fenstern am oberen Bildschirmrand:
Edit²Zitat:
Zitat von DynRPG.ini
InfoDisloc
Damit kann man das Infofenster bei Items/Skills sowie Item-/Skillfenster im Kampf verschieben.
Zitat:
Zitat von DynRPG.ini
Klingt super. Ich werde das mal ausprobieren.
Row-ATB-Switch
Aufwändig? Vielleicht eine etwas längere Eintipp-Zeit als bei Plugins. (Vorausgesetzt man weiß, wo man den Kram einbinden muss.)Zitat:
Zitat von DynRPG.ini
Cool, danke dir =D
Kommentierter Code der gesamten MenuScene dekodiert. (2k RPG_RT v1.07 und 2k3 RPG_RT v1.08 )
91% Pseudo-Quellcode und 9% Fragezeichen.
Und Doppelpost.
Und Trippelpost. (Weil ich das Zeichenlimit zweimal überschritten habe)
Das ist der Unterschied zwischen drei Tage auf ein Plugin warten und drei Minuten Zahlen eintippen.
Wer mit diesen Informationen etwas anfangen will, kann seine RPG_RT (bitte vorher immer Backups anlegen) mit einem HexEditor öffnen und durch einen Disassembler jagen. (Wenn alles in kleinen Fenstern angezeigt wird: Rechtsklick -> "Text view")
Einfach die 4*****-Adressen kopieren -> im Disassembler G drücken -> Einfügen -> Enter. Unten im Fenster steht die Adresse für den HexEditor (generell 4***** - 400C00). Oder für den RM2k3 die 4*****-Adresse in die DynRPG.ini schieben. (Bitte vorher in das "Hex-View"Fenster schalten, um zu sehen was die genaue Adresse der zu verändernden Zahl ist.)
Für alle, die meinen: "Da stehen aber nicht durchgehend die ganzen blauen Adressen!" Öffnet eine 2k RPG_RT mit dem Disassembler und springt zu den jeweils angegebene Adressen am Kopfende der <>Funktionen. Von 2k zu 2k3 gab es eine Menge copy&paste, daher ist der Aufbau des Codes stellenweise gleich. Ein bisschen Scrollen und Vergleichen ist schon der ganze Trick an der Sache.
Wer sich wegen den Versionsnummern der RTs unsicher ist: betterAEP nutzt die 1.07/v1.08 (und DynRPG läuft auf der v1.08 )
Wem langweilig genug ist:
Kann man x86 essen?
Mehr als Disassembler, Papier, Taschenrechner, Musik und HexEditor (oder OllyDbg, falls es funktioniert) braucht man nicht.
x86Asm-to-Hex-Converter
288Dez -> Hex ergibt bei mir 120 laut Taschenrechner, wie kommt man auf 20 01 00 00?Zitat:
Wer damit rumspielen will, kann die Werte, welche größer als #256 sind in hexadecimal umrechnen (Bsp: 288 = 20 01 00 00) und anstelle des #*** diesen Wert eintippen.
Irgendwas wegen signed/unsigned integers auf HexEbene. Der Least Significant Byte liegt bei einer 4-Byte-Operation links.
[AA BB CC DD]:
AA = 256^0
BB = 256^1
CC = 256^3
DD = 256^4
Irgendwo bei 2147483648 (in HexDec: 00 00 00 80) flippt's ins Negative. (01 00 00 80 = -2147483647)
Und FF FF FF FF ist -1.
FE FF FF FF ist -2 etc.
Das Ergebnis vom Taschenrechner hat den LSB rechts, weswegen man die Zahl in Zweiergrüppchen aufteilen muss und quasi rückwärts eintippen muss:
11F = 00 00 01 1F (Rechner) -> 1F 01 00 00 (HexEditor)
Edit:
Soll das eine unterschwellige Botschaft sein, dass ich mir einen Assembler zulegen oder OllyDbg zum Laufen zu bringen soll?