Programmwunsch und -erstellungsthread #2

[elvissteinjr]

Ähm, mir erschließt sich hier nicht wozu man für so ne Schleife den Destiny Patch braucht.

Man könnte sich doch wunderbar ein Common Event bauen, welches die gewünschten Werte in 2 Variablen schreibt, welche immer fürs Show Picture verwendet werden. Oder ähnliches.
Über sein genaues Einsatzszenario bin ich mir immer noch nicht im Klaren, aber das lässt höchstwahrscheinlich noch ganz gut mit Makercode lösen.

[BlueGesyr]

Ah, ich glaube, ich hatte die Frage falsch verstanden. So wie ich das aufgefasst hatte, ging es darum, die X- und Y-Werte zu speichern, nachdem die Bilder bereits angezeigt wurden. Schande über mich.

Also noch ein Versuch: Es sollen bis zu 50 Bilder anzeigt werden, deren X- und Y-Koordinaten zuvor in bestimmte Variablen gespeichert wurden? So richtig?
In diesem Fall würde ich wieder zum Destiny greifen, den PPP finde ich etwas umständlicher.

Code:

$
d[2] = 12; // erste Variable mit X-Wert
for(d[1] = 1; d[1] < 51; d[1]++)
  Command.ShowPicture(d[1], "BILDNAME", d[2], d[2]+1);
  d[2]++;
  d[2]++;
next;

@ elvissteinjr: Im unpetatchten Maker ist so etwas zwar möglich, erfordert für meinen Geschmack jedoch zu viele Forks, da die Picture-Nummer nicht gepointet werden kann. Außerdem scheint der Destiny dem normalen Makerskript performancemäßig stark überlegen zu sein.

[Oktorok3]

Tagchen.
Ich habe seit längerem eine Idee für ein nützliches Hilfttool für den Maker, das bestimmt nicht nur für mich eine sehr hilfreiche Angelegenheit wäre, sondern für jeden, der Events mal hier und dahin kopiert und sei es nur, um die Map zu verschönern (z.B.Bäume).

Das Problem kennen sicher viele und manchmal können diese Routineaufgaben im Maker ziemlich nerven, wenn man sagen wir 25 Bäume per Events hintereinanderlegt und jedes einzelne Event 25 mal kopieren und einfügen muss (falls man also jeden Baum nur mit Events setzt, bei 25 Bäumen 625xCopy+Paste)
Nur eines von vielen Beispielen.

Deshalb meine Idee dazu->


Tool für Massencopy+paste von Events (zusätzlich evtl. auch Massenverschieben, da das Einzelverschieben der Events auch Ewigkeiten dauern kann)

Ich habe mich dazu bereits mit dem "Spezialist" in Verbindung gesetzt, doch da diesem die Zeit dazu fehlt findet sich ja vielleicht auch ein Anderer, der sich an der Umsetzung dieser Idee versuchen will.

Damit wäre eine weitere Extremeinschränkung des Makers umgangen,
von der Zeiteinsparung dadurch gar nicht erst zu reden!

[MarcL]

Tagchen.
Ich habe seit längerem eine Idee für ein nützliches Hilfttool für den Maker, das bestimmt nicht nur für mich eine sehr hilfreiche Angelegenheit wäre, sondern für jeden, der Events mal hier und dahin kopiert und sei es nur, um die Map zu verschönern (z.B.Bäume).

Das Problem kennen sicher viele und manchmal können diese Routineaufgaben im Maker ziemlich nerven, wenn man sagen wir 25 Bäume per Events hintereinanderlegt und jedes einzelne Event 25 mal kopieren und einfügen muss (falls man also jeden Baum nur mit Events setzt, bei 25 Bäumen 625xCopy+Paste)
Nur eines von vielen Beispielen.

Deshalb meine Idee dazu->


Tool für Massencopy+paste von Events (zusätzlich evtl. auch Massenverschieben, da das Einzelverschieben der Events auch Ewigkeiten dauern kann)

Ich habe mich dazu bereits mit dem "Spezialist" in Verbindung gesetzt, doch da diesem die Zeit dazu fehlt findet sich ja vielleicht auch ein Anderer, der sich an der Umsetzung dieser Idee versuchen will.

Damit wäre eine weitere Extremeinschränkung des Makers umgangen,
von der Zeiteinsparung dadurch gar nicht erst zu reden!

...

Kuck mal ob du hiermit was anfangen kannst ^^ habs selbst noch nicht getestet, aber es mir fest vorgenommen ^^;

http://www.youtube.com/watch?v=ei-aMOWgHgs

Ich denke (keine Ahnung) dass das hier http://rubydragon.uw.hu/jatek/mapmaker.zip der Downloadlink war ^^

[G-Brothers]

Ich glaube nicht, dass das Tool im Video dafür ausgelegt ist, mehrere Events zu markieren und kopieren, wie Oktorok es sich wünscht.
Aber recht praktisch. Das Teil schreibt automatisch die Events, wenn sich Objekte überlappen.

