So I have minigame where the player constantly goes down. When pressed down, the player goes down faster than normal and when up, he goes slower. The minigame is basically dodging oncoming objects and enemies. Eventing does not give good enough results so I thought to turn for scripters for assistance?
Minigame with changed control mechanics
● ARCHIVED · READ-ONLY
-
-
I'd still need this.
-
Cool, I love it when people's problems, gives me ideas.
No script is needed, and It's real easy to event too.
Make a event, set it to Parallel proc. Create a condition branch, if push down button, move route/change speed.
Under else, put move route/change speed to normal/whatever is slower then the faster speed you picked before hand.
That's it, you wouldn't think such a feature would be that easy, but it really is :)
PS. didn't see you wanted up to go slower as well, well same deal, after the first condition branch, make another, if push up, change move route slower
Note remove the else speed change from the first 1 -
This does not function, if I press up to slow down the character will get in cycle of going up and down instead of continuously going down rendering you unable to slow down. Also eventing makes the minigame have input lag and points where it doesn't register the key presses. (if it's during the time there's wait command)Cool, I love it when people's problems, gives me ideas.
No script is needed, and It's real easy to event too.
Make a event, set it to Parallel proc. Create a condition branch, if push down button, move route/change speed.
Under else, put move route/change speed to normal/whatever is slower then the faster speed you picked before hand.
That's it, you wouldn't think such a feature would be that easy, but it really is :)
PS. didn't see you wanted up to go slower as well, well same deal, after the first condition branch, make another, if push up, change move route slower
Note remove the else speed change from the first 1 -
This does not function, if I press up to slow down the character will get in cycle of going up and down instead of continuously going down rendering you unable to slow down. Also eventing makes the minigame have input lag and points where it doesn't register the key presses. (if it's during the time there's wait command)
Actually I just figured away to stop it from going up, when you press up(the trick is, after the speed up command, put move down, that's how you make the up button, make you still move down), and it all actually works(double parallel proc events, I didn't even know this could be done) It moves down automatically, when you hit up, it slows down, yet still moves down, and hitting down speeds up.
Everything works perfect, except the input delay is still there. Sigh, I suppose you'll need to script it, to get rid of the input delay, what a shame. -
No, you still go up and then down, this cannot be evented. Are you trying this out for yourself, because I can assure you that it does not work the way you're telling and how I wanted.Actually I just figured away to stop it from going up, when you press up(the trick is, after the speed up command, put move down, that's how you make the up button, make you still move down), and it all actually works(double parallel proc events, I didn't even know this could be done) It moves down automatically, when you hit up, it slows down, yet still moves down, and hitting down speeds up.
I already tried adding the move down to when it slows down already before posting and that just simply does not function. >_> -
I didn't tell you the full procedure(put exit proc in both condition branches, in up after the move down, and the other one after the speed up. I worked all of it out, so pushing up, never makes you go up, you still go down when pressing up.No, you still go up and then down, this cannot be evented. Are you trying this out for yourself, because I can assure you that it does not work the way you're telling and how I wanted.
I already tried adding the move down to when it slows down already before posting and that just simply does not function. >_>
However the button input delay is a big problem, so much so, It's no use for you, that's why I didn't submit the entire procedure. -
wrong, you cannot erase an input by eventing, and because of this the player will go up when pressing up.I didn't tell you the full procedure. I worked all of it out, so pushing up, never makes you go up, you still go down when pressing up.
You can make it appear to the player that he doesn't go up by adding a go down so fast that he cannot see the single frame where the character goes up, but you cannot erase the command to go up by eventing alone - and that can and will cause issues as soon as other functions check for movement, because the computer is fast enough to see that the player had gone up for a microsecond.
You're simply wrong with your assumption that this could be done by eventing alone. -
wrong, you cannot erase an input by eventing, and because of this the player will go up when pressing up.
You can make it appear to the player that he doesn't go up by adding a go down so fast that he cannot see the single frame where the character goes up, but you cannot erase the command to go up by eventing alone - and that can and will cause issues as soon as other functions check for movement, because the computer is fast enough to see that the player had gone up for a microsecond.
You're simply wrong with your assumption that this could be done by eventing alone.
You're forgetting one thing, I have another Parallel event, that is constantly moving the player down as well.
Trust me, the player Isn't doing a damn thing, other then going down.
Not like it matters, the input delay issue is so serious that It's not ideal for a minigame type of thing(am I really gonna have to post SSs). -
Try this. Initial testing shows it works. There's a slight slowdown when you move left and right. You'll have to modify it to get the correct feel of course.
You don't need the 'puts' script call, it just shows the current player speed.
Personally, I would replace the player with an event and use the player as a camera only, but you'd need to figure out a way to see when the event collides with others. If it's just getting off camera, then you can make it so that when the event is this distance away from the player (camera) then game over.
-
That was exactly what I was talking about - and you have proven that you cannot do it.You're forgetting one thing, I have another Parallel event, that is constantly moving the player down as well.
Compensating for a move up by adding more move downs into the command queue is NOT the same as canceling (deleting) the move-up from the command queue. There is no event command that can delete a keyboard command from the command queue...
Adding move downs by parallel process events might appear to the player as a constant move down and it might be a usable workaround in some cases, but it will not work in all cases, because sometimes the frame where the keyboard command move up is executed before the parallel process compensates it will matter. -
Yea you're right. After a dozen more tests, the char ended up going up, when I"held in up". Evidently many times the up slow down proc didn't happen because the button input is so damn buggy(engine based bug, not procedure based), and in general, It's so slow It's not funny, so most of the time, I would spam the button. The up condition branch would proc, yet the char wouldn't go up at all(It's like the old school input bugs that would take place, just tapping the button quick wouldn't do the full action).That was exactly what I was talking about - and you have proven that you cannot do it.
Compensating for a move up by adding more move downs into the command queue is NOT the same as canceling (deleting) the move-up from the command queue. There is no event command that can delete a keyboard command from the command queue...
Adding move downs by parallel process events might appear to the player as a constant move down and it might be a usable workaround in some cases, but it will not work in all cases, because sometimes the frame where the keyboard command move up is executed before the parallel process compensates it will matter.
However if you hold down the up button, and the input command decides to actually proc, you'll go up. -
Here you go ...
Change ARCADE_VAR to a variable you have available. When you're ready for the minigame to begin, just set that variable to whatever direction you want the player to move in automatically (2=down, 8=up, 4=left, 6=right). This script will handle the automatic downwards movement, so whatever mechanic you have running now that causes the player to move down when no keys are pressed, you can remove. When you want the minigame to end, set the variable back to 0.
Just be careful with obstacles, that there aren't 3 side by side - if the player hits the middle one, they won't be able to move. If that's a problem, and you want them to be able to move directly left or right (instead of down and left or down and right), just let me know, and I'll make the (hopefully) small mod that's required.
SpoilerCode:class Game_Player < Game_Character ARCADE_VAR = 16 #-------------------------------------------------------------------------- # * Processing of Movement via Input from Directional Buttons #-------------------------------------------------------------------------- alias shaz_arcade_move_by_input move_by_input def move_by_input return if !movable? || $game_map.interpreter.running? if $game_variables[ARCADE_VAR] > 0 move_arcade else shaz_arcade_move_by_input end end #-------------------------------------------------------------------------- # * Arcade Movement - always move in one direction, allowing for sideways # movement #-------------------------------------------------------------------------- def move_arcade if Input.dir4 == 0 || Input.dir4 == $game_variables[ARCADE_VAR] || Input.dir4 == 10 - $game_variables[ARCADE_VAR] move_straight($game_variables[ARCADE_VAR]) else horz = [4,6].include?(Input.dir4) ? Input.dir4 : $game_variables[ARCADE_VAR] vert = [2,8].include?(Input.dir4) ? Input.dir4 : $game_variables[ARCADE_VAR] move_diagonal(horz, vert) end end #-------------------------------------------------------------------------- # * Get Move Speed (Account for Dash) #-------------------------------------------------------------------------- def real_move_speed if $game_variables[ARCADE_VAR] > 0 if Input.dir4 == $game_variables[ARCADE_VAR] return @move_speed + 1 elsif Input.dir4 == 10 - $game_variables[ARCADE_VAR] return @move_speed - 1 else return @move_speed end else super end endend