RPG Maker MZ, Preview #3: Character Generator, Plugin Manager, Event: Plugin Command!

Status
Not open for further replies.

Archeia

Level 99 Demi-fiend
Developer
Joined
Mar 1, 2012
Messages
15,056
Reaction score
15,341
First Language
Filipino
Primarily Uses
RMMZ
I love seeing my proposal for the plugin command I made back in 2017 in the latest iteration of RM! I appreciate seeing my ideas come to fruition finally. It would've been nice to tell me it was coming though :stickytongue: , did you really come up with this
Actually, no. Lmao. Pure coincidence actually. 2017 was a point we stopped taking suggestions and focused on stability.
 

Touchfuzzy

Rantagonist
Staff member
Lead Eagle
Joined
Feb 28, 2012
Messages
7,171
Reaction score
8,594
First Language
English
Primarily Uses
RMMZ
I'm fine with negative criticism.

I'm just not really happy about being told that we are trying to scam people or go for a cash grab because the things that are being changed are not things they specifically care about. (I actually think people who are saying these aren't big changes will care more about this stuff once they start seeing the differences it will make in their games).

Or twisting what I say to mean something different than what I said.

I'm perfectly happy to address stuff with people and share what I know that I can. But when we are being made out as being deceitful, lazy, etc, it isn't exactly conducive to a constructive conversation, because instead of talking about how things work, I'm put on the back foot trying to defend us as human beings rather than trying to talk about the systems themselves.

And if what MZ has isn't a big enough upgrade over MV for you personally, that is fine. MV still exists. We are happy for you to continue using it.
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,949
Reaction score
3,038
First Language
French
Primarily Uses
RMMV
@Archeia
@Touchfuzzy
do you guys have the authorisation to speak a little more about the code framework?
we know about the pluginCommand is there other big new 'internal' tools that you guys can mention (if any)?
like did you guys changed how sprite are handled as such?
 

EmmaB

Veteran
Veteran
Joined
Feb 20, 2018
Messages
118
Reaction score
159
First Language
English
Primarily Uses
RMMV
@Touchfuzzy Send my thanks as well! You guys put so much work into these engines and do such a great job! I personally love the character generator updates because I use the generator quite regularly and often got annoyed at not being able to have more colours for hair, clothes etc.
I've definitely been wowed and am eagerly waiting for the release date! :LZSsmile::LZSsmile::LZSsmile:
Keep up the good work!
 

Knightmare

Knight of the Night
Veteran
Joined
Mar 14, 2012
Messages
1,171
Reaction score
239
First Language
English
Primarily Uses
RMMV
Negativity is just as important to have as positivity, you shouldn't be hard on people for not being persuaded to spend $80 of their hard-earned money again on what amounts to another marginal update to an engine that already doesn't have the best reputation in the market, even in comparison to its other versions.

You can rally and cry about all the improvements and additions, if it walks like MV, talks like MV, plays like MV, and looks like MV, you are going to have a hard time telling people to move on from MV. Especially if it still have many of the same faults as MV...
I agree with your premise for the most part but think there's also a right and wrong way to do it. I'm all for seeing and hearing about a variety of opinions, positive, negative, and anything inbetween. If everyone just says the same things over and over then things just get boring and robotic. Although I disagree with your opinion somewhat I will fight for your right to say it. Thank you for your contribution. I can understand why some people may not like MZ but to me personally my body is ready to dig in.

I like many about MZ. But I'm not wowed. After 5 years i would be wowed. Realy i use the maker since 2k.

I like the new particle animation, all the small updates and the new plugin commands.

But this is all? After 5 Years a engine wat be like MV+?

Im very frustrated about the generator thing. Many Artist would make more Stuff for the Generator then this damn system would be better.

Then i become no info about the Android stuff..

This big thing of mv! (Mobile version?) Export to Android! Bäm! Oh wait..
This was a big failure. No Plugin are works on Android, no good performance. Nice.. and all plugin maker are to lazy to test there plugins on mobile because the export system is not intuitiv and easy like the rest of the engine. Oh,.. wait,.. same probleme like the one with the Generator.

This are 2 realy disappointed points in MV wat still would be in MZ after 5! Years..

Should i wait 5 other years for fix this?

I'm here to get Infos from the New engine. I'm postet the infos this like touchfuzzy hete, in a German RPG-Maker Community.

I make Marketing for free for this.. but okay then here is only aloud to be positive. I'm quiet.
If you don't like it that's fine, you are entitled to your opinion, there will be others who will give it a pass as well. There's quite a bit more fixes and improvements as is and there will be even a few more announced. Stay tuned, hopefully you'll let all the features come out before making a firm decision.

