Beiträge von Tamschi

Ja, das wird durch die Funktion Game_Party.prototype.maxBattleMembers geregelt.

Wenn du also (in MV oder MZ)

Game_Party.prototype.maxBattleMembers = function() {
    return 6;
};

Sprite_Actor.prototype.setActorHome = function(index) {
    this.setHome(600 + index * 32 * 4/6, 280 + index * 48 * 4/6);
};

schreibst, dann hast du bis zu 6 Kämpfer wo sonst 4 stehen.

Wobei du rechts index auch durch ((index * 2) % 7) ersetzen kannst. Dann stehen die in bis zu zwei Reihen, was sie vielleicht etwas besser sichtbar macht.

Zitat von I.Z.

Tamschi ich finds richtig nice, wie durchdacht deine Plugins sind und auch wie kreativ sie sind, fetten Respekt. Vllt. sollte ich doch noch coden lernen, einfach um sie mal auszuprobieren

Mein Geheimnis ist, dass ich (oft-nicht-so-)heimlich die Bugtracker, Devlogs und Spielerfeedback der Spiele anderer lese

Da kommt dann einiges zusammen, wobei solche Sachen wie die "Flipbooks"-Serie und reines dev-tooling eher auf meinem eigenen Mist gewachsen sind.

Fast alle meiner Plugins lassen sich allerdings auch ohne JavaScript vollständig nutzen (und sind wahrscheinlich deutlich einfacher zu bedienen als die meisten von Yanfly).

Die JS-API ist eher dafür da, dass, falls mal jemand Erweiterungen oder Änderungen and den Funktionen meiner Plugins braucht, die sauber in einem anderen Plugin implementiert werden können und dass bei Updates dann nichts kaputt geht. Battler Flipbook Sound Effect Events ist z.B. komplett über solche Schnittstellen realisiert.

Falls du dich für die Plugin-Erstellung interessierst, kann ich Eloquent JavaScript, 3rd edition (2018) wärmstens empfehlen. Das Buch ist ziemlich genau auf dem gleichen Stand, der auch von der MV-Runtime standardmäßig unterstützt wird. JavaScript | MDN ist als Referenz extrem nützlich, listet aber auch Funktionen auf, die zu neu sind. (MV entspricht normalerweise Chrome 65, aber falls du die Plugins nur für eigene Spiele nutzt, ist es deutlich besser/einfacher einfach NW.js zu aktualisieren.)

Edit: Ach ja, und Plugin Tutorial for RPG Maker MZ (Google Docs) ist sehr praktisch für alles, was wirklich RPG-Maker-spezifisch ist. Ich benutze das aber eigentlich nur für Parameter und andere Metadaten. Wenn du schauen willst, wie irgendwas in der Engine funktioniert, dann öffne deinen Projektordner mit z.B. VS Code und spring' da mit der Volltextsuche (Strg+Shift+F) zur Definition. function Game_Map und function Scene_Map bringen dich z.B. zur Implementierung der Karten (respektive Logik und Grafisches), und // Show Text oder // Conditional Branch führen zu den entsprechenden Befehlen im Game_Interpreter, der Ereignislaufzeit. Die Kommentare setzte ich auch genau so in meinen Plugins, falls ich mich in existierende Befehle einklinke, damit ich die hooks dann direkt mit-finde.

Die RPG Maker-Engine selbst und die meisten Plugins sind allerdings in einem älteren Stil geschrieben. Ich bin schreibfaul und lass mir gern vom Editor etwas helfen, daher benutze ich eher etwas modernere (aber zu 100% kompatible) Klassensyntax und ein paar eigene Idiome, wie diese Art, mich in Engine-Funktionen einzuklinken:

'use strict';

// Dateiname ohne Endung. Ist manchmal praktisch, wenn das zentral geändert werden kann.
const MY_PLUGIN = 'My_Plugin';

