About Parallel/Autorun+SaveGame+EditProject+LoadGame

Engr. Adiktuzmiko · 2014-04-03T21:29:45+0900

First and foremost, I'm not sure if this behavior is only for Ace. Second, this is more of a "BEWARE" kind of thing So let's get it on. Here's the thing: If you have parallel/autorun events on a map, then you use Erase Event to erase them, then used the save command and then quit the game, then opened it up on RM and then edit (or no-edit) then hit save button then start the game and load the old file, the parallel/autorun event will re-run. Why? Because DataManager re-calls the Game_Map update method when the internal version of the game on the save file is different from the current internal version of your game. So, this problem will probably only appear during development, and on releasing patches I think. For most games that won't get any updates, you won't experience it. And it's easy to counter too The most effective method is of course, prevention. basically don't allow saving on maps that has autorun/parallel events that uses erase event. Now if you need to, there are some workarounds. One would be "temporary self switches", which is basically using a second page + self switches, but you reset the self switch once you leave the map. That way, once you return to the map, it will still run but when you load from a different version, it won't. The method I used to achieve this is scripted (via aliasing the setup method of Game_Map), and I'm not sure if resetting self switches before a transfer event command will work flawlessly. For the method I used: Code: class Game_Map alias setup_reset_switch setup def setup(map_id) setup_reset_switch(map_id) @id = 0 if @id.nil? if not @id == map_id @id = map_id $game_self_switches[[some_map_id,eventid,self_switch]]=false #do that for each self switch that needs to be reset #so like $game_self_switches[[1,1,"A"]]=false # this will reset the self switch A of map 1's event 1 end endend

● ARCHIVED · READ-ONLY

Started by Engr. Adiktuzmiko Apr 3, 2014, 12:29 PM 5 posts View original ↗

Engr. Adiktuzmiko

#1 Apr 3, 2014, 12:29 PM Source
First and foremost, I'm not sure if this behavior is only for Ace.

Second, this is more of a "BEWARE" kind of thing

So let's get it on.

Here's the thing:

If you have parallel/autorun events on a map, then you use Erase Event to erase them, then used the save command and then quit the game, then opened it up on RM and then edit (or no-edit) then hit save button then start the game and load the old file, the parallel/autorun event will re-run.

Why? Because DataManager re-calls the Game_Map update method when the internal version of the game on the save file is different from the current internal version of your game.

So, this problem will probably only appear during development, and on releasing patches I think. For most games that won't get any updates, you won't experience it. And it's easy to counter too

The most effective method is of course, prevention. basically don't allow saving on maps that has autorun/parallel events that uses erase event.

Now if you need to, there are some workarounds. One would be "temporary self switches", which is basically using a second page + self switches, but you reset the self switch once you leave the map. That way, once you return to the map, it will still run but when you load from a different version, it won't. The method I used to achieve this is scripted (via aliasing the setup method of Game_Map), and I'm not sure if resetting self switches before a transfer event command will work flawlessly.

For the method I used:
Code:
class Game_Map alias setup_reset_switch setup def setup(map_id) setup_reset_switch(map_id) @id = 0 if @id.nil? if not @id == map_id @id = map_id $game_self_switches[[some_map_id,eventid,self_switch]]=false #do that for each self switch that needs to be reset #so like $game_self_switches[[1,1,"A"]]=false # this will reset the self switch A of map 1's event 1 end endend
The Prince of Sarcasm

#2 Apr 10, 2014, 04:51 PM Source

You could also make so that when the event is done it turns on a switch, and make a new event page that is blank when that switch is turned on.
seita

#3 Apr 10, 2014, 05:16 PM Source
From what I understand, "Erase Event" only erases the event for the duration of your time on the map, which ends if you leave the map or exit the game. Everything resets once you re-enter the map including all events that have been erased, so the only surefire way to make sure the event stays erased is by using a second page with a valid conditional. I believe it was made this way intentionally, as having a way to permanently erase an event during a single playthrough would be even more inconvenient.

Edit:

As an example of the convenience of this command, I use it on every map that requires a parallel process or autorun to manage the map. (which is basically every map).

Depending on the progress of the main storyline, each map will be a little bit different in YANTH.

Let's say in one town, there's normally 10 NPCs around. The weather is normal. The autorun for this map goes like this:
- If specific NPC needs to be somewhere, place them there.
- Set weather and BGM.
- Tint screen to normal. (I don't use fade in or fade out during transfers, instead I tint the screen to complete black. This gives me 100% control over everything during a fade out and fade in).
- Erase Event.
if I need to leave and re-enter the map, everything adjusts properly.

Now say I'm further into the game. A new page in the same autorun event will trigger instead.
- Erase Event 3 and 5 since they did not survive. (make them through and transparent)
- If specific NPC needs to be somewhere, place them there.
- Set bridge to broken.
- Set weather and BGM.
- Tint screen to normal.
- Erase Event.
etc etc.
Zeriab

#4 Apr 12, 2014, 08:13 AM Source

Thank you for telling us about this behavior.

I encounter a variation of this problem creating my Map copy script.

Here's my solution which can serve as additional inspiration: ($game_map.data_modifications is set during the map-copy operation)

### Change reload mechanism#module DataManager class << self unless self.method_defined?:)zeriab_copy_reload_map_if_updated) alias_method:)zeriab_copy_reload_map_if_updated, :reload_map_if_updated) end ## # Reload must not occur when we have made any runtime data changes. # Otherwise we may throw our changes away # def reload_map_if_updated if !$game_map.data_modifications # No copy changes so we are save to use the normal reload code zeriab_copy_reload_map_if_updated end end endend
Generally I find having a parallel event to set the environmental conditions before using Erase Event nice. Having them run again is typically not a problem. (Yes, the type Seita is talking about)

*hugs*
Engr. Adiktuzmiko

#5 Apr 12, 2014, 08:41 AM Source

@super - yeah the way to erase completely is to simply have a second page. But erasing isn't really the topic here.

This problem specifically pertains to the situation where you have an event that needs to re-run upon entering the map, hence using autorun + erase only...

Normally when you save, the event status of that map is saved (because the current (or technically last) map itself it saved), so that even if you quit then load, the autorun events won't refire because the game thinks that you still didn't left the map (same reason why they don't autofire after opening and closing the menu)

BUT

If you hit save, close the game, and then edit the game file, the game then calls the setup method of that map which resets the erased status. and that causes the problem...

so technically, this will only be a problem for games under development or still under patching... because already finalized games won't be edited anyway so it won't prompt the game to recall the setup method upon loading of a saved file...

:)