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

[Candacis]

I made a gradient with more realistic skin and hair colors for MV.

 

[nio kasgami]

Wow, I'm so happy that the base classes have been rewritten in ES6. It'll make navigating and reading them so much easier for someone with a poopbrain like me.
How might someone alias a method now? It's pretty much the same syntax I imagine?

There's will be a tutorial incomming today but YES and NO

ES6 is ES5 but....prettyfied?

but if you overwritting a class function or adding to a existing class you would do the ES5 way.
Since ES6 class are considerate 'Final' which are not like Ruby class you can't just go and Re-declare them.

 

[Anyone]

So it seems to me that your real concern on the new MZ plugin command is that it makes you hard or even impossible to use it fast enough thus disrupting your otherwise very fluent and smooth workflow, as you mentioned that you can use the MZ counterpart within 1 second and you really don't want to be bogged down by that.

Assuming that the following possible alternatives won't be an option(or that they're possibly not acceptable by you):
1. Script calls whose function names look like plugin commands(it needs the MZ plugin developers to make these work) -

function pluginXActorPluginCmdY(actorId, cmdArg1, cmdArg2, cmdArg3, cmdArgN) {
    $gameActors.actor(actorId).pluginXScriptCallY(cmdArg1, cmdArg2, cmdArg3, cmdArgN);
} // Plugin command names can have collisions in MV too even though it's less likely and less severe
function pluginCmdZ(actorId, cmdArg1, cmdArg2, cmdArg3, cmdArgN) {
    $gameActors.actor(actorId).pluginXScriptCallZ(cmdArg1, cmdArg2, cmdArg3, cmdArgN);
} // This risks name collisions but is even more intuitive and easy to call

Using scripts calls instead would work, but as you point out, it comes with a slew of additional stuff to do which is inconvenient for experienced users and downright hostile to beginners, because plugin commands are simple (command, arguments) wheras with script calls, you need to also watch the syntax.

