BIG MAPS

[DerVVulfman]

AN ADAPTIVE BUMP!

to version 1.4

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.

[DerVVulfman]

ANOTHER

ADAPTIVE BUMP!

to version 1.5

Well, I have another update related to Zeriab's Anti-Lag system, one that is pretty crucial.  This one fixes an issue where Zeriab's system places sprites within the map before Big Maps creates its compiled array of events from all the maps.

 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 effect could be considered 'static sprite cloning'.   If a 'Hilda' sprite was in a big map and was supposed to be walking back and forth, you would see a very active witch in blue going left to right on the map.  But you would also see a blue-robed witch standing still where Hilda was originally drawn, the static clone.

 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!

So this new Adaptive update adds a new map condition, one to determine when the map begins to load if it is a Big Map or not, and turns itself off when it is either NOT a big map or the map is finally done setting up.

And it attaches some code to Zeriab's AntiLag to stop it from drawing the sprites ... IF it is a big map and isn't ready with all the events.

Oh, don't worry if you're not using Zeriab's AntiLag.  I added conditions so it only tries to add the code to Zeriab's work if it is detected.  Otherwise... you're good to go.

[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.

[Mel]

Hmm the newest version is giving me this error

[DerVVulfman]

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).

[Mel]

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

[DerVVulfman]

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...

Code:

   for event in @events.values
     # Adaptation for Zeriab's Anti-Lag
     if Game_Event.method_defined? :check_update
       event.check_update(true)
     end
   end

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.....

Code:

  # Rewrite of method in Zeriab's Anti-Lag
  if Game_Event.method_defined? :check_update
    #------------------------------------------------------------------------
    # * Checks how the event should be updated.
    #------------------------------------------------------------------------
    def check_update(big_map = false)
      name = @event.name
      # Checks if the event is never to be updated. (For decoration)
      for pattern in NEVER_UPDATE_NAME_PATTERNS
        if (pattern.is_a?(String) and name.include?(pattern)) ||
        (pattern.is_a?(Regexp) and !(pattern =~ name).nil?)
          self.never_update = true
        end
      end

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:  

Code:

def check_update(big_map = false)

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:

Code:

def check_update(big_map=false)

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:

Code:

def setup(*args)
    # Makes an event map as a hash
    @event_map = {}
    # Original Setup
    zeriab_antilag_gmmap_setup(*args)
    # Go through each event
    for event in @events.values
      # Check how the event should be updated
      event.check_update(false)
    end
  end

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.

[Mel]

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:

Code:

#--------------------------------------------------------------------------
# * Checks how the event should be updated.
#--------------------------------------------------------------------------
 def check_update(big_map = false)
   name = @event.name

[DerVVulfman]

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.

[Mel]

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.