[RM2K3] TRANSFER PLAYER IN AIRSHIP EVENT

Posts

Pages: 1
So, I'm trying to implement an ascend/descend function while in the airship.
My descend event works fine, I'm assuming since it's activated via 'event touch'.
The ascend event however, must use a key input to work, in this case, I chose the cancel key. I encounter one of two errors each time I test it.

When done like this, copying the same transfer architecture from descending, it fails to show screen unless I press the menu button:



When done like this, removing all waiting, it transfers me after hiding and showing the screen:



(ignore Land in the move route, I've removed it and still get the same errors)

What am I doing wrong?
To start with, you're nesting it inside a Key Process event. Key Input is notoriously flakey, and sometimes skips certain processes because it requires hair-trigger timing.

So look at it this way, you have your hopes pinned on pushing... it looks like cancel with the timing perfect, and then checking again if another condition is met, which btw, it won't be. That set of conditions says:
- If you push Cancel
-If you happen to be currently riding the airship.

You're not currently riding the airship, or it wouldn't need to send to you.

Lemme see if I can find my vehicle events in one of my games. Holdon, I'll try to get you a better event.

Okay, first off. Landing on a flying object (sorta Final Fantasy airship thing):

-Make an event: Collision, Above Hero
-Do a Key Input Event, and add 1-5 as the checkboxes, wait for key
-Condition for each number, 1-4 are Move, Hero, (That Direction) which allows you to move through the object.
- Condition for Input 5, Branch if Vehicle (see, right now I'm riding the thing)
-Enter Vehicle (which exits vehicle, landing you)
-Wait 0.1 Sec
-Hide Screen
-Memorize your location
-Put the airship somewhere else using Set Vehicle Location
-(If things don't work, hit Enter Vehicle again, just to be sure of dismount)
-Teleport to the place
-Show Screen

A ship dock or a ride location:
-Memorize event
-Set Vehicle Location (the memorized number)
-Either move the ship, or Move Hero, 180 Turn, Forward, 180 Turn (Ignore Impossible)
-Enter Vehicle

Now, I'm trying to find where I summon vehicles using keys or events. Holdon some more. Uhhh, it looks like I have it keyed to a switch-based event that is used from an item. If you absolutely must do it using Key input, since cancel does the menu, I'd strongly advise against. Use, +, -, or *. Maybe even Shift or the numbers. The point is, Key Input tends to hijack other functions of the key so don't use something that has other functions. Also, to get it to work like I have, we're just gonna make this Toggle Switch SummonAirship ON/OFF. This should allow you to use an item as a backup. What I think you were trying to do before is mark that you have the airship. Either assign a switch like OwnAirship and check for that, or make an item, and check for that.

Common Event: SummonAirship, Parallel Process, Trigger: Summon Airship
-Basically, call the airship to your location in the common event and enter.
-Switch OFF the SummonAirship Switch and End Event Processing

Making it Switch based instead of directly called by the Key Input removes some of the finicky crap, as does trying to key it to cancel (don't do that, it will compete with the menu and actually canceling when making choices).
author=bulmabriefs144
To start with, you're nesting it inside a Key Process event. Key Input is notoriously flakey, and sometimes skips certain processes because it requires hair-trigger timing.


I'm definitely beginning to see that; I had thought I could use it as a workaround for the lack of options for custom controls. Thank you!
Ok, combined our coding, looks like setting the key input for wait made the difference, but I'm only assuming. I'm also not sure I need the 'Get Player Location' event because I want the character to appear in set locations upon ascending/descending.
What I'm trying to do is like in G.O.D Mezameyo to Yobu Koe ga Kikoe or Final Fantasy V; you're in a vehicle and can ascend/descend to a sub-world from the main overworld (there's usually arrows that allow you to choose which direction, but a simple choice text box will do) a short animation will take place and you're transported there.
Trust me, saving your current location is a must when working with airships and vehicles. It helps the thing get to your location, and it helps you get back to wherever you parked your ship.

Ah. Yeah that. Personally, I'd have a deal where you're calling it using something else. And then, make a choice menu Ascend/Descend. You might try swapping the order, making the Condition for riding the airship first, this would also prevent the whole competing with menu thing. But I've never tried conditions before key input, because I've had too much trouble with key input to start with. That's for cancel.

Uhhh, try this. Some other number, shift, or just an item calls the ship in the first place.

+ causes ascend (simplify things with switches or call events), - causes descend. Use the basic landing thing, then either land or fiddle around so you exit the airship and enter a boat. Depending on where you land. Now refer to that special landing on something I listed above for going up from flying. You'll probably want to simulate this with a picture instead of trying to Move Event it (make it larger, and raising the picture to a higher part of the map, meanwhile set hero transparency and dismount, then teleport). Not only will it be more flashy, but you can hide some of the things that it's really doing, which is actually just teleporting you to a new map. Otherwise, we're switching from boat to airship. We might want an Altitude variable with 0 as landed or ship, 1 as airship flying, and 2 teleports you to the new map for the sky dungeon.

The key to this is to keep experimenting. I haven't done the ascend/descend thing before. But I know from working with airships that it's pretty tricky and becomes trickier if you have competing stuff like opening menus. Final Fantasy may do it with cancel, but this doesn't mean it's necess the best way.
I call a custom option with the airship in my game. In my case, hitting escape takes you to the interior of the airship, which requires a forced (hidden) dismount. It's not too dissimilar to what you're doing, in a way. In my experience, this is how I'd probably handle your situation:

Have a PP which disables menu while riding the airship (branch, if vehicle=airship disable menu) and then wait for key input. You don't need to ignore 1-5 (just leave it out), as it'll only activate if exactly 6 (menu) is pressed. When 6 is pressed, I would show arrows, exactly how FF5 does it, up and down, and then call new events depending on which key is pressed. If you don't want to worry about further keypresses, a menu choice works as well. Just don't show an opaque dialogue box, as it'll look cruddy (transparent background!).

Like Bulma said, you'll want an Altitude variable as well, just to make sure you can tell the code where the airship is. You can also try using Shift as your teleport key, but bear in mind that the Shift key isn't bound to any controller key so far as I know, so it'll work for keyboard users (potentially fixed in the official RM2k3 release?). The option to ascend or descend should work fine with just a Menu Choice on keypress 6, though.

As for the actual execution of the Altitude changing, I'm not sure how I'd carry that out. There's no easy way to do it seamlessly in RM2k3 that I know of.

I know key inputs can be tricky, but so far I haven't had a serious issue with mine. Because the menu is disabled, 6 is only trying to execute my custom command. At worst, the player has to hit it twice.

(and yes, always memorize location)

I may have just completely whiffed answering the question, but, maybe this will help:

When I was teleporting after forced disembarkation from the airship, the Show Screen command DID NOT WORK unless I placed the Show Screen on the same screen as the player was on. So, in your case, you'd need a run-once autostart event on Overworld-Pristine after the player has teleported in to it. I don't know why this was, but I remember it happening.
The problem with Menu choice is that it is Cancel/Menu. That is, when you cancel any choice selection it will re-popup the menu. So, even you have it working, and even if you've disabled the menu itself, it's basically a hard-override. I've had it activate when I canceled a shop menu, and had it activate when canceling the custom menu.

So if you tie it to Menu and say Ascend/Descend, and try to exit, it might try to popup AGAIN a second later.

Essentially, the only way I can think of to do it that way is:
1. Tie it to several conditions so it only opens if you are actually flying, and
2. Make the choices Ascend/Descend/Cancel, and ignore cancel.
3. In both Ascend and Descend, you are no longer flying after the option. Descend, land the airship or convert into boat. Ascend, teleport to a new map. This way, the menu doesn't keep cycling.


Instead of putting all your code inside a key input process, try putting only one piece of code in that key input. A call to a common event, then run all the code from there. You only need the key input for one thing, recognizing when you press a button to initiate an action. Once you do that the code will run better as a standalone thing.

I can't see the rest of the event but you should have a switch turn on when entering an airship and this key input only work when that switch is on. To prevent it from activating elsewhere. From what I can tell you don't have that kind of switch and this key input process will always happen at all times during your game/on this map. And only after pressing cancel, does it check if you are on the airship. This whole event would be better off being disabled until a switch is turned on, because only when that switch is turned on does this even matter. That can cut down on lag, too, as you will have less things constantly running in the background.

Do you not have any waits in that key input event? You should have at least 0.0, or 0.1 at the bottom of that(and any parallel process for that matter). As it stands now it will be checking for key inputs without stopping to breathe, using up processing power needlessly, and that is what causes lag. With 0.1 that means it will check about 10 times per second if the player is pressing that key, which is plenty. As the wait goes higher you start to miss key presses, but it uses less processing.
Pages: 1