I personally brought up folders because I make my own generator parts & I find filesaving stressful and disorienting, it's not actually...a Capital P "Problem". I thought to point it out because of basic repetition fatigue and remembering how many packs are in the store. I'd buy a $10 Tool that just imports pieces for me and let Degica monetize my file-organization-hating brainrot. After typoing "TV" and "SV" 8 times in a row despite knowing the difference between the 2 perfectly well I'm ready to let the elements take me (and my wallet).

I think there's this absolutism with "MZ changing/not changing SUCKS" VS "don't criticize that, MZ is fine", but there's really a third emotion, which is "now that I don't have to rest on MV, I'm reminded of things that were roadblocks/are integral to my flow/etc that I set aside at the time, but knowing that we're getting an update, I'm thinking about again". I think a lot of criticism is to that effect; I ended up spending like 3 days cataloguing the extent of colourism in RPG Maker RTP all the way back to the Super Dante era not because it was of grave import to me or something I was "ready to be angry about", but because now that there's new RTP to think about I end up thinking of old issues with fresh new eyes.

It's a little easier to digest "negativity" if you remind yourself that sometimes comments aren't just hate or pessimism, but genuinely people dusting off old thoughts that were buried until now. Like the fact I hate filenames ♥♥♥

Not to say this thread hasn't been Battle 3 150% Pitch dire. Because it has. The final boss of a dev cycle: the fandoommmm

Also as an apology for accidentally producing small essays every time I post I saw an Out Of Touch Thursday tweet as soon as I woke up the thursday of this update and this was the absolute funniest thing I've ever thought in that moment
Don't apologize! We' all here to discuss the new Maker! I know I personally don't mind reading long posts.
 

TWings

The Dragon Whisperer
Veteran
Joined
Jul 26, 2017
Messages
523
Reaction score
854
First Language
French
Primarily Uses
RMMV
It may not seem like a big deal, just to skip a couple of mouse clicks, but I often help people troubleshoot their projects, and when all else fails, we resort to "send me your project" and one of the most annoying things is that I have to go through their list of 50-100 plugins (because apparently people need that many when they start a new game) and turn them all off in one big hit.
It's really not that much of difference in that case.
MV : ctrl+A, right click, Turn OFF
MZ : ctrl+A, SPACE
I mean sure you save maybe like 0.5 seconds but I wouldn't call it annoying.
 
Last edited:

Piyan Glupak

Veteran
Veteran
Joined
Nov 14, 2016
Messages
68
Reaction score
39
First Language
English
From what I have seen so far, many users who are reasonably happy with MV's mapping system and don't know a huge amount about animations except that people seem to expect their use sometimes won't have a huge immediate feeling of "Wow!". On the other hand, some improvements will become very noticeable in the medium to long term.

The increased efficiencies in terms of smaller project sizes, and hopefully, increased speed and smoothness are very good, although not necessarily enough to purchase a new RPG Maker on their own. They may affect how many plugins may be feasible for projects on low-spec computers, though.

I am pleased that MZ should be more stable than MV, but MV seems to have achieved stability now.

If plugins are easier to write, there is a reasonable chance that the range of plugins for MZ will rapidly equal the range of MV plugins, and probably exceed them.

The biggest advantage of MZ for non-power users is that plugins become easier to use. I don't know how effective the new feature about sorting the order of plugins will be, but the major advance seems to be that plugin commands will be as easy to use as commands built in to the editor. I tend to avoid using more than a few plugins because some plugins slow MV on my laptop, and because many interesting plugins take a lot of effort to master full use of. The more efficient code for MZ and the new plugin commands feature should make using more plugins a lot easier in future.

The fact that I might wait a few months before seriously consider buying MZ fits in nicely with the comment Andar made that MV Linux version didn't come out immediately upon MV's release, so there is the possibility that a Linux version of MZ might appear later.
 

Galenmereth

Retired
Veteran
Joined
May 15, 2013
Messages
2,248
Reaction score
2,141
First Language
English
Primarily Uses
N/A
Then i become no info about the Android stuff..

This big thing of mv! (Mobile version?) Export to Android! Bäm! Oh wait..
This was a big failure. No Plugin are works on Android, no good performance. Nice.. and all plugin maker are to lazy to test there plugins on mobile because the export system is not intuitiv and easy like the rest of the engine. Oh,.. wait,.. same probleme like the one with the Generator.
This is a bit of an aside but my personal reason for not testing plugins on Android (and iOS) wasn’t due to MV, but because these platforms are in my opinion absolutely awful to work with. Constant changes to the underlying OS infrastructure causing all sorts of issues with a nwjs implementation; so many different devices with uncountable versions of the OS circulating; the sheer mind-numbing task of keeping track of all this.

