Druckbare Version
Danke! Meine Gebete wurden erhört!
Ich hab wieder eine Idee! Es gab ja schon mal für den RPG Maker XP ein AntiLag-Script, das einfach Events, die außer Sichtweite waren angehalten hat (außer es waren Parallele oder Automatische Prozesse). Gibt's sowas auch schon für DynRPG?
(vllt. sollte ich mal langsam halb lang machen, ich Spam hier sonst vor lauter Freude noch alles zu! :'D)
Such mal bugmenots Posts durch. Irgendwo hat er was gemacht mit Optimierung der Performance, war aber ein Fix und kein Plugin.
>>AntiLagSwitch<<?Zitat:
Zitat von Corti
Ja, den kenn' ich schon. Aber ich meine genau noch so etwas.
Eigentlich suche ich auch viel mehr etwas, was die Route von Events erst beginnen lässt, wenn sie in Bildschirmnähe auftauchen. Aber beim XP hat das mit diesem Script auch funktioniert... :/
Nennt sich Logik und eine Prise Mathematik. Vielleicht noch ein bisschen Coden mit den Funktionen, die dir das Werkzeug (mit dem du arbeitest) bereits zur Verfügung stellt.Zitat:
Zitat von Stray
Wenn es trotzdem ruckelt, kannst du ja posten, welche Eventbefehle du am meisten ausführen lässt. Lösungen gibt es nur für definierbare Probleme.
Entschuldigung, dass ich dem jetzt ohne gentleman'sche Wortwahl antworte, aber das klingt dämlich. Also das Konzept von "Was nicht auf dem Screen ist, wird nicht aktualisiert".Zitat:
Zitat von Stray
Die VXP-Reihe leidet an irgendetwas anderem, was die Performance so grottig werden lässt.
Da helfen auch keine asynchronen Wasserfallgrafiken.
Na gut. Es hat beim RmXP damals zumindest geholfen. Es hat natürlich nicht das Problem beseitigt, dass der RPGXP ohnehin viele Ressourcen frisst usw.
Es geht dabei auch um eine ganze Menge Events, da es ja sonst nicht laggen würde. Es wäre nämlich etwas großer Aufwand für eine große Anzahl an Ereignissen eine Horde an extra Variablen und co. für die Berechnung dessen, wann ein solches im Bildschirmbereich auftaucht aufzustellen und für jedes davon gesondert anpassen zu lassen.
Aber es war nur eine kleine Idee und sicher ist die Performance vom Rm2k(3) in den meisten Fällen auch gut genug.
Die Performance sämtlicher RPG Maker ist mit Ausnahme des XP hervorragend. Es sei denn, du hast einen wirklich alten PC.
Beim XP hilft wiederum die Fusion mit dem VX Ace, d.h. du benutzt den RMXP mit RGSS3. Sofern du Skripte benutzt, müssten die dafür aber extra abgeändert werden.
Die 2k-/2k3-Performance-Schwierigkeiten resultieren dagegen meistens aus diesen Sachen:
- größere, rotierende Pictures (nicht bei jedem PC)
- keine 0.0s oder 0.1s waits am Ende eines parallelen Prozesses
- zu riesige Maps mit zuvielen Objektcharsets
*senf
Soweit ich weiß funktioniert dann die native Encryption vom XP allerdings ebenfalls nicht mehr.Zitat:
Zitat von Davy Jones
Sofern du nicht auf die Idee kommst mehr als 200 mal <MoveEvent> je Frame ausführen zu lassen. (Das kann man zB. mit einem 0.0 wait in 200er Blöcke aufteilen.) MovementRoutes sind da weniger anspruchsvoll im Hinblick auf Prozessorauslastung.Zitat:
Zitat von Stray
Dazu braucht man insgesamt nur 5 (Hero_x, Hero_y, Event_ID, Event_x, Event_y). Für alle Events. Und nicht für jedes Event x Werte. Bei Differenz von Hero_x - Event_x falls kleiner -20 / größer +20 bzw. Differenz in y-Pos wird halt... ich weiß nicht... so eine Art SelfSwitch umgelegt, welcher die zweite EventPage aktiviert, bei der der MovementType auf [stationär] steht. Wenn das Event wieder im Screen ist -> SelfSwitch OFF, dann geht die MovementRoute soweit ich weiß da wieder weiter, wo sie unterbrochen wurde.Zitat:
Zitat von Stray
Oder besser noch: Event_ID[xyz] bis Event_ID[zyx], welche sich in einem Bereich der Map aufhalten, erst stillegen, wenn man eine bestimmte Entfernung verzeichnet. Dann laufen die Events zumindest nicht mehr asynchron oder sonstwie ungeplant durcheinander. (Ich nehme mal an, auf das Problem stößt man mit dem XP Skript?)
Item&EventPointer-Ersatz
Aber es sieht auch irgendwo dämlich aus, wenn etwas, das aus dem Bild raus ist, auf einmal nicht mehr hinterherkommt.
Die XP-Verschlüsselungen wurden schon vor Jahren geknackt, dementsprechend ist der Kram so unnötig wie ein Kropf.Zitat:
Zitat von goldenroy
Ich möchte aber eine wirklich große Menge Events auf einer Map verwenden, die blöderweise alle gleichzeitig einen Parallelen Prozess bräuchten. Waits habe ich bereits überall eingefügt. Laggen tut es trotzdem immer wieder mal und ich bin mir nicht sicher, ob das auf jedem anderen Rechner noch genauso 'knapp-gut' läuft, obwohl mein Computer nicht gerade eine Low-End-Maschine ist. Er ist relativ neu und funktioniert gut.
@bugmenot:
Auch bei 5 Variablen wäre es bei der Menge an Events und den damit zu ersetzenden Variablen extrem, da in einem Event nicht nur die Werte abgespeichert werden, sondern auch in Bedingungen abgefragt werden, was auch wieder ersetzt werden muss. Ich benutze zur Zeit für jedes Event die selben Variablen, was verrückterweise sogar ganz okay funktioniert.
In meinem Fall wäre es nicht so wichtig, weil es ein Sidescroller ist, bei dem sich der Bildschirm während des Spielens automatisch verschiebt.Zitat:
Aber es sieht auch irgendwo dämlich aus, wenn etwas, das aus dem Bild raus ist, auf einmal nicht mehr hinterherkommt.
Wäre es nicht sicherer und einfacher die Events von einem globalen Loop-Event zu callen? So hättest du a) nur einen PP und b) verhinderst du von vornherein, dass sich die Events - wenn sie die gleichen Variablen nutzen - gegenseitig in die Quere kommen.Zitat:
Zitat von Stray
PeAcE
MorDen
Aber das würde ja bedeuten, dass man wieder für jedes einzelne Event neue Variablen schaffen muss - und gerade das will ich nicht.
Die Überschneidung ist nicht das große Problem, denn die funktioniert sogar ganz gut, wenn man sie in den Griff kriegt.
Hi Stray. Vielleicht misverstehe ich das Problem mit den eigenen Variablen aber vielleicht hilft dir meine Vorgehensweise bei solchen Sachverhalten.Zitat:
Zitat von Stray
Ich benutze für den Rm2k den Destinypatch und habe auf meinen Maps bis zu 40 Events die sich per Call einer Datenbankevents registrieren.
Im Anschluss daran wird in einem einzigen Event der Datenbank über die IDs geloopt und je nach Eventnamen zu der ID oder weiteren Infos reagiert.
Dabei ist der Destinypatch unersetzlich, denn er hat die Möglichkeit ein Events per ID aus einer Variable fernzusteuern oder sogar ihr Aussehen zu verändern.
Das Minimum was du brauchst ist eine reservierte Anzahl von Variablen des RPGMaker für die ID-Liste.
Falls deine Events Gegner sind, die eine gewisse Energie haben brauchst du logischerweise für jeden Gegner mindestens eine eigene Variable für die Energie. Der DestinyPatch bietet hier zusätzlich eigene Datentypvariablen an, die hierfür sehr praktisch sind.
Du kannst damit beispielsweise die HP-Variable in den dworten des Destinypatch zusammensetzen aus (MapID * 1000) + EventID.
d.h. Event 1 auf Map 1 = d[1001]
Event 90 auf Map 150 = d[150090]
Der DestinyPatch lässt maximal 900.000 dworte zu, soweit ich weiß.
Auf diese Weise kannst du deinen Events eigene globale Variablen zugestehen aber du kannst ganz ohne konkrete Variablen arbeiten indem du die entsprechende Variable immer über die Formel (MapID * 1000) + EventID = dwordPointer erhälst.
Kann man überhaupt verstehen, was ich meine?
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?Zitat:
Zitat von bugmenot
Der Einfall ist mir vor vier Monaten auch in den Sinn gekommen. Mir war aber kein freier Platz in den Pointern bekannt (ohne groß zusammenfassen + anpassen zu müssen) um die Flag unterzubringen, und keine Funktion bekannt, welche jeden Frame nur 1 mal abgerufen wird.Zitat:
Zitat von Cherry
Das lässt sich beides doch extern in einer DynRPG-Routine unterbringen?
...und die loop in loc_4AB8C5 verlassen, solange Flag = true (nach Durchlauf der Schleife setzen) und das ding/flag halt nach jedem Frame per externe Funktion auf false (= do not block EvUpdate) flippen. Warum brauchst du dafür meinen Konsens?
P.S.
Mir ist etwas eingefallen:Zitat:
Zitat von bugmenot
download MapInMenu
Keine Ahnung, was ein transparentes F9-Menü bringen soll. Credits an Cherry's erste 2k3 Version.
Ich würd mir meinen eigenen Platz für das Flag suchen, z.B. 4CE100, oder irgendwo ein unbenutztes Byte klauen, wie z.B. Offset 5 (nach der Scene, die nur als Byte und nicht als DWord verwendet wird) in TLcfgSystem, also [[4CDC7C]]+5.
Dann würde ich das richtige UpdateEvents (wenn nötig) einfach bei 4903AB machen, also nachdem die Scene geupdated, aber noch nicht gedrawt wurde (weil letzteres vom Maker ja auch geskipt werden kann wenn ersteres zu lange gedauert hat).
Ich werd das bei Gelegenheit mal einbauen, wenn du es noch nicht gemacht hast bis dahin.
Deinen Konsens: Naja, weil du den AntiLagSwitch gemacht hast, dich also schon mit den Auswirkungen auseinandergesetzt hast, wenn man UpdateEvents nicht aufruft, und daher, sollte meine Idee fehlerhaft sein, was gesagt hättest :)
@all: Kann mir mal wer ein Spiel verlinken was derbe laggt (und zwar nicht wegen Show Picture)? Ein Real Life Example wär praktisch.
Btw, ich frag mich ja auch woran es liegt, dass das Rotieren von größeren Pictures so extrem laggt. Ich vermute ja, dass sich der Frameskip-Mechanismus da selber ein Ei legt, sobald das Updaten länger dauert als 1/60 Sekunde (weil es das ja jedes Frame braucht).
... du meinst sicher das Byte neben der GameScene, welche durch den [MainPtr]+4 dargestellt wird?Zitat:
Zitat von Cherry
Wenn nicht, dafür sind die 90 90 da. GameScene auf [+4] wird sowieso überall als BytePtr gesetzt/abgefragt bzw. mit zero extend für jmp off_4...[eax*4] ausgelesen.
Eine nicht so schwachsinnige Version.
UpdateEvents setzt eine Byte_flag und in sub_4A35D0 wird dann die flag wieder = false gesetzt und das eigentliche UpdateEvents durchgeführt (ohne nach dem ersten EventBefehl zu blockieren).
Frag mal Itaju, ob er noch den Downloadlink der semi-aktuellen Version von AtV hat.Zitat:
Zitat von Cherry
Oder copy&paste dir ein paar dutzend Events mit 100 EventPages (zählt dann als ca. 50 Events) zusammen und einige hundert mal inc(Var1) in einem parallel process.
Ja, sollte alles beschreibbar sein... was crasht da bei dir?
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.Zitat:
Zitat von Cherry
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....)Zitat:
Zitat von Davy Jones
Das.Zitat:
Zitat von Cherry
Edit:
...
Die Festlegung des Datenbereiches mit einem FF FF FF FF 01 00 00 00 fehlt?
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!
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.
Da hat eine gewisse Person vor knapp 17 Monaten etwas anderes behauptet.Zitat:
Zitat von Cherry
1. ...hat sich erledigt... (DePatch)Zitat:
Zitat von Cherry
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.
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.
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:Zitat:
Zitat von Cherry
Ausgabe muss sein: AC, das parallele Event bricht sofort ab, sobald eine andere Bedingung erfüllt ist.Code:Event:
Seite 1 (Paralleler Prozess, ohne Startbedingung):
Message "A"
Schalter 1 an
Message "B"
Seite 2 (Autostart, Bedingung Schalter 1 an):
Message "C"
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.
Ohne Patch: ACZitat:
Zitat von Ghabry
Mit Patch: ABC
Mit Patch mit [0.0 Wait] vor B: AC
Inwiefern?Zitat:
Zitat von Ghabry
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)
?
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.
Hm, für diesen Fall könnte man ja einführen, dass UpdateEvents nur das aktuelle Event (das am Bottom des Calltrees) updatet.
@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.
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:
Die Parent Map dazu hat übrigens 2190 Events. Und da ist kein Text...Zitat:
Zitat von MarcL
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.
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:
Der Vollständigkeit halber müsste das ganze btw auch bei Item Management und Change Party ausgeführt werden.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)
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.
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.
Okay, LocalUpdate jetzt beiZitat:
Zitat von Cherry
<ChangeSwitch>
<ChangeVariable>
<ChangeTimer>
<ChangeItem>
<ChangeParty>
<KeyInput>
Ich hoffe das Ding ist nur für den 2k3.Zitat:
Zitat von Cherry
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:
Zitat von DynRPG.ini
Awesome! Hat mich schon immer genervt der Fehler ^^;Zitat:
Zitat von bugmenot
PS: Werde den Antilag bezeiten mal testen danke :)
Den hab ich mir mal sofort reingeschmissen =)
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.
Edit: Fade-In gefixtZitat:
Zitat von Kyuu
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)
O________________________OZitat:
Zitat von bugmenot
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
Ä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.Zitat:
Zitat von bugmenot
Bitte erklär mal... Danke
@goldenroy
Ähh, warum das lange Gesicht? Obwohl, ich kann es mir schon vorstellen...
Da ich nichts von Framebuffern verstehe, kann ich darauf nicht wirklich - im Sinne des Fragenden - antworten.Zitat:
Zitat von Cherry
Nur ca. 400 Adressen. Ich dachte mir da:Zitat:
Zitat von Cherry
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.
Verdammt... Plugins, die irgendwelche Grafiken laden führen zu Crashes.Zitat:
Zitat von Cherry
Soviel zum Thema null Ahnung haben und einen ganzen Abend mit dem Kram verschwenden.
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. ;) )
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?
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.
@bugmenot:
http://i.imgur.com/kP9EFCx.png
Zumindest damit ist es jetzt kompatibel ;) (kommt in nächster Version)
EDIT: Ja, es sollte "bits" heißen. Ich ändere den Screen jetzt aber nicht mehr.
Hey Cherry,
wollte mich mal hier im Thread erkundigen, ob es möglich wäre, mit einem Plugin eine Art "Filter" über den Maker zu werfen (oder wie man das nennen kann),
mit dem man zumindest ähnliche Effekte erzielen kann wie bspw. in Max Payne 3 (bei Einnahme von Painkillern etc.)?
In diesem Video sieht man diese "Bildverzerrungs- und verfärbungseffekte" öfters mal: https://www.youtube.com/watch?v=SlP7hKLhsaE
Ich bräuchte solche Effekte (wenn auch in niedrigerer Anzahl und Intensität) für mein Spiel, aber wie ich es mir hätte denken können ist das mit dem "Vanilla-Maker" ohne halbwegs ordentliche Filter kaum bis gar nicht möglich.
Ob es mit einem zusätzlichen Plugin (auch DynRPG Plugin) geht, weiß ich selber leider auch nicht so genau, aber deshalb frage ich ja.
Wenn es bereits ähnliche Anfragen gab, entschuldige ich mich, aber ich habe keine Lust mich um diese Uhrzeit noch durch 106 Threadseiten zu buddeln..
Ich hoffe du kannst mir helfen :)
lg/ aleksy
Ich hab dazu jetzt keine Zeit, aber man (= jemand anderer) kann dafür sicher ein DynRPG Plugin schreiben. Mit DynRPG kann man nämlich auf den Bildschirminhalt zugreifen.
Das hört sich ja gut an :) Dann müsste ich ja jetzt nur jemanden finden der sowas kann.. Oder ich lerne, selber DynRPG Plugin zu schreiben ^_^
Kazesui hat ein Plugin für Blendmodes gemacht. Damit kannst du Verfärbungen umsetzen. Wie du aus den Blendmodes aber etwas künstlerisch Wertvolles machst, musst du selbst rausfinden.
Kurioserweise bringen .lua Skripte das Spiel nicht zum Abstürzen. Das Bild ist zumindest schonmal verzerrt und verfärbt, so we got that.Zitat:
Zitat von BDraw
Also könnte DynRPGSS da potentiell noch was aus Bananen-Joe's umgeschriebenem Framebuffer rausholen, falls der Zugriff auf den Framebuffer seitens DynRPG auf einen 32bit-Mode umgestellt werden könnte - hat doch auch mit unidebug funktioniert? (weil keine inflexiblen header und so)
Ich vermute, dass DynRPGSS "funktioniert", liegt daran, dass es nicht Bildpuffer für einzelne "Bildobjekte" verwendet (wie es der Maker und andere Plugins normal tun), sondern direkt auf den Framebufer zugreift. Das hat zur Folge dass es nur dasselbe Problem hat wie UniDebug es hatte. Bei UniDebug war es deshalb leicht lösbar, weil meine Grafikbibliothek bei nicht-indizierten Bildmodi (also 16-Bit und 24-/32-Bit) sowieso immer RGB mit 8 Bit pro Farbe verwendet hat im seinem Interface (die intern halt auf 16-Bit-Farben reduziert wurden). Ich musste also nur der Grafikbibliothek die andere Farbtiefe mitteilen (und meiner Methode, die Zeugs auf dem Puffer der Grafikbibliothek in den Framebuffer vom Maker kopiert oder andersrum, und es lief.
Es wäre also tatsächlich für DynRPGSS möglich, sich da anzupassen, ich aber nicht was Kyuu dafür intern alles tun müsste. (Und es ist natürlich immer noch blöd dass nix anderes damit funktioniert.)
GuardRevamp
download GuardRevamp
Gleich mal alles in den DynPatch-Ordner geschmissen =)
Nur der 32-Bit-Patch ist mir schleierhaft. Hab die DynRPG-Variante im Ordner und wollt gleich mal ein beliebiges PNG-Bild als Panorama benutzen. Unsupported PNG Image sagt er mir dann.
Den kann man wohl nur für ganz spezielle Sachen benutzen, oder?
Alle Plugins, die irgendetwas auf den Bildschirm zeichnen führen zu einem Absturz. Mal so... nebenbei.
Soll ja auch Farbschleier und Ähnliches verhindern. Der Image Loader (oder wie auch immer das Ding heißt) vom 2k(3) ist bisher immernoch nur in 8bit.Zitat:
Zitat von Davy Jones
Der 32bit Patch erhöt die Anzahl der Farben in der Farbpalette des 2k(3), das heißt es gibt:
A) bei irgendwelchen Farbverläufen (zB. default Menühintergrund oder 8bit Bilder mit Farbverläufen) keine auffallenden, abweichenden Verfärbungen.
B) bei Transparenzen oder Änderung der Farbe/Tint weniger milchige Schlieren oder diese sich bildenden Farbbereiche, welche sich scheinbar hin- und herbewegen (probier einfach mal ein <TintScreen> mit irgendeinem detaillierteren Panorama aus. Bevorzugt eines, welches einen Farbverlauf drin hat).
@Davy: Da kommen einige Sachen zusammen.
Die Grafiken die wir im Maker benutzen haben nicht 8 Bit Farbtiefe, sondern eine 8Bit Palette mit 24Bit Farbtiefe. Jeder Pixel enthält einen Wert zwischen 0 und 255 ( 8 Bit ) , dieser entspricht dem Index der Farbe in der Palette. Die Farben in der Palette haben für Rot,Grün, Blau jeweils einen Wert von 0 bis 255, wieder 8 Bit, also in Summe 24 Bit.
Wenn der RPG Maker diese Grafiken lädt, dann erstellt er intern eine weitere Palette mit einer Farbtiefe von 16 Bit, damit diese in den 16Bit Bildbuffer geschrieben werden können. In 16 Bits bleiben nur 5/5/6 Bit für die einzelnen Farbkanäle. Der z.B. Rot-Wert von 0 bis 255 wird in einen Wert zwischen 0 und 31 konvertiert. Dadurch werden Farbwerte, die vorher nur gering unterschiedlich waren, z.B. 254 und 250 zu dem selben Farbwert, und Farbverläufe werden dadurch unsauberer.
Dieses Verkrüppeln der Farben ist es, was der Patch angeht.
Hey!
ich habe folgende Fixes rumliegen, alle mit dem Zweck das Standardmenü zu beenden und irgendwas zu setzen.
- SA Switch -> Beendet bei Status und Atb
- SOA Switch -> Beendet bei Status, Order und Atb
- SROA Switch -> Beendet bei Status, Order, Row und Atb
- RowVar[2+] -> Beendet bei Row mit Variable des gewählten Helden
Gibts auch einen Fix, der nur Atb zum Switchbefehl macht, falls ich Status wie gewohnt benutzen möchte?
Deaktiviert sich die Funktion der Hacks, wenn man die SwitchID mit 0 parametriert? Die Readme sagt dazu nichts und ich möchte ungern Bomben ins Projekt anderer Leute einbauen.
download A SwitchZitat:
Zitat von Corti
Zitat:
Zitat von DynRPG.ini
und Order und Switches werden gesetzt.Zitat:
Zitat von Corti
Bei ID = 0 werden zwar keine Switches oder Variablen verändert, aber die ursprünglichen Funktionen werden auch nicht wieder hergestellt.Zitat:
Zitat von Corti
Ich könnte da eine Abfrage reinpacken, sodass bei ID = 0 der ursprüngliche Code ausgeführt wird, aber das ist irgendwo kontraproduktiv auf zwei oder mehr Ebenen.
Gibt es da nicht bereits seitens DynRPG die Möglichkeit, dies über Plugins zu regeln? Z.B. Quit Switch Plugin (da ist eine dokumentierte(?) source Datei mit bei) oder du fragst PepsiOtaku selbst.Zitat:
Zitat von Corti
Edit:
Ich sehe gerade, dass das einfach nur ein Patch ist.
Da hätte ein callback an loc_4A24EE (bool onMenuOption (int OptionID)) und ein "jl short loc_4A2545" dahinter irgendwie mehr gebracht. Bei positiver Pluginaktivität ein call sub_4A1054 sowie [[4CDC1C]+0C] = 1) und ein return -1
Planst du zufällig Plugins an Patches zu binden?
Ich habe ein paar Sachen auf Eis gelegt (Zugriff auf die Condition- und Attribute-Arrays; Zugriff auf das Setzen und Ausführen von BattleCommands; etc.), weil die Initialisierung irgendwann nicht mehr funktionieren würde (zB. durch das Ändern von Variablen) oder es sich auf 1 mal je Frame eingrenzen würde.
Und weil es für den Endnutzer mehr Sachen gibt, auf die er/sie achten muss = höhere Wahrscheinlichkeit Mist zu bauen.
Und es würde eine Eingrenzung von Plugins auf nur ein paar bestimmte zusätzliche Funktionen bedeuten.
Und am Ende würde niemand mehr damit hinterherkommen, wer was wo benutzt und wo Bomben oder Eier eingebaut wurden... ugh, Entschuldigung.
Kann man per C++ einen Pointer auf den Ort im RAM der laufenden RPG_RT Applikation erhalten und zur Laufzeit damit interagieren? Es fehlen bisher noch zu viele Zugriffe auf Objekte, Klassen und interne Funktionen.
Noch 'ne Anfrage: elvissteinjr hat hier für den 2k3 einen patch gemacht, mit dem man Item- und Ausrüstungs/Skill-Menüs direkt aufrufen kann. Funzt das auch für den 2k, bzw. kanns jemand darauf umbiegen?
Originalpost & Patch - Item & Equip
Originalpost & Patch - Items, Skill & Equip
__________________________________________________________________
@bugmenot: Die Dark Sword Crew dankt für den Patch! :)
Sowas gehört mit zu meinen Traumwünschen bisher *gZitat:
Ich habe ein paar Sachen auf Eis gelegt (Zugriff auf die Condition- und Attribute-Arrays;
Man kann in DynRPG Adressen beschreibenZitat:
Kann man per C++ einen Pointer auf den Ort im RAM der laufenden RPG_RT Applikation erhalten und zur Laufzeit damit interagieren? Es fehlen bisher noch zu viele Zugriffe auf Objekte, Klassen und interne Funktionen.
Oder auslesen:Code:// 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
Wenn du also sagen kannst, wo die Conditions und Attribute rumliegen, könnte man Funktionen basteln, die das komfortabel handlen.Code:int getMenuScreen()
{
return ( **reinterpret_cast<char ***> ( 0x4CDC60 ) ) [12];
}
Mal schauen, was sich zusammenpuzzeln lässt...
Ein Problem vorweg: ich bin mir nicht sicher, wann die Arrays für Attribute bereits vorliegen, weswegen man unter Umständen das Zeug manuell initialisieren muss:
Code:int getAttributeAmount () //gibt Anzahl der Einträge in der Database aus
{ return ( **reinterpret_cast<char32_t ***> ( 0x4CDE44 ) ) [8] [8]; //Kann man eigentlich mehrmals hintereinander dereferenzieren? }
int getConditionAmount ()
{ return ( **reinterpret_cast<char32_t ***> ( 0x4CDE84 ) ) [8] [8]; }
void initACArrays (int BattlerID)
{
int A = getAttributeAmount ();
int C = getConditionAmount ();
int BattlerPtr;
//RPG:: Battler gibt doch einen Pointer auf ein Array aus? Dieser wird als Parameter für eine interne Funktion der RPG_RT benötigt.
//über " RPG:: Battler (BattlerID); " an den BattlerPtr herankommen[...]
call RPG_RT.004BFE1C (BattlerPtr, A); //mal angenommen die calling convention ist: Param1 = %EAX, Param2 = %EDX
call RPG_RT.004BFF5C (BattlerPtr, C);
//deswegen (unter Anderem) wird der Zugriff auf die laufende RPG_RT-Instanz benötigt
}
int main ()
{
initACArrays (BattlerID);
}
Die Pointer für die Arrays von Attributen und Conditions sollte man eigentlich über RPG:: Battler ansteuern können (die selben Ptr gelten für Actor und Monster).
Ehrlich gesagt steige ich noch nicht ganz durch bei der ganzen Re- und Dereferenzierung von C++. Kann also sein, dass da ein paar & oder * fehlen.Code://Attribute_ID als Parameter ID angeben
int getAttribute (int BattlerPtr, int ID)
{
int ArrayPtr = BattlerPtr [48]; //Ptr auf das AttributeArray
return ArrayPtr [ID*2-1];
}
//Condition_ID als Parameter ID angeben
int getCondition (int BattlerPtr, int ID)
{
int ArrayPtr = BattlerPtr [56]; //Ptr auf das ConditionArray
return ArrayPtr [ID*2-1];
}
Schreibzugriff sollte eigentlich auch möglich sein(?).
Die ArrayStruktur sieht wie folgt aus (IDs starten nicht bei 0):
[ID*2-1] die zweiten 8bit für die Resistenzangabe (0=A, 1=B, ...) und
[ID*2-2] die ersten 8bit für zusätzliche Information (-1|+0|+1 Modifier für Attribute oder die Uptime von Conditions)
Arraygröße ist 2 x 8-bit x get[xyz]Amount
Es gibt schon Klassen für die internen Arraystrukturen ,wie z.B. DArray bzw. DList...
was genau hast du da vor? Ich versteh das momentan grade nicht.
Direct Menu Patch
download DirectMenuPatch(fix)
Langsam verlier ich den Überblick über diese ganzen Menüpatches. xD
Da gibt es welche, um Menüpunke direkt zu öffnen, welche um Menüpunkte auszuhebeln, dann noch VisuMenu für generelles umgestalten, Cherrys MapInMenu und von allen irgendwie zig verschiedene Versionen und dann noch für 2k/2k3 und manche als Plugin und aaaah. D8
Ich glaub ich such die mal zusammen und mach nen "Pimp my menu"-Thread oder so. °3°
Besten Dank!
Update
... da ist jetzt ein Patch für 2k3 mit bei, sowie ein Bugfix für die 2k Version (bei leerer Party kein Crash mehr).
... es müsste eigentlich auch möglich sein mit einem geupdateten SystemClock w/ Foreground & Background Plugin noch mehr Zeug in die ganzen anderen Menüs reinzupacken.Zitat:
Zitat von goldenroy
Ohne mal an zusätzliche Möglichkeiten des Zugriffs von DynRPG (irgendwann vielleicht) auf Menünavigation zu denken (Ordnungsfunktion + Reihenwechsel in Einem. Wie in den gängigen klassischen Rollenspielen... so mal als Beispiel)
Edit:
Solange ein Battler noch nie angegriffen wurde, istZitat:
Zitat von Cherry
immernoch gleich Null. Lese- und Schreibzugriff auf das Array mit den ganzen Attributresistenzen ist somit nicht möglich. Man kann vielleicht noch über die Klassen Actor und Monster(nicht "subtype of battler") die ganzen Resistenzen auslesen.Code:call sub_4A6014
mov eax,[eax+30h]
Andere Frage: mit
kommt man an einige Informationen ran... wie dreht man das jetzt aber um (einen Pointer erhalten, über den man neue Werte setzen kann)?Code:int MonGroupID = ( **reinterpret_cast<long ***> (0x4CDD38) ) [3];
bool BatDefeat = ( **reinterpret_cast<char ***> (0x4CDD38) ) [132];
bool BatVictory = ( **reinterpret_cast<char ***> (0x4CDD38) ) [133];
Und wie kann man Code wie
gescheit in C++ umsetzen?Code:mov eax,[eax]
mov eax,[eax+8]
mov eax,[eax+8]
Wenn man mittels RPG:: Action die Parameter kind, basicActionId, skillId, monsterId, itemId, target, targetId setzen würde... sowieZitat:
Zitat von Cherry
target an [[0x4CDD38]+B0h],
targetId an [[0x4CDD38]+B4h] und
Hero_ID (bzw. -1 if isMonster=true) an [[0x4CDD38]+B8h]
schreiben würde, dann würde es noch lange nichts nützen, solange
nicht aufgerufen wird (entspricht manuellem Ausführen eines Kampfbefehls... wäre nützlich für Kontern, eigene KI, SkillCombo, etc.)Code:call sub_4A6014
xchg eax,edx
mov eax,off_4CDD38
mov eax,[eax]
mov eax,[eax+5Ch]
call sub_4175DC
http://rpg-maker.cherrytree.at/dynrp...c8c3785a52161a ?
Und wegen "umdrehen": Eine Referenz erstellen - int &monGroupID, etc.
Sowas wie dein +8 +8 Beispiel würd ich so direkt natürlich nicht einbauen (außer halt eben wenn ich noch keine Strukturen habe, aber das ist ja da nicht der Fall), sondern - mal davon ausgehend dass da von einem TCatalog die Länge willst - einen DListPtr setzen und die length property verwenden (dafür ist sie ja da).
Habe ich übersehen. Kann mit der Information vielleicht etwas anfangen, wenn ich insgesamt mehr als 3-4 Stunden Erfahrung mit C++ habe.Zitat:
Zitat von Cherry
@DArray
Du meinst, dass sich über
mit dem angepointerten Array arbeiten lässt?Code:static RPG::DArrayPtr *&namegoeshere = (**reinterpret_cast<RPG::DArrayPtr ***>(0xoffset));
Andere Frage: hat man per Plugin Zugriff auf den address space von der RPG_RT.exe Applikation? Lesen und Schreiben geht ja über reinterpret_cast bereits. Was mir persönlich fehlt, ist ein bequemes Angeben von Funktionsadressen aus der RPG_RT zum Ausführen jener Funktionen und um schnell mal ein paar dutzend Sachen durchzuprobieren.
Edit³:
Dammit... Soetwas wie:
Werde das beizeiten mal auseinandernehmen. Der Aufbau hiervon sagt mir nur leider nicht viel, außer dem Zuweisen der %Register.Code:function RuntimeFunction(RPG::AppropriateClass *PtrOnObject, int x, int y) {
int ret;
asm volatile("call *%%esi" : "=a" (ret), "=d" (RPG::_edx), "=c" (RPG::_ecx) : "S" (0xFunctionOffset), "a" (Object), "d" (x), "c" (y) : "cc", "memory");
return ret;
}
Ach und: Bugfix.
Im 2k3 fehlt im Database Editor der Zugriff auf einen Parameter von Skills (dieses "failure message" Ding beim 2k). Wenn man Skills löscht und neue erstellt, dann setzt sich der Parameter zurück auf 'magic type evasion' und ignoriert AGI-Werte und Conditions für die Berechnung von Trefferwahrscheinlichkeiten.
Wenn man ATK influence auf Null setzt, dann werden AGI-Werte und Zustandsänderungen (wie Blind) ignoriert (für klassische Zauber). Damit eine Ausweichrate durch AGI berücksichtigt wird, muss man die ATK influence auf 1 oder höher setzen.Zitat:
Zitat von DynRPG.ini
Und nochmal:
Wenn AGI(target) / AGI(user) gegen Null läuft:
Falls die Trefferrate nicht bei 50% hängen bleiben soll, egal wie blind der Nutzer eines Skills ist.Zitat:
Zitat von DynRPG.ini
Edit:
Oder für Diejenigen, welche den Int Stat nicht für die Schadensberechnung nutzen
AGI und conditions ignorieren, solange INT influence größer/gleich 1 ist.Zitat:
Zitat von DynRPG.ini
Edit²:
Oder wenn sich die Skill_ID innerhalb eines festlegbaren ID-Bereiches befindet, gehen AGI und conditions in die Trefferrate mit ein:
Zitat:
Zitat von DynRPG.ini
SkillSubsets sollten nun wieder funktionieren.
Und ein paar kleine Änderungen... nützlich für "Stehlen" Fähigkeiten oder Ähnliches (siehe Readme).
"Miss!" Verarbeitung wurde etwas verbessert.
Einen Fehler beseitigt, bitte nocheinmal herunterladen:
Update/BugFix (19.02.2015); Crash bei explodierenden Gegnern.
RowPhysSkills[+] (2k3)
download RPS[+]
http://i.imgur.com/xdtVZyy.gif
http://i.imgur.com/LY6hdMf.gif
Ich hatte eigentlich vorgehabt Sachen nicht mit reinzunehmen, die man per Plugin erreichen kann... was soll's.
Edit:
download DBX.ini
(höhere DmgMul[A|B|C|D|E] für Attribute)
Nur interessehalber? Was für ne Form von Logik steckt hinter so einem fix? Steht da irgendwo in der AddCondition-Funktion ein StopMovement oder wie hat man sich sowas vorzustellen?
Btw. führt das Wechseln von Waffen zu einem ähnlichen Effekt.
Ähm... Beispiel? (greift der Fix da nicht mehr?)Zitat:
Zitat von Corti
Standardmäßig wird in dieser AddCondition-Funktion der Animation2-Parameter von RPG :: Battler sofort auf "Bad Status" gesetzt. Der Animation2-Parameter "Move back" liegt in dem Moment nicht mehr vor und das Zurückbewegen nach x/y-Pos(return) wird dadurch in der UpdateBattler-Funktion nicht abgehandelt.Zitat:
Zitat von Corti
Hab den Fix nicht ausprobiert. Hab mich nur dran erinnert, dass ich den Effekt daher kannte. Wenn man direkt nach einem Angriff die Waffe eines Helden tauscht, bevor er wiedr an seinem Platz ist, so bleibt er an der Stelle stehen.
Edit (18.11.14):
Edit (24.11.14):
Kleiner Fix, neue Version:
StatusAnimationFix[+] (2k3)
download StatusAnimationFix[+]
Ersetzt den Vorgänger (SAF.ips)
Das ist weniger eine Behebung des eigentlichen Fehlers, sondern eher ein Exception Handling für den Fall:
Animation2 = Idle mit x|y(now) ungleich x|y(return)
Animation2 (bzw. animationId) wird auf "Move back" gesetzt, FrameCounter der Aktion auf 23 gesetzt. Idle erst, wenn die Bewegung vorbei ist.
Wer jetzt mit der Positionierung der Battler-Sprites rumspielt, muss darauf achten, dass beim RPG :: Battler die Attribute x, und originalX gleichgesetzt werden müssen (das Selbe für y).
Ich habe noch ein Phänomen für dich.
Es gibt die Möglichkeit eine Event-Seite in den Monstergroups anzulegen mit der Bedingung "Hero X does Y command". Diese Eventseite wird ausgeführt, wenn der Held beginnt diese Sache zu tun, nicht nachdem er das getan hat.
- Befehl auswählen
- Eventseite "does Y command"
- Held macht Y
Wenn man nun in dieser Eventseite "does Y command" ein Switch setzt, dass eine andere Eventseite schaltet, dann passiert das hier:
- Befehl auswählen
- Eventseite "does Y command" -> Switch1=on
- Held macht Y
- Eventseite (if switch1==on) -> Switch1=off
Das ist genau richtig so. Auf diese Weise kann man vor und nach der Handlung Eventcode ablaufen lassen.
Leider gibt es Ausnahmen.
- Wenn der Spieler ein Item anwendet, wird die SwitchEventseite nicht ausgeführt.
- Wenn der Spieler den Abwehrbefehl anwendet, wird die SwitchEventseite nicht ausgeführt.
- Wenn der Spieler einen Skill nutzt und mit dieser Skil eine Condition auf den Helden selbst ausgeführt wird, wird die SwitchEventseite nicht ausgeführt.
BugFix(2k3)
download ClassChangeEquipFix
Wenn man einen Klassenwechsel macht, wurde vorher einfach die gesamte Ausrüstung abgelegt.
Und: StatusAnimationFix-Update
@Corti
Sehe ich mir schon noch an. Ich habe die Dokumentation von BattleEvents irgendwo rumflattern.
Edit:
BugFix:
Die Zeilen mit DmgCapper, minDMG, maxDMG damit ersetzen. Der QuickPatch hat vorher negative Schadenszahlen nicht beachtet.Zitat:
Zitat von DynRPG.ini
Edit²:
Das Ding hat ein Problem damit, wenn absorbierter Schaden durch zu hohe Abwehr auf 0 runtergerechnet wird (Ziele, welche Schaden absorbieren würden, machen nun den oben angebenen Mindestschaden.)
Edit:
Falls damit etwas nicht zu funktionieren scheint, proiert die #Zahlen mit HexDezimal-Zahlen zu ersetzen:
HexConverter
Setzt die Zahl in das rechte Feld neben dem "big-endian" und nehmt die Zahlenfolge des linken Feldes neben dem "little-endian", fügt die Zahl hinter das Komma eines QuickPatches ein:
Bsp. DmgCapper(max)=446E3C,0F270000
(Oder im Windows Rechner -> Alt+3 halten)
Und: RPS[+]-Update
Edit³:
BattleMessenger(2k3)
download BattleMessenger
Ausmaße und Position der message box im Kampf über Variablen steuern.
Dafür müssen alle QuickPatches entfernt werden, die direkt mit der message box im Kampf zu tun haben.
Ich träume immer noch von einem Pixelmovement für die Kamera vom RM2k3. Auch toll wäre es sogar wenn man die Kamera auf ein bestimmtes Bild scrollen lassen könnte. Gibt es dazu schon etwas?
Zitat:
Zitat von Stray
Zuweisung der Argumente mapOffsetX/Y und scrollSpeed per onComment callback oder so.Code:int mapOffsetX; //positiv=rechts, negativ=links
int mapOffsetY; //positiv=hoch, negativ=runter
int scrollSpeed;
//[...] Argumente zuweisen
mapOffsetX = mapOffsetX*16; //16 je pixel
mapOffsetY = mapOffsetY*16; //16 je pixel
scrollSpeed = scrollSpeed*32; //"normal" speed = 32 (2x = 64; 1/2x = 16; ...)
( **reinterpret_cast<long ***> (0x4CDE54) ) [45] -= mapOffsetX;
( **reinterpret_cast<long ***> (0x4CDE54) ) [46] -= mapOffsetY;
( **reinterpret_cast<long ***> (0x4CDE54) ) [47] = scrollSpeed;
Frag jemanden (versuch es mal an Schalter 2), der Ahnung von C++ hat.
Edit:
Und die originalen Kamerapositionen wiederherstellen:
Code:( **reinterpret_cast<long ***> (0x4CDE54) ) [45] = 2304;
( **reinterpret_cast<long ***> (0x4CDE54) ) [46] = 1792;
Danke. Seit ich im Juli dort nachgefragt habe hat keiner mehr einen Beitrag geschrieben.
Bei einem RPG :: Battler von Typ Actor wird direkt nach einer Aktion das reguläre updateBattleEvents nur mit RPG :: BattleEventUpdateMode = BEUM_BEFORE_ACTION durchgeführt. Bei Battlern vom Typ Monster wird jedoch zuerst RPG :: BattleEventUpdateMode = BEUM_BEFORE_ACTION und dann noch ein RPG :: BattleEventUpdateMode = BEUM_AFTER_ACTION durchgeführt.Zitat:
Zitat von Corti
Es gibt jetzt (mindestens) zwei Sachen, die man machen kann:
Hiermit wird sowohl für Actors/Heroes als auch für Monster erst BEUM_BEFORE_ACTION und dann noch ein BEUM_AFTER_ACTION abgehandelt.Zitat:
Zitat von DynRPG.ini
Oder:
Hiermit gilt für Monster nur BEUM_BEFORE_ACTION, für Actors/Heroes jedoch auch wieder Beides.Zitat:
Zitat von DynRPG.ini
Warum das vorher nur für Monster verwendet wurde, kann ich nicht sagen. Es scheint jetzt zumindest keine Crashes oder irgenwelchen anderen Kram auszulösen*. (*citation needed)
Ich fänds toll, wenn man per Event erkennen könnte, welche der beiden Fenstergrößen gerade aktiv ist und
dass man diese auch umschalten kann. Ich halte es für verwirrend, wenn man Spielern ein Menü mit vielen
Einstellungen bietet, aber dann dabei steht, dass dieser Wechsel ausschließlich per F5-Hotkey funktioniert.
Falls jemand also richtig Langeweile hat: Betrachtet es einfach als kleinen Anstoß [RPG2000-107]
download VarExtender[+]Zitat:
Zitat von MagicMaker
Ich würde die Änderung am Eventeditor ja in eine 2k9 uimod packen, aber dazu müsste mir erstmal jemand sagen, wie man in Delphi5 auf eine StringList / Array / was-auch-immer-das-ist zugreift.