Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
INPUT BASED MINIGAME (TROUBLE RESETTING)
Posts
Pages:
1
King of Games
View playlists
CloseI'm making an input based mini game. It works like this, there's one master event set to autorun that calls the input generator (decides which key you have to press).
The Key Input Processing is set to wait until key is pressed, and stores the amount of time it takes to press the key.
Then it just branches to see if you pressed the right key in a fast enough time, which triggers bits of dialogue from the master autorun event. It works perfectly unless you press nothing.
My problem is this, I can't figure out how to erase the input generated if no keys are pressed. (wrong presses +1) It sounds simple in theory, to branch if the key press is 0, shut down the event and +1 to wrong presses. If I put a branch like this under the key input processing command, it won't do anything unless a key is pressed, which would have to be >0, so that portion of code never commences.
I've tried a couple theories, including separate pp/autorun events branching if key press is 0 after an allotted wait command. Does anyone have any ideas or theories about this? I know my RM very well, but this is a roadblock for me. I can post code if I have to. Thanks for any help.
The Key Input Processing is set to wait until key is pressed, and stores the amount of time it takes to press the key.
Then it just branches to see if you pressed the right key in a fast enough time, which triggers bits of dialogue from the master autorun event. It works perfectly unless you press nothing.
My problem is this, I can't figure out how to erase the input generated if no keys are pressed. (wrong presses +1) It sounds simple in theory, to branch if the key press is 0, shut down the event and +1 to wrong presses. If I put a branch like this under the key input processing command, it won't do anything unless a key is pressed, which would have to be >0, so that portion of code never commences.
I've tried a couple theories, including separate pp/autorun events branching if key press is 0 after an allotted wait command. Does anyone have any ideas or theories about this? I know my RM very well, but this is a roadblock for me. I can post code if I have to. Thanks for any help.
Kazesui
5797
Assuming we're talking 2k3 here, you could take a look at this minigame sample
It's a tiny project showing how you can probably do something sounding similar to the problem you're describing.
Basically a solution to it is to have "wait until key is pressed" to be unchecked and manually control how much time has passed with variables. This would also mean you'll have to manually check when the button has been released.
The sample up there generates a key to be pressed and shows a picture corresponding to this key. It then checks if a button is still being held down and continues to loop until it's released, while still counting towards the amount of time left. When released, it waits to see if the key input is not equal to 0, meaning a key has been pressed and if so, check if it's the right one. if it's still 0 the variable keeps on counting toward whatever threshold has been chosen.
It's a tiny project showing how you can probably do something sounding similar to the problem you're describing.
Basically a solution to it is to have "wait until key is pressed" to be unchecked and manually control how much time has passed with variables. This would also mean you'll have to manually check when the button has been released.
The sample up there generates a key to be pressed and shows a picture corresponding to this key. It then checks if a button is still being held down and continues to loop until it's released, while still counting towards the amount of time left. When released, it waits to see if the key input is not equal to 0, meaning a key has been pressed and if so, check if it's the right one. if it's still 0 the variable keeps on counting toward whatever threshold has been chosen.
Interesting solution, I'll check it out. Thanks. (and yes, rm2k3)
Edit: I'm guessing you made this? If so would you be able to help me with tweaks? I want there to be a 1.5 sec interval between button presses, and a system to make sure the random number doesn't generate the same number twice. I had this in my old system, but it's strange injecting new code into someone else's.
Edit: I'm guessing you made this? If so would you be able to help me with tweaks? I want there to be a 1.5 sec interval between button presses, and a system to make sure the random number doesn't generate the same number twice. I had this in my old system, but it's strange injecting new code into someone else's.
KoG
If you went with
Key Input Proc for Variable(with Wait unchecked)
Wait 0.1 Seconds
Branch if Variable = Key pressed
- Jump to Label/Call
and repeat for the 1.5 seconds with all the end event processing you might need, then have the "no key pressed at all" event trigger at the end of that 1.5 seconds. You should get the desired result within your existing code.
I'm not sure exactly how the Key Input Proc with wait unchecked works, but this layered input opportunity works for that time interval. And it makes it easier for there to be different reactions at different stages of the same interval.
I have a soccer timing minigame where pressing the key in the first 0.3 seconds causes you to sky the ball. The next 0.3 seconds is the sweet spot for a good shot. And the 0.3 seconds after that scuffs the ball for a slow roller.
Hope that helps.
If you went with
Key Input Proc for Variable(with Wait unchecked)
Wait 0.1 Seconds
Branch if Variable = Key pressed
- Jump to Label/Call
and repeat for the 1.5 seconds with all the end event processing you might need, then have the "no key pressed at all" event trigger at the end of that 1.5 seconds. You should get the desired result within your existing code.
I'm not sure exactly how the Key Input Proc with wait unchecked works, but this layered input opportunity works for that time interval. And it makes it easier for there to be different reactions at different stages of the same interval.
I have a soccer timing minigame where pressing the key in the first 0.3 seconds causes you to sky the ball. The next 0.3 seconds is the sweet spot for a good shot. And the 0.3 seconds after that scuffs the ball for a slow roller.
Hope that helps.
Kazesui
5797
Here's a sample with the tweaks you want sample 2
Also, you can adjust the maximum time for keypresses by altering the value of the variable "0009: Key Delay" in the second variable. 60 = 1 second, 90 = 1,5 seconds and so on.
Also, you can adjust the maximum time for keypresses by altering the value of the variable "0009: Key Delay" in the second variable. 60 = 1 second, 90 = 1,5 seconds and so on.
Got it working perfectly! Thanks for posting those demos man, a new level of coding that I've definitely learned from.
Kasezui, that's some interesting coding. But I'm curious about the need for to check Key timer less than Key delay.
I understand that you're adding a +1 to Key timer every 0.1 seconds that an input isn't pressed.
Am I missing some other use for those variables? The Key Input Process even with wait until press unchecked is active and will register inputs for more than the next 0.1 seconds.
and I repeat for as long of an interval as I need.
I tried your sample, and this doesn't do anything less. You're probably a much more capable coder than I am. Could you explain to me why you use those extra variables?
I understand that you're adding a +1 to Key timer every 0.1 seconds that an input isn't pressed.
Am I missing some other use for those variables? The Key Input Process even with wait until press unchecked is active and will register inputs for more than the next 0.1 seconds.
and I repeat for as long of an interval as I need.
I tried your sample, and this doesn't do anything less. You're probably a much more capable coder than I am. Could you explain to me why you use those extra variables?
Kazesui
5797
I'm not adding +1 every 0.1 seconds, but rather +1 every 0.0167 seconds. (the top 0.1 wait in the first demo was a bug)
Also, when you have "wait until key is pressed" unchecked, it will only check what keys is held down the very moment that line of code is executed, meaning that it won't check for key inputs during that 0.1 wait of yours following the key input command. This becomes easier to see the higher the wait is.
The key delay variable is there of course to set the maximum delay in the variable. The good thing about having a variable like that, is that you can configure the wait more easily and whenever you want. Say you want 3 different levels, where you have to be quicker in hitting the buttons for each level. Having a variable like that allows you to change the maximum allowed delay for each level and then still run the same event code for the key triggering event script. This is also the reason why there are variables for amount of correct inputs needed and maximum amount of inputs as well.
Also, when you have "wait until key is pressed" unchecked, it will only check what keys is held down the very moment that line of code is executed, meaning that it won't check for key inputs during that 0.1 wait of yours following the key input command. This becomes easier to see the higher the wait is.
The key delay variable is there of course to set the maximum delay in the variable. The good thing about having a variable like that, is that you can configure the wait more easily and whenever you want. Say you want 3 different levels, where you have to be quicker in hitting the buttons for each level. Having a variable like that allows you to change the maximum allowed delay for each level and then still run the same event code for the key triggering event script. This is also the reason why there are variables for amount of correct inputs needed and maximum amount of inputs as well.
Obviously, you need a ton of variables for all the reaction possibilities, I just meant the timing check.
All I needed to hear. Thanks, I get it. Maybe the reason my method never failed is because it's near impossible to press a key and lift off the key before the next Key Input Process check happens 0.1 seconds later.
So it's just a matter of being pragmatic with your coding. I have something similar to your example of 3 different levels, and I just made a separate event for each stage.
author=Kazesui
Having a variable like that allows you to change the maximum allowed delay for each level and then still run the same event code for the key triggering event script.
All I needed to hear. Thanks, I get it. Maybe the reason my method never failed is because it's near impossible to press a key and lift off the key before the next Key Input Process check happens 0.1 seconds later.
So it's just a matter of being pragmatic with your coding. I have something similar to your example of 3 different levels, and I just made a separate event for each stage.
Pages:
1
