BIG MAPS

[DerVVulfman]

ONE MORE
ADAPTIVE BUMP
FOR GOOD MEASURE
to version 1.6.

This is yet one more adaptive bump in relation to Zeriab's Anti-Lag system.  Now, Zeriab set up a means to let the game developer make a list of events that either 'always' or 'never update.  And to identify any event, you need both the map and event ID.  But this feature didn't respond with Big Maps since it compiled all the events from every map and resequenced (or sorted) them. In other words, the dang list wouldn't WORK with Big Maps!

So I had to design a system that would easily convert a 'Big Map' event's ID into the original Map and Event ID which Zeriab's system would use, altering his original method so the change would only be in effect for a 'Big Map' map.

Oh, do not worry.  Like before, I took pains to make sure it wouldn't hamper anyone not using Zeriab's system.

*    *    *

Meanwhile, I made two handy little methods you can use:

$game_map.old_big_event
    This gets the original Map and Event ID based on the Big Map's event ID.  So if you have something that checks the event's ID, you can get the originals (as an array) like so:
[old_map_id, old_event_id] = $game_map.old_big_event(new_event_id)

$game_map.new_big_event
    This generates the new BigMap event ID if you already know the original  Map and Event ID for an event.  So if you have the need for the new event and know the map and event ID values, , you can get the new event ID like so:
new_event_id = $game_map.old_big_event(old_map_id, old_event_id)

*    *    *

Lastly, since the original Zeriab script gave Melana issues, I used the suggested 'pattern' syntax that kyonides provided within the Big Maps and Anti-Lag thread in its place.