Additional Event Conditions - Scripting as a choice

[Castspeller]

I know @Archeia has posted that there would be no more Page Conditions but I would hope that this suggestion gets considered and thought out thoroughly.

What I purpose is to add one additional Page Conditions, this would be a checkbox with a text box for Javascript that must return either True or False.

This would be good for many reasons, among them it gives the developer the control they have been asking for without the addition of more conditionals, except the Javascript one I purpose.

This scripting could be used in many scenarios, for example:

• what if I want an Event Page to show if a Variable is less than 10 and Variable2 is exactly "abc". Both these thing individually you cannot do, let alone together
• The Conditions for an Event only take into consideration numbers, true and false, never strings
• It does not allow for a range like Variable 1 less than 100 and Variable 1 greater than 10

I can see a lot of potential and I hope the developers do too.

Cheers

NOTE: This is x-posted in the moderated RPG Maker MZ Feedback - I have had a suggestion disappear with any explanation or for the community to see
Per @caethyril, I hear there's a glitch where posts sometimes disappear from view if queued for long enough.

 

[Starbird_Resources]

This would be extremely powerful and convenient. Would love to have that functionality available.

 

[GmOcean]

As @Starbird_Resources said, this is definitely powerful and convenient. You can definitely 'simulate' this right now by just using an IF(statement) to encode everything for that event, but I'd much rather have each page utilize the JS check from the get go, for pure QoL.

 

[caethyril]

Remember that pages are checked from high to low. For a "variable < X" condition, you can use two pages:

• Page 1: no conditions
• Page 2: variable >= X

Page 1 will be active when the variable is less than X. With more pages, this can be extended for ranges like 5 < var < 10.

You're correct that text/string checks etc can't be done directly. One common workaround for more complex conditions is to have a Parallel common event that runs every few frames and toggles switches on/off using Conditional Branches. These switches can then be used as page conditions as necessary.

---

As noted, "More Page Conditions" is currently a rejected feature:

Rejected Features

Introduction The purpose of this thread is to avoid duplicate threads that request the same feature. These are features that the community have recommended and had been rejected due to design decisions by the lead developer. Event Functions More Self Switches Self Variables More Page...

forums.rpgmakerweb.com

As far as I'm aware, this is primarily for performance reasons. The existing page conditions are checked only when necessary, e.g. when a switch is toggled or the party gains an item. A generic script check would require the evaluation of the entered script every frame, which could become noticeable if used on many events.

Remember that scripted page conditions can be added by plugins, e.g.

Custom Page Conditions - Eventing your own page conditions

