Parallel Process Events Execution Bug Fix.

[♥SOURCE♥]

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:

 

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":

 

 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:

 def running?   @fiber != nil end

and the "run" method for the interpreter is the following:

 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:

 

 def update   @fiber.resume if @fiber end

How to fix the problem?​

 

The solution is simple:

 

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

 

[AeghtyAteKees]

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

 

[bgillisp]

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.

 

[Shaz]

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:

# 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

 

[Sixth]

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.

 

[Shaz]

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.

 

[TheoAllen]

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

 

[Another Fen]

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