Parallel Process Events Execution Bug Fix.

Discussion in 'RGSS3 Scripts (RMVX Ace)' started by ♥SOURCE♥, Feb 10, 2015.

  1. ♥SOURCE♥

    ♥SOURCE♥ Too sexy for your party. Member

    Messages:
    693
    Likes Received:
    407
    Parallel Process Events Execution Bug Fix.
     

    There is a problem with the execution of Parallel Process events in RPG Maker VX Ace (at least at the time of writing). Unlike Autorun events, they are not executed every update cycle (frame) by default due to a misplaced line in Game_Interpreter. The execution of the Parallel Process events skips one frame after one successful execution, potentially causing serious synchronization problems for event based systems. 

     

    That behavior is completely unexpected and counterintuitive, and has the potential of making your game feel unresponsive to your players if you rely on Parallel Process events for any system that requires player input (like mini games).

     

    How to corroborate the problem?
     

    The easier way is to make a Parallel Process event report the game's frame count. To do that, simply create a Parallel Process event and add a Call Script command on it with the following:

     

    Code:
    p Graphics.frame_count
     

    Solistra was kind enough to provide a video showing the problem and comparing the execution with Autorun events (which works as expected):

     




     

    What causes the bug?

     

    Event "update" method setups the interpreter only if it is not "running":

     

    Code:
     def update   super   check_event_trigger_auto   return unless @interpreter   @interpreter.setup(@list, @event.id) unless @interpreter.running?   @interpreter.update end
     

    "running?" is defined as the following in Game_Interpreter:

    Code:
     def running?   @fiber != nil end
    and the "run" method for the interpreter is the following:

    Code:
     def run   wait_for_message   while @list[@index] do     execute_command     @index += 1   end   Fiber.yield   @fiber = nil end
     

    The problem is that the control is passed back to the caller before the "@fiber = nil" line is executed, so by the time of the next Event update cycle, the Interpreter is still "running" and won't setup again, making it skip one update cycle because when the Fiber gains back control, it will execute the pending "@fiber = nil" line, and the condition for the Interpreter update won't be met:

     

    Code:
     def update   @fiber.resume if @fiber end
    How to fix the problem?
     

    The solution is simple:

     

    Code:
    # Parallel Process Events Execution Bug Fix.# Version 1.0.0# 09/02/15 - DD/MM/YY# www.rpgmakersource.com# forums.rpgmakersource.comclass Game_Interpreter  # Overwrites default method with the fixed version.  def run    wait_for_message    while @list[@index] do      execute_command      @index += 1    end    @fiber = nil    Fiber.yield  endend
    Pasting the above code right below the default scripts, or anywhere below Game_Interpreter and above any custom script, will fix the problem.

     ​
    Terms of Use
     

    The code is free. You can use it in any commercial or non commercial game. Credits are appreciated but not necessary. Don't remove the original header.
     
    Last edited by a moderator: Feb 10, 2015
    #1
    GethN7, Kvothe, Dymdez and 5 others like this.
  2. AeghtyAteKees

    AeghtyAteKees Nyctopheliac Veteran

    Messages:
    30
    Likes Received:
    2
    The text in the code boxes is not parsed correctly, and cannot be used. (And I'm not adept enough to know how to parse it myself :( .)
     
    #2
  3. bgillisp

    bgillisp Global Moderators Global Mod

    Messages:
    10,646
    Likes Received:
    10,135
    Location:
    USA
    First Language:
    English
    Primarily Uses:
    RMVXA
    You may have to ask in script requests to get that fixed, as I haven't seen that person around in a really long time.
     
    #3
  4. Shaz

    Shaz Veteran Veteran

    Messages:
    36,634
    Likes Received:
    10,640
    Location:
    Australia
    First Language:
    English
    Primarily Uses:
    RMMV
    I have never heard of this problem before, and I would suggest you confirm that it IS the cause of your problem before using this, but here is the reformatted code from above:

    Code:
    # Parallel Process Events Execution Bug Fix.
    # Version 1.0.0
    # 09/02/15 - DD/MM/YY
    # www.rpgmakersource.com
    # forums.rpgmakersource.com
    
    class Game_Interpreter
    # Overwrites default method with the fixed version.
      def run
        wait_for_message
        while @list[@index] do
          execute_command
          @index += 1
        end
        @fiber = nil
        Fiber.yield
      end
    end
     
    #4
    MHRob likes this.
  5. Sixth

    Sixth Veteran Veteran

    Messages:
    2,070
    Likes Received:
    746
    First Language:
    Hungarian
    Primarily Uses:
    RMVXA
    I can confirm that this IS a problem happening in all VX Ace projects without exception, so installing this fix can only benefit Ace users.
    There are tons of problems without this fix, like Source mentioned in the OP.
     
    #5
    Archeia and Shaz like this.
  6. Shaz

    Shaz Veteran Veteran

    Messages:
    36,634
    Likes Received:
    10,640
    Location:
    Australia
    First Language:
    English
    Primarily Uses:
    RMMV
    I had never run into any problems with my project in Ace, but then most of my parallel process events were to initialize things on maps, followed by deleting themselves.
     
    #6
  7. TheoAllen

    TheoAllen Self-proclaimed jack of all trades Veteran

    Messages:
    3,605
    Likes Received:
    3,775
    Location:
    Riftverse
    First Language:
    Indonesian
    Primarily Uses:
    RMVXA
    Idk if I'm gonna get scolded for, well... necropost?
    But I'd love if it's also listed in RGSS3 bugfix (or pinned) since I had a hard time finding this script, and almost making a request of finding this (also too lazy to find what's wrong in Game_Interpreter). Found it after a constant search using different keywords

    I never thought I'd use parallel process for input handling, so in the past I never really bother to use it. But now, I do. Now it's actually not a game breaking bug, it just something annoying that renders the input sometimes not responsive
     
    #7
    Oscar92player likes this.
  8. Another Fen

    Another Fen Veteran Veteran

    Messages:
    500
    Likes Received:
    221
    First Language:
    German
    As mentioned, the default script practically adds an implicit 1-frame-wait to the end of each event.
    I've not had problems with parallel process events (you can always "Jump to Label" to the beginning of the event when you need the extra frame), but common events called through "Call Common Event" getting extended were a bit annoying.

    Probably not relevant to most, but without the implicit wait any autostart map event will not block player movement or menu calls if it can be instantly completed, because it will still only run once per frame.
    (For example, if you use this fix, create an autostart event on your map that does nothing but increasing a variable, you can move freely while the event keeps counting up the variable).
     
    #8

Share This Page