Script condition on event pages

[Schlangan]

Description of the Feature:

• In event pages conditions, getting a Script feature instead of/in addition to the second Switch option. Doing so would add more versatility to events and the ability to directly call plugin JS functions.

Code for Implementation:

Spoiler

A script variable to the page events should be added, and the meetsConditions function of Game_Event should be altered as well.

Game_Event.prototype.meetsConditions = function(page) {
    var c = page.conditions;
    if (c.switch1Valid) {
        if (!$gameSwitches.value(c.switch1Id)) {
            return false;
        }
    }
    if (c.script) {
        if (!eval(c.script)) {
            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;
        }
    }
    return true;
};

Mockups:


Why is this feature good?
This feature is great because of the following:

• Better conditions in events, including several variables/switches at once through && or || operators
• Ability to overcome the editor limits through a single textbox.

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

• If removal of one of the switch option, it would force users to use a script to have two switches. It is not really difficult, but I understand some users might not want to use scripts. Of course they would be welcome to ask on the forums how this works.

 

[Archeia]

I would honestly love this too. It seems like the best alternative if more event page conditions cannot be a thing.

 

[Shaz]

I just don't think it's do-able, as it would have significant performance implications.

Event pages currently have switches, self switches, variables, item-in-inventory and actor-in-party conditions. Therefore, every time a switch, self switch, variable, item or actor changes, it could trigger a different page of an event. Each time one of these things happens, a flag is turned on to tell the map to update all of its events on the next frame, and when that flag is on, every page of every event on the map is checked, until a page is found where the conditions are met. These things do not constantly change - they change at specific points, which could be a few seconds to several minutes apart, which means the events are being checked at reasonable intervals.

If you add a script call, because there are no limits to what that script call could be, it would be necessary for the map to cycle through all the events, and for the events to cycle through all their pages, on every single frame, just in case the script was false on the previous frame but now is true. That would cause the game to run very slowly.

Believe me, I'd love something more flexible to give a wider set of options for page conditions, but a script call carries too much baggage.

 

[Schlangan]

@Shaz : In that case, it would easy to store the value of the script evaluation in a temp variable and only require the graphics update after a given amount of frames. Hence a slowdown would be prevented. Also, if this possible issue is written in a tooltip or the help file, users would only have to be careful to not do too much.

Also on a side note, I'm already doing this through a parallel event that changes a switch to On or Off to reproduce the same things, I never had any performance loss.

 

[Shaz]

But you're only using one parallel event to change one switch. If it were introduced to event page conditions, it would get much, much more use.

If you define the kinds of scripts you're likely to run, you could add a script to turn the 'refresh' flag on when any of the underlying data (that's used by the script call) changes. But the devs would not be able to build that in to the engine, because they couldn't fathom the variety of uses something like this would have.

 

[Schlangan]

I'm not really convinced, since we only alter the meetsCondition function, which only get true or false as a result. Also, there are many ways to implement limitations, for example canceling the script effet if the time it takes to calculate exceeds a given amount of frames.

 

[Andar]

canceling the script effet if the time it takes to calculate exceeds a given amount of frames.

Please not that one.
You have to keep the effect on the user in mind, and having some script lines be cancelled that way will create a load of support questions "why does this script code don't work?"...
And the same goes for the other problems - as Archeia said this is theoretically a good idea and a lot of people would like to have something like this, but the developers always have to keep in mind how this might be used by people who don't know enough about programming to understand its limitations.

 

[Schlangan]

but the developers always have to keep in mind how this might be used by people who don't know enough about programming to understand its limitations.

Why not advanced options, not enabled by default, for people who know what they are doing then ? But it would require much more work. I need to check if with OSS we can implement ourselves things to test them.

 

[Shaz]

You're not only altering the meetsCondition function. You're altering when it gets called - how often. Currently whenever any of those things happen that I listed, the meetsCondition function gets called on every event on the current map, and on every page from the last one until it finds something. In the grand scheme of things (60 frames per second), it doesn't get called very often, because those things don't happen very many times per second, if at all. When those things happen, a flag is set to say the game map needs to be refreshed, which is what triggers the testing of all the event pages. Because you're now saying ANYTHING could activate a new event page, that function has to be called on every page until a valid one is found, on every event, on every frame. A flag cannot be used anymore because there is no restriction on what might be used as a page condition.

Here is a simple test you can do to see what would happen. Grab a typical map from your game - average size, average number of events. Go into the rpg_scene.js script and find the Game_Map.prototype.refreshIfNeeded function. Change it to look like this, because this is what will have to happen if you want to add a script call as an event condition:

Game_Map.prototype.refreshIfNeeded = function() {
  this._needsRefresh = true; // this line added, because we need to retest the event page conditions on every frame now
  if (this._needsRefresh) {
    this.refresh();
  }
};

See what the difference is on that map, with the extra line, and without it.

Given that a lot of people already complain about lagging, how is this going to affect it?

 

[Schlangan]

People always complain for everything, but unfortunately you are right. Since many users just don't know what they are doing (and this is normal, we all need to learn), my suggestion would be difficult to implement for everyone. Too bad, it would have been extremely more efficient using it (with condition-check through frame timing, hence avoiding lag).

Since the alternative of checking script through switches by parallel events exists, this functionality is already implemented albeit more subtile.

Hence we can close this topic, Shaz convinced me that it cannot work in the current state of RPG Maker.

 

[Archeia]

Understood