[RM2K3] NEED HELP WITH STEP COUNTER!
Posts
Before you ask, yes I have looked at all the tutorials and none of them are accurate enough for my game. I need a 100% accurate step counter. I tried using the hero's xy values, but it would either skip a step when holding a direction key or add to many steps to the counter.
Just tried that exact event and when I hold the directional key it sometimes skips a step.
Edit: I need an exact step counter because every time you move or do an action a turn passes in game which triggers other events to move/action.
Edit: I need an exact step counter because every time you move or do an action a turn passes in game which triggers other events to move/action.
I tried wait 0.0 and it doesn't add to the counter most likely because the two sets of variables are always the same.
Edit: I did figure out a way for an exact step counter, but it involves conditions which mess with the HP. The problem with that though is I'll see a red flash every time I walk.
Edit: I did figure out a way for an exact step counter, but it involves conditions which mess with the HP. The problem with that though is I'll see a red flash every time I walk.
When you say you try that exact same event, do you refer to the one here or by GRS?
The one here lacks one tiny yet important detail. The code has to be put in a loop (label or regular). If you put the code here in a parallel process with no loop, you will find that at the end of the event, the code will wait for a frame ( 0.0 wait ) before it returns to executing the code from the start.
What this in effect means, is that you're not guaranteed that PlayerXY will take the same value as NewPlayerXY before it, which can lead to occasional step skips.
This should be fixed if you put the whole thing inside a loop, or if you instead of taking the coordinates of the hero, just let PlayerXY take the value directly from NewPlayerXY, given that you initiaize these four variables before running the step counter event.
If for some reason this didn't fix it, try reducing the 0.1 wait to a 0.0 wait.
The one here lacks one tiny yet important detail. The code has to be put in a loop (label or regular). If you put the code here in a parallel process with no loop, you will find that at the end of the event, the code will wait for a frame ( 0.0 wait ) before it returns to executing the code from the start.
What this in effect means, is that you're not guaranteed that PlayerXY will take the same value as NewPlayerXY before it, which can lead to occasional step skips.
This should be fixed if you put the whole thing inside a loop, or if you instead of taking the coordinates of the hero, just let PlayerXY take the value directly from NewPlayerXY, given that you initiaize these four variables before running the step counter event.
If for some reason this didn't fix it, try reducing the 0.1 wait to a 0.0 wait.
@Kazesui
I copied Sated's event that he posted and yes it seems to work with the loop, but I only tested it in short distances. Will it be 100% accurate if I continue walking for +100 steps?
I copied Sated's event that he posted and yes it seems to work with the loop, but I only tested it in short distances. Will it be 100% accurate if I continue walking for +100 steps?
It should be 100% assuming movement speed is kept to 4 or slower. If you increase movement speed, you will have to decrease the length of the wait command.
If the event is running continuously in a loop, a 0.0 wait should work. To regulate wait below 0.1, you typically use various amounts of 0.0 waits.
6 x 0.0 waits = 0.1 sec. At move speed 5, the event needs ~0.67 seconds (4 x 0.0 waits) to go from one tile to another, so that's the maximum amount you're allowed to wait for.
If you keep getting trouble with 0.0 waits, make PlayerXY take the values from NewPlayerXY directly rather than from the coordinate of hero option.
6 x 0.0 waits = 0.1 sec. At move speed 5, the event needs ~0.67 seconds (4 x 0.0 waits) to go from one tile to another, so that's the maximum amount you're allowed to wait for.
If you keep getting trouble with 0.0 waits, make PlayerXY take the values from NewPlayerXY directly rather than from the coordinate of hero option.
This should work.
I tested it pretty well when I put it up but GRS's code is smaller so I'm sure people basically jumped on that instead.
And yeah, just type in 0.0, or just highlight and delete the number in there - that should take it to the lowest possible. If it's in Ace, the lowest is .1 though.
I tested it pretty well when I put it up but GRS's code is smaller so I'm sure people basically jumped on that instead.
And yeah, just type in 0.0, or just highlight and delete the number in there - that should take it to the lowest possible. If it's in Ace, the lowest is .1 though.
Thanks for your help everyone, works now. Does anyone know why a loop works and a parallel process doesn't, seems weird to me?
author=McBick
Thanks for your help everyone, works now. Does anyone know why a loop works and a parallel process doesn't, seems weird to me?
author=Kazesui
in a parallel process with no loop, you will find that at the end of the event, the code will wait for a frame ( 0.0 wait ) before it returns to executing the code from the start.
The reason this is a problem, is that you can have changed the coordinate of the hero within that single frame at the end of a parallel process. When this happens, it won't be registered by the variables since it only checks if there's a difference from the coordinates it loads at the start of the event, with the ones retrieved after the wait.
Adding a loop fixes this problem by making sure the code never reaches the end of the parallel process, and as such, the hidden 0.0 wait at the end of it never happens.
Alternatively, by not reloading the coordinates at the start of every check also works because you eliminate the chance of retrieving bad values from the coordinate option.
At the end of the event script of every parallel process there's a hidden 0.0 wait.
Also, loops themselves don't cause lag. What causes loops to lag is if you have a loop with no waits in it, which practically never terminates.
A loop with a 0.0 wait at the end is pretty much equivalent with a parallel process, and will not cause any more lag than a parallel process running freely with no waits in it. You could say that the hidden 0.0 wait at the end of parallel process events is the reason why they don't seem to lag when you use them (unless you use too many with too much code of course).
Also, loops themselves don't cause lag. What causes loops to lag is if you have a loop with no waits in it, which practically never terminates.
A loop with a 0.0 wait at the end is pretty much equivalent with a parallel process, and will not cause any more lag than a parallel process running freely with no waits in it. You could say that the hidden 0.0 wait at the end of parallel process events is the reason why they don't seem to lag when you use them (unless you use too many with too much code of course).
If that's true then I can speed up parallel processes by adding a loop in it? I ask this because one of my events just isn't fast enough to be useful. Also I thought someone told me that the loop in 2k3 was buggy and caused lag.
There is one bug related to the "loop" command given by rm2k3. When calling the break out of loop command, it will jump to the end of the first loop command it can find, not necessarily the loop you're currently in. This is something which can become a problem if you're using nested loops, and trying to exit the loop before going into a nested loop.
Apart from that, any bug or lag you encounter from loops are likely going to be from bad coding than from problems with rm2k3. You could also make a loop with labels, and you won't have the bug mentioned above either.
As for your question... Yes, if you put a loop inside your parallel process with no waits in it, you will be process the code faster by means of looping faster (the actual commands themselves won't be executed any faster). Whether this is very bad idea or not depends on why you need that extra speed though. Without knowing what your event does or is supposed to do, it's bit hard to say whether it's a bad idea or not.
Apart from that, any bug or lag you encounter from loops are likely going to be from bad coding than from problems with rm2k3. You could also make a loop with labels, and you won't have the bug mentioned above either.
As for your question... Yes, if you put a loop inside your parallel process with no waits in it, you will be process the code faster by means of looping faster (the actual commands themselves won't be executed any faster). Whether this is very bad idea or not depends on why you need that extra speed though. Without knowing what your event does or is supposed to do, it's bit hard to say whether it's a bad idea or not.
Oh so if i just use label loops instead I'll be fine? The event I am talking about checks every tile on the screen and will create a black tile if your character's view is obstructed. To check every tile it takes about 5-10 seconds depending on where the character is located relative to the screen, this can be optimized to reduce the total time to 5-6 seconds. I have to combine 2 pages of coding into one to try it though, as it is now it cycles through 2 pages in the event.
Edit: By my estimate I should save 5.12 seconds since it cycles through 320(Every tile on screen) times which is 320 invisible 0.0 waits.
Edit2: Might save even more time since I only counted one page, but it cycles through 2 pages of an event.
Edit: By my estimate I should save 5.12 seconds since it cycles through 320(Every tile on screen) times which is 320 invisible 0.0 waits.
Edit2: Might save even more time since I only counted one page, but it cycles through 2 pages of an event.
Assuming you can easily check whether a tile is it outside the character's view, then this sounds like a typical task for a loop indeed. Just make sure to actually exit the loop after you have gone through all tiles. By letting the code either execute a wait command or reach the end of the event script, you tell rm2k3 that it can continue to the next event script for that frame (thus preventing lag).
If the check for whether a tile is outside the character's view is big enough, this could still cause lag though, so you'll just have to try it out to figure how well it works.
edit: 320 x 0.0167 = 5.344 seconds
I'm not sure how you're including the extra page, but you would have to do some very peculiar to face extra penalties from it.
If the check for whether a tile is outside the character's view is big enough, this could still cause lag though, so you'll just have to try it out to figure how well it works.
edit: 320 x 0.0167 = 5.344 seconds
I'm not sure how you're including the extra page, but you would have to do some very peculiar to face extra penalties from it.