In my job we never bother making native apps for mobile anymore, we just make mobile-first versions of our web apps. Because we’re a relatively small team and it’s impossible to do native apps without bloating our development team, increasing financial risk and adding rigidity.

Obviously this won’t work with games and many other types of apps. But my point is, as a solo plugin dev, testing it on mobile isn’t realistic. And while it’s going to be unpopular, in the future I’ll be honest up front and say I personally won’t support my plugins on mobile devices. If others want to help out and contribute to the open source code I’d welcome that, but I personally won’t have the time.
 

Touchfuzzy

Rantagonist
Staff member
Lead Eagle
Joined
Feb 28, 2012
Messages
7,171
Reaction score
8,594
First Language
English
Primarily Uses
RMMZ
Supporting mobile is very very hard. Pretty much for all the reasons @Galenmereth said.

Android and iOS is just insanely harder to work with compared to PC OSes.

There was a reason the MV instructions for exporting to mobile were pretty much already outdated by the time MV was released. Just the time from when the instructions were written to MV releasing were enough for underlying changes to mess with it.
 

Dalph

Nega Ralph™ (RM Tyrant)
Veteran
Joined
Jul 15, 2013
Messages
7,744
Reaction score
19,469
First Language
Italian Curses
Primarily Uses
RMMZ
Give or take the Android exporter still works to me.
I was able to port my 3 minigames without too many hiccups, but then again as I mentioned somewhere else, I only made small stuff and with very few plugins added.
Tested them on a Xiaomi Mi 9 with Android 10 and they work very well, I'm not sure how older/slower devices would perform though, especially with bigger and more complex projects.
The Android exporter was just an extra to me, if it's there OK and if it's not we can still live without it.
PC has to be the main focus.

I personally didn't buy MV for the Android exporter but because it was a solid improvement over ACE.
 

Chaos17

Dreamer
Veteran
Joined
Mar 13, 2012
Messages
1,304
Reaction score
482
First Language
French
Hello,

So, @Archeia has given me the go-a-head to explain properly how the new Plugin Commands work. So this is how they do the things.

To setup a plugin command, a lot of you have guessed that it would be defined in the help file of your plugin. Similar to plugin parameters, well you're right. This is the syntax for defining a plugin command to be displayed in the event editor:

JavaScript:
* @command PluginCommandFunctionName
* @text My Plugin Command
* @desc Plugin Command Description Text
*
* @arg Actors
* @text Which Actors?
* @type actor[]
* @desc Select which Actor ID(s) to affect.
* @default ["1"]
*
* @arg State
* @text State
* @type state
* @desc Which State to apply?
* @default 1
As you can see, it is very similar to the way plugin parameters were created in MV. The difference is the following:

@command - defines a new command, this is how the plugin manager knows what command you are referring to or needing to execute. This is a unique identifier per plugin.

@arg - defines a new command argument/option. This is the name of the property that is passed along when the command is executed.

The above example would net you the following outcome in the event editor:


Other than that, as you can see the defining of a plugin command is extremely similar to plugin parameters, you can even specify data types like you can for plugin parameters.

Now on to how a plugin developer would create the code for such a plugin command. Unlike in MV you no longer have to alias a function, parse a string for your argument, and all that awful stuff. In MZ it is quite as simple as registering a function call with the name of your plugin, and the name of the plugin command you defined. Like so:

JavaScript:
PluginManager.registerCommand("TestPlugin", "PluginCommandFunctionName", args => {
    // Get Arguments
    const actorIds = JSON.parse(args.Actors);
    const stateId = args.State;

    // Use the arguments
    for (const actorId of actorIds) {
        const actor = $gameParty.members().find(member => member.actorId() === Number(actorId));
        if (actor) {
            actor.addState(stateId);
        }
    }
});
What you are doing is registering with the plugin manager that "TestPlugin" has a plugin command called "PluginCommandFunctionName" along with the actual function itself as a lambda. The plugin manager then passes the arguments to that function with the variable "args" as an object containing the values the user selected.

and that is how you would create a new plugin command using the MZ system.

- Kaliya
Thank you for your explanation but does this apply only to Plugin commands?

"Unlike in MV you no longer have to alias a function, parse a string for your argument, and all that awful stuff. In MZ it is quite as simple as registering a function call with the name of your plugin, and the name of the plugin command you defined."

Or does it apply also to the rest of the codes and to making a plugin too?
Because at the moment in MV it's difficult for plugins to co-exist if one use same function without aliasing it which is probably 90% of the reason we've compatibility problem.
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,949
Reaction score
3,038
First Language
French
Primarily Uses
RMMV
Thank you for your explanation but does this apply only to Plugin commands?

"Unlike in MV you no longer have to alias a function, parse a string for your argument, and all that awful stuff. In MZ it is quite as simple as registering a function call with the name of your plugin, and the name of the plugin command you defined."

