Well
that was a rough patch of code. It seems that the Pumpkins had a problem they couldn't solve, so they did a workaround by loading the "between" levels when they needed a Transporter on the main map for player use. They'd load up the between level with a Transporter
already on it, then send it off to drive the player's forces once it was loaded.
What I did to get around this was a bit of "brute force". When the time requires it, I plonk a Transport at the edge, set the Landing Zone and Limbo Landing area, and finally drive it there using orderDroidLoc(DORDER_MOVE) to simulate a "flyTransporterIn()".
That's not the part I ran into problems with. Getting the Transport to cooperate with the setTransporterExit() was dodgy. Unlike most other things, it requires one to use
tile coords in order to work, and the conventions in use for that function are abnormal.
Code: Select all
setTransporterExit(player, 105, 0);
is how it's
supposed to be, rather than setTransporterExit(x, y, player); .
I had to look to up to get it right.
Once you load up the Transport, your units are in the limbo list.
So we load the new map we want them on. Here's the procedure to get them where they are supposed to be.
- add your Transport using addDroid(). To be safe, use the same name you used in the previous script. It might even
need to be the same. Putting the Transport on the map using FlaME ahead of time will NOT work.
- setLandingZone(x1, y1, x2, y2); and setLimboLanding(x1, y1, x2, y2); like normal.
- flyTransporterIn(player, x, y, false); . Note the abnormal function parameters again. The 'false' is a bool for whether we follow the Transporter in with the camera. 'true' seems to do nothing.
So, that's the misadventure with using a Transport. Dodgy to say the least.
Took me all night to get that sorted.