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

Status
Not open for further replies.

Poryg

Dark Lord of the Castle of Javascreeps
Veteran
Joined
Mar 23, 2017
Messages
4,113
Reaction score
10,541
First Language
Czech
Primarily Uses
RMMV
@Dalph I've been with the community for 3 years. Started on MV 1.4.4. In 1.5.0 we got better plugin manager. In 1.6.0 we finally got better nwjs.
I was one of the 7 people who provided feedback on MV 1.6.0 open beta. Their support of that was good - so good that they did not even fix any of the bugs that were reported before launching that as a release version. When they released it, I was glad... Because I had thought they'd fix the bugs. But then I saw that 100% of the bugs stayed... Hence backlash was inevitable, because they'd released an unstable version. And backlash did happen.
Also, yes, they supported MV for 5 years. But considering that the release of MV was already premature and that the updates were not particularly frequent for what they brought, I'm not sure if 5 years is that amazing.


As for the features you listed... Better performance and optimization... That's something that has been requested in MV for years. Not because it was a good thing to have some extra performance, but because MV has serious performance issues.
The biggest issues with it were never solved. Rewriting the engine to ES6 was requested for years too... We never got it, because "they wanted to keep compatibility with plugins"... Even though if I only rewrite code from ES5 to ES6, I'm hardly breaking anything as it's from 90% syntactic sugar. Therefore I am not going to be impressed by MZ's improved performance when MV's already left a lot to be desired. Just like the features you listed... Some of them were quality of life features that were definitely portable to MV. They had 5 years for it.
Don't get me wrong. The features are great... But there is very little of what's been revealed so far that doesn't leave me asking myself - why wasn't this in MV?
Effekseer is one of such features. Native ATB too... And the extra layer too. But no move route preview in 2015? No ES6 when it came out?

And nope... I don't expect infinite support. I only feel that MV is left unfinished. We're going to have a more complete project, but that might cost 100€ for all I know considering all the extra assets.
That's why I feel gutted. I can't consider that as good practice - to abandon an unfinished project and charge money for a new one that's more complete.
That's why I'm going to whine.
 

rue669

RueToYou
Veteran
Joined
Aug 29, 2016
Messages
442
Reaction score
361
First Language
English
Primarily Uses
RMMV
The QoL improvements sound excellent.

Seems like plugin makers really like this announcement.

Quick question for plugin makers: does it sound like it'll be easy (or relatively simple) to convert MV plugins to MZ? (I ask because I have several custom plugins for my MV project that I'd like to convert to MZ.) Thanks!
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,338
Reaction score
1,495
First Language
English
Primarily Uses
RMMV
The QoL improvements sound excellent.

Seems like plugin makers really like this announcement.

Quick question for plugin makers: does it sound like it'll be easy (or relatively simple) to convert MV plugins to MZ? (I ask because I have several custom plugins for my MV project that I'd like to convert to MZ.) Thanks!
It shouldn't be vastly difficult. You're still working in JavaScript, and for the most part JS is designed so that newer versions don't break legacy code.

The main thing is going to be making sure aliases and overwrites of core functions are rewritten to compensate for changes to the core code. That's not something we can really predict the difficulty of until we see how different the core codebase is, but again I can't imagine it being so vastly different that hugely significant edits are needed.
 

rue669

RueToYou
Veteran
Joined
Aug 29, 2016
Messages
442
Reaction score
361
First Language
English
Primarily Uses
RMMV
@Trihan Thank you for the quick response. I appreciate you taking the time. What you're saying makes total sense to me. (BTW, love your post in the plugin support about the lunatic code!)
 

MikePjr

Artist
Veteran
Joined
Nov 7, 2012
Messages
731
Reaction score
452
First Language
English
Primarily Uses
So does this gradient stuff mean I can have the hair color I want now?
Up till now, I'd get irritated that the shade of red i wanted was missing.
So now I can make the colors I want for character parts?
I'd like to see more on this actually.
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,338
Reaction score
1,495
First Language
English
Primarily Uses
RMMV
So does this gradient stuff mean I can have the hair color I want now?
Up till now, I'd get irritated that the shade of red i wanted was missing.
So now I can make the colors I want for character parts?
I'd like to see more on this actually.
Both of those appear to be the case, yes. You'd just add a new row to the appropriate gradient png file for the kind of part you want to use it in, and it'll appear in the editor as one that's selectable.
 

Wavelength

