Yeah, people using Zeriab's Anti-Lag will love this one!  Yeah, talkin' about ya, you dreamer you.

Zeriab's anti-lag checks if an event has a tag in its name, something akin to [N] or [A] if the user of Zeriab's system left the options untouched.  These tags indicate if an event never updates or always updates.

Well the option which Zeriab put into the system which tested for these tags was ignored by BigMaps.  When it compiled all of the events from every map, it did so 'after' Zeriab's check system was encountered, and nullified the test.

This meant that any Event that was set to never update, still updated if the event is in a BIG MAP. But this was looked into... insofar as setting the [A] and [N] tags directly into the event's names anyway...

So now, this newest version of BIG MAPS will now auto-detect Zeriab's Anti-Lag, and will access and run Zeriab's test if it exists in your project.

 Wait.  What?  What do you mean????

 When the system runs, both Big Maps and Zeriab's Anti-Lag run their own setup code.

    Zeriab's code quickly and cleanly grabs all of the events and compiles them into a nifty event_map array and then draws them on the Spriteset... the field map that you see. So you have a map and a bunch of events already set up for display.

 But right after Zeriab's setup code, Big Map's setup code then runs, compiling the events from every map that is part of the so-called 'big map' into a new 'events' array and starts fresh.  After that, it then works on putting all its events in the same Spriteset / field map.

 There in lay the dilemma.   Zeriab's code draws sprites from the very first map in the list before Big Maps can get to compiling all the sprites.  When Big Maps takes over, all the Zeriab sprites are already drawn. However, Big Maps also eliminates the old events array... detaching the Zeriab sprites from their events.  The old sprite graphics remain pasted in the field map right before the Big Maps sprites appear.


 This only happened with the first map of the Big Maps array.  Even if I were to teleport to the right-most map in a grid, only the top-left most one was affected.  Weird, but Big Maps compiles maps left/right top/down.

  Yeah, Zeriab's system to draw the sprites... good!   Drawing them before Big Maps finishes compiling all the sprites... bad!

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.

Hmm the newest version is giving me this error

Placement is key. Within the KNOWN / TESTED WITH THE FOLLOWING section, I note that it works with Zeriab's Anti-Lag. But that Zeriab's Anti-Lag needs to be above BigMaps.

You see, BigMaps actively changes one of Zeriab's functions, the check_events method you are having issues. It was necessary to pass into it whether the check_events system was going to acquire normal map/event_id combinations for the SPECIAL_UPDATE_IDS test, or whether it needed to find the original map/event_id from a newly created BigMap event.

So BigMaps needs to be below Zeriab's system.

OR you can rip the code from Big Maps and paste my edited rendition of check_events into Zeriab's code (not recommended).

I placed Zeriabs script above Bigmaps but it only works when I erase the (true) in line 471 of the Bigmaps script.

(06-10-2020, 07:17 PM)Melana Wrote: I placed Zeriabs script above Bigmaps but it only works when I erase the (true) in line 471 of the Bigmaps script.

This is extremely weird and should not occur for a couple of reasons...

This bit of code appears within BigMaps's  bigmaps_gm_generate method... and formerly working within the bigmaps_gm_generate_events_setup method, but commented out for better placement so to handle the list so described..

As you can see, the statement of event.check_update(true) includes a 'true' parameter.  This means it passes control to the check_update method and is notifying it that the command is supposed to respond for Big Maps.

STILL... it shouldn't matter.....


This is just the beginning of the rewritten check_update method.

FIRST, as you can see, it only works if the original 'check_update' method by Zeriab is even detected.  This by the use of the method_defined? statement.  Neat, eh?


But here's the magic:  

The part that says big_map = false .... this is a default setting.  If no value is passed, this method assumes that the big_map value is false, and assumes that it is being used by a normal map.  This technique is basically classic and I've used it for over a decade.


 I checked this and it works with RMXP, and should work with HiddenChest   The only thing I can think of then is to eliminate the spaces within this parameter so it reads:


The only other option I can think of would be to actually change the call to the check_update method within Zeriab's Game_Map setup method like so:
Still, this shouldn't even be necessary because the change which I added assumes a 'false' setting by default.


But if you do not have this enabled, you will not have the ability to use the SPECIAL_UPDATE_IDS entries.

I tested it in standard RMXP and it worked there for me aswell.
But it still doesn't work in HiddenChest.

Now I tried to add the "(big_map = false)" to the check_events method in Zeriabs script aswell and the game doesn't crash anymore.

It looks like this now:

That is extremely strange, Melana. That makes it sound as HiddenChest prevented my version of the check_update method from overwriting Zeriab's own.

Perhaps it might be a good idea to copy 'all' of my check_update method and paste it in place of Zeriab's. Afterall, this takes care of the 'always / never' tags that get added to the events. And without this alteration, big maps won't have that option.

HiddenChest can cause some weird issues which never appear in normal RMXP. But it's worth it. :)
I will combine the methods now and then everything should work as intended. Hopefully.