Programmwunsch und -erstellungsthread #2

[Cherry]

Wenn jetzt Event A das Event B aufruft, Event B setzt einen Switch der Event A (und dadurch auch die Ausführung vom gecallten Event B!) deaktivieren würde, funktioniert das mit deiner Methode nicht.

Meine Methode mit dem Call Stack ginge so:

In den einzelnen Funktionen für die Eventbefehle (z.B. 4ACB18 ProcChangeVariable) gibt es ja drei Parameter: eax = aktueller TLcfgScripter, edx = aktuelle TLcfgScriptData, ecx = aktuelle TLcfEventScriptLine.
Davon ausgehend:

Code:

; angenommen, eax ist der TLcfgScripter
mov eax, [eax+4] ; TLcfgScriptDataList
mov eax, [eax+8] ; innere TList der TLcfgScriptDataList (quasi der Call Stack)
mov eax, [eax+4] ; Pointer auf Array
mov eax, [eax] ; Erster Eintrag (ursprünglicher Caller)
mov eax, [eax+1c] ; Event ID (0 wenn kein Map Event)

Der Vollständigkeit halber müsste das ganze btw auch bei Item Management und Change Party ausgeführt werden.

EDIT: Bei DynRPG oder beim RM2k3 Debug Addon oder der Revolution Patch Preview-Version kann die Event ID da auch negativ sein, das ist dann eine Common-Event-ID, du solltest also überprüfen ob sie >= 0 ist, nicht != 0.

[bugmenot]

download AntiLag(Slow)


Sollte jetzt oben beschriebene Fälle (AC statt ABC; A callt B, B bricht A ab) und Folgendes richtig durchführen:

Im 2k(3) wird nicht nur der Caller (@ bottom of CallTree) sondern auch der Callee (@ current CallTree_pos) geupdatet.

...im Falle, wenn der Caller eine höhere Event_ID hat als der Callee, wird der Ausgangspunkt des <CallEvent> als letztes geupdatet. Ist klar von den Zahlen her. Wenn der Callee aber eine höhere Event_ID als der Caller hat, dann wird der Ausgangspunkt des <CallEvent> auch als letztes geupdatet. Das mit dem "aktuellen Event (das am Bottom des Calltrees)" funktioniert nicht in beide Richtungen.

Setze mal im 2k3 Patch 0x35 = EB und 0xB1 = EB, dann wird nur das Event da vorne im CallTree geupdatet.

Wenn der Switch, welcher das erste Event ausstellen soll, beim gecallten Event eine neue Seite öffnet, dann wird diese Seite vorher ausgeführt, bevor der Ausgangspunkt des <CallEvent> seine neue Seite ausführt.

mov eax,[MainPtr]
mov eax,[eax]
[EAX+4] = Byte, GameScene
[EAX+5] = Byte, GlobalUpdate_flag
[EAX+6] = Word, LocalUpdate(Caller)_flag (Event_ID)
[EAX+4E] = Word, LocalUpdate(Callee)_flag (Event_ID)

...wenn +4E schon irgendwo eingeplant ist, habe ich noch +36 und +45 anzubieten.

Der Vollständigkeit halber müsste das ganze [...]

...

Okay, LocalUpdate jetzt bei
<ChangeSwitch>
<ChangeVariable>
<ChangeTimer>
<ChangeItem>
<ChangeParty>
<KeyInput>

Revolution Patch Preview-Version kann die Event ID da auch negativ sein

...

Ich hoffe das Ding ist nur für den 2k3.

[bugmenot]

download AnimationBugFix

Die Skillanimation wird beim Benutzen von SkillScroll und InvokeSkill wieder vernünftig angezeigt. Vorher ploppten Schadenszahlen während der Skillanimation auf oder der Gegner starb mitten in der Animation.

[QuickPatches]
DmgCapper=49D03B,E8F69DFAFF,446E36,B800000000E86C34FEFF92B80F270000C3
minDMG=446E37,#0
maxDMG=446E42,#9999

...

[MarcL]

download AnimationBugFix
Die Skillanimation wird beim Benutzen von SkillScroll und InvokeSkill wieder vernünftig angezeigt. Vorher ploppten Schadenszahlen während der Skillanimation auf oder der Gegner starb mitten in der Animation.

...

Awesome! Hat mich schon immer genervt der Fehler ^^;

PS: Werde den Antilag bezeiten mal testen danke

[Davy Jones]

Den hab ich mir mal sofort reingeschmissen =)

[bugmenot]

Damage over own Time
download DooT(2k3)

Hiermit wird bei Zuständen, welche HP/MP (je Zug) heilen/abziehen, nicht mehr in jedem getätigten Zug (von irgendetwas im Kampf) der Heilungs-/Schadenseffekt ausgelöst, sondern nur nach dem Zug vom betroffenen Kampfteilnehmer.


BugFix(2k3)
download BattleEndBugFix