Edge of Eternity
Global Mod
Joined
Jul 22, 2014
Messages
5,390
Reaction score
4,781
First Language
English
Primarily Uses
RMVXA
I didn't say the new way isn't useful. But I cannot comprehend why someone would replace the command line entirely, rather than just adding the new one?
No one argues that isn't useful.
But I cannot understand why you'd remove the normal command entirely, instead of leaving it as a powerful backdoor option.
I'm not claiming the new plugin command isn't useful, but you end up doing in one place what you would've done previously anyway. Reading up on what does what and how to use it.
I'm normally on the side of inclusiveness (for allowing different types of workflows), but here, in my opinion, the benefits aren't worth the drawbacks, and I believe that's why they would get rid of the old free text entry Plugin Command event command.

For one, plugin creators would now be essentially forced to cater to two completely different methods of accessing their plugin commands that each do the same exact thing. The format for making a plugin command "acceptable" to RPG Maker's way of reading it would be completely different between the two entry formats (there is no way I can think of to combine them into a format that the plugin creator could enter just once). If they provided one but not the other, it would look remiss when, for example, a user tried to access a plugin's commands in the new style and couldn't find those commands anywhere on the list. Having both formats as event commands would waste a lot of plugin creators' time (much more than they'd waste by simply having an "Advanced" plugin parameter with free text entry).

The second type of drawback is for the game designers using the plugins. In addition to the bloat of having yet another event command available in a sea of options, it would also cause a lot of confusion for people who aren't advanced users yet like you and I are. Why are there two different Plugin Command event commands? Which one do I use? What am I supposed to do with this empty box? What's the difference between Script command's empty box and Plugin Command command's empty box? Why am I getting a crashing error when I type stuff into it?

While a free text entry box would occasionally have a convenience-related use for advanced/expert users, I feel there are too many stakeholders it would hurt to justify its presence.

And you don't have to recall most of the 200 different plugin commands, that's a strawman argument. But they are going to pop up in the list, forcing you to search through the entire arsenal.
For you to take a very valid and realistic concern (which a majority of plugin users have expressed having in MV, by the way) and dismiss it out of hand as some kind of "strawman argument", is at best ignorant of you to say, and at worst completely dishonest.

If you don't remember the exact syntax of plugin commands (often 4+ parameters, some of which contain multiple words or "formatting" syntax), you have to:
  • Leave the Event Editor
  • Open up your Plugin Editor
  • Scroll through your 200 plugins (which is what you're complaining about having to do in the first place!)
  • Find the plugin and look through the help documentation if it's even there
  • Copy the correct plugin command from the documentation
  • Leave the Plugin Editor
  • Go back to the Event Editor and find the place you were trying to insert a Plugin Command
  • Paste that Plugin Command and change Parameters to your liking
  • Realize that you don't know what type of syntax to use for one of the Parameters, because the options aren't in front of you (dang, was I supposed to use Succubus.png, "Succubus.png", or Graphics/Battlers/Succubus.png?)
  • Leave the Event Editor
  • Open up your Plugin Editor
  • Scroll through your 200 plugins again
  • Find the plugin and look through the help documentation for your answer - if it's there
  • Leave the Plugin Editor
  • Go back to the Event Editor and find the place you were trying to insert a Plugin Command
  • Fix the parameter you weren't sure about
Holy crap, that's a lot of work and annoyance to get a single Plugin Command right. And that's the normal flow of using Plugin Commands in RPG Maker MV, if you're using a mix of plugins from different scripters. We've (as novice and expert users alike) dealt with the frustration because we've had to in order to accomplish things that eventing alone can't accomplish. But now we don't have to deal with that anymore!

It seems really weird to insist that we confuse users and burden plugin makers by adding that frustration back in alongside the better way "as an option to have".

The point at which you can add a custom command line via the parameters is the point where you've already browsed through the plugins and done the whole scrolling and clicking.

Ideally, in any interface design, you want to have the least amount of actions between decision and outcome.
Yes, that's true (my proposed workaround would require one additional dropdown menu click as opposed to your Event Command approach). However, my workaround would still save you the trouble of hunting for specific parameters within the Plugin and/or using a dropdown-style approach for entering values for those parameters if you don't like doing that.

And it doesn't require the doubled work from plugin developers or the massive confusion that would result from having Plugin Command Parameter Entry, Plugin Command Script Entry, and Script Entry as three different options together on the Event Editor window.

Giving plugins the ability to add event command itself on a seperate event page would have been a much faster and more streamlined way, but unfortunately they skip any and all plugins directly affecting the editor.
Interesting idea in that it would save by streamlining out the need to click "Plugin Command" first (and then choose the plugin name and command). But I feel like it would be a lot less organized than the way it's being handled right now.

For example, every time you add a new plugin to your editor (especially one that needs to be placed early on in your list due to overwriting/aliasing of methods), you will completely change which page that these new Event Commands appear on. You'd also have a lot (dozens or even hundreds) of event commands that you don't care about cluttering up the list. Yuck. I think it would cost more time hunting for event commands, than it would save with the more streamlined series of clicks.


I guess if you feel the need to 'die on a hill' over the way you input plugin commands, then you can keep using MV to make your games and refuse all of the great features that MZ is offering. But understand that you are in an extremely small minority of designers whose workflow is a little faster using the current free text entry method, and that while it would genuinely be nice for designers like you to have "as an option", including it would actually harm plugin makers as well as the vast majority of designers so it's very unlikely to happen.
 

rue669

RueToYou
Veteran
Joined
Aug 29, 2016
Messages
442
Reaction score
361
First Language
English
Primarily Uses
RMMV
@Touchfuzzy Hope you're doing well and getting some rest. Quick question for you: you had said previously that there were two things about MZ that you were super hyped about. One was the animation editor. Is this update/preview the second one?
 

MikePjr

Artist
Veteran
Joined
Nov 7, 2012
Messages
731
Reaction score
452
First Language
English
Primarily Uses
Both of those appear to be the case, yes. You'd just add a new row to the appropriate gradient png file for the kind of part you want to use it in, and it'll appear in the editor as one that's selectable.
Awesome Sauce!
That was a huge gripe I had in MV.
I think it was a thing i struggled with in vx and ace as well.
 

Animebryan

Need more resources!
Veteran
Joined
Jul 31, 2012
Messages
411
Reaction score
194
First Language
English
Primarily Uses
RMMV
Having the Plugin manager give you a heads up on the proper plugin order is a great addition, but don't expect it to prevent errors caused by plugin incompatibilities. If you're using a mix of plugins from different creators, there's bound to be a compatibility issue if 2 or more plugins try to rework a certain function. It would've been nice if the error messages that come up would CLEARLY state which plugins are conflicting along with which lines & functions are clashing, so that we don't have to go through that stupid process of turning off plugins 1 by 1 or turning them all off & back on 1 by 1 just to narrow down the culprit.

At least that way we'll know for sure which plugins are the problem & we can contact their authors for a compatibility fix.
 

Trihan

Speedy Scripter
Veteran
Joined
Apr 12, 2012
Messages
2,338
Reaction score
1,495
First Language
English
Primarily Uses
RMMV
Having the Plugin manager give you a heads up on the proper plugin order is a great addition, but don't expect it to prevent errors caused by plugin incompatibilities. If you're using a mix of plugins from different creators, there's bound to be a compatibility issue if 2 or more plugins try to rework a certain function. It would've been nice if the error messages that come up would CLEARLY state which plugins are conflicting along with which lines & functions are clashing, so that we don't have to go through that stupid process of turning off plugins 1 by 1 or turning them all off & back on 1 by 1 just to narrow down the culprit.

At least that way we'll know for sure which plugins are the problem & we can contact their authors for a compatibility fix.
The problem with that is that there isn't really a massively easy way to tell. All a plugin essentially does is replace parts of the core code or add new code to it, but in the end everything is just rendered as one big script section. It would probably be way too much overhead to add tracing of which individual .js file tried to overwrite a function that was already overwritten earlier by another one.
 

Anyone

Veteran
Veteran
Joined
Aug 24, 2019
Messages
191
Reaction score
200
First Language
German
Primarily Uses
RMMV
I'm normally on the side of inclusiveness (for allowing different types of workflows), but here, in my opinion, the benefits aren't worth the drawbacks, and I believe that's why they would get rid of the old free text entry Plugin Command event command.

For one, plugin creators would now be essentially forced to cater to two completely different methods of accessing their plugin commands that each do the same exact thing. The format for making a plugin command "acceptable" to RPG Maker's way of reading it would be completely different between the two entry formats (there is no way I can think of to combine them into a format that the plugin creator could enter just once). If they provided one but not the other, it would look remiss when, for example, a user tried to access a plugin's commands in the new style and couldn't find those commands anywhere on the list. Having both formats as event commands would waste a lot of plugin creators' time (much more than they'd waste by simply having an "Advanced" plugin parameter with free text entry).

The second type of drawback is for the game designers using the plugins. In addition to the bloat of having yet another event command available in a sea of options, it would also cause a lot of confusion for people who aren't advanced users yet like you and I are. Why are there two different Plugin Command event commands? Which one do I use? What am I supposed to do with this empty box? What's the difference between Script command's empty box and Plugin Command command's empty box? Why am I getting a crashing error when I type stuff into it?

While a free text entry box would occasionally have a convenience-related use for advanced/expert users, I feel there are too many stakeholders it would hurt to justify its presence.
I disagree. First of all, it'd be still the plugin creator's decision of whether to use one or the other or both or none.
That decision already exists currently, where plugin creators can decide whether to add, for example, plugin commands to change or specify an automated plugin process.

Secondly, I disagree that it'd be a lot of work. Both are effectively doing the same thing:
They call a function with a number of arguments. The only difference is how the function and the arguments are selected.

In the current version, from what I can see, you select the function to be called and edit the parameters in the plugin command's option window.
What the editor then sends to the js game system is effectively no different than a call(function, arguments) which is ultimately the same thing as calling it via plugin command.
All you'd have to do is add the plugin commands into the plugin interpretor which is not difficult at all.

The way the function and the parameters are handled would be identical in both systems.

JavaScript:
  //===========================//
 //Plugin Commands            //
//===========================//

var _Game_Interpreter_pluginCommand = Game_Interpreter.prototype.pluginCommand;
Game_Interpreter.prototype.pluginCommand = function(command, args) {
    _Game_Interpreter_pluginCommand.call(this, command, args);
    if (command === 'FadeIn' || command === 'Fadein') {
        this.customFadingIn(args);
    } else if (command === 'FadeOut' || command === 'Fadeout') {
        this.customFadingOut(args);
    };
};
That's what would have to be added. Just the way the function is called with the arguments.
Everything else stays identical, because both ways handle the parameters identically.

For you to take a very valid and realistic concern (which a majority of plugin users have expressed having in MV, by the way) and dismiss it out of hand as some kind of "strawman argument", is at best ignorant of you to say, and at worst completely dishonest.

If you don't remember the exact syntax of plugin commands (often 4+ parameters, some of which contain multiple words or "formatting" syntax), you have to:
  • Leave the Event Editor
  • Open up your Plugin Editor
  • Scroll through your 200 plugins (which is what you're complaining about having to do in the first place!)
  • Find the plugin and look through the help documentation if it's even there
  • Copy the correct plugin command from the documentation
  • Leave the Plugin Editor
  • Go back to the Event Editor and find the place you were trying to insert a Plugin Command
  • Paste that Plugin Command and change Parameters to your liking
  • Realize that you don't know what type of syntax to use for one of the Parameters, because the options aren't in front of you (dang, was I supposed to use Succubus.png, "Succubus.png", or Graphics/Battlers/Succubus.png?)
  • Leave the Event Editor
  • Open up your Plugin Editor
  • Scroll through your 200 plugins again
  • Find the plugin and look through the help documentation for your answer - if it's there
  • Leave the Plugin Editor
  • Go back to the Event Editor and find the place you were trying to insert a Plugin Command
  • Fix the parameter you weren't sure about
Holy crap, that's a lot of work and annoyance to get a single Plugin Command right. And that's the normal flow of using Plugin Commands in RPG Maker MV, if you're using a mix of plugins from different scripters. We've (as novice and expert users alike) dealt with the frustration because we've had to in order to accomplish things that eventing alone can't accomplish. But now we don't have to deal with that anymore!

It seems really weird to insist that we confuse users and burden plugin makers by adding that frustration back in alongside the better way "as an option to have".
Or you have a hyperlink to the plugin page in saved in a folder, that's easily accessible via desktop or hyperlink.
1. You open the folder.
2. You click the link.
3. You read the instructions. (with pictures!)

Or, if no online page exists:
1. You open your editor (e.g. sublime text 3)
2. Click in the imported folder structure that's already present on the plugin you wish to use.
3. Read the instructions.

A strawman argument is when you make the opposing argument as unbelieveable as possible in order to have it almost defeat itself for the explicit purpose of making your argument seem obviously the only reasonable solution.

MZ offers a welcome improvements. It's not the end-all solution, and there are other ways. (See online page with pictures, as is the case with, for example, moghunter's plugins. Which you can, conventienly, also translate with google translate for super easy use.)

Yes, that's true (my proposed workaround would require one additional dropdown menu click as opposed to your Event Command approach). However, my workaround would still save you the trouble of hunting for specific parameters within the Plugin and/or using a dropdown-style approach for entering values for those parameters if you don't like doing that.

And it doesn't require the doubled work from plugin developers or the massive confusion that would result from having Plugin Command Parameter Entry, Plugin Command Script Entry, and Script Entry as three different options together on the Event Editor window.
The work is, as I show in the code example above, not nearly massive nor is it required or mandatory.
Plugins have always been designed by what the plugin developer decided what he/she is willing to do. Point me to a plugin and I can tell you a number of additional plugin commands or options that could have been added to make it more streamlined or optimized.
Whether a plugin creator engages in that additional work has been, is, and will remain the decision of that creator. No universal standard that has to be adhered to exists.

If you want to talk about a massive amount of work that you wish to spare plugin developers, then not forcing them to program & code the new plugin command options into the plugin & giving them descriptions, etc. would be at the top of the list?
Because between a command line plugin command and a plugin command event with options and descriptions, if it works similar to the structs that the plugin manager uses, this new way will actually be a lot more work-intensive for plugin developers. With no way around it.

Interesting idea in that it would save by streamlining out the need to click "Plugin Command" first (and then choose the plugin name and command). But I feel like it would be a lot less organized than the way it's being handled right now.

For example, every time you add a new plugin to your editor (especially one that needs to be placed early on in your list due to overwriting/aliasing of methods), you will completely change which page that these new Event Commands appear on. You'd also have a lot (dozens or even hundreds) of event commands that you don't care about cluttering up the list. Yuck. I think it would cost more time hunting for event commands, than it would save with the more streamlined series of clicks.
Or you could let those things be in the purview of the enduser, such as allowing them to have a event command button that accesses only commands from a plugin directly, or seperate pages for managing them, or a search command on the site to easily search event commands by name or plugin author, etc. etc. etc.

All of those have easy solutions within a more flexible editor system that allows more plugin creator and end-user decision making to have things more customizable for the ones that prefer it that way.
 

Wavelength

Edge of Eternity
Global Mod
Joined
Jul 22, 2014
Messages
5,390
Reaction score
4,781
First Language
English
Primarily Uses
RMVXA
@Animebryan Kind of like @Trihan mentioned, it would be nearly impossible to tell which plugins were conflicting without some kind of very specialized, very intelligent program that could read and judge their interactions (I think such a program would be possible to create for a large team of creative engineering experts, but not practical for something like RPG Maker).

Plugins are supposed to overwrite (or otherwise modify) existing behavior, which often includes existing behavior from other plugins (for example, one plugin might change the normal battle system to a tactical battle system, and another plugin might change the way that either battle system handles TP gains by modifying some of the same methods - this is not an incompatibility despite hitting the same areas). And often where there is an incompatbility, it's something that's not revealed until much later, where (for example) a variable has been intentionally changed by one plugin, but that change puts it in a form that's not usable by another plugin.

While I fully agree such a tool would be awesome to have, I think it's going to be a pipe dream for another decade or two. :(
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,587
Reaction score
656
First Language
Chinese
Primarily Uses
N/A
Having the Plugin manager give you a heads up on the proper plugin order is a great addition, but don't expect it to prevent errors caused by plugin incompatibilities. If you're using a mix of plugins from different creators, there's bound to be a compatibility issue if 2 or more plugins try to rework a certain function. It would've been nice if the error messages that come up would CLEARLY state which plugins are conflicting along with which lines & functions are clashing, so that we don't have to go through that stupid process of turning off plugins 1 by 1 or turning them all off & back on 1 by 1 just to narrow down the culprit.

At least that way we'll know for sure which plugins are the problem & we can contact their authors for a compatibility fix.
The only such way I can think of is for the codebase itself to be extremely testable and have a comprehensive test suite, and every plugin to be extremely testable with its own comprehensive test suite as well, meaning that:
1. The default RMMZ codebase clearly states its assumptions(preconditions, postconditions, invariants, argument checks and/or even sometimes implicit dependencies, etc) in tests
2. Every plugin clearly states its counterparts, along with what assumptions in the default RMMZ codebase that plugin rely on and what assumptions in the default RMMZ codebase have been broken intentionally/knowingly

It's because, most plugin compatibility issues stem from either of the following:
1. Plugin A relies on some assumptions in the default RMMZ codebase, but plugin B has broken some of those intentionally/knowingly
2. Some of the assumptions from Plugin A itself have been broken by plugin B unnoticed
(Of course there are some really much more complicated and convoluted cases and I've faced one such case causing me a world of hurt, but those should be rare enough to be exceptions)
With the aforementioned approach, the majority of these assumption violations should be caught and reported by the involved test suites, so users will not only know which plugins have compatibility issues with each other, but sometimes even the root causes of such issues, thus making reporting compatibility issues even more effective and efficient.
While even this won't catch all compatibility issues, the lives of users facing compatibility issues should be much, much easier in general.

Unfortunately, for that to happen:
1. The default RMMZ codebase would need to be extremely testable, meaning that it'd be so different from the MV counterpart that only plugin developers who are already very experienced in reading/writing extremely testable codes(like ECS with BDD or TDD) can adapt to MZ reasonably quickly.
2. Almost all MZ plugin developers, even those being used to be writing extremely testable codes, would need to have the highest self-disciplines possible all the time, as writing extremely testable codes takes tons of dedications and efforts most of the time no matter how good you're at it.
Combined, I could expect tons of MV plugin developers to just vanish completely in MZ, and I doubt that the number of MZ plugin developers being new to RM would be very low too.

Therefore, I don't think it'll ever happen, and I actually think this whole thing can be indeed a very bad idea in MZ, as it'd at least drastically reduce the number of MZ plugin developers and the average number of plugins per plugin developer(writing a test suite for a plugin can cost tons of time, sometimes even much more than the time to develop the plugin itself).

To conclude, I'm afraid that plugin users will have to remain on the oldschool way - Pinpoint the conflicting plugins by themselves or send their projects to someone who'd be kind enough to do it for them.
I know that it's really, really far from ideal, but I just can't think of an alternative that won't create even greater problems in MZ yet :)

P.S.: As for the plugin ordering thing, while MV plugin developers can already check plugin load ordering if they've the devotion to do this(which can be very painful involving plugins not declaring their existence), the MZ plugin manager featuring plugin load ordering check out of the box can somehow further encourage, recommend, or even to some extent, enforce the MZ plugin developers to implement these checks, thus removing some compatibility issues from wrong plugin orderings :D
 
Last edited:

AfroditeOhki

Veteran
Veteran
Joined
Oct 3, 2019
Messages
68
Reaction score
81
First Language
Portuguese
Primarily Uses
RMMV
Hey, wait, what's that sound?

Can you hear it? Shhh wait. I think I know!

It's the sound of plugin makers chanting in glee weeeee

(And the sound of me, the arty girl with the memory of a goldfish, no longer having to check the same plugin's help section for the eighth time today to be reminded of the plugin command)
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,587
Reaction score
656
First Language
Chinese
Primarily Uses
N/A
I work a lot with plugin commands to custom tailor cut-scenes and not having fast command lines is going to pull me out of the workflow every single time, getting me bogged down in scrolling and clicking rather than the 1 second it takes me to input a plugin command that I've designed to be easy to use and easy to memorize.
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) -
JavaScript:
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
2. Further upgraded plugin command with plugin/plugin command name search/type(you said it's unlikely)
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)
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)
5. The existence of the MV plugin command counterpart in MZ(it's assumed to be not the case for now)

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 :D

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 :p
 
Last edited:

mlogan

Global Moderators
Global Mod
Joined
Mar 18, 2012
Messages
14,875
Reaction score
8,235
First Language
English
Primarily Uses
RMMV
I feel like her name should be Wendy. She looks like a Wendy.
I’m going to propose a name that starts with M or Z, since the RTP names spell out RPG Maker.

So does this gradient stuff mean I can have the hair color I want now?
Up till now, I'd get irritated that the shade of red i wanted was missing.
So now I can make the colors I want for character parts?
I'd like to see more on this actually.
You could change gradients in MV, you just had to overwrite a gradient. There is somewhere in MV resources a more realistic hair color gradient file someone created years ago.
 
Status
Not open for further replies.

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

Latest Threads

Latest Profile Posts

When you realize @Kupotepo is a champion among RM Web users, and it all makes sense now:
Worst nightmare this morning, tried to get 20 minutes of work done on my project before heading to work and got hit with a POWER SURGE. Restarted my computer and the project was CORRUPTED, luckily I made a back up a few days ago so I only lost 4 days of work but still
Ami
what the other name of Elixir?

many games are use that,i want name it different.
What does your project folder look like?
I was told that an iPhone can provide a personal internet hotspot...You learn something new everyday!

Forum statistics

Threads
100,458
Messages
976,185
Members
132,082
Latest member
nwr
Top