Programmwunsch und -erstellungsthread #2

**MarcL** · 06.09.2014, 14:04

Zitat von Davy Jones

Alone - Cold Winter und Eternal Legends 2. Allerdings ist ersteres mit Molebox verschlüsselt (deswegen auch die Ruckler) und bei letzterem kommt es auf den PC an, von welchem es gestartet wird. Bei einigen laggt es sich langsam bis zur Unspielbarkeit, bei anderen passiert garnix.
Ansonsten fallen mir keine Spiele ein, die stark ruckeln.

Weiß zwar nicht genau worums geht, aber mein Spiel (Legend of the Silverstone) ruckelt im Gebirge (MarcLMaps-->GebirgeTeilLinks/GebirgeRECHTSunten) ziemlich stark, da sind auf den Maps ~1000-2000 Events? und dann noch PPs... Wenn man den alten AntiLag einschaltet, geht es merklich schneller, aber ich müsste erstmal kucken, worauf ich dann noch achten müsste, damit sonst von der Technik alles hinaut (man muss das Teil ja zu bestimmten Zeiten wieder ausschalten bzw. resetten oder so....)

**bugmenot** · 07.09.2014, 10:10

Zitat von Cherry

Ja, sollte alles beschreibbar sein... was crasht da bei dir?

Das.

Edit:
...
Die Festlegung des Datenbereiches mit einem FF FF FF FF 01 00 00 00 fehlt?

**Cherry** · 07.09.2014, 18:23

4ACB17 ist ja mitten im Code-Segment, das ist natürlich nicht beschreibbar... drum hatte ich ja zwei Vorschläge im Datensegment respektive in einem zur Laufzeit allozierten beschreibbaren Speicherbereich gebracht.
See also: http://msdn.microsoft.com/en-us/library/ms809762.aspx

Und FF FF FF FF 01 00 00 00 hat damit nix zu tun, das ist nämlich keine "Festlegung eines Datenbereiches" sondern gibt die Stringlänge (und das ist kein String) an.

Kleiner Exkurs zu Delphi-Strings, falls es dich interessiert: Delphi-Strings sind nämlich ein relativ geniales Konzept: Sie sind quasi erweiterte C-Strings. C-Strings sind ja einfach nullterminierte Strings ohne Längenangabe, d.h. da steht dann z.B. "Hello World" + ein 00-Byte im Speicher, letzteres gibt das Ende des Strings an. Das heißt natürlich im Umkehrschluss, dass ein String selber kein 00-Byte enthalten kann, und dass jedes mal die Bytes im String durchgezählt werden müssen wenn man dessen Länge rausfinden will. Delphi hängt davor noch zwei DWords an (davor, weil man dann den eigentlichen Stringpointer genauso Delphi- und C-/WinAPI-Funktionen geben kann und es funktioniert). Und zwar Reference Counter und Länge. Angenommen, eax ist gerade ein Pointer auf den eigentlichen String (also quasi auf das "H"-Byte in "Hello World"), dann kann man mit [eax-4] die Länge des Strings und mit [eax-8] den Reference Counter auswählen. Der Reference Counter wird für zur Laufzeit erstellte Strings verwendet - dadurch kann derselbe String mehrfach verwendet werden, ohne jedes mal neu erzeugt zu werden, solange bis ihn keiner mehr verwendet, dann wird der Speicher freigegeben. Nun sind aber hardgecodete Strings im Code-Segment anders, weil sie eben nicht zur Laufzeit erstellt worden sind, können sie auch keinen Reference Counter haben (er wäre ohnehin nicht beschreibbar weil Code-Segment). Deshalb ist der Wert des Reference Counters bei Stringkonstanten -1 (FF FF FF FF), als "Special Value" quasi. Leere Strings werden übrigens gar nicht gespeichert, sondern durch einen Nullpointer repräsentiert.
See also: http://www.codexterity.com/delphistrings.htm (runterscrollen zu AnsiString)

EDIT:
Sag mal, was machst du denn da eigentlich? Wieso baust du so viel Code um, an nichts damit zu tun habenden Stellen, sodass andere Patches oder Offsetsuchprogramme daran verzweifeln, anstatt eine vernünftige Codecave an einer unbenutzen Stelle zu verwenden? Da ist so viel nicht verwendet...

Um nicht alles unnötig zu verkomplizieren, würde ich dich dringend bitten, nur mehr minimale Änderungen am Code vorzunehmen, und zwar da, wo es auch logisch hingehört. Wir müssen unsere Codecaves natürlich koordinieren, deshalb wird ich sagen, du kannst im 2k3 446D30-449DD3 haben. (Da sind Funktionen für Kontextmenüs, aber es gibt ja keine im Spiel, kann man also überschreiben). 442600-443A6F und 45CDF4-45D84B bitte nicht anrühren, das ist für DynRPG, und irgendwo in der Nähe von 433XXX hab ich noch Zeugs für PicPointerPatch, wenn ich mich Recht erinnere. Die Zone nach dem Ende des Codes ab 4C9D10 ist auch schon belegt, BetterAEP z.B.