Or does it apply also to the rest of the codes and to making a plugin too?
Because at the moment in MV it's difficult for plugins to co-exist if one use same function without aliasing it which is probably 90% of the reason we've compatibility problem.
I think that's mainly for pluginCommand not for the whole codebase it's kinda impossible to make plugin who doesn't clash if they overwrite both the same function.
 

Anyone

Veteran
Veteran
Joined
Aug 24, 2019
Messages
225
Reaction score
304
First Language
German
Primarily Uses
RMMV
Thank you for your explanation but does this apply only to Plugin commands?

"Unlike in MV you no longer have to alias a function, parse a string for your argument, and all that awful stuff. In MZ it is quite as simple as registering a function call with the name of your plugin, and the name of the plugin command you defined."

Or does it apply also to the rest of the codes and to making a plugin too?
Because at the moment in MV it's difficult for plugins to co-exist if one use same function without aliasing it which is probably 90% of the reason we've compatibility problem.
You're probably not getting around aliasing functions.
The key to doing it correctly is to alias with your plugin name.

Code:
var ANY_Advanced_Fading_Game_Interpreter_prototype_command221 = Game_Interpreter.prototype.command221;
If you don't, then you're bound to get problems in any function that isn't a property of your plugin by virtue of being assigned to a plugin author's variable. (e.g. using ANY.Game_Interpreter_prototype_command221).
But even that can result in problems when multiple of the same author's plugins target the same command (a mistake I once made in the past), so going by a unique identifier prefix based on the plugin name is the best way to avoid compatibility issues.

I don't see a way how that could be prevented, beyond automatically turning every function into a function that's a property of an object that's created based on the name of the plugin name. Which would then force you to call them via that. (e.g. ANY_Advanced_Fading.functionName() anytime any function is to be called)
That helps with compatibility but makes it more tedious to call functions. (Lots of work for marginal at best improvement)
 

Chaos17

Dreamer
Veteran
Joined
Mar 13, 2012
Messages
1,304
Reaction score
482
First Language
French
Thank you both for explaining, tho I still hoped MZ would've done something about that since they made the effort for Plugin Commands.
I guess we will never have an API which would have helped with compatibility problems.
 

Galenmereth

Retired
Veteran
Joined
May 15, 2013
Messages
2,248
Reaction score
2,141
First Language
English
Primarily Uses
N/A
With ES6 you can do this instead:

JavaScript:
class TDP_Example_Scene_Battle extends Scene_Battle {
    create() {
        console.log("This happens first");
        super.create(); // This is functionally equivalent to the old Original_Scene_Battle.prototype.create.call(this);
    }
}

Scene_Battle = TDP_Example_Scene_Battle; // This overwrites Scene_Battle with the new extended class, similar to the old way but far less verbose
You can do this in MV today already, since this is supported in the current nwjs implementation :)
 

Animebryan

Need more resources!
Veteran
Joined
Jul 31, 2012
Messages
423
Reaction score
206
First Language
English
Primarily Uses
RMMV
@Touchfuzzy I forgot to ask this before but in regards to mapping, I have 2 questions;
#1 - Was RM2k3's Randomize Dungeon option brought back? (Where a dungeon map randomly generates each time it's entered)
#2 - Was the Max Map Size restored to Ace's 500x500 or perhaps have that limit removed? Or is it still 256x256?
 

R1PFake

Villager
Member
Joined
Jul 11, 2020
Messages
12
Reaction score
13
First Language
German
Primarily Uses
N/A
With ES6 you can do this instead:

JavaScript:
class TDP_Example_Scene_Battle extends Scene_Battle {
    create() {
        console.log("This happens first");
        super.create(); // This is functionally equivalent to the old Original_Scene_Battle.prototype.create.call(this);
    }
}

Scene_Battle = TDP_Example_Scene_Battle; // This overwrites Scene_Battle with the new extended class, similar to the old way but far less verbose
You can do this in MV today already, since this is supported in the current nwjs implementation :)
This will not work if multiple plugins make their own battle class which extend the Scene_Battle and set their own battle.
In these cases it would be better to "override" the specific functions you want to change instead of setting a whole custom class.
 
Last edited:
Status
Not open for further replies.

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

Wow... For the longest time I thought, my game had a memory leak. I've been doing everything I can think of to optimize it. I was at a loss... Then today I tried a deployed version. Turns out the memory leak is MV running it.
:ewat:
It's not the biggest number ever, but I am so happy!
I started to paint again after it didn't fit my female character. (I really intend to draw women)

Forum statistics

Threads
103,165
Messages
997,737
Members
134,636
Latest member
Koichi
Top