Djigital Aura

[DerVVulfman]

I applaud you for the attempt. And I appreciate that the name for the switch is in keeping with the naming structure.

An easier way to look at the two methods would simply be:

Code:

#--------------------------------------------------------------------------
  # * Aura System Mode One : Single keypress that draws the aura for X frames
  #--------------------------------------------------------------------------
  def aura_mode_one
    # Disable the system if the switch isn't activated
    return if $game_switches[Aura::AURA_SWITCH] == true
    # Do test if key triggered
    aura_test if Input.trigger?(Aura::AURA_KEY)
    # Update timer
    aura_delay_update
  end
  #--------------------------------------------------------------------------
  # * Aura System Mode Two : Constatn keypress the shows aura until released
  #--------------------------------------------------------------------------
  def aura_mode_two
    # Disable the system if the switch isn't activated
    return if $game_switches[Aura::AURA_SWITCH] == true
    # Player cannot be moving
    return aura_cancel if $game_player.moving?
    # Obtain keypress as local variable (works better as set variable)
    test = aura_toggle_key
    # If the current aura_key state doesn't match the keypress, we toggled
    if @current != test
      # Turn on or off the effect based on the new toggle state
      (test == true) ? aura_test : aura_cancel
      # And reset the toggle aura key toggle state
      @current = test
    end
  end

By using the

Code:

return if  blah blah blah...

means that the method is never run if the switch is turned off. You won't be able to press the trigger or anything.

Oh, and the 'aura_cancel' method runs through all the events in the area over and over and over... which causes lag. I only use it when the effect is being turned off, so it is reduced. Your version would have it run constantly. Better to have the system disabled and exit than having it run the cancel method instead.

[RASHIDA12]

I've tried your edited version but I keep getting lags.
Its a bit better now but only a little - it also has very slow performance. Like up 10 FPS while I normally have 40 FPS constantly.
It only happens if AURA_MODE is true 
if AURA_MODE is false, everything seems like normal.

The reason why I used aura_cancel is because of a bug.
When I hold the aura button and the aura_switch is set on at the same time, the aura is still seen until the switch is switched again which I didint want.
That bug happens with the code above.
EDIT:
I've tested your original aura script:
The lag issue only happens when  AURA_MODE    is set to  = true  
When AURA_MODE     = false everythign runs normal.
Is there anyway to fix it? I dont thing players want to play with solid 5 FPS. 



BTW: what do you say about changing the aura_cancel method into the same method used in mode one.
I mean changing aura_cancel to aura_delay_update.
Would it cause troubles?
EXAMPLE:

#--------------------------------------------------------------------------

  # * Aura System Mode Two : Constatn keypress the shows aura until released
  #--------------------------------------------------------------------------
  def aura_mode_two
    if $game_switches[Aura::AURA_SWITCH] == true then
      # Player cannot be moving
      return aura_delay_update if $game_player.moving?
      # Obtain keypress as local variable (works better as set variable)
      test = aura_toggle_key
      # If the current aura_key state doesn't match the keypress, we toggled
      if @current != test
        # Turn on or off the effect based on the new toggle state
        (test == true) ? aura_test : aura_delay_update
        # And reset the toggle aura key toggle state
        @current = test
      end
    end
  end

[DerVVulfman]

Within a confined 40x30 map, I have over 350 events being tested. Even without an anti-lag script, my 'average' good speed is around 30-35FPS. Granted, it begins the map with a mere 20FPS when everything is loading. But that's pretty good given that the map is having to update hundreds of events regularly. This does not change whether or not I even have Djigital Aura loaded. But the issue is regarding the active use of Mode2 with an extreme number of events.

The problem you have for lag is twofold:

One is that the 'True/Mode2' option requires that the system checks events on a regular basis. It attempts to only test and retest events within the screen area. But using Mode2 will cause lag for the very reason that it must test all events within the visible area. It is unavoidable.

Two is that the number of map events you have is a bit ... intensive. I admit that having up to 999 events on a map is possible. I have done it myself and a replacement for RPGMaker XP which I am working on can handle that many without difficulty. However, having that many events on the map will require you to have an Anti-Lag script. It is true that I ran 350+ events testing. But you won't see that many events in a single 20x15 tile area.

Grab an anti-lag script when you have that many events, else you will get lag. And while I did code the system for both Mode1 and Mode2, Mode1 is likely easier on the framerate.

And no, changing aura_cancel into aura_delay_update is no good. The aura_cancel method goes through all events in the map and forces the aura to be turned off. Given that you have 300+ events, that is a lot of events to turn off at a time. So it is ill advised to run it constantly. The slow down would be enormous. As to why you shouldn't use aura_delay_update for mode2 is simple. It is not meant for mode2 as it is the countdown timer used by Mode1. It doesn't erase the events, but just changes their countdown until its countdown reaches 0. It doesn't erase any aura but is used to see (when mode1 is on) IF it is time to erase em.

In any event, go and find a good anti-lag script. I did enough changes to Near Fantastica's original code used in THIS script that his own Anti-Lag shouldn't interfere.