Beim 2k kannst du 432CAC-436FE3 haben.
Ist das OK für dich?

Ich hätte noch eine große Bitte an dich... ich hab mir nämlich mit meinem Vorschlag, wo du den Code der 1x pro Frame ausgeführt wird, hintun sollst, selber ein Ei gelegt. Genau die Stelle brauche ich nämlich in meinem neuen Projekt, einem Debugger, und ich habe eh überlegt ob ich eine andere Lösung finde, aber es ist mir fast unmöglich, mit deiner Änderung da noch vernünftig zu arbeiten. Also bitte sei so nett und lege den Code stattdessen auf 4A35D0, das ist der Anfang der Routine die 1x pro Frame die Map updated. Sollte für dich denselben Effekt haben, ohne dass dann mein Debugger bei keinen Projekten mit AntiLagSwitch+ funktioniert! Vielen lieben Dank!

**bugmenot** · 08.09.2014, 09:32

download AntiLag(Fast)

Jetzt sollten eigentlich alle Fehler raus sein.

download ALS DePatch
(entfernt den AntiLagSwitch Patch restlos, wenn man ihn nicht im Ordner DynPatches hatte, sondern direkt auf die RT gepatcht hat).

CodeCaves:
432CAC..432D02 (2k v1.07 )
446D30..446D85 (2k3 v1.08 )

Ich stell heute noch welche für 2k v1.51 Value! und 2k3 v1.09 raus. Wer was anderes benutzt bitte laut rufen.

Zitat von Cherry

Da ist so viel nicht verwendet...

Da hat eine gewisse Person vor knapp 17 Monaten etwas anderes behauptet.

Zitat von Cherry

Wieso baust du so viel Code um, an nichts damit zu tun habenden Stellen

1. ...hat sich erledigt... (DePatch)
2. Generell: wenn einem gesagt wird, dass in der RPG_RT kein Platz mehr ist, dann macht man sich Platz. Ohne vorher raten zu müssen, welche Funktionen im Programm nie ausgeführt werden.

**Cherry** · 08.09.2014, 13:28

Ja, du hast Recht, ich hab vor 17 Monaten echt was anderes geschrieben (da kannte ich diese Stelle auch noch nicht, aber das ist jetzt egal). Und wenn ich jetzt meinen Satz von vorher lese, nämlich den da: "Sag mal, was machst du denn da eigentlich? Wieso baust du so viel Code um, an nichts damit zu tun habenden Stellen, sodass andere Patches oder Offsetsuchprogramme daran verzweifeln, anstatt eine vernünftige Codecave an einer unbenutzen Stelle zu verwenden?", dann denke ich mir "WTF, klingt das unfreundlich". Dafür möchte ich mich wirklich entschuldigen, weil es nicht deine Schuld war, ich glaube ich war gestern gerade prinzipiell weniger guter Laune, was nicht an dir lag, und hab mich dann darüber geärgert dass plötzlich mein Zeugs mit deinem Patch nicht mehr ging und ich dann auch noch selber dir die Adresse gesagt habe. Ich hätte auf mich selber sauer sein sollen, also vergiss es bitte einfach, es tut mir Leid. Danke, dass du dir überhaupt die Arbeit machst a) diese Patches zu machen und b) noch meinen Bitten nachzukommen.

**Ghabry** · 08.09.2014, 19:05

Zitat von Cherry

Könnten wir nicht die UpdateEvents-Funktion so umbauen, dass sie nur ein Flag setzt, und am Ende der Eventverarbeitung in einem Frame das eigentliche UpdateEvents ausführen, wenn das Flag gesetzt ist? Ich seh momentan keinen Grund warum man mehr als 1x pro Frame die Events aktualisieren sollte, was meinst du?

Also ich hab nicht probiert, ob das mit diesem neuen Antilag-Patch Probleme verursacht, aber eine Situation würde mir einfallen, wo man zwischendurch neu evaluieren muss:

Code:

Event:

Seite 1 (Paralleler Prozess, ohne Startbedingung):

Message "A"
Schalter 1 an
Message "B"

Seite 2 (Autostart, Bedingung Schalter 1 an):

Message "C"

Ausgabe muss sein: AC, das parallele Event bricht sofort ab, sobald eine andere Bedingung erfüllt ist.
Wenn Seite 1 nen anderer Typ ist, ist die Ausgabe immer "ABC".