[Oktorok3]

Nein, das meinte ich nicht.
Soll ja auch sehr praktisch sein, dennoch funktioniert dieses sowieso bei mir nicht (Errors).

Naja, vielleicht wird sich noch jemand darum kümmern. Immer optimistisch bleiben.

[Corti]

Sachen, die Cherry mir auf dem BMT mal eben live gestrickt hat.

Diese Änderungen sind C++-Codezeilen, die per DynRPG verwendet werden können. Wer die per HexHex anweden will, oder per Quickpatch muss das umrechnen. Konstanten findet man irgenwo in diesem Topic.

Zeile Sofort anzeigen:
Diese Funktion, eine Textzeile oder auch den gesamten text einer Messagebox sofort anzuzeigen kennt man aus dem TestPlay-Modus. Dort gibt es diese funktion per Shift-Taste. Die folgenden Zeilen dienen dazu diese Funktion mit einer oder allen Zeilen auch im Nicht-testplay anwenden zu können.

// im NormalPlay eine Zeile sofort anzeigen
*reinterpret_cast<unsigned short *>(0x4C7C42) = 0x9090; // Default: 0x1074
// im NormalPlay alle Zeilen sofort anzeigen
*reinterpret_cast<unsigned short *>(0x4C7C88) = 0x9090; // Default: 0x1074

Die Tastenbelegung dieser Funktion umändern.
Die folgenden zeilen ändern die Taste für Text sofort zeigen von Shift in Decision um. Somit wird die "Message bestätigen"-Taste auch zum Message anzeigen benutzt, viel komfortabler.
Der "Hack" den bugmenot hierzu vor einigen Seiten veröffentlicht hast tut das nicht, sondern belegt statt dessen alle Funktionen der Shift-Taste um.

// Taste für "Zeile anzeigen" auf alle Decision-Tasten
*reinterpret_cast<unsigned char *>(0x4C7C4D) = 0x44; // Default: 0x41
*reinterpret_cast<unsigned char *>(0x4C7C51) = 0x10; // Default: 0x01
// Taste für "alle Zeilen anzeigen" auf alle Decision-Tasten
*reinterpret_cast<unsigned char *>(0x4C7C93) = 0x44; // Default: 0x41
*reinterpret_cast<unsigned char *>(0x4C7C97) = 0x10; // Default: 0x01

Funktion zum ändern der Position des Blinkcursors
// Blinker X-Korrektur-Wert von rechter Seite des Fenster aus (Default: Mitte)
*reinterpret_cast<unsigned short *>(0x4C8689) = 0x08EB; // Default: 0xF8D1
// Blinker X-Korrektur-Wert (größer = weiter links)
*reinterpret_cast<unsigned char *>(0x4C8695) = 20; // Default: 8
// Blinker Y-Korrektur-Wert (größer = weiter oben)
*reinterpret_cast<unsigned char *>(0x4C8685) = 10; // Default: 8

[bugmenot]

BGM&SE Pointer

Download vorübergehend entfernt. (WIP)

[bugmenot]

Switches lassen sich nicht "anpointern" und sind fürs Scripten daher unbrauchbar.

...

Ich widerspreche anderen Leuten nur allzu gerne:


SwitchPointerPatch
download SwitchPointer

Bei Gebrauch von ForkCondition "Switch[0001] = ON/OFF" wird stattdessen die Switch_ID aus Var[3397] verwendet.


download LunarIPS
Erster Schritt: legt euch eine Sicherungskopie eurer RPG_RT.exe an (für den Fall der Fälle)
Lunar IPS öffnen -> apply IPS patch -> .ips-Datei (den Patch) wählen > Dateityp: all types -> RPG_RT.exe auswählen

Nach dem Patchen lässt sich die Var_ID in der RPG_RT.exe unter 0x708C7 (2k) und 0x92F5F (2k3) per HexEditor umstellen. Oder packt den Patch in den Ordner DynPatches und:

[QuickPatches]
SwitchPointer=493B5F,#3397

...

When using ForkCondition "Switch[0001] = ON/OFF" the Switch_ID stored in Var[3397] will be used instead.


download LunarIPS
First step: make a backup of your RPG_RT.exe (just in case)
open Lunar IPS -> apply IPS patch -> select the .ips file (this patch) -> file type: all types -> select the RPG_RT.exe

Upon patching you can change the Var_ID in the RPG_RT.exe at 0x708C7 (2k) and 0x92F5F (2k3) by using a HexEditor. Or put this patch into your DynPatches folder and:

[QuickPatches]
SwitchPointer=493B5F,#3397

...

P.S.
Hat bisher schon jemand Patches hinter dem betterAEP angereiht? Oder stehen diese potentiellen Codestellen noch frei?

[Cherry]

Da ist gar nichts mehr frei, ich verwende sogar schon mehrere Bereiche aus der VCL, die der Maker nicht verwendet (Drag&Drop zum Beispiel). Zusatzsachen macht man daher am Besten via DynRPG (wo du deine Pointerpatches wohl mit 1/5 Aufwand und wartbarem Code, von leichter (de)installation ganz zu schweigen, hättest machen können).

