VX Ace Script Running Twice

[dott]

I have a script called in a parallel process event that, whenever triggered, runs in its entirety twice before the game moves on. I have tried changing variables in the middle of the script so that it won't trigger again, but it didn't do anything. The script does exactly what it's supposed to both times, except that it happens twice, and I have no idea why. My only idea is that it might be something to do with how VX Ace handles parallel processes, but I don't know how else I would call it.
Common Event 2 sets variable 4. Common Event 1 shows a few text boxes, plays some sound effects, and transports the player elsewhere before turning on the switch to play the parallel process Common Event 3. Common Event 3 is only ever called once, which means that Common Event 1 and the scripts are being called twice before the game checks the parallel process condition for Common Event 3.

Spoiler: Parallel Process Event

>Call Common Event [2]
>Script: [map_7]

Spoiler: map_7 Script

def map_7
@var = $game_variables[4]
case @var
when 17..23
if !$game_switches[ 16 + @var ]
spotted( @var )
end
end
end

Spoiler: spotted Script

def spotted ( var )
mr = RPG::MoveRoute.new
mr.repeat = false
mr.wait = true
mr.list = []
mr.list.push( RPG::MoveCommand.new( 25, []) )
mr.list.push( RPG::MoveCommand.new )
$game_map.events[ @var ].force_move_route( mr )
$game_map.events[ @var ].balloon_id = 1
$game_temp.reserve_common_event( 1 )
end

Solutions that didn't work:

• Changing $game_variables[4] in the if statement of map_7
• Resetting $game_variables[4] after the script call in the parallel process

While not technically game-breaking, this glitch breaks immersion, and is very annoying. Does anyone have any ideas on how to fix it?

 

[MobiusXVI]

So to help you troubleshoot, I would recommend posting screenshots of all your events. You never know when maybe there’s just a setting mismatch or something like that. As for calling twice, my initial guess is that something like this is happening:

The game updates the map, which checks all events.
The parallel process is triggered.
A script/event marks other events to be run but doesn’t actually run them right away.
On the next frame, the game updates the map, which checks all events.
The parallel process is triggered.
The marked events are triggered thereby disabling the parallel process.
The marked events were also re-marked by the parallel process.
On the next frame, the marked events are called again.

I can’t remember exactly the script call but you should be able to print stuff to a console while debugging. That should help you trace the execution of your code.

 

[A-Moonless-Night]

I have a feeling that common events restart as you change maps, so that could have something to do with it?

 

[bgillisp]

Maybe post what you are trying to do too? Odds are there is a better way to implement it which can avoid this, as I can't think of any reason you would need 3 common events to do one action.

 

[dott]

I am doing a stealth segment of a game, and wrote a script and some common events to make the event pages shorter for all the guards.

1. A parallel process common event finds the region id of the square the player is standing on and runs a script.
2. A script checks to see if that region id is associated with a guard, and if the guard is still there. If the region id and switch indicate that there is a guard who can see the player, the script specific to that map is called.
3. A script takes as input the region id which matches the event id of a guard. That guard turns towards the player and a balloon icon appears over them. A common event is called.
4. A common event shows a bit of dialogue and fades out the screen. A few fighting sound effects play, the player is transported to their cell, and a switch is turned on to trigger a common event.
5. A common event fades the screen back in and shows dialogue depending on where the player is in the game. The switch to trigger the common event is turned off.

When I originally implemented this, steps 4 and 5 were in the same common event, but for an unknown reason the screen wouldn't fade back in after the transport. Splitting it into two events fixed it. Theoretically I could now put steps 4 and 5 into another script, but I still don't know why the screen wouldn't fade back in, and would rather not mess with it.

The common event of step 1 is written in its entirety in the original post under "Parallel Process". The script of step 2 is in the original post under "map_7 Script". The script of step 3 is in the original post under "spotted Script". The common events of steps 4 and 5 are below and attached as files to this post.

There are some guards on the same map as the player's cell, and whether or not the player remains on the same map doesn't affect whether or not the script runs twice. As an additional note, if the common events are called through an event page, they only run once.

 

[dott]

After a lot of testing, I ended up combining steps 3 and 4 in a script, which seems to have fixed the problem. I think that Mobius was right, and the parallel process was triggering twice because step 4 happened before the player moved off of the trigger square before the event. Thank you all for your help.