Script condition for event page activation

[Poryg]

Description of the Feature:
Just as the thread suggests. I'm still surprised it actually hasn't been implemented yet, since conditional branch has it. And I don't think I'm the only one who would appreciate this.
The thing is, as it is now, if we want to activate an event based on some weird condition, for example if the party leader is dead, we need a workaround for it, for example a parallel process event that tracks if the hero is dead and turns a switch on or off accodingly.
Having a Script condition would simplify that a lot.

Code for Implementation:
in the rpg_objects:

Game_Event.prototype.meetsConditions = function(page) {
    var c = page.conditions;
    if (c.switch1Valid) {
        if (!$gameSwitches.value(c.switch1Id)) {
            return false;
        }
    }
    if (c.switch2Valid) {
        if (!$gameSwitches.value(c.switch2Id)) {
            return false;
        }
    }
    if (c.variableValid) {
        if ($gameVariables.value(c.variableId) < c.variableValue) {
            return false;
        }
    }
    if (c.selfSwitchValid) {
        var key = [this._mapId, this._eventId, c.selfSwitchCh];
        if ($gameSelfSwitches.value(key) !== true) {
            return false;
        }
    }
    if (c.itemValid) {
        var item = $dataItems[c.itemId];
        if (!$gameParty.hasItem(item)) {
            return false;
        }
    }
    if (c.actorValid) {
        var actor = $gameActors.actor(c.actorId);
        if (!$gameParty.members().contains(actor)) {
            return false;
        }
    }
  if (c.scriptValid) {
       if (!eval (c.scriptValue)) {
          return false;
      }
  }
    return true;

Mockups:

I made the script window too small, but whatever, the principle is the same.
Why is this feature good?
This feature is great because of the following:

• Puppies will be happy (and me too )
• User friendliness
• It is easy to implement
• Adds versatility to eventing and improves performance, because it won't require 3rd party plugins or other workarounds that waste precious processing power

Possible issues with this feature?
Issues that might arise from this feature:

• Some 3rd party plugins that use custom conditions might become a bit redundant
• The page editor space might be cramped

 

[Llareian]

Yes, please! As Poryg noted, this would cut down on the need for parallel process events to check complex conditions, which would improve game performance.

I also see this feature as improving the editor's compatibility with 3rd party plugins, since it removes the need for some sort of event page comment reader inside the plugin to switch event pages (which I've only seen once or twice). Instead you can just input conditions from the plugin code directly into the script box. So overall that means the engine is more easily extended and modified!

 

[gstv87]

this would cut down on the need for parallel process events to check complex conditions, which would improve game performance.

Script command inside move route, enabling self-switch.




What! It's what I came up with, on the fly! XD

 

[Shaz]

This has already been suggested, but I don't know that it can be achieved. Right now, there are certain things that can happen that will cause every event to be checked for a new active page. Those things are members joining/leaving the party, switches being on/off, variables being changed, items being received, self switches being changed. In all of the functions that handle those things, a flag is turned on saying there's been a change, so the map needs to be refreshed, which causes all events to be checked. So the process of looping through all pages of all events to make the correct page active only ever happens when one of the things above occurs - ie, not very often, when considering 60 updates per second.

If you add a script as a condition, that means ANYTHING could cause the page to refresh. There is no way to anticipate what you might put into that script, so the flag to refresh the map can't be set at specific points/actions. This means the map would continually have to check, on every frame, to see if any of the scripts evaluate to true, because it's possible that on every frame, something could have been changed that will make that script return a different result.

Lag central.

If you script, I suggest you try and do this yourself using comments (that's what was done in Ace to add extra page conditions), and make it continually check to see if the page has become active due to the script/comment. That will give you an idea of the difficulties surrounding such a request.

Don't get me wrong - I'd love to be able to do this too, but the problem is with leaving it so open-ended that ANY script call could be used.

 

[Poryg]

Makes sense. Didn't think of that.
I thought about a solution, but in the end that is no better than the current state, because it involves the update function... Thank you for clarification

 

[Kuro DCupu]

FINALLY! Years ago I was hoping for that too, but it's more like this (just for personal taste)...


Think of the possibility! So powerful, it's like limiter release or somekind!
Back then, I though "it's just a little change, so what could go wrong?" but as I learn my stuff, like what Uncle Ben said "powerful stuff blablabla responsible stuff" now I see why that is not an option.

So I guess in practical use, checking condition via roundabout parallel process way is still better then?

 

[Poryg]

Yes. A parallel process is better, because it's one parallel process event, while in case of the script box you'd need to refresh every event quite often to see if something has changed. Which hurts performance instead of helping it, especially when there are for example 100 cosmetic events on the map.

As for the two switches, I like them, I use two switches as a condition quite a bit, so I wouldn't touch them.

 

[xDGameStudios]

Script can actually replace everything in the list, you can check for switches, variables, self switches, items and actors... and I would be okay with it... just a plain script box there. Much like the damage formula stuff... with a hint box describing the basic stuff.

For self switches use: self_switch[x]
For switches use: switch[x]
For variables use: variable[x] == y

Something in those terms.

 

[Poryg]

That wouldn't be easy enough for a child though.

 

[xDGameStudios]

That wouldn't be easy enough for a child though.

Good point... sometimes I wish there was a intermediate RPG Maker.... other engines are just too.. overwhelming... and not RPG directed.
(Like Unity and GMS2) Well I think the real deal here isn't even the engine itself... is the database creation... I wish the database was more flexible (custom attributes, custom traits (to be used with custom scripts), no caps...) I thought of building one myself... though having a base to start from would be really great... specially when it comes to graphics (wish the database would be opensource)

 

[Poryg]

MV allows for use of any 3rd party tools though, so you can technically develop the engine into your own.
https://forums.rpgmakerweb.com/index.php?threads/adding-your-own-tools-to-rpg-maker-mv.86920/