What's up, RMers?

[DerVVulfman]

Performed some minor updates to my working Anti-Lag, though I had encountered the ever loving "Step-Forward / Step-Backwards" scenario.

Trying to perform some cleaning and streamlining, my antilag went from a 38 FPS down to a 35fps rate.  While it visibly didn't affect the motion or reaction within the game map, it was still greatly unacceptable. But the thing is, the cause was rather strange.

My initial work that held an average 37-38 frame rate with 998 tiles used the following code to ensure that  Auto-Run and Parallel Process events were exempt:

    return true if obj.trigger == 3            # Permit for autorun
    return true if obj.trigger == 4            # Permit for parallel

However, I attempted the following in its place:

    return true if [3,4].include?(obj.trigger) # Permit for triggers

Who would think that one command using the include? method in the Array class would cause more lag? But it does as it comically takes more processing time than two simple if...end blocks.

It does.

Be that as it may, and some more cleaning up, I added a simple little test command.  

While you might not think it may happen, I would not put it past anyone to accidentally flag an event "ALWAYS" update even when not in the player's view and "NEVER" update which would effectively turn an event into a glorified tile.  That would be an issue indeed.

So I added a single method that will, upon entering any field map, check to see if any events contain both flags and generate a pop-up display indicating the IDs of the so offending events.

---

My current config setup for the script.  

module AntiLag

  # VIEWPORT TILES
  # ==============
  # Understanding that an additional Resolution Script may be used to change
  # the game window's size, it's here where you set the size of the player's
  # viewport in tiles both width and height.
  #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  TILES_HORIZONTAL = 20
  TILES_VERTICAL   = 15

  # VIEWPORT BUFFER
  # ==============+
  # Because the player is moving across the map,  it should be accepted that
  # events should be  active and functioning  before they are visible in the
  # player's viewport.  It is here that you set how far outside the viewport
  # in tiles where event activities are permitted.
  #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  BUFFER_SIZE = 2

  # DISABLE SWITCH ID
  # ==============+==
  # This determines the RPGMaker XP Switch  that lets you enable/disable the
  # anti-lag system with a simple [Control Switches] event command.
  #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  DISABLE_ID = 4

  # EVENTS ALWAYS ACTIVE
  # ==============+=====
  # This establishes a custom tag  that can be placed within an event's name
  # allowing it to update even if off-screen. OR set to nil if there's none.
  #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  EVENTS_ALWAYS = nil #"[Alw]"

  # EVENTS NEVER ACTIVE
  # ==============+====
  # This establishes a custom tag  that can be placed within an event's name
  # preventing from ever updating.. OR set to nil if there's none.
  #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  EVENTS_NEVER = nil #"[Nev]"

  # EVENTS CONFLICT TEST
  # ==============+=====
  # Essentially, this will bring up a pop-up window upon entering a map when
  # any events contain BOTH  the "Events Always' and 'Events Never' which is
  # an obvious accidental error. It will report both the map ID and name for
  # reference and a list of all event IDs that have this issue.
  #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  EVENT_TEST = true

end

Have you seen anything more self-explanatory and understandable? 

Don't answer that. 

---

And I'm contemplating two things for development

1. Event command calls to add or remove the "EVENTS_ALWAYS" / "EVENTS_NEVER" flag while running, though it would likely reset each time you enter the map.
   
2. The ability to read flag-applying comments from the Event's "List of Event Commands" page, which would allow different flag conditions per page. Though an additional script call would be needed to ensure any such event with such would be able to update.
   

Yep, I try to consider eventualities.