Programmwunsch und -erstellungsthread #2

[Cherry]

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!