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)
[2K3] TAP AN ARROW KEY TO FACE DIRECTION WITHOUT MOVING?
Posts
Pages:
1
Avee
5794
Avee
View playlists
CloseAgain for my Roguelike project under 2k3.
I want the hero to face a direction without moving if an arrow key is tapped, while if it is pressed and held the hero will move.
I can't figure out how to code this, so any help would be greatly appreciated ^^
I have to mention that using a "Move Hero: Wait" stops the hero for too long between movements. The coding should avoid using this command (or find a way to lessen the waiting time) if possible.
Also, moving with this system should still allow for Collision events to initiate.
I want the hero to face a direction without moving if an arrow key is tapped, while if it is pressed and held the hero will move.
I can't figure out how to code this, so any help would be greatly appreciated ^^
I have to mention that using a "Move Hero: Wait" stops the hero for too long between movements. The coding should avoid using this command (or find a way to lessen the waiting time) if possible.
Also, moving with this system should still allow for Collision events to initiate.
What you need is that patch that allows you to use all of the keys on the keyboard. Then, you can use WASD to change direction. Using the arrow keys to change direction would require you to use an outside event as the player and code it that way. As for the collision events? The amount of event coding to even get that to work a little bit would take an enormous amount of time for every single event, it's really not worth it. Otherwise, I don't see it as possible.
Avee
5794
Thanks for the suggestion, but using the patch would actually be more trouble than needed to solve this problem. I'd rather not change the available controls either, and having two sets of keys both used for movement is out of the question design-wise.
I know it is possible to code this with a simple database common event. I tried several sets of commands but I just couldn't achieve the perfect result. There is no need to code additional collision detection either, I just mentioned it because sometimes certain sets of move commands will deactivate them.
Still waiting for an answer. Thanks.
I know it is possible to code this with a simple database common event. I tried several sets of commands but I just couldn't achieve the perfect result. There is no need to code additional collision detection either, I just mentioned it because sometimes certain sets of move commands will deactivate them.
Still waiting for an answer. Thanks.
Kasezui beat me to it. But my method is different.
These are two separate parallel events. In order for it to work, all tiles in the map must be non-passable.
You can adjust the number "5" in the second event to determine how long the player has to hold the key before the hero starts moving.
These are two separate parallel events. In order for it to work, all tiles in the map must be non-passable.
You can adjust the number "5" in the second event to determine how long the player has to hold the key before the hero starts moving.
Avee
5794
@Kazesui: This method works fine. It causes a weird problem though: after having pressed a Menu key, the default menu won't come up unless the hero is in motion, but that won't be an issue for me as I'll be using a custom menu system. Thanks.
@calunio: I can see that this method works but the non-passable map requirement won't be compatible with the other NPCs/enemy sprites and level-design, as this project will use an ARPG battle system. The precise control over holding time part is neat though (both of you included that in your suggestions).
So, problem solved :D
@calunio: I can see that this method works but the non-passable map requirement won't be compatible with the other NPCs/enemy sprites and level-design, as this project will use an ARPG battle system. The precise control over holding time part is neat though (both of you included that in your suggestions).
So, problem solved :D
Pages:
1
