reserve_transfer is NOT the same as Transfer Player

Hi,

I racked my brain on this for about three days before realizing this: the reserve_transfer function is NOT the same as Transfer Player.

Internally, there is some difference. Externally, you can notice some effects, like $game_map.map_id not changing.

- Create a map (Map ID #1)

- Create another map (Map ID #2)

- Add a script event on map #1 that calls reserve_transfer to transfer to map #2

- Print out (raise, log, etc.) the value of $game_map.map_id directly after the reserve_transfer call

You'll notice the ID is still 1 (Map #1's ID). It appears that this doesn't change until the script finishes executing.

To give you a comparison, this is like the difference between Autorun and Parallel Process. Autorun events on a map run after the map is fully initialized and faded in; Parallel Process runs while the map is fading in.

Hopefully someone else will see this and not waste as much time as I did figuring it out. (The solution is, unfortunately, to use the Transfer Player map event; you can't achieve everything in code.)

Reserve transfer is asynchronous.


You first tell the engine that you would like to reserve a transfer, and then the engine will process your request when it is ready to do so (cause it might still be doing a bunch of other things like updating graphics and so on)


Same with common events, or even calling the menu: you don't just execute them whenever you want to; you first tell the engine that you want to do something, and it will do it when it's ready.


So pretty much almost 100% of the time, you should not expect your request to be processed right after making the script call.


The reason why printing out the map ID after making the transfer player call is because the event engine basically just waits under the transfer is complete.

Interesting.

Even more interesting, if I use a while/wait loop, I can actually synchronously wait for this to work.

Thanks... you just made my code better :)

I'd question whether adding a loop while waiting for a reserve_transfer makes your code better.


Why don't you do it the way the engine does it by default? It's a combination between Game_Interpreter setting things up, and Scene_Map handling it all. Scene_Map does not do a loop while waiting for things to happen - it relies on the default looping that's inherent in every type of scene.


I've moved this thread to RGSSx Script Support. Please be sure to post your threads in the correct forum next time. Thank you.

Thanks for moving the topic. Since you asked, I can explain in details.

This is for my RPG Maker roguelike.

In my roguelike, I have a single map ("Dungeon", ID=1) where I randomly generate the tiles. This is good, and if this was the only map, life would be awesome.

One of the use-cases I support is allowing people to add hand-crafted maps; that is, something like "on floor #17, transfer the player to map #2." Ditto for going back to the dungeon map.

Here's the exact call work-flow:

From dungeon to custom map:

1. Transfer player to custom map
2. Generate stairs events (up/down) appropriatley
3. Position the player on top of the right stairs (depending on if they came up or down a floor)

For the first call, I use reserve_transfer. This doesn't change the map ID; so when I add the stairs events, they're generating on the wrong map, and I'm in trouble. Ditto for going back.

What I actually, really need in this case is a synchronous player transfer. With a synchronous transfer, I can dynamically generate the events -- in my case, stairs -- on the right map at the right time. Without this, anyone who makes a custom map needs to copy/paste the stairs event manually. If there's a bug in the stairs code, it will need to be updated on all the copies of the stairs.

I hope this makes sense. In my case, asynchronous doesn't get me much; I need synchronous map changes.

Then just use player transfer, or look at how the interpreter does it.