const api = window[MY_PLUGIN] = {
  // z.B.
  oldGame_MapUpdate: Game_Map.prototype.update,
  ...(Game_Map.prototype.update = function () { return api.newGame_MapUpdate.apply(this, arguments); }, {}), // "trampoline"-Funktion
  newGame_MapUpdate() {
    // Mein Code hier.
    return api.oldGame_MapUpdate.apply(this, arguments);
  },
};

Für mich ist das praktisch, weil damit alles an einer Stelle liegt. Außerdem können andere Plugins damit sehr zielgerichtet meinen hook ändern oder auch ganz abschalten (My_Plugin.newGame_MapUpdate = MyPlugin.oldGame_MapUpdate;) falls nötig. Falls die Methode etwas spezifischer ist als .update() lass' ich aber meistens den Klassennamen weg.

Ich bin immer noch am Rande meiner Belastungsgrenze was angehäufte Arbeit angeht, aber ich hab' mal wieder ein Plugin fertig: Live Menu and Pause MV + MZ

Meint man wahrscheinlich von der Beschreibung her nicht, aber es war ziemlich kompliziert, das so sauber hinzubekommen. Daher auch der ein bisschen höhere Preis.

Naja, jedenfalls ist das gut für Spiele, die entweder ein bisschen nervenaufreibend oder tiefentspannend sein sollen.

Oder letzteres und dann ersteres, aber Schockmomente im Menü einzubauen ist schon ziemlich fies

Mit dem Menu Editor aus der Super Tools Engine könnt ihr im MV die Menüs etwas ausdünnen, was zusammen mit diesem Plugin nochmal netter aussieht.

(Gibt es schon einen Menü-Editor für MZ? Ich habe ein bisschen gesucht, aber nichts gefunden.)

Die Pause-Funktion funktioniert auch in Kämpfen und bei Videos einwandfrei, das wäre also was bei Echtzeitkämpfen oder falls ihr längere Filmsequenzen habt.

Kleiner Tipp am Rande: Falls ihr ein Tileset-Setup teilen (oder beim selbst veröffentlichten Tileset mitliefern) möchtet, könnt ihr alternativ zu Beispielprojekten auch dieses Tool verwenden: Clipboard Helper for RPG Maker MV (Die kostenlose Version reicht dafür völlig. Ich hab' die "Bearbeitungsfunktion" nur hinter 'ner Bezahlschranke, weil ich dafür nicht umsonst Support machen möchte.)

Ich bin allerdings noch nicht dazu gekommen, das Programm auch mit MZ kompatibel zu machen.

Zitat von Baxeda

Die Vorteile von Party Command Hooks gegenüber Events habe ich in ihrer Funktionsweise aber nicht ganz verstanden. Könntest du mir das vielleicht noch mal in Kurzform erklären?

Es ist rein zur Arbeitseinsparung: Wenn du ich sag' mal 12 verschiedene Truhen mit Items in dein Spiel stellst, dann musst du ja jeweils relativ einzeln:

"Einen Fußball gefunden.", "Ein Schwert gefunden.", "Einen Schild gefunden.", "3 Holzschilde gefunden", "5 Gummihühner gefunden.", usw... Text-Popups schreiben, und dann auch jedes mal anpassen, wenn du die Anzahl oder den Namen von dem Kram änderst. Oder du nutzt ein gemeinsames Ereignis für die Truhen, aber dann ist es schwieriger, die Inhalte individuell anzupassen.

Mit Party Command Hooks kanns du einfach einen von diesen Befehlen in der Truhe direkt verwenden: pasted-from-clipboard.png (die ganzen Parameter und noch ein paar Infos zum Effekt werden dabei vom Plugin in den konfigurierten Schaltern, Variablen und Namen gespeichert) und dann rufst du ein gemeinsames Ereignis auf, das sich wiederverwendbar um die Nachricht an den Spieler bzw. die Reaktion auf ein überfülltes Inventar kümmert und den Self-Switch der Truhe setzt, falls die entleert wurde.

Du musst dann also nur noch ein einziges Mal eine schicke Textbox mit Icons/Farben/Platzhaltern erstellen und kriegst da immer die aktuellsten Infos zum jeweils letzten dieser Befehle.