Das Verhalten weicht übrigens beim XP und neuer ab, da ist die Ausgabe auch bei parallelen Events "ABC", ist also ne 2k/3-Besonderheit.

**bugmenot** · 08.09.2014, 19:56

Zitat von Ghabry

Also ich hab nicht probiert, ob das mit diesem neuen Antilag-Patch Probleme verursacht

Ohne Patch: AC
Mit Patch: ABC
Mit Patch mit [0.0 Wait] vor B: AC

Zitat von Ghabry

zwischendurch neu evaluieren

Inwiefern?
Wieder zum Ausgangszustand des "alle Events abklappern, wo Eventbedingungen erfüllt sein könnten und viele Frameeinbrüche verursachen" zurück?
Einen CommentCommand @Update für einen erzwungenen Eventupdate einführen? (wovon ältere Spiele dann nichts haben)
Sich darüber aufregen wie dämlich es sich anhört, den Code für irgendeine Funktion auf mehrere EventPages zu verteilen statt irgendwo intern zu verschachteln oder <CallEvent> richtig zu nutzen?
Edit:
"EventUpdate(Global)" = 1x je Frame, updatet jedes Event auf der Map nach einem Eventbefehl
und
"EventUpdate(Local)" = nach jedem einzelnen Eventbefehl, updatet nur das Event, aus dem der Befehl hervorgeht (+eigene EventPages)
?

**Ghabry** · 08.09.2014, 20:55

Also eigentlich wollte ich mich nicht in die Diskussion einmischen, sondern Cherry ein Beispiel bringen, wo die Annahme nicht funktioniert, weil ihm spontan keins einfiel.

Die einfachste Lösung wäre natürlich nur 1x neu zu evaluieren. Würde ich auch persönlich für die sauberste halten, als so ein rumgefrickel wie @Update oben hinzuschreiben. Vorm patchen sollte sich nur der Entwickler bewusst sein, dass seine parallelen Events im Spiel sich anders Verhalten, wenn der von mir genannte Fall eintritt.

**Cherry** · 08.09.2014, 21:16

Hm, für diesen Fall könnte man ja einführen, dass UpdateEvents nur das aktuelle Event (das am Bottom des Calltrees) updatet.

**Stray** · 09.09.2014, 02:27

@SuperSimon:
Es fällt mir sehr schwer das so nachzuvollziehen und glaube auch nur ungefähr verstanden zu haben. Aber es liest sich zumindest irgendwie vielversprechend. Ich werde mir den DestinyPatch später mal näher ansehen.

**bugmenot** · 12.09.2014, 15:56

Nach stundenlangem Suchen kann ich Folgendes mit Stolz verkünden: keine Ahnung, wie ich an den CallTree herankommen soll.
Ich habe es mal mit etwas anderem versucht (über die Event_ID):

Post-Umleitung

P.S.

download AntiLag(Fast)

Patches für RPG_RT2k v1.51 und RPG_RT2k3 v1.09 hinzugefügt. EventUpdates allesamt am Ende eines Frames.

Edit:

Zitat von MarcL

(MarcLMaps-->GebirgeTeilLinks/GebirgeRECHTSunten) ziemlich stark, da sind auf den Maps ~1000-2000 Events?

Die Parent Map dazu hat übrigens 2190 Events. Und da ist kein Text...

Habe den Kram mal mit MarcL's Zeug durchgetestet. Der Patch nennt sich zwar "Slow", aber einen großartigen Unterschied zur schnellen Variante gibt es, hinsichtlich der Performance, nicht (außer man hat zig Events mit 50 Eventseiten und in jedem eine ganze Menge <ChangeSwitch> und <ChangeVariable>).

Ach und: nicht vergessen die Zeile AntiLagSwitch aus der DynRPG.ini zu löschen.

**Cherry** · 13.09.2014, 17:39

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** · 14.09.2014, 14:57

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.

Zitat von Cherry

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

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

Zitat von Cherry

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

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

**bugmenot** · 17.09.2014, 18:04

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.

Zitat von DynRPG.ini

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

**MarcL** · 17.09.2014, 20:47

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

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

PS: Werde den Antilag bezeiten mal testen danke

**Davy Jones** · 21.09.2014, 23:51

Den hab ich mir mal sofort reingeschmissen =)

**bugmenot** · 22.09.2014, 17:23

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.

**bugmenot** · 26.09.2014, 12:09

Zitat von Kyuu

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.

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

**goldenroy** · 26.09.2014, 12:46

Zitat von bugmenot

download 32Bit

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

O________________________O

**BDraw** · 26.09.2014, 13:23

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

Thema: Programmwunsch und -erstellungsthread #2

Themen-Optionen

Anzeige

Berechtigungen