FIX DIRECTION SYSTEM (2K3)
Posts
Pages:
1
This was a complete chaos but it's actually work, is a fix direction system
holding a key made using only common events.
Maybe there is some bugs,
it's need more testing.
Link of the demo: http://www.mediafire.com/?jocj2rl4e97n1bb
holding a key made using only common events.
Maybe there is some bugs,
it's need more testing.
Link of the demo: http://www.mediafire.com/?jocj2rl4e97n1bb
What is this and why should I care? Try explaining it better.
I can create a video like that by starting a new project and hitting test play xD
I can create a video like that by starting a new project and hitting test play xD
Oh that, I see it now.
Well it's not in the text, so reading carefully wouldn't have helped any. I did in fact read before I posted. Fix direction implies that the direction of the hero is fixed, as in strafing. Lock facing. That's what I was expecting, so I didn't clue into the turning. You tend to use the wrong words to explain yourself, which is understandable considering your native language. A better name for this is "turn in place" or "fixed turning" or closer to how you put it "fixed direction change".
I downloaded the project and I'm looking at it now. You don't explain anything in the code and all the switch and variable names are not in english. So it's difficult to understand at a glance. Generally if you're going to share something for others to use, you should make it easy for them to understand and use. People don't copy from your test project into theirs, they have to recreate it from scratch. Any small error and it won't work and they won't be able to understand why.
Just for fun I tried to make my own system and was able to make it with less code. Looks like you did mostly the same thing, but with some extra stuff that I don't understand it's purpose. I did notice a slight problem with yours. If you hold 3, it does freeze you in place, but if you let go of 3 and press it again right away, it won't always freeze you in place. There seems to be a bit of a buffer after using it once, where you won't be able to use it again. And even though you continue you hold 3, it never kicks in again until you release 3 and press it again. My method avoids this problem. Mainly because of how I did this part:
I was going to post it here, but figured since I took the trouble of doing so that I might as well submit it as a tutorial. It's still pending but will be found here http://rpgmaker.net/tutorials/876/
Well it's not in the text, so reading carefully wouldn't have helped any. I did in fact read before I posted. Fix direction implies that the direction of the hero is fixed, as in strafing. Lock facing. That's what I was expecting, so I didn't clue into the turning. You tend to use the wrong words to explain yourself, which is understandable considering your native language. A better name for this is "turn in place" or "fixed turning" or closer to how you put it "fixed direction change".
I downloaded the project and I'm looking at it now. You don't explain anything in the code and all the switch and variable names are not in english. So it's difficult to understand at a glance. Generally if you're going to share something for others to use, you should make it easy for them to understand and use. People don't copy from your test project into theirs, they have to recreate it from scratch. Any small error and it won't work and they won't be able to understand why.
Just for fun I tried to make my own system and was able to make it with less code. Looks like you did mostly the same thing, but with some extra stuff that I don't understand it's purpose. I did notice a slight problem with yours. If you hold 3, it does freeze you in place, but if you let go of 3 and press it again right away, it won't always freeze you in place. There seems to be a bit of a buffer after using it once, where you won't be able to use it again. And even though you continue you hold 3, it never kicks in again until you release 3 and press it again. My method avoids this problem. Mainly because of how I did this part:

I was going to post it here, but figured since I took the trouble of doing so that I might as well submit it as a tutorial. It's still pending but will be found here http://rpgmaker.net/tutorials/876/
@link
You should consider adding some buffering to that event you show in the image.
By this I mean that you should add some 0.0 waits each followed by a key input process where you again check if the input is still 0.
The reason for this is that rm2k3 has some trouble reading certain keyboards and will issue a 0 eventhough the key is clearly being held down, which in this case could lead to player walking unintendedly.
You should consider adding some buffering to that event you show in the image.
By this I mean that you should add some 0.0 waits each followed by a key input process where you again check if the input is still 0.
The reason for this is that rm2k3 has some trouble reading certain keyboards and will issue a 0 eventhough the key is clearly being held down, which in this case could lead to player walking unintendedly.
Hi, maybe there is a lot of ways of do it, of course,
I had to use more code for buffering (like Kazesui say),
because my Lufia fangame use some skills like sword meanwhile the face direction is fixed.
I will wait to see your tutorial.
I had to use more code for buffering (like Kazesui say),
because my Lufia fangame use some skills like sword meanwhile the face direction is fixed.
I will wait to see your tutorial.
Ok, I'll update the tutorial. I made it quickly and tested it with no issue. I was actually surprised it worked so well considering when I tried to make a strafing system before using a similar method, I got that kind of stuttering when holding a key. Actually, when I tested it I had an event with a sprite graphic so I could see when the key was pressed. The graphic stuttered, but the hero never moved from that spot.
I can understand the need for small adjustments based on other events, I know that pain all too well. Still, I recommend more explanation in the future when you share something like this. So that it's more accessible to everyone. Because that is the goal, right?
I can understand the need for small adjustments based on other events, I know that pain all too well. Still, I recommend more explanation in the future when you share something like this. So that it's more accessible to everyone. Because that is the goal, right?
Pages:
1