Zitat von Tamschi

Davon abgesehen baue ich gerade an einem Plugin, das die Infos von den Inventar- und Gruppenänderungsbefehlen abgreift und Ereignissen zur Verfügung stellt:

Ich war tüchtig erkältet und habe das mit dem Vorstellungspost daher noch nicht hinbekommen, aber das ist jetzt fertig: Party Command Hooks

Außerdem habe ich relativ spontan das hier gebastelt, was vielleicht ganz nett ist: Battle Command Descriptions

Müsste auch mit den meisten geänderten Kampfbildschirmen ganz gut funktionieren, jedenfalls geht's schon mal mit Yanfly und VisuStella.

Das Ganze war nicht wirklich Aufwand da klein (Ich habe das Plugin an einem Tag geschrieben weil ich's eh brauche und Testen/Bugfixes/Marketing alles heute gestern (ups, doch schon spät(er)) gemacht.), daher hab' ich's mal versuchsweise zeitlich begrenzt sehr günstig gemacht und haue das jetzt auf allen Kanälen raus die ich kenne. Mal sehen, welche Herangehensweise besser läuft (wobei mein Shop da definitiv nicht statistisch signifikant ist).

Zitat von Lyon

Tamschi

Welche (Social Media) Kanäle strebst du an / nutzt du jetzt?

Hm, ist vielleicht nicht gut zu sehen, weil ich Emojis für die Links benutzt habe.

Ich habe mir erstmal einen mastodon.gamedev.place- und einen Bluesky-Account gemacht.

Twitter habe ich eigentlich keine Lust mehr zu, da wird man ja eh nicht gesehen wenn man nur selten postet.

Reddit habe ich auch und nutze das sporadisch (auch um da mal jemandem weiterzuhelfen), aber das meine Plugins Geld kosten wird da teilweise recht negativ gesehen.

Ich habe mir endlich mal social media accounts für Projektupdates erstellt: 🐘, 🦋

Eigentlich bin ich aber ziemlicher Social-Media-Muffel, also mal sehen, ob das was wird

Davon abgesehen baue ich gerade an einem Plugin, das die Infos von den Inventar- und Gruppenänderungsbefehlen abgreift und Ereignissen zur Verfügung stellt:

Ihr könnt damit dann ein oder zwei Mal eine schicke "Gold gefunden!"- und/oder "Gegenstand gefunden!"-Nachricht implementieren und die dann für die meisten Truhen und so einfach wiederverwenden. Ihr könnt auch eigene Notiztags definieren, über die ihr weitere Schalter, Variablen oder Textbausteine steuern könnt.

Einen Singular zum Plural zu machen ist im Deutschen leider ein bisschen zu kompliziert für die Automatikfunktion, aber ihr könnt das auch ziemlich effizient einzeln über Notiztags festlegen, falls nötig.

Zitat von IanZarewitsch

Ich hab mal ne allgemeine Frage:

Viele von euch besitzen ja praktisch jeden jemals erschienenen Maker. Warum? Wegen der Lizenzen? Einfach weil ihr mit ihnen gewachsen seid, oder weil es neue Features gab, die nicht gehalten haben, was sie versprechen, das aber erst revealed wurde nachdem ihr die gekauft habt?

Wir bleiben auf jeden Fall bei MV und ich zumindest plane nicht mir noch einen weiteren Maker zuzulegen.

Ich verkaufe Plugins, wenn ich sowohl MV als MZ habe, dann kann ich also leicht meinen potentiellen Kundenkreis erweitern

(Fast alle Plugins brauchen keine oder nur minimale Änderungen zwischen diesen Versionen, aber ich muss halt beides haben, um es zu testen.)

Theoretisch könnte ich einige davon wahrscheinlich sogar zu den Ruby-Versionen portieren (die Engine ist nicht groß anders strukturiert), aber die habe ich mir erstmal nur aus Interesse geholt, und weil sie wirklich sehr günstig im Angebot waren und ich wissen wollte, ob es da andere eingebaute Features gibt. Ich kann allerdings auch bisher kein Ruby.

Zitat von Lytharias

Jetzt müsste ich eigentlich, nachdem die Ergebnisfee alle Ergebnisse ausgespuckt hat, einen Plugin Befehl zum "Exportieren"

auswählen können... und daran hapert es.

Jo, da steht zwar "@target MZ" drüber, aber das Teil hat dir das Plugin für RPG Maker MV geschrieben

Der MV-Pluginbefehl dort ist ExportVariables.

Für MZ bräuchtest du eine Befehlsdeklaration und müsstest den Befehl anders registrieren. Ich würde dir da diese Anleitung empfehlen:

- RPG Maker MZ Plugin Tutorial > 4.0 Making a Plugin > 4.2 Deciphering an Official Plugin > Defining Plugin Commands,

- RPG Maker MZ Plugin Tutorial > 4.0 Making a Plugin > 4.3 Explanation about Annotations > Plugin Commands

Java ist komplett anders. Das hier ist JavaScript (was korrekt ist).

Ich hatte sowas schon etwas länger in Arbeit, aber letzte Woche ist der Groschen gefallen und gestern habe ich es veröffentlicht

Diesmal leider ohne Video, da ich hier keine entsprechenden Ressourcen für eine Demo zur Hand habe.

Dynamic Pictures

Flackerfreie "Bild zeigen"-Bilder, die auch während "Bild bewegen" ausgetauscht werden können. Zusätzlich auch regelbasierte Variationen, wodurch z.B. eure Charaktere in Szenen die richtige Ausrüstung tragen können oder ihr Kämpfe etwas aufpeppen könnt.

Funktionsweise

Im Endeffekt gibt euch dieses Plugin die Möglichkeit, die Bilddatei für angezeigte Bilder auszuwechseln, ohne dass irgendwas anderes an dem Bild abgeändert wird. Die neue Version wird dann im Hintergrund geladen und eingewechselt, sobald sie bereit ist. Das System kommt auch damit klar, wenn ihr die Bilder in schneller Folge auswechselt, eventuell wird dann aber mal ein Bild übersprungen, da das System nicht direkt auf flüssige Animationen ausgelegt ist.

Die Ressourcen werden dabei wie mit "Bild zeigen" auch im Voraus im Hintergrund geladen, das Bild "flackert" allerdings durch die Pufferfunktion nicht, falls sie vorher aus dem Speicher fliegen.
(Mit Community_Basic könnt ihr für besseres Timing im MV den cacheLimit-Wert auf ca. 300 erhöhen. Standardmäßig liegt der bei 10, was den gesamten unkomprimierten Texturcache auf nur 40MB beschränkt. MZ hat dieses Problem nicht so stark.)

Darauf aufbauend habe ich auch ein regelbasiertes Ebenensystem implementiert. Ihr könnt damit basierend auf diversen Spielzuständen Bildebenen ein- und ausblenden (in beliebiger Reihenfolge), um zur Laufzeit verschiedenste Variationen von Szenen anzuzeigen. Die Regeln bleiben auch aktiv, während das Bild schon angezeigt wird, wodurch ihr dann Änderungen 'live' vornehmen könnt. (Das ist fast komplett per Maus konfigurierbar, ihr müsst also nicht erst groß die Funktionsweise auswendig lernen. Ich würde allerdings empfehlen, den Hilfetext bzw. die itch.io-Seite einmal komplett durchzulesen, da es einige nicht ganz so offensichtliche Funktionen gibt, die oft viel Zeit sparen können, wie z.B. Regeln die spätere Regeln beeinflussen.)

Benutzung

Das ganze sollte relativ selbsterklärend sein. Regeln (z.B. nach Zustand, Ausrüstung, Schaltern) könnt ihr in den Plugineinstellungen per Maus definieren, speziellere Regeln wie z.B. nach Kampfphase als boolean-Ausdrücke.

Bilder tauscht ihr in Ereignissen mit Hilfe der Pluginbefehle aus, und diese können auch 'tags' für jeweils ein aktuell angezeigtes Bild dauerhaft setzen, wodurch ihr eventuell weniger Schalter verwenden könnt. Die Tags werden zurückgesetzt, wenn das Bild gelöscht oder mit dem standardmäßigen RM-Befehl ersetzt wird. Beachtet allerdings, dass beim Austauschen die Anzeigeeinstellungen und die Position nicht geändert werden können und dass es eine kleine Verzögerung geben könnte, sodass es nicht immer simultan mit "Bild bewegen" passiert. Dieses Plugin eignet sich also vor allem für Bildschirmfüllende Cutscenes und den Wechsel zwischen Bildateien, die die gleiche Ansicht zeigen.

Vorgefertigte Bildressourcen mit optionalen transparenten Ebenen gibt es leider nicht so wirklich oft. Im RM-Bereich sind das hauptsächlich Teile für den Charaktergenerator, also nicht solche, die als "Bild zeigen"-Bilder Verwendung finden würden.

Ihr könnt aber auch vorgefertigte zusammengesetzte Variationen verwenden, die dann über die Regeln ausgetauscht werden. Das ist in etwa genau so einfach, da auch das ursprünglich gezeigt Bild eine Ebene ist, die ausgeblendet werden kann.

Stabile JavaScript-API und Entwicklerfunktionen

Sind wie üblich eingebaut. Ihr könnt mit euren eigenen Plugins zusätzliche Regeln bauen, falls die eingebauten JavaScript-Eingabebereiche nicht ausreichen. Außerdem sind die Regeln automatisch auch für andere Nutzungen von Game_Picture + Sprite_Picture verfügbar, nicht nur für die "Bild zeigen"-Bilder.

Wo gibt's das und was kostet es?

Das Plugin gibt es hier auf itch.io, aktuell für $15.

Die Shopseite enthält wie üblich die gesamte Bedienungsanleitung.

Zitat von Lyon

Bilder in den Cache Vorladen

[...]

Das macht der RM seit mindestens MV auch automatisch für vorhandene "Bild zeigen"-Befehle wenn das Ereignis startet.

Im MV ist dieser Cache allerdings standardmäßig lächerlich klein (10MPix = 40MB unkomprimierter Texturspeicher), daher sollte man den im Community_Basic-Plugin etwas erhöhen:

300 oder 500 wären gute Werte. Damit sollte dann das 'Flackern' in den meisten Fällen ausbleiben.

Falls nicht alles gleichzeitig in den Grafikspeicher passt, dann wird dadurch auch nicht direkt das Spiel langsamer, sondern Runtime/Grafiktreiber verwalten dann den Texturspeicher, was effizienter ist, als die Bilder neu von der Platte zu laden.

Im MZ ist der Cache unbegrenzt, wird dafür aber bei jedem Szenenwechsel (also Karte-zu-Karte/Kampfbeginn und -ende, Menübildschirme) komplett weggeworfen, weshalb das da manchmal ein bisschen länger lädt und eventuell in anderen Situationen flackert.

(Ich habe zufälligerweise gestern auch ein relevantes Plugin veröffentlicht. Mache ich gleich einen Thread dazu, aber in den meisten Fällen ist das für einfache Szenen unnötig wenn der Cache vergößert wird.)

Ich habe die letzten drei Wochen damit verbracht, einen abstrus langen technischen Text zu schreiben (gut 17.000 Wörter )

Bin mir allerdings noch nicht sicher, was ich jetzt mit den zwei Wochen bis Weihnachten mache. Ich glaub' ich brauche erstmal ne Pause von Projektkram.

Im Allgemeinen würde ich den Stil von Chat-GPT im Englischen als 'aktiv langweilig' bezeichnen, und das trifft auch auf Übersetzungen zu, selbst dann wenn sie "richtig" sind.

Ich stimme zu, dass man das als Ausgangspunkt verwenden kann, aber ich glaube nicht, dass das wirklich so viel Arbeit einspart, weil man für ein brauchbares Ergebnis auch Stilkorrekturen vornehmen muss.

Wenn ich LLM-Texte lese dann schaltet sich bei mir nach einem halben Absatz oder so das Hirn ab, weil die so öde sind. Auf Mastodon hat das gestern jemand mit nem Apfel verglichen, der sich beim Reinbeißen als Styropor entpuppt. Oberflächlich plausibel, bei näherer Auseinandersetzung komplett Murks.

Mir war nicht klar, dass wir hier ein dunkles Thema haben
(Ich kann den weißen Text kaum lesen, ohne ihn erst zu markieren.)

Das Projekt sieht auf den ersten Blick cool aus (und hört sich gut an!), ich habe aber wie immer keine Zeit für direkte Mitarbeit.

Ich denke aber, dass da die Chancen jemanden zu finden relativ gut sein werden, nachdem du deine Projektplanung besser vorgestellt hast.

Zitat von Kojote

Sag mal würde so was auch mit Bilder die man anzeigt funktionieren? Ich lasse da oft welche im Spiel anzeigen und muss jedes mal recht umständlich die X-Y-Koordinaten der Maus abfragen und alles genau ausmessen.

Ja, ist machbar. Du müsstest dann nach "Bild zeigen..." noch einen Plug-in-Befehl mit der Bildnummer und einem Gew. Ereignis als gleichartiger Vorlage haben.

Im MZ würde ich das einfach per Auswahl machen, im MV per Id oder Ereignisnamen als Text. Sonst wären die Funktionen identisch.

Schau aber erstmal, ob dir eins der existierenden Plugins von anderen ausreicht. Mimosa Mouse Cursor kann die ButtonPictures aus MZ z.B. per Alphatest auf das sichtbare Bild zurechtstutzen und das kostet nur $5. Falls ich das mit den Bildern hier einbaue, was ich aktuell nicht plane, dann würde ich den Preis leicht anheben.

Zitat von Kojote

EDIT: Kanns leider nicht laden. Wenn ich auf Download klicke kommt: "invalid game"

Okay, dann ist die Seitenvorschau wirklich nur eine Seitenvorschau. Ups.

Ich hänge die Version 1.0.0 hier an: mv-in-mz-tools-mv-commands-for-mz-editor-mv+mz.zip

Zitat von Kojote

Jetzt bin ich aber mal gespannt, was du gezaubert hast.

So, ist online.

Im Editor sieht es so aus, als würdest du einen MZ-Pluginbefehl hinzufügen, aber beim Laden wird der so umgeschrieben, dass in der Befehlsliste stattdessen nur der MV-Befehl steht. Daher funktioniert das auch mit Befehle-als-Metadaten-Plugins wie OnTouch.

Wenn du den Parameter im Plugin auf ON/true setzt, dann updated es beim Spieltest deine Projektdaten (wie bei Pretty JSON oder OnTouch) und du hast nach dem Neuladen den echten kompakten MV-Befehl im Code stehen. Du kannst das Plugin dann auch beim Veröffentlichen deaktivieren oder entfernen.

Kojote So, exklusive Vorabveröffentlichung: (itch.io) MV in MZ Tools (Link funktioniert irgendwann, wenn ich die Seite eingerichtet habe. Bis dahin Version 1.0.0 weiter unten im Thread.)

Die Datei sollte in spätestens 30 Minuten da erscheinen, dann anders als die Seite auch mit Help-Text.

(Ich muss noch kurz in Windows booten, um das zu testen, dann schalte ich es frei. Der MZ-Editor läuft unter Linux ja nicht mehr )

Zitat von Kojote

FlipelyFlip Kann man das Script von Shaz auf den MZ umschreiben? Du bist doch echt gut im programmieren für MV und MZ. Mir fehlt da leider der Einblick in beiden Engins um das richtig umzuschreiben.

Ich könnte mal mein MV-Befehle-in-MZ-Plugin fertig machen und hochladen, dann geht das damit.

Das einzige Problem ist hier, dass man im MZ keine MV-Befehle neu erstellen kann, aber man kann sie aus einem existierenden Projekt reinkopieren.