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)
NEED HELP EVENTING A CUSTOM-TYPE OF ATTACK
Posts
Pages:
1
Mitsuhide_The_Vagrant
View playlists
CloseI need help with making an event work right, everyone.
What I want the event to do is this: while on specific "combat" maps of the game, I want the player to use the "confirm" key to attack. The way I want the attack to be executed is holding down and then releasing the button. When the player holds the "confirm" key down, all enemies on the screen will stop and the player then has the ability to face any direction he/she wants before releasing the "confirm" key, which executes the attack.
So...
- HOLD CONFIRM KEY - all enemies stop and the player can face different directions.
- RELEASE CONFIRM KEY - character executes attack (with accompanying animations) then all the enemies start moving again.
Thanks, guys.
What I want the event to do is this: while on specific "combat" maps of the game, I want the player to use the "confirm" key to attack. The way I want the attack to be executed is holding down and then releasing the button. When the player holds the "confirm" key down, all enemies on the screen will stop and the player then has the ability to face any direction he/she wants before releasing the "confirm" key, which executes the attack.
So...
- HOLD CONFIRM KEY - all enemies stop and the player can face different directions.
- RELEASE CONFIRM KEY - character executes attack (with accompanying animations) then all the enemies start moving again.
Thanks, guys.
LDanarkos
430
If this were on RM2K, my only area of expertise, then I see no way this can be done as-is, because the get input command (called Enter Password in RM2K) can't register two inputs at the same time. If you altered it slightly so that you hit enter once to freeze all events, then faced any direction, and hit enter again to resume events and execute the attack, then you'd have a much easier time pulling it off. Another similar thing you could do, but slightly differently, is press enter once to freeze all events, and press the direction key to face a direction and unfreeze events, without the need to hit enter again.
You could make some sort of common event that's a parallel process with an appearance condition switch called "Combat Map." Whenever you teleport to a combat map, turn the switch on, and when you teleport to a non-combat map, turn the switch off. The common event can be like...
Wait 0.0
Enter Password: 'Input' (Don't check 'wait until key hit')
Fork Optn: Varb 'Input'-5 (assuming 5 is the action key for your RPG Maker)
<>Stop All
<>Disable System Menu (you might not want the player to be able to call the Menu while in freeze mode)
<>Set Screen Tone (You'll probably want a dimmer screen while events are stopped, for effect)
<>Enter Password: 'Input' (Wait until key hit. You may or may not want to disable the action key and the menu / cancel keys, that's up to you. As long as you have a plan for them and don't just overlook them)
Then put all of the forks for if Input = 1, Move Event Hero, face down, etc. for each different direction.
<>Set Screen Tone (return screen to normal tone)
Then put your code for how the attack works, etc.
<>Enable System Menu
<>Move All
End Case
You could make some sort of common event that's a parallel process with an appearance condition switch called "Combat Map." Whenever you teleport to a combat map, turn the switch on, and when you teleport to a non-combat map, turn the switch off. The common event can be like...
Wait 0.0
Enter Password: 'Input' (Don't check 'wait until key hit')
Fork Optn: Varb 'Input'-5 (assuming 5 is the action key for your RPG Maker)
<>Stop All
<>Disable System Menu (you might not want the player to be able to call the Menu while in freeze mode)
<>Set Screen Tone (You'll probably want a dimmer screen while events are stopped, for effect)
<>Enter Password: 'Input' (Wait until key hit. You may or may not want to disable the action key and the menu / cancel keys, that's up to you. As long as you have a plan for them and don't just overlook them)
Then put all of the forks for if Input = 1, Move Event Hero, face down, etc. for each different direction.
<>Set Screen Tone (return screen to normal tone)
Then put your code for how the attack works, etc.
<>Enable System Menu
<>Move All
End Case
Kazesui
5797
What you generally do for "charging" attacks, i.e. ones where you hold down a button for an amount of time is that you make use of key inputting without "wait until pressed" checked running in a loop until the key you're checking isn't held down any more.
Assuming rm2k3, it's also important to do multiple checks before accepting that the key has been released, since it will occasionally claim to have been released on lot of keyboards without it being the case.
Here's a sample project which should fit your description somewhat: Sample (assuming rm2k3).
The top left event handles everything of interest. It first runs on parallel process waiting for confirm key to be pressed, and activates a switch as soon as it does.
This switch triggers the next page which is an auto-start event, and thus stops the enemies from moving. This page sets a "Charge Counter to 0" and then starts iterating through a loop. The charge counter is there for the sake of differentiating between just hitting the confirm key, and holding it down for a longer time.
For each iteration, you increase the charge counter by 1 and do two key input processes. One only checks for the confirm button, while the other only looks for direction buttons. Both have "wait" unchecked.
You then use change the facing according to the variable used for key input of the directions, and you then check if the confirm button is still pressed with the other.
if it isn't, then you do the check a few more times with a 0.0 wait inbetween. If any of the branches say that the key is still pressed, you jump to the top of the event again, if not you check if the button was held down long enough, and execute whatever code you want to happen if yes. Then you turn the switch off and the event will return to page one and wait for key input.
Assuming rm2k3, it's also important to do multiple checks before accepting that the key has been released, since it will occasionally claim to have been released on lot of keyboards without it being the case.
Here's a sample project which should fit your description somewhat: Sample (assuming rm2k3).
The top left event handles everything of interest. It first runs on parallel process waiting for confirm key to be pressed, and activates a switch as soon as it does.
This switch triggers the next page which is an auto-start event, and thus stops the enemies from moving. This page sets a "Charge Counter to 0" and then starts iterating through a loop. The charge counter is there for the sake of differentiating between just hitting the confirm key, and holding it down for a longer time.
For each iteration, you increase the charge counter by 1 and do two key input processes. One only checks for the confirm button, while the other only looks for direction buttons. Both have "wait" unchecked.
You then use change the facing according to the variable used for key input of the directions, and you then check if the confirm button is still pressed with the other.
if it isn't, then you do the check a few more times with a 0.0 wait inbetween. If any of the branches say that the key is still pressed, you jump to the top of the event again, if not you check if the button was held down long enough, and execute whatever code you want to happen if yes. Then you turn the switch off and the event will return to page one and wait for key input.
Pages:
1