2. Further upgraded plugin command with plugin/plugin command name search/type(you said it's unlikely)

2 Would be an acceptable solution. Ideally, next to the browser list, you have an input field where you can write a part of the plugin name and it immediately displays a short list of the results or the plugin directly, if only 1 result comes up.
That way, you have both the easier functionality and a smooth and quickly usable interface.

3. Further upgraded plugin command with a text equvalent(just like MV 1.5.0+ plugin manager parameter value raw text counterparts as the inputted MZ plugin command in the editor should be converted to data consumed by codes anyway so MZ plugin command should be able to let users handwrite something like a JSON or JavaScript object as well as using the more friendly version)

Having a text box at the top or bottom of the plugin command screen that, if filled, will ignore any and all other settings and execute direct plugin command would also solve it, yes.

4. Script call wrappers made by yourselves being more intuitive and easy to call functions(do it once per script call now and use each of them faster many times later even though it can still suck at first)

Not sure what you mean with that exactly, but it sounds pretty much like no1, except that you simplify the function name even further, e.g.
command(args);
->
morph(target, size);
->
morph(Actor1, 200)
or
$morph(Actor1, 200)

Doable, but it ends up with similar problems. You have loose commands floating around.
It does what a Plugin command would do, just slightly more complex and less forgiving, due to syntax sensitivity.

5. The existence of the MV plugin command counterpart in MZ(it's assumed to be not the case for now)

So far, everything indicates it won't be in, but if it were, my point about it missing would obviously be void.

I'd wonder whether you'd consider making a new MZ plugin command once in a separate common event just for that(that common event's named to be the plugin command), then whenever you want to use that plugin command, you call that common event instead(which can be done within 1 second), thus preserving your fluent and smooth workflow.

Of course it won't work if you're using tons of plugin commands that way(now the common events will be bloated and you'll have to scroll through a long list of common events assuming that it's no grouping mechanism like what the MV counterpart could have) or the same plugin commands with tons of different argument values that way(I wonder whether the MZ plugin command supports passing game switch/variable values as arguments, if it does then the issue can be mitigated somewhat by dedicating some variables/switches named as the argument names).

But the big picture would become that you're using tons of different plugin commands and/or the same plugin commands with tons of different arguments in MV, most done very quickly(as fast as 1 second in your case), meaning that you're really very familiar with possibly many plugin commands all at once while still being able to focus on your workflow at the same time, thus implying that your memory is really excellent, which is definitely a very, very good thing as it does let you keep your workflow very fluent and smooth for a very long time

So if MZ does have removed your beloved MV plugin command counterpart, what workaround would you use if you're to use MZ? Right now the above is all I can think of

P.S.: As it seems to me that you do know how plugin command works in details for MV(including the fact that it can have name collisions just like script calls), I'll assume that you're a plugin developer, so I'd also wonder what workarounds you'd use when developing a MZ plugin

I honestly would run away from common events as stand ins as far as I possibly can.
They're an organizational nightmare.

One of the big things I'm currently doing is writing plugins to replace things I previously handled as common events, because at 250+ common events, the list becomes nightmarishly long and every time I create a new type of commands, I need to guess how many slots I'll need for common events, because when I run out of space, I have to put those common events somewhere else.
Going through a long list of common events that no longer are sorted by their functionality (weather effects, day & night systems, Attribute changes, drunkenness mechanics, quest popups, party join/leave messages, clothing systems, etc.) because you didn't leave enough empty slots is incredibly frustrating. And you can't just simply sort them anew, because the common events are called by ID, not any other identifier, so you'd break all usage of the common events across the game if you change their ID location.

A much more likely replacement would be to simply say:
Shuck it all, I'm making a Plugin Command Plugin.
"_Plugin Command"
(Dash to have it listed in the first slot of the list)
It has only one command, which is "command".
It has only 1 entry field as parameter:
"Plugin Command:"

And then you simply have that command parse the input to the js as if everything had been selected as options & parameters & commands.
It requires 3 more clicks on lists & clicks on the first entry than previously, but it would get you the same thing as the old Plugin Command.
More tedious, a downgrade, but the functionality is preserved and you're almost as fast as you used to be.

But then it gets into the whole: who will use it, can you expect authors to use it, who manages it in case an update is required, etc.

It'd just be so much simpler to have it as option 3 or 5, with option 2 being not just an acceptable compromise, but just vastly improved functionality of the new plugin command for everyone.

So yeah, my workaround would probably be a Plugin that allows you to enter a plugin command that is tricked into being first in any list.

 

[nio kasgami]

For any plugin developper wondering for ES6

and also @Shaz and @meowengine

It should cover a big 'beginner' question for who doesn't know how to extends, overwrite, alias a existing class

How to Extends / Alias / Overwrite existing class in MZ/ ES6 [Tutorial]

Hi there! As MZ is now officially confirmed to be full ES6 us programmer can now use the ES6 javascript as the official javascript coding standard. ES6? what is the differences between ES5? Well here's a quick look at how class are defined in ES5 and ES6 // ES5 class function Scene_Dummy() {...

forums.rpgmakerweb.com

 

[PARCB]

PD: it should be Team MZ, because it's AMAZING

 

[killdude]

It seems that the existing engine's deficiencies have been fixed rather than bringing new things.
In this context, I liken Mz very much to Assasins Creed 2 or Resident Evil 2. They don't create anything too much, but they make the existing better.I hope they have improved the database capacity as well. Even though its skills and enemy parts are enough, 1000 options for animation and states were a bit less, especially if you are using plugins.Now wowed but frankly I have expectations.

 

[masterlobo]

Daaaaaaaaamn, the Plugin Commands update is awesome. A game changer imo.

 

[nio kasgami]

Yep! @masterlobo Now Imagine you want to make a custom message system like a VN well now u can! no need to go like full blown typing long butt command.

or a Custom shop system with custom pricing conditions? pretty easy to setup just with a single array of item. and then setup their prices!

 

[Hudell]

The Plugin Commands extension is really good, but I wish they could be used in more places, like move routes and as conditions on conditional branches. Assigning the result of them to variables and switches would be cool too.

 

[K2loid]

Enhanced Generator
Overall just meh. Not gonna use it, I'll keep using Schlangan's generator, which is still vastly more powerful and has lots of features the generator doesn't have - or if I find the time, I'll find a programmer to work with to build a new one that has even more improved functionality.
It's probably nice for people who only want to build their default characters, but damn, there's like a couple dozen improvements, many of them that require little work, that could be done to make the tool vastly more useful.

Oh WOW, thanks for that rec! Even if its just alpha, Schlangan's generator is incredible; easy to add assets, fully customizable, and ease of sharing. Kind of makes RPG maker's hard limitations and filename finnicking a bit of a downer. And thus this update a downer.

 

[Starmage]

Woow!! I am happy for our plugin creators in this update! And im also excited for the generator with the offset thingy too! ^_^ xD

Btw I have a question... How will MZ handle new generator parts? Because I remember it being quite of a confusing journey and a hassle when importing new generator parts in MV. I hope theres some update on that generator parts importing as well?

 

[RPGMakerWeb]

Btw I have a question... How will MZ handle new generator parts? Because I remember it being quite of a confusing journey and a hassle when importing new generator parts in MV. I hope theres some update on that generator parts importing as well?

Adding new parts is going to follow the same scheme as before. There are just a lot of hurdles involved in creating a different way to import pieces into the Generator.

 

[Touchfuzzy]

@Touchfuzzy
Does Rpg Maker MZ keep the option to easily search for a plugin with CTRL+F as in Rpg Maker MV?

This behavior still exists.

Also as a note: when selecting what plugin to select a plugin command from, only ones that actually have plugin commands show up. So you won't have to scroll through 200 unless you have 200 different ones that all have plugin commands attached.

 

[SOC]

Can we manually set the offset or do we have to use the arrows?

 

[Touchfuzzy]

Can we manually set the offset or do we have to use the arrows?

You have to use the arrows, you can't drag on the faceset or anything like that.

 

[Sharm]

Adding new parts is going to follow the same scheme as before. There are just a lot of hurdles involved in creating a different way to import pieces into the Generator.

That's too bad. I assume this means that the sprite size for the battlers is still fixed instead of variable like the walk sprites?

 

[Starmage]

Adding new parts is going to follow the same scheme as before. There are just a lot of hurdles involved in creating a different way to import pieces into the Generator.

Ohh!! I understand! I do see that the new generator has a ton of stuff already as it is along with the new gradient feature, so im not gonna worry too much about it. xDD Unless of course, I decide to DL all of the wonderful generator parts in the community again for fun! xD Thanks for the response!! <3

 

[chalkdust]

Sweet new features, definitely some solid QOL improvements.

I may have missed this on a previous page, but any chance the new generator allows you to change the base human body? There are a lot of non-human fan-made body templates out there by various artists. If I recall, in MV we had to either implement them as "FacialMark" or temporarily replace the human template file. If we can swap the body a little easier, it'll help add species variety.

 

[Tea's Jams]

I like what I see. MZ is looking to be great engine, I'm so glad it was created. This will be my first official RM engine release!

 

[DJK1NG_Gaming]

Nice!
Although I do want to know how much default Generator Assets are there.
Or if the default all actors, people and evil clothes are available in the generator this time.
But overall loving all the improvements.
Definitely moving halting my game development on MV.