Charas-Project
Game Creation => Requests => RPG Maker Programming => Topic started by: drenrin2120 on November 09, 2010, 04:00:01 AM
-
Is it at all possible to code a hold key event in rm2k3?
Best example:
Browsing through a list of items. Instead of pushing the arrow keys repeatedly, the player holds down the key and the arrow automatically scrolls down.
-
Key input processing, yo!
-
I have no idea for the life of me how that would work.
-
Okay, well, I assume this is for some sort of custom menu system, yeah? So you'd need to use key input processing to figure out which arrow keys the player is pressing anyway, right?
-
No, I get that you need key input processing. =P Setting up key input is easy. The problem is when scrolling down a list of things, you have to push down or up each time you want to go to the next item, as opposed to just holding the key down for faster, more conveniently scrolling. Which is kind of a must if the player finds them self in a tight spot.
-
Well. It's kinda easy (says I)
You make a key input process, the usual stuff.
Now you make a parallel process that checks if you're pressing the up arrow.
If yes - move up.
If no, well a wait/ stop I guess.
So as long as you're pressing the button, this will repeat and the arrow will move up, right?
-
Well, I don't think there's any way to check if a player is holding down a key. You can only tell if a player has pushed a key, not whether they are still holding it down.
I could be wrong though. If it is that simple. I hope I'm wrong.
-
Oh right, you must set the variable it stored the key input to 0 if the button is not pressed.
I just remember using one of these for a charge up attacks.
As long as the action button was held down - the parallel process increased a variable by 1 each time.
If the button was no longer pressed / held down - the varaible would reset to 0.
If it had passed 10 or 15 or something it unleashed the charge attack when released.
Maybe you can do just that.
Paralell process that checks if the Key input VAR is the number of the direction. If it is - add 1 to another variable, and if not - set that variable to 0.
Now create a new (parallel) event. Make it check if the other variable is above 0 and if so - scroll thingy.
-
Oh, okay, that makes a lot of sense. The key input's "wait" option would have to be unchecked. Then, I could use labels to loop through the conditional branches and an operation that sets the variable to 0 before it loops again.
Thanks purp. Ill try this out
-
Oh, okay, that makes a lot of sense. The key input's "wait" option would have to be unchecked. Then, I could use labels to loop through the conditional branches and an operation that sets the variable to 0 before it loops again.
Thanks purp. Ill try this out
Although you won't need a loop as long as the parallel process is independent.
-
There's a huge event with multiple key input's going on at specific times. So, the loops will have to be put in place or else the thing would crash. :x
-
There's a huge event with multiple key input's going on at specific times. So, the loops will have to be put in place or else the thing would crash. :x
Makes sense
-
I've also been trying to get something like this. So far, no luck. Good thing my menus only have a few options each...
-
Hmmm... I encounter an interesting problem. I've got layers of conditional branches operating my menus. Imagine within these layers there are key input processes for different menus function. Like, the first, most dominant key input, controls deciding between some main branches (i.e. Attack, Escape, Magic, Items, etc.) Other key inputs operate things like item selection, skill selection, and target selection. I set the key input operating the item menu so it doesn't wait for the key to be input. It merely loops indefinitely so scrolling can occur. What ends up happening, since the event processes things so quickly, that whatever the key the player is holding to open the items menu (which happens to be the decision key) that key gets stored in the variables controlling the scrolling event. So, no matter what the player does, the first item on the list is always selected, rapid fire.
I don't know, can be remedied with a wait command. I just thought it was kind of a funny bug.
-
I had similar problems when I tried to tie the escape key to an alternate menu. Hitting escape opened the menu and then escaped out of it so fast that the player could never select anything. Try putting in a wait 0 at the end. Wait 0 sounds functionally useless, but it does help a lot with these sorts of super fast loops that scroll a bazillion times a second for reasons I don't fully understand but are totally legitimate.
-
Okay, I'll give that a whirl, because for whatever reason, wait .1 second is not working.
EDIT: I'm shocked that worked. There's only 0.0 waits preventing the system from looping madly out of control, but it doesn't crash.