EDIT: OK, 2k-Support spricht dagegen, stimmt.

EDIT2: Ein Loader, der eine DLL lädt, wäre auch eine Idee.

[MagicMaker]

Die mit Debugtasten zugestopften FatalMix-Versionen von RPG_RT sind um die 20kb größer als normale,
müsste es also nicht auch so Möglichkeiten geben, Inhalte anzuhängen?

[goldenroy]

EDIT: OK, 2k-Support spricht dagegen, stimmt.

...

Gibt es überhaupt bis auf das KS irgendwelche Gründe, noch den 2k zu benutzen? Das 2k3-KS wurde ja auch kürzlich von Corti weniger schrecklich gemacht.

[MagicMaker]

Gibt es überhaupt bis auf das KS irgendwelche Gründe, noch den 2k zu benutzen?

...

FirstParty:
- Kein fragwürdiger Schnickschnack
- Keine neuen Extrabugs
- Harmony-Soundsysteme von Haus aus
- Viel länger weiterentwickelt

ThirdParty:
- Es gibt Destiny
- Englisches RTP ist einheitlicher

Da gibts sicher noch mehr.

[goldenroy]

FirstParty:
- Kein fragwürdiger Schnickschnack
- Keine neuen Extrabugs
- Harmony-Soundsysteme von Haus aus
- Viel länger weiterentwickelt

ThirdParty:
- Es gibt Destiny
- Englisches RTP ist einheitlicher

Da gibts sicher noch mehr.

...

Fürn 2k3..
FirstParty:
- Neue Zusatzfunktionen
- Nativer MP3 Support

ThirdParty:
- Es gibt DynRPG (!)
- Patches heben verdammt viele Bugs auf
Und das RTP ist bestimmt wirklich kein Switchgrund. U:

[MagicMaker]

- Nativer MP3 Support

...

Haben 1.5, 1.51 und 1.52 auch.
Wer Haus-Support für so ein mieses Format braucht, hat jedenfalls kein Hindernis.

- Es gibt DynRPG (!)

...

Ja, für Programmierer.

[Corti]

Als er die Frage stellte wusste ich wer was schreiben würde.
Haha :-D

Maker-Unterschiede werden hier als Glaubensfrage behandelt, also geht ins Forum für Glaubensangelegenheiten

[bugmenot]

Gibt es überhaupt [...] irgendwelche Gründe, noch den 2k zu benutzen?

...

Gegenfrage: warum nicht?

Geschmackssache

...

Kugelschreiber oder die Feder, mit was schreibt es sich besser? Wen stört das Arbeitswerkzeug schon.

..und HEY! Wo bleibt dein "Danke, dass du dir sowohl für 2k als auch 2k3 die Mühe machst Patches zu basteln, die hier niemanden interessieren." ?

DestinyV2

...

32bit. 'nuff said.

[Corti]

Hast natürlich recht. Der Switchpointer ist großartig! Well done.

Eine Frage dazu hätte ich noch: Du schreibst danach was von "Codestellen frei", hast du im Switchpointer irgendwelche Sprünge drin, die sich nicht mit anderen Patches vertragen können oder ist deine Änderung eine risikolose Änderung im Switchcode und die Frage bezog sich auf etwas anderes, dass du planst?

Noch etwas:
Könntest du rausbekommen, an welchen Stellen im Speicher die Attribute und Conditionanfälligkeiten der Monster liegen?
Im Maker sind diese mit A bis E einstellbar. Durch Senken/Erhöhen kann im Kampf die Attribute-Anfälligkeit um eins nach oben oder unten geändert werden.
Interessant wären also sowohl die Werte aktueller Monster als auch die der Monster in der Database.

mfg

[bugmenot]

[...] im Switchpointer irgendwelche Sprünge drin, die sich nicht mit anderen Patches vertragen können

...

Nur im Falle des 2k Patches. Es fehlte 1 Byte... wow... Weswegen 8 Byte Code ans Ende einer zerstückelten Funktion ausgelagert wurden, welche direkt hinter dem bAEP liegt.

Edit:
Sonst könnte ich bei beiden Versionen den Code auch in das ShowLogoOnStartUp packen (Was nicht alle OK finden könnten) und den üblichen FailSafe wegen initialisierten Variablen reinpacken (hier ist das irgendwie nicht wirklich nötig) sowie einen Sonderfall für Var[SwitchPointer] = 0 (get Switch_ID = 1 instead).

Edit²:
[DATA EXPUNGED]

Noch etwas:
Könntest du rausbekommen, an welchen Stellen im Speicher die Attribute und Conditionanfälligkeiten der Monster liegen?

...

Könnte ich mal reinschauen... Wie gesagt, ich bin nur ein Laie in Sachen Software-Innereien. (Rhyme not intended)

[Corti]

Für einen Laien schlägst du dich ganz gut