Wenn der Kampf beendet wurde (Sieg/Niederlage), dann werden die ganzen geöffneten Fenster geschlossen. (Es konnte vorher z.B. eine transparente Skillbeschreibung unter dem "Sieg" Text liegen oder andere Fenster waren noch offen.)
Entfernt auch den Cursor, welcher auf wartende Helden zeigt. Manche plugins müssten vielleicht angepasst werden, wenn sie zusätzliche HUD-Grafiken anzeigen.

Hmm... BattleEnd_flags gibt es bisher nicht in DynRPG?

[bugmenot]

Okay, man sieht im Endeffekt nur 16-bit, da der RPG Maker Framebuffer nur 16-bit unterstützt...

...

Edit: Fade-In gefixt
download 32bit(fix)

Smooth color gradients. Jetzt auch für DynRPG hinzugepackt.

Solange sich an den Adressen 45D030, 45D50F, 45D554, 45D58B, 45D59E nichts ändert... sollte es mit künftigen DynRPG-Versionen kompatibel sein.

Edit²: Fade-In gefixt für 2k:
download DestinyV2 32bit fix
(erst Bananen-Joe's Destiny Patcher dann .ips anwenden)

[goldenroy]

download 32Bit

Smooth color gradients. Jetzt auch für DynRPG hinzugepackt.

...

O________________________O

[BDraw]

Verstehe ich das richtig, in Kombination mit Kyuus RPGSS wären somit 32Bit-Bilder mit Alphakanal möglich? Das wäre ja wahnsinn!
Endlich hochwertige Portraits mit sauberen Rändern anstatt diesen kleinen Facesets xD

[Cherry]

download 32Bit

Smooth color gradients. Jetzt auch für DynRPG hinzugepackt.

Solange sich an den Adressen 45D030, 45D50F, 45D554, 45D58B, 45D59E nichts ändert... sollte es mit künftigen DynRPG-Versionen kompatibel sein.

...

Äh, was genau hast du da gemacht? Banenen-Joe hat extrem viel umändern müssen weil ja überall die Palettengröße auf 16 Bit zugeschnitten ist, die Logik die Paletten anpasst, etc... also inwiefern kann das jetzt mit DynRPG gehen? Besonders weil ja die Headerfiles und die Library auch von 16 Bit ausgehen.

Bitte erklär mal... Danke

[bugmenot]

@goldenroy
Ähh, warum das lange Gesicht? Obwohl, ich kann es mir schon vorstellen...

was genau hast du da gemacht?

...

Da ich nichts von Framebuffern verstehe, kann ich darauf nicht wirklich - im Sinne des Fragenden - antworten.

Banenen-Joe hat extrem viel umändern müssen

...

Nur ca. 400 Adressen. Ich dachte mir da:
1) die RPG_RTs von 2k und 2k3 zum größten Teil auf der selben Software beruhen
2) die 32bit-Einstellung von Destiny auch unabhängig vom restlichen Destiny Patch auf dem 2k laufen kann
3) die Auflösung des Framebuffers auch verändert werden kann, ohne extern was machen zu müssen
...könnte man das, was Bananen-Joe für den 2k gemacht hat, auch für den 2k3 nachbauen, die restlichen Zugriffe auf Bildeigenschaften anpassen und zumindest mal durchtesten.

inwiefern kann das jetzt mit DynRPG gehen?

...

Verdammt... Plugins, die irgendwelche Grafiken laden führen zu Crashes.

Soviel zum Thema null Ahnung haben und einen ganzen Abend mit dem Kram verschwenden.

[Cherry]

Oh, du hast das nur geportet, verstehe.

Naja, verschwendet ist nix, es ist sicher hilfreich für Leute die keine Plugins verwenden. Erzeugt halt leider eine "entweder-oder"-Situation, und es ist nicht leicht oder fast nicht möglich, das vernünftig zu beheben.

(Und ich muss jetzt wohl doch Support für diese "komischen" Framebuffer in UniDebug einbauen. Pöh. )

[bugmenot]

Läuft die Anzeige von Bildern über Plugins etwa über diese beiden dll files die... irgendwo sind? Oder über die kompilierten Plugins, welche die Bilder einfach nur in den Framebuffer injizieren?

Kann man wirklich nirgendwo umschreiben, dass bei Fund von 8B 92 08 06 00 00 an offset 45D02D header und lybrary nicht von 16bit ausgehen?

[Cherry]

Die kompilierten Plugins.
Nein, 1. weil Header die Datenstrukturen definieren und die müssen zur Compile-Time bekannt sein. Man müsste sonst 2 Strukturen definieren und jeder Pluginentwickler müsste überall Abfragen einbauen, welche verwendet wird. Und die Library ist ja auch statisch gelinkt und daher kann man das nicht vernünftig ändern, besonders nicht die existierenden Plugins. Außerdem können Plugins direkt mit dem 16-Bit-Bildpuffer arbeiten, das ist auch so vorgesehen, was natürlich nicht funktioniert wenn der nicht 16 Bit hat.