Having trouble with event conditions? Are the default conditions not enough? If you look at the page conditions, you get - up to two switches - a variable (and must be greater or equal to a certain value) - a self switch - an item (in the party's inventory) - an actor (currently in the party)...

forums.rpgmakerweb.com

I think one of the VisuStella plugins also offers scripted-value variables, which can be used in a similar way.

---

Re the feedback board stuff: I hear there's a glitch where posts sometimes disappear from view if queued for long enough. I can still see your suggestion in the approval queue, will try to get around to it sometime soon.

 

[Castspeller]

@caethyril - I understand adding multiple Conditions could impact performance but I do not believe that this would.

Respectfully, the rest of response are work-a-rounds, some of them as you say complicated, especially for newer users and some veterans. This would be an OOTB(Out of the Box) feature without having to potentially use Plugins. *rant* I think the developers rely too much on the Plugin approach to make up for common functionality */rant*

It should also be noted that there is the ability to use Javascript in the Contents, this would be an extension of that.

I have always thought of all the RPG Maker programs was ease of use, this is ease of use.

@caethyril - after posting that new suggestion it DID show back up, thank you for the explanation I am editing my original post to reflect your explanation.

 

[ATT_Turan]

I understand adding multiple Conditions could impact performance but I do not believe that this would.

Well, the point there was not multiple conditions, but multiple events:

As far as I'm aware, this is primarily for performance reasons. The existing page conditions are checked only when necessary, e.g. when a switch is toggled or the party gains an item. A generic script check would require the evaluation of the entered script every frame, which could become noticeable if used on many events.

Basically, your proposal of a script Condition would turn that event page into a parallel process. So you could already achieve this by doing:
- Event page 3 has a condition of whatever...we'll say a self-switch
- Event page 2 is a parallel process. It consists of:

Conditional -> Script (your script condition)
    turn on the self-switch

(and obviously the page numbers are immaterial, I'm just presuming you have a page 1 that does something)

Will you consider this a workaround? Probably But I can understand why the developers wouldn't want to implement the script condition, as it erodes the distinction between parallel processes and the other event triggers.

This way, you can achieve the same results out of the box, but you have to do it intentionally so you're aware of what you're putting into your game that could affect performance. And it's really pretty easy.

 

[Castspeller]

Well, the point there was not multiple conditions, but multiple events:

I am talking about potential multiple conditions on a single event, not having multiple events/plugins to achieve this single, simple goal. Your suggestion is yet another work-a-rounds when there should not need to be one.

From my own experience, down the road when reviewing work-a-rounds with/without plugins and/or multiple events Christmas tree'd together to achieve a goal it makes it harder to review/debug why something is or that is failing, and that takes time that is not needed.

Also, where plugins are concerned, people are now obfusistacting their JavaScript and it makes it that much harder to debug - even if you have purchased their script(s). That is their choice and I respect that. That is why, unless I must, I try not use other people's plugins. If I do use another's plugin, then I understand all of the code contained inside, or at least can follow it However, if it is obfusticated I automatically reject using it and will not consider using it.

 

[Jragyn]

I understand adding multiple Conditions could impact performance but I do not believe that this would.

I'm just going to say that folks must underestimate the power of how much can be processed in javascript before you start to feel the pain of javascript performance.

My JABS plugin (see signature if unfamiliar), which performs countless additional processes and various conditional checks every frame, still spends most all of its time above 55fps (of 60).

With that in mind, I can with pretty high confidence state that it is not a matter of performance, it is a matter of the MZ devs getting around to it.

 

[TheoAllen]

My JABS plugin (see signature if unfamiliar), which performs countless additional processes and various conditional checks every frame, still spends most all of its time above 55fps (of 60).

How many conditions? What is the complexity? Was it an eval function? or a regular function call? How many instances does it check?

This scripting could be used in many scenarios, for example:

• what if I want an Event Page to show if a Variable is less than 10 and Variable2 is exactly "abc". Both these thing individually you cannot do, let alone together
• The Conditions for an Event only take into consideration numbers, true and false, never strings
• It does not allow for a range like Variable 1 less than 100 and Variable 1 greater than 10

I can see a lot of potential and I hope the developers do too.

Oh also, since you can put scripting conditions, of course, you can also flip the page when the second in your clock is divisible by two. So the page would flip once per second. How can you achieve that? check it every frame of course!

Oh, why not make the page flipped every frame, so it changes 60 times per second? You can do that in page condition by eval script function and make the total frame count divisible by two, of course, you can!

I am talking about potential multiple conditions on a single event.

You are assuming a single event. Maybe, because you only need it for a single event as for now. But have you thought of someone who would abuse it and ended up hurting their game?

An idea to put them in the parallel common event as a workaround means to remind you "what you're doing", that you're adding a burden to the game update loop. What if it is actually being implemented, then for some reason, the user put one single expensive function call or something that softlock the game then blame the RPG Maker dev for that.

The dev doesn't want to take the blame for a potential performance impact by putting script conditions. If it was the plugin, at least they are not responsible for that.

Don't get me wrong, I don't hate the idea.
I'm actually curious if someone could come up with a better idea.

Take Hime's code, for example, they have a "custom page condition". Sounds too good to be true. But when I investigated it, Hime did put a lot of additional checks everywhere. They put refresh all events when

• Actor's stat has changed
• Party's inventory has changed
• Gold has changed
• Class changed
• The actor's name has changed

To avoid checking every frame. I'm not sure if Hime's plugin can be used to "flip page every frame" using page condition eval script alone.

TLDR:
Is it hard to understand the concept of "refresh when necessary"?

 

[Castspeller]

You are assuming a single event. Maybe, because you only need it for a single event as for now. But have you thought of someone who would abuse it and ended up hurting their game?

For simplicity sake I have said a single event but it could be used more. Respectfully, I completely disagree with "hurting their game". With that logic then there should not be plugins that could potentially run amok. The same thing can be said about using the existing functionality of using a parallel script and adding a JS script to the Contents to do the scenario you describe and you're right it comes back to the person who developed the JavaScript.

The dev doesn't want to take the blame for a potential performance impact by putting script conditions. If it was the plugin, at least they are not responsible for that.

I do not like the idea of passing the buck, to anyone. If there is a performance issue with their code then let the developer take it to the forums, that is why there is a JS forum.

Again, there is the talk of plugins. This is a simple function that should not require the use of any plugin(s).

Don't get me wrong, I don't hate the idea.
I'm actually curious if someone could come up with a better idea.

I definitely would like to hear other opinions, but there are other points in the game where JavaScript can be injected. I think that wherever there is a "Condition Builder", like in troops, there should also be a selection for JavaScript that I am describing. This alone adds a lot power. Can that power be abused, of course it can, but so can plugins or any code that a user writes.

 

[TheoAllen]

With that logic then there should not be plugins that could potentially run amok.

Oh, I completely agree with this. Especially if the plugin is paid.
Free plugins have it easy since they don't have many obligations to listen to you.

The same thing can be said about using the existing functionality of using a parallel script and adding a JS script to the Contents to do the scenario you describe and you're right it comes back to the person who developed the JavaScript.

But can you put a customized frame delay for each check if it isn't by customizing it in the parallel common event manually, maybe check only happens per 5 frames? or maybe 60 frames? Or if you want to turn it off at all? Do you know what I mean by "frame delay" at all?

I do not like the idea of passing the buck, to anyone. If there is a performance issue with their code then let the developer take it to the forums, that is why there is a JS forum.

But what if they do not bother and pass the rumor that the engine sucks (because it is mistaken as a bug and doesn't bother introspecting that it might be their fault) then leave negative reviews on it?

This is a simple function

This is nowhere near simple. Please address the issue I brought up. And many others have (ATT_Turan and Caethryl).

Can that power be abused, of course it can, but so can plugins or any code that a user writes.

In that case, we can keep this in the plugin territory.

EDIT:
I've discussed this matter with Wavelength in the old RMMZ hype thread

• Here
• His reply here
• My continued reply here
• And his final reply here

He at least provided a good discussion for this.

 

[GmOcean]

EDIT:
I've discussed this matter with Wavelength in the old RMMZ hype thread

• Here
• His reply here
• My continued reply here
• And his final reply here

He at least provided a good discussion for this.

Having read those, what would your take be on having access to just && == or || == operators?
For instance the scope wouldn't be as wide as you could ever do with JS code, but you'd be able to check for Switch X && Switch Y. Or even, Variable X == Y || Variable Z == Y. Right now those would require different pages for the event, and are checked in descending(?) order based on page number.

Wouldn't 1 page having those conditions use up the same resources as multiple pages each doing their own check?

I mainly only see the reason this would be wanted is for Event Page realestate. Having to use multiple pages to do complex eval checks when you're limited to 20, seems pretty expensive in that regard. Though to be honest, I can't think of a situation where an event would be 20 pages, and each page requiring a complex condition.

All in all, I'd settle for just additional basic operators, like == or <= rather than just >=

 

[Bex]

No need for a Scriptline Field in the Eventpage Conditions on my End.

1 Parallel Event for checking several conditions for the Game and depending on that
Activate/Deactivate Eventpages is how its done and that is a good structure.

Can you give a few examples of what kind of Conditions you would write into that Scriptline?
Just curious.

 

[TheoAllen]

@GmOcean I'm sold to the idea, honestly. I even made a plugin that did exactly the same. This is why I'm actually not against the idea. Just not as broad as "script call everything".

 

[Archeia]

For more page conditions like Variable control, we had a megathread discussing it with the entire community and the head developer, Ojima-san, rejected every proposal. It's just not gonna happen unless you can give proof why this feature is absolutely necessary that can't be done either way. Performance is just one factor of implementing a feature. Don't forget that stability is another reason a feature will be rejected. The more features there are, the longer it takes to beta test and the more prone it is to bugs.

And, before this is brought up again, we already tried implementing script condition to events. It does not work. If you know how the event handler works you'll see why it wouldn't.

The script condition will only work if an event is on player touch and event touch. If you set it to action, autorun or parallel it will not work. The game map only checks for event conditions "onRefresh" which only occurs on item gain, party member gain, actor gain, switch and variable change. The more events you have, the worst it gets performance wise as well.

I looked into it like, June 2018 and we concluded it's not a good feature to have. I don't remember the full details since it's been years but after extensive testing, that was the one that stood out the most.

 

[Castspeller]

@Archeia - Thank you for the explanation, I understand now why that would not work.

It might be a good idea to have a document, like on Google, on the features purposed and the reason they were rejected because trying to research before submitting suggestion is challenging - too much signal to noise.

@caethyril - Please close and lock this thread.

 

[caethyril]

Closing this thread at the original poster's request.

For future reference, the usual way to ask a mod to close your thread is to report your own post, rather than tag a specific moderator. All mods see the report queue, which allows a faster response.