Erweiterung für RPG2003 1.12: Destiny for Maniacs!

  • Holerö!~


    Es ist viele Jahre her, da ersonn ein deutscher Programmierer mit dem klangvollen Namen Bananen-Joe die Erweiterung Destiny für den RPG Maker 2000, die neben einigen Patchfunktionen auch eine eigene Scriptsprache mitbrachte. Diese wurde bis Anfang des Jahres 2012 weiterentwickelt und schließlich mit der Veröffentlichung des Sourcecodes eingestellt.


    Da mich dieses Addon schon von Anfang an sehr begeistert hat, ich viel damit gebastelt habe und schließlich beim Vorabtest für Version 2 sehr viel Energie reinfeuerte, begab es sich 2016, dass ich anfing, Destiny auf Basis des veröffentlichten Source, größtenteils in x86-Assembler (ja, wahnsinnig gruselig) verfasst, um einen Berg neuer Möglichkeiten zu erweitern, denn in vielen Punkten hatte der Umfang noch deutliche Lücken. Diese Nebenbastelarbeit hielt bis Ende 2017 an, als ich eine Pause von all diesem Zeug einlegen musste, um nicht verrückt zu werden. Viele dazugehörige Experimente liegen neben so einigem fertigen Stuff seitdem unvollendet oder kaputt herum.


    Vor gut einer Woche hat mich der Wahnsinn erneut gefesselt, etwas daraus zu machen, diesmal jedoch mit Fokus auf den RPG Maker 2003 1.12! Auch wenn ich noch nie allzu sehr begeistert von diesem Programm war, da es das runde Produkt des Vorgängers mächtig zu zerpfuschen wusste, hat es besonders in jüngerer Vergangenheit einige neue Vorteile aus fähigen Händen geerntet, die man nicht ignorieren sollte. Doch was genau ist und kann dieses ominöse "Destiny" nun eigentlich? Dazu kommen wir jetzt.


    [Wie war das damals eigentlich?]

    Destiny kam ursprünglich in Form eines Patchers im Jahr 2008 heraus, der diverse Einstellungsmöglichkeiten mitbrachte. Das Herzstück war die Einbindung der Bibliothek "Destiny.dll", die Notizen und den sogenannten MessageLink als Scriptcode in einer eigenen Sprache verarbeiten kann. Weitere Einstellungen, von denen diverse erst gegen Ende der Entwicklung hinzukamen, waren unter anderem das Ändern von Fonts oder diversen Dateinamen, eine EnterHeroName-Reperatur sowie das Vertauschen der Zeichenebenen-Reihenfolge (Panorama, Above-Tiles, Pictures, Timer, etc.) auf dem Mapbildschirm. Ob und was alles von diesen Extras diesmal dabei sein wird, ist noch nicht entschieden, denn diese sind absolut nicht der Fokus.


    [Hab gehört, es gibt Scripting?]

    DestinyScript bietet eine Vielzahl an Datenlese- und -Manipulationsmöglichkeiten, eigene Speicherbereiche für Zahlen, Kommazahlen und Texte sowie das Ausführen von diversen Spielfunktionen, die nicht über Eventbefehle erreichbar sind. Dazu gehörten 2012 bereits Objekte wie Helden, Skills, Gegenstände, Attribute, Zustände, Events, Pictures, die Map, der Bildschirm und ein voller Tastenzugriff auf Tastatur und Maus. Die zuvor unveröffentlichte Erweiterung von ab 2016 gab vielen dieser Bereiche eine Menge weitere Inhalte, fügte allerdings auch Zugriff auf bspw. Animationen, Gegner, Gruppen, ChipSets, Terrains, System-BGM/-SE und Timer hinzu, es würde einfach zuviel werden, hier wirklich alles davon zu nennen. Ihr könnt außerdem diverse Syntax-Basics nutzen, die ungefähr jede Sprache mitbringt, jedoch beherrscht sie z.B. nicht das eigene Anlegen von benannten Konstanten oder Programmvariablen. Kurzum bekommt ihr eine Menge mehr Macht über die Engine, jedoch, das sei gesagt, NICHT im geradezu unendlichen Maße eines RPG Maker MZ.


    [Ist das denn alles legal?]

    Eine berechtigte Frage und was ältere Fassungen für RPG2000 angeht, so möchte ich dazu keinerlei Aussage treffen, diese sind hier nämlich nicht das Thema, zudem wurden dafür nie offizielle Regeln für Patches und dergleichen herausgegeben, auf die man sich stützen könnte. RPG2003 ab Version 1.10 jedoch verfügt über den Patchvertrag, der unter Erfüllung diverser Voraussetzungen das Verändern und Erweitern der Engine gestattet, ohne dass Entwickler die Berechtigung zur Verbreitung der damit geschaffenen Spiele riskieren. Ein populäres Beispiel hierfür ist Maniac Patch, prägt ihn euch gut ein, dieses gute Stück wird noch wichtig.


    [Für welche Version nochmal gleich?]

    Wie ich gerade sagte, ist Maniac Patch ein wichtiges Element hierbei, denn dieser wird für die Version, die ich hier hoffentlich irgendwann bereitstellen werde, in der Revision "200128" vorausgesetzt, das bedeutet, ihr müsst euren Maker sowie die RPG_RT 1.12 eures Spiels bereits zuvor damit verarbeitet haben. Es lohnt sich, selbst wenn ihr Destiny nicht auch noch draufpacken wollt. Wenn euch interessiert, was der so kann, schaut mal in den oben verlinkten Artikel.


    [Wie ist der Stand?]

    Am gestrigen Tage habe ich mich nach einer guten Woche Vorarbeit, die größtenteils aus einer weitreichenden, supertrockenen Datenanalyse mit viel Drecksarbeit bestand, an die Einbindung von Destiny.dll in die RPG_RT.exe 1.12 mit angewendetem Maniac Patch gesetzt und mittlerweile geht das Programm nicht mehr beim Testen in Flammen auf oder verweigert den Dienst. Die Verarbeitung des Scriptcodes funktioniert, womit ich mich nun langsam daran machen kann, die ganzen Datenzugriffsmöglichkeiten und Funktionen, die inhaltlich momentan in Destiny stecken, durchzuprüfen, zu fixen und zu erweitern.


    [Brauch ich das?]

    Keine Ahnung, aber wenn du in den alten Makerchen Menüs, Kampfsysteme, Nameneingaben oder viel abgefahrenere Dinge bauen willst, sind Maniac und Destiny eine enorm große Hilfe bei der Arbeit.


    [Kommt das auch für RPG2000?]

    Ich habe tatsächlich eine Version für 1.61 herumliegen, aber die müsste ich noch für 1.62 anpassen, weil es seitdem wieder ein Update gab (und das würde VIEL wiederholte Arbeit bedeuten). Zudem... wie bereits erwähnt, es könnte problematisch sein, da dafür nichts geregelt wurde.


    [Wann kommt's raus?]

    Sobald ich mir sicher bin, dass dieses Ungetüm auf die Menge losgelassen werden kann. Das kann noch lange dauern, ich hab auch noch andere Sachen vor als das hier.


    [Darf ich testen?]

    Möglicherweise wird irgendwann mal in die Runde gefragt, ob wer Lust dazu hat, momentan aber noch nicht.


    [Soll ich hierauf warten bis ich was erstelle?]

    Das wäre keine besonders schlaue Idee. Frohes Basteln! Hopp-hopp! Los, baut coole Sachen. =D


    [Wird das denn überhaupt fertig?]

    Finden wir's einfach mit der Zeit heraus. Hakuna Matata!


    [Dein Lieblingsfeature?]

    Picture-Manipulation all the Way!


    [SCREENS BITTE!]

    Momentan fällt mir nichts Aufregendes ein, das unmissverständlich in Standbildform die Macht von DestinyScript demonstriert und aus der Reverse-Engineering-Arbeit werde ich aus offensichtlichen Gründen nichts zeigen können. Also begnügt euch einfach mit einem winzigen Einblick darin, wie einfacher Testcode aus zweckentfremdeten Notizen und dem Messagelink ("\()") aussehen kann, mit dem ich mich vergewissere, dass die Verarbeitung klappt. Das hier ist nichtmal die Spitze der Spitze der Spitze des Eisbergs.




    [DER DOWNLOAD, VERDAMMT!]

    Ja, äh... hast du nur hier runtergescrollt, um was zu laden? Not ready yet. Ich hab noch nichtmal Patching-Tools bereit, damit ihr es so bequem wie möglich habt (wenn das überhaupt je passiert), geschweigedenn die Hilfedokumentation.



    Nun denn, das soll's erstmal gewesen sein. =D


    © 2006~2012 Bananen-Joe | Extended by KotatsuAkira


    ~炬燵あ

  • Zeit für den ersten kleinen Zwischenstand, was die letzte Woche so zusammengekommen ist an Fortschritt.


    Die meiste Arbeit nimmt neben ein paar kleinen Aufräumarbeiten und Neubenennungen, ansonsten tut sich funktionell erstmal wenig, derzeit die neue Hilfedokumentation ein, die bedeutend knapper ausfallen wird als die vorbildlichen, jedoch auch mitunter wahnsinnig ausführlichen Seiten der alten Destiny2-Hilfe, die sich immer mit nur einer Eigenschaft oder Methode/Funktion gleichzeitig, passendem Beispielcode und allem drum und dran auseinandersetzten.


    Strukturell wird es sich mehr so verhalten, dass die Inhalte und Möglichkeiten eines ganzen Objektes jeweils auf einer Seite untereinander aufgeführt werden, ohne sich großartig viel mit Beispielen aufzuhalten, zumindest vorerst. Ich möchte in einem realistischen Zeit- und Aufwandsrahmen das Nötigste fertig haben, das man braucht, um mit DestinyScript mindestens halbwegs ordentlich zu arbeiten und nicht ewig an allem hängen.


    Hier eine kleine Übersicht über die übergeordneten Objekte, die DestinyScript bietet, was sie ganz grob gesagt bedeuten und wie sie in der Hilfe momentan repräsentiert sind (alles was auf dieser groben Ebene neuer als 2012 ist, ist unterstrichen). Neben den Ausführungen zu diesen wird es allerdings auch noch andere Inhalte geben, wie eine Willkommensseite, Erklärungen zu Destiny, DestinyScript, der Syntax, Operatoren, Konstanten, Einschränkungen und solchen Dingen.


    *.AuroraSheet Einheitliche Grafikmanipulation für viele verschiedene Bereiche im Speicher:

    Kampfhintergrund, Gegnergrafiken, Eventlaufgrafiken, ExFont, Windowskin, Tileset, Dialogbox, Dialogface, Panorama, Pictures, Animation, Wetter
    Angefangen
    a[], d[], f[]
    s[], v[]
    Speicherbereiche für ANSI-Strings, Dwords und Floats sowie Zugriff auf Switches und Variablen Dokumentiert
    Actor[] Helden, Heldendatenbank Dokumentiert
    Animation[] Animationsdatenbank Dokumentiert
    Battle Kampfdaten, Aktuelle Gegnergruppe, Kampfeinstellungen Dokumentiert
    Battler[] Datenbanktab "Animations 2" (RPG2003) Dokumentiert
    Client[] Netzcode-Basis: Verbindung zu anderen Computersystemen Angefangen
    Command Ausführen eines Eventbefehls nach Abschluss des Scriptblocks (bisher nur RPG2000 bis 1.10) Dokumentiert
    CommonEvent[] CommonEvent-Datenbank Dokumentiert
    Convert Formatwandlung für verschiedene Arten von Werten. Angefangen
    Destiny Destiny-Basisdaten, Destiny-Speicherformat, Windows-MessageBox, Debugger, Konsolenfenster Ausstehend
    Directory Verzeichnisfunktionen innerhalb des Spielordners (Anlegen, Umbenennen/Verschieben, Löschen,...) Ausstehend
    Element[]
    (LEGACY: Attribute[])
    Elementdatenbank (umbenannt, alte Bezeichnung weiterhin benutzbar) Dokumentiert
    Enemy[]
    Gegnerdatenbank Dokumentiert
    Error[] Einzelne Fehlermeldungen von Destiny Dokumentiert
    Errors Allgemeine Fehlereinstellungen von Destiny Ausstehend
    Event[] Events auf der Map, Indexiert per ID Dokumentiert
    File[] Dateifunktionen innerhalb des Spielordners (Erstellen, Lesen, Schreiben,...) Ausstehend
    Game Standard-Spielstandformat, Spiel verlassen, Parameter, Viele sonstige Datensätze die ich vielleicht noch umlagere Ausstehend
    Harmony Audiosystem von Harmony.dll (RPG2000 <1.50, RPG2003 <1.05) bzw. RPG_RT.exe Ausstehend
    Input Vollzugriff auf Daten der Engine-internen Ergebnisse von Tastenabfragen auf den Gamebuttons Ausstehend
    Item[] Gegenständedatenbank Ausstehend
    Job[] Jobklassendatenbank (RPG2003) Ausstehend
    Joypad[] Komplette Beschaffenheits-/Statusabfrage von allen Joysticks/Gamepads, die Windows-Multimedia erkennt (üblicherweise bis zu 16) Ausstehend
    Keyboard Tastenabfrage- und Kontrolle auf der Tastatur, Abfrage diverser Tastaturbeschaffenheitsdaten Ausstehend
    Logic Logische Schaltungen und Vergleiche (teils ein Relikt von Destiny 1.0) Inhalt fertig
    Map Aktuelle Map, Mapbildschirm, Mapeinstellungen, MapTree-Daten Ausstehend
    MapEvent[] Events auf der Map, Indexiert wie sie im Datensatz hintereinanderweg stehen Dokumentiert
    Math Komplexe mathematische Abläufe (größtenteils Winkelfunktionen in allen Varianten) Inhalt fertig
    Message Dialoge-Textbox, Textboxeinstellungen, Enthält das ehemals eigenständige Objekt "FaceSet" (als "Face", alte Bezeichnung weiterhin benutzbar) Inhalt fertig
    Mouse Zugriff auf Mausposition und diverse andere Eigenschaften, KEIN Mausrad (da Maniac es abfragen kann, kann ich diese Daten vielleicht für diese Version abgreifen lassen, bisher nur Theorie) Ausstehend
    Panorama Map-Panorama-Eigenschaften Ausstehend
    Party Heldengruppe/Spielerfigur, Inventar Inhalt fertig
    Picture[] Pictures, Picturemanipulation Ausstehend
    Screen Spielbildschirm, Animation, Wetter, Spielfenster Ausstehend
    Server Netzcode-Basis: Eingehende Verbindungen von anderen Computersystemen Dokumentiert
    Skill[] Skilldatenbank Angefangen
    State[]
    (LEGACY: Condition[])
    Zustandsdatenbank (umbenannt, alte Bezeichnung weiterhin benutzbar) Angefangen
    String Analyse, Vergleich und Änderung von Zeichenketten Dokumentiert
    Terrain[] Terraindatenbank Dokumentiert
    Tileset[] Tilesetdatenbank Dokumentiert
    Time Aktuelle Uhrzeit, Aktuelles Datum, System-Tick, Zeitverschiebung, Sommerzeit Dokumentiert
    Troop Gegnergruppendatenbank Dokumentiert


    ~炬燵あ

  • Hallu !OwO!


    Ich habe absolut keine ahnung was du genau machst, aber Probs an dich dafür das du dir diese ganze Mühe machst und all das für die Community (schätze mal für Community xD) ausarbeitest, Aktualisierst, und verbesserst, das ist echt ein krasser Haufen Daten, den du da geschriebselt hast uff. =O:thumbup:8)


    Meow !OwO!

    Meow !OwO! Neko-Chan am start! Du interessierst dich für meine Projekte?
    Dream of Memories Work In Progress (Pausiert zwecks Aneignen weiteren Fähigkeiten)

    Das Rätselhaus Work in Progress (Aktuelles Projekt)

  • Myau!~ °ω°


    Es hat sich heute infolge einer spontanen Idee ergeben, dass sich ein weiteres neues Objekt zum Roster hinzugesellt, mit dem ihr vollständigen Lesezugriff auf die MapTree-Daten erhaltet. Der MapTree enthält Informationen, die von der Engine schnell gelesen können werden müssen, ohne betreffende Maps zu öffnen, das sind bei RPG2000/2003 eine ganze Menge (weswegen Spiele mit kaputter LMT nach Anwenden des Notfall-Tools MapTreeCreator was das angeht nur Dummy-Daten bieten können... immer noch besser als ein kaputtgebliebenes Spiel).


    Ich präsentiere, aus dem Debugger heraus, einen Blick auf "TreeMap"! Wenn jemand einen besseren Bezeichner dafür auf Tasche haben sollte, immer raus damit, denn mir fiel nichts Besseres ein. Ebenfalls aufgeführt werden, wie man sehen kann, auch der symbolische "Ordner" sowie AREAs.




    ~炬燵あ

  • Neulich erwähnte ich in der Tabelle noch, dass ich, was das Mausrad betrifft, erstmal gucken muss, ob und wie ich an die Daten rankomme, die ManiacPatch da sich zusammenholt, schon hat's gestern Abend geklappt, "Input" von Destiny darauf Zugriff zu verschaffen.


    Einen Teil der Nacht habe ich nun damit zugebracht, noch einen obendraufzusetzen, damit über die Version, wie sie für DestinyForManiacs gepatcht werden wird, auch horizontale Mausradeingaben in RPG2003-112MP erkannt und verarbeitet werden. Eine Sache, die kaum jemand jemals anwendet oder überhaupt kennt, kann das sein? Ein horizontales Rad existiert allerdings per Definition, bzw. lässt sich z.B. bei meiner Maus (und das ist eine der einfachsten, die es derzeit so gibt) dieses sogar benutzen, indem das normale Rad zur Seite gekippt wird. Ein Feature, das ich bei dem guten Dingchen überhaupt erst einige Zeit nach dem Kauf entdeckt habe, so unüblich kann's also nicht sein.


    Und das war's auch schon an Neuigkeiten, abgesehen davon, dass auch bei der Hilfe die Inhalte noch immer halbwegs vorwärtskommen.


    ~炬燵あ

  • Die Hilfe kommt recht gut vorwärts, jedenfalls fehlen bei den Objekten nur noch ein paar wenige, die abgehandelt werden müssen, danach wird es daran gehen, endlich Sachen wie die Syntax zu erklären (ohje, ohje). Parallel dazu schaue ich mir noch immer die vor allem neueren Sachen von DestinyScript an und baue/benenne einige von ihnen noch um. So auch geschehen mit der Achsen-Erkennung von Joysticks/Gamepads, was in unveröffentlichten Versionen von 2016/2017 noch leicht komplizierter gewesen ist. Und damit es ein bisschen bunter hier wird, gibt's noch anbei einen Screen von einem GamepadInput-Test-Tool, das ich vorhin in einem Event zusammengeklebt habe.




    ~炬燵あ

  • Sämtliche Objekte, so wie sie jetzt existieren, sind abseits von Senf, den ich aussortieren werde, grob dokumentiert (offenkundige Schwachstelle, bei Funktionsparametern stehen bislang keine Datentypen). Vielleicht kann ich die unfertige Hilfe ja demnächst oder weißdergeierwann vorab irgendwo im Webseitenformat ausstellen, damit sich Interessierte schonmal vom gequetschten Inhalt überrumpeln lassen können, ist bisher nur ne Überlegung.


    Jetzt stehen noch so einige aufregende Schritte an. Neben dem Kümmern um die Erklärung von DestinyScript ansich, da werd ich mich bestimmt sehr an der alten Hilfe orientieren, müssen einige Sachen noch funktionstechnisch in der DLL auf RPG2003, bzw 1.12, bzw. Maniacs ausgerichtet werden (ohne die Funktionalität bei anderen Versionen zu zerstören), seit vorhin ist das Laden von Pictures aus Dateien (ohne weitere Angaben), ohne den herkömmlichen Eventbefehl dafür direkt zu verwenden, fertig angepasst. Zumindest crasht es nicht.


    Was das Command-Objekt zum Zwischenschieben eines (fast) beliebigen Eventbefehls angeht, würde ich mir in nächster Zeit bei RPG2003 erstmal keine große Hoffnung machen.


    ~炬燵あ

  • Das geht leider mit den Einschränkungen einher, die vom Patchprogramm gesetzt werden, das Maniac (die Grundvoraussetzung für DestinyForManiacs) nicht nur auf RPG_RT, sondern auch auf das Makerprogramm von RPG2003 anwendet und sofort meckert, wenn die vorhandene Datei nicht stimmt. Der Maker unterscheidet sich in der RMWeb-Version etwas und schaltet noch eine DRM-Ebene dazwischen. Ich möchte nicht ausschließen, dass man Destiny irgendwann auch in eine RPG_RT von 1.12 ohne Maniac Patch integrieren kann, allerdings erstmal nicht.


    ~炬燵あ

  • Mittlerweile hab ich mit dem Tool "MEX", das eh niemand mehr kennt, eine Menge Eventbefehle per Windoof-Zwischenablage analysiert, inklusive der neuen ab RPG2003-1.10 und denen, die Maniac hinzuwirft. Es hilft schon sehr, den Aufbau zu kennen. Einige bestehende sind jetzt auch für RPG2003 im Objekt [Command] angepasst und funktionieren ebenda (z.B. Richtungsangabe beim Teleport oder dauerhaftes Screen-Flashen), vor manch anderen graut es mir sehr.


    Ach, warum nochmal kümmer ich mich jetzt doch viel zu viel um den Command-Bereich, obwohl er ein übles Biest voller Funktionen ist, von denen so einige redundant und schlechter als ihre Pendants an anderer Stelle sind? Weiß es selber nicht.


    Die DestinyScript-Hilfeseiten habe ich nach diesem vielen Gemache nun aber auch endlich angefangen, Die Grundlage zur Verwendung sowie Kommentare in Code einfügen und die Erklärung der Datentypen sind bislang geschrieben. Ausstehend: Zahlenformate, Strings, Operatoren, Verzweigungen, Schleifen, Sprungbefehle, Konstanten, Fehler, MessageLink, Debugger.


    ~炬燵あ

  • Die meisten Seiten der Hilfe sind "fertig", andere angefangen/lückenhaft und voller unerledigter Fleißdrecksarbeit, ich hab's auch endlich hinbekommen, den Eigenschaften von Objekten eindeutig beizufügen, ob sie schreibgeschützt sind oder nicht, musste dafür viele natürlich nochmal selbst im Code durchgehen und habe nebenher noch ein paar Dinge gefixt.


    So langsam könnten wir uns also einem Fertigungsstadium nähern, in dem ich andere (vorzugsweise Programmier-Erfahrene und Makerkundige mit ausreichend Willen und Geduld, sich eine Scriptsprache anzueignen) an die aktuelle DLL lassen kann, um mit all den Sachen zu experimentieren, die DestinyScript ihnen so vor die Nase wirft, und zu schauen, wie gut die Hilfe ihren Zweck erfüllt. Und wann das passieren könnte, steht weiterhin in den Sternen.


    Happy Halloween, so für die verbleibenden PFÜMPF Minuten.


    ~炬燵あ

  • Eine Sache, die ich hier noch unbedingt teilen muss, ist, dass der Eventbefehls-Einschleuser für ShowPicture jetzt offenbar genau auf der absoluten Kotzgrenze von dem liegt, was der gute alte MASM32 bereit ist zu kompilieren. Einige Parameter, die durch Maniac Patch hinzugekommen sind, musste ich kürzen oder vereinfachen. Entsprechend ekelhaft sieht es an der entsprechenden Stelle auch in der aktuellen Version der Hilfe aus. Ich hab das Feature übrigens bisher nichtmal getestet, aber nur schonmal so am Rande:




    Die Reihenfolge der Parameter ist nicht verhandelbar, die Anweisung muss auch in anderen Versionen weiterhin funktionieren.


    ~炬燵あ

  • "Command.ShowPicture()" scheint, wie ich kurz darauf festgestellt habe, in RPG2003-1.12MP seine Funktion ordentlich zu erfüllen, sieht jedenfalls jetzt noch danach aus, Tests mit [Move] und [Delete] sind noch ausstehend.


    Ein anderer Anschein hat mir dafür bis vorhin große Probleme bereitet, denn der MessageLink zum Ausführen von Code mitten in der Dialogtextbox hat, was ich ewig lange nicht gemerkt habe, alles an Text, abgesehen von aufgelösten Ergebniswerten in den jeweiligen Zeilen bei RPG2003-1.12MP plattradiert (ist halt blöd, wenn man nur isolierte Tests wie "\d[1]" macht, aber kein "Schinken \d[1] Käse"). Das Problem ist jetzt aber, ein paar hirnschmelzende Analysen und Experimente mit viel zu vielen offenen Programmfenstern später, aus der Welt.


    Abseits davon schleichen sich, daher straucheln ausstehende Parts der Hilfe leider gerade extrem, immer noch neue Mini-Ergänzungen in den Fundus von DestinyScript ein, die viel zu viel Extra-Arbeit mit sich bringen, ich aber einfach nicht lassen kann. Die letzten zwei Tage betraf das den Lesezugriff auf einige Eigenschaften des RPG_RT-internen MIDI-Players (also wirklich nur für genau dieses BGM-Format) ab RPG2000-1.50 und RPG2003-1.05. Aus diesem gibt es jetzt die eingestellten Werte für Fade/Lautstärke/Pitch/Panning, den FadeIn-/FadeOut-Status, die Taktposition und ein paar entschlüsselte Eckdaten der laufenden Datei (Anzahl enthaltener Tracks, Abspieldauerangabe in Ticks, TimeDivision-Wert). Außerdem gibt es zwei Datensätze, die anscheinend mit den 16 MIDI-Kanälen zu tun haben, ich aber nicht ganz sicher zuordnen kann (die Defaults für die Werte darin sind bei jedem Kanal [100 (??Lautstärke??)] und [64]).


    ~炬燵あ

  • Der eine MIDI-Kanäle-Datensatz hat sich mittlerweile wirklich als die jeweilige Lautstärke entpuppt, mit dem anderen von den beiden kann ich noch immer nichts anfangen. Wenn jemand Ahnung davon hat, bzw etwas weiß, das zum Dateiformat und zu einem Default-Wert von 64 passen würde, nur zu, ich bin neugierig. Wenn ich an den Werten herumdrehe, kann ich leider keinen Unterschied im Wiedergegebenen feststellen.


    In der Zwischenzeit ist auch der MP3-Part (auch wenn ich dringlichst abrate, dieses Format jemals zu verwenden) vom Audiosystem halbwegs analysiert (Bei WAV sieht's währenddessen eher aus wie Krätze und die Betrachtung vom OGG-System, das Maniac Patch mitbringt, steht noch aus) und mit Zugriffsmöglichkeiten versehen.


    Und hier ein paar neue Eventbefehls-Ersatzfunktionen, die beliebig in Scriptblöcke eingebaut werden können und teils mehr als ihre Vorlagen können:

    • BGM und SE aus einer Datei (Spiel/RTP), einem Datenbankeintrag oder dessen Standardeinstellung, falls seit Spielstart geändert, abspielen
    • BGM-FadeOut mit Millisekunden-Angabe, BGM Stoppen, Alle SEs stoppen
    • BGM-Eckdaten ins Event- (auf Befehl gemerkte BGM), Kampf- (gemerkte Map-BGM) oder Fahrzeug-Backup (gemerkte Lauf-BGM) verfrachten
    • BGM aus einem der drei Backups abspielen, jetzt auch mit FadeIn-Dauer, die auch permanent überschrieben werden kann

    ~炬燵あ

  • Hm, ich habe keine Ahnung, da ich MIDI nicht sonderlich verstehe, darum hier nur ein paar Vermutungen:


    Bist du dir sicher, dass es keinen hörbaren Unterschied gibt? Am offensichtlichsten wäre nämlich die Raumausrichtung des Klang (wohl CC10), die ist bei dem Wert 64 nämlich genau in der Mitte, heißt der Klang kommt aus beiden Lautsprechern mit gleicher Stärke. Allerdings sollte man das beim Verstellen des Werts mit Stereo-Kopfhörern oder Lautsprechern schnell merken.


    Oder es handelt sich um einen PitchBend-Value (MSB), denn 64 (zusammen mit LSB-Wert 0) wäre die ungebeugte Mittelstellung, was dem Standardklang entsprechen könnte (Referenz). Da du beim Verstellen keine Tonverschiebung hörst, kann man das wohl auch ausschließen.


    Ansonsten ist es möglich, dass es sich um einen der Switches handelt, der ab dem Wert 64 auf ON-gesetzt wird. Siehe hier im Link von den Message Codes 64 bis 69. Sustain und Sostenuto könnte man ausschließen, weil man das Liegenbleiben der Noten in einem normalen Lied sofort hören würde. Es könnte also einer der anderen wie Soft-Pedal sein, allerdings weiß ich wirklich nicht wieso diese Einstellung notwendig sein sollte. Vielleicht hat es irgendwas mit der Eigenart des Microsoft-Synthesizers zu tun.

    Aber abseits davon: Arbeitest du eigentlich mit Hexcode pur im Hexeditor oder nutzt du irgendwas wie die 010-Editor-Templates oder Frameworks wie Kaitai Struct, um dir die Arbeit zu erleichtern? Oder stell ich mir deine Arbeitsweise falsch vor?


    Tolle Arbeit bisher - ich wünsch dir noch viel Glück und Durchhaltevermögen beim Basteln :)

  • Vielen vielen Dank für die vielen Ansätze, es ist tatsächlich Panning (Raumausrichtung), das war mir irgendwie vorher nicht aufgefallen oder ich hab's gar nicht erst richtig gemacht. Wenn ich die auf die Extreme hin- und herschalte (ich nehm zumindest mal an, dass 0~127 stimmt), fällt es direkt auf.




    Arbeitsweise ist schwer zu beschreiben, der Hex-Editor hat recht wenig Anteil momentan, wenn ich nicht irgendwas per Hack fixen muss. Die meiste Zeit verbring ich im Disassembler (zum Herumwühlen und Adressen-/Funktionen-Benennung in RPG_RT.exe) und im einfachen Notepad (letzteres für Assembler-Code für Destiny.dll, die Hilfedokumente und allerlei Datensammel-Listen), gefolgt vom RPG Maker, um obskure Tests in ihm zusammenzukleben, über temporär eingebaute Funktionen nehm ich dann auch mal hin und wieder direkt mit DestinyScript bei laufendem Spiel ein paar Sachen im Speicher auseinander.


    Die neuste kleine Bastelei, von der ich berichten kann, hat erstmal nichts mehr mit Audio zu tun, sondern ist eine DestinyScript-Variante des Befehls zum Scrollen des sichtbaren Map-Ausschnitts um N Felder in eine beliebige Richtung mit den Standard-Tempoangaben. Die Koordinaten konnten zwar bereits geändert werden (und wenn man abseits von ganzen Feldern und der Tempowahl [1~6] arbeiten will, muss man das auch weiterhin direktbestimmend tun), ich wollte trotzdem eine Möglichkeit ohne die Nachteile von [Command] bieten, das klassische Feature zu nutzen. Das Zurückzentrieren auf die Spielerposition ist natürlich auch dabei, nur die WartenBisFertig-Einstellung nicht.


    ~炬燵あ

  • Der DestinyPatcher für den Rm2k3? Träume ich oder ist das real?


    Entweder gibt es hier nicht viele Rm2k3-Nutzer oder sie realisieren nicht, was der DestinyPatch für sie bedeuten würde. Bisher war DestinyScript für mich der Grund, den Rm2k anstelle des Rm2k3 zu verwenden. Viele lästige Dinge werden dadurch einfacher und viele unmögliche Dinge überhaupt erst möglich.


    Mich hat Mitte dieses Jahres auch mal wieder die Destiny-Euphorie gepackt und ich habe das eine oder andere Script auf dessen Basis veröffentlicht. Die häufigste Rückmeldung, die ich darauf in mehreren Foren bekam, lautete: coole Sache, aber gibt's das auch für den Rm2k3?


    Meine Antwort war dann immer: leider nein, aber vielleicht kann jemand meine Scripts mit DynRPG nachbauen (womit ich mich nicht auskenne). Jetzt besteht also die Möglichkeit, die Scripts zu portieren? Sind die alten und neuen DestinyScripts miteinander kompatibel oder müsste ich was an der Syntax ändern, um meine Scripts für den Rm2k3 flott zu machen?


    Und noch eine Frage: wird es den Befehl Command.ShowMessage() geben? Der hat mir bei DestinyScript immer gefehlt. Wäre ziemlich cool, wenn er dabei wäre.


    Auf jeden Fall ein klasse Projekt. Wenn du Betatester brauchst, sag Bescheid. Wenn sich die Syntax mit der alten Version deckt, kann ich auch schon ohne Dokumentation mit dem Testen beginnen.

  • Holerö!~


    Ob das altbekannte Patcherprogramm bestehen bleibt, steht noch aus, da muss ich nochmal ein paar Sachen genauer unter die Lupe nehmen, wenn ich die Nerven dafür habe. Die verlinkten Scripte sind mir tatsächlich wohlbekannt. Auch wenn ich sie mir nicht allzuviel angeschaut habe, fand ich's einfach schon immer toll, wenn jemand was mit DestinyScript bastelt und zeigt.


    Die Syntax brauchst du nicht anpassen, da sich an ihrem Aufbau nix ändern wird (ich wollte ternäre Operatoren verbauen ({Expr} ? {IsTrue} : {IsFalse}), das ging aber mächtig schief). Und solange du nichts verwendest, das in RPG2003 nicht existiert (wenn Des2.018 überhaupt RPG2000-exklusiven Krempel hatte), sollte da hoffentlich kein Problem aufkommen. In Sachen Funktionstüchtigkeit tu ich mich derzeit nur leider noch schwer damit, Pictures einblenden zu lassen, wenn einfach nur ein AuroraSheet generiert wird, statt eine Quelldatei zu laden.


    "Command.ShowMessage()" wurde damals, wie einige andere auch, ausgelassen, weil der Befehl auf die Codeliste zugreift, um weitere Textzeilen ausfindig zu machen, die technisch auch eigenständige Befehlszeilen sind. Selbst wenn ich ihn verbaue und die RPG_RT davon überraschenderweise nicht explodiert, könnte also auch nur eine Zeile angegeben werden. Ist es das dann wert? Ich hab noch meine Zweifel daran.


    ~炬燵あ

  • Dachte mir schon, dass es einen guten Grund gegeben haben muss, warum Bananen-Joe den Befehl weggelassen hat. Ist zwar schade, aber man kann damit leben. Letztendlich lässt sich ja alles über MessageLink erledigen.


    Weitaus wichtiger ist der Befehl Command.GoToLabel(), weil man damit DestinyScripts und Eventbefehle ineinander verzahnen kann. Den habe ich exzessiv in meinen Scripts verwendet. Solange der Befehl dabei ist, ist alles gut.


    Noch eine Frage, von der nicht allzu viel abhängt: wäre es möglich, den Schreibschutz von Event[].Name aufzuheben? Dadurch könnte man in jedem Event Informationen abspeichern. Das wollte ich ursprünglich für mein SelfVariables-Script nutzen, bis mir der Schreibschutz auffiel und ich umdenken musste. Alternativ wäre auch eine Möglichkeit cool, ein zusätzliches Feld wie Event[].Notes einzuführen, wo man einen beliebigen String zu jedem Event abspeichern kann. Wäre sehr cool, aber auch nicht allzu dramatisch, wenn es nicht geht.


    Edit: Wenn ich schon dabei bin, meine Wunschträume zu äußern… wie wäre es mit einem Regexp-Objekt für reguläre Ausdrücke? Ich musste mich beim Analysieren von Strings mit den normalen String-Funktionen bisher immer herumquälen. Es wäre traumhaft, wenn die Mustererkennung von Text vereinfacht würde.


    Edit 2: Die aller, aller, allergrößte Verbesserung gegenüber dem alten DestinyScript wäre es, wenn als Variablen-Indizes nicht nur Zahlen zugelassen wären (d[1], d[2], d[3], …), sondern auch Strings (d["HP"], d["MP"], d["Name"]). Dadurch würde der Code lesbarer - nein, was sag ich: lesbar - werden. Ich kann mir vorstellen, dass das mit großem Aufwand verbunden wäre, aber der würde sich ungemein lohnen. Wenn ich mir ein einziges Feature wünschen könnte, wäre es dieses.


    Ich habe meine DestinyScripts bisher immer intensiv kommentiert und Tabellen darüber geführt, welche Variablen-IDs wofür verwendet werden. Dadurch haben sich die Höllenqualen zwar lindern, aber keinesfalls vermeiden lassen. Wer meint, ich übertreibe, darf gerne mal einen Blick auf folgendes Codebeispiel aus meinem MagicMessageSystem werfen. Darin kommen nicht nur haufenweise namenloser Variablen vor, sondern auch der klägliche Versuch, Textverarbeitung ohne reguläre Ausdrücke durchzuführen.

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von Fauchi ()

  • Ye, wie wahnsinnig nützlich der Labelsprung-Befehl in einem Scriptblock ist, hab ich unlängst auch wieder auf's Neue bemerkt.


    Schreibschutz aufheben bei Eigenschaften sollte keine große Sache sein, zumindest meistens. Es sei aber natürlich dazu gesagt, dass geänderte Eventnamen und andere fest vordefinierte Daten zurückgesetzt werden, wenn du später auf die gleiche Map zurückkehrst. Und bezüglich Notes: Die Definition von Events um neue Inhalte zu erweitern stell ich mir je nach Umsetzungsmethode schwer vor, letztendlich wäre hier jedenfalls auch bei Implementierung die gleiche Problematik präsent, wenn ich sie in der RPG_RT vornehme. Destiny bräuchte, damit sich Extra-Stuff Map-übergreifend gemerkt werden kann, ein Imitat der gesamten MapTree-Grundstruktur. Grundsätzlich erstmal vermerkt, hört sich nur erstmal nach viel zuviel Arbeit an.


    Regexp wäre definitiv cool, keine Frage. Die Sache ist nur... finde erstmal eine bereits existente Variante, die man möglichst einfach mit MASM32 in jedes Programm, das man kompilieren will, mit reinstopfen kann und darf, dann reden wir weiter. Zum Selberbauen ist der Vorgang viel zu komplex. °~°'


    ~炬燵あ