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
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsKAZESUI'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
[RM2k3] Need help with step counter!
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.
[RM2k3] Need help with step counter!
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).
[RM2k3] Need help with step counter!
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.
[RM2k3] Need help with step counter!
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.
[RM2k3] Need help with step counter!
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.
[RM2k3] Need help with step counter!
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.
Ponder this? A different, but interesting question.
You should be a bit careful about calling people out for not having read what you wrote... just to go on to make a reply to a post which you didn't read carefully yourself.
You seem to justify why you believe the dinosaurs would have been better suited for long term survival, but nowhere did I ask that, nor did I post anything which would imply you needed to clarify it, as I was practically saying they were better suited.
By saying this, you imply that since the dinosaurs are no longer around, that humans are indeed better suited for survival, even though we haven't even existed close to as long as the dinosaurs have. My post was about why you would make this implication.
That aside, I think you should research the actual scientific theories before you go on to making conclusions about them. The meteor didn't just kill off dinosaurs, it killed off lots of other animals and plants as well, and I think you'll have a hard time finding a version of the theory with any scientific backing which says that only dinosaurs died from it.
You seem to justify why you believe the dinosaurs would have been better suited for long term survival, but nowhere did I ask that, nor did I post anything which would imply you needed to clarify it, as I was practically saying they were better suited.
Jparker1984
I was simply wondering how humans survived and dinosaurs didn't. I personaly feel that they were better suited for long term survival then us.
By saying this, you imply that since the dinosaurs are no longer around, that humans are indeed better suited for survival, even though we haven't even existed close to as long as the dinosaurs have. My post was about why you would make this implication.
That aside, I think you should research the actual scientific theories before you go on to making conclusions about them. The meteor didn't just kill off dinosaurs, it killed off lots of other animals and plants as well, and I think you'll have a hard time finding a version of the theory with any scientific backing which says that only dinosaurs died from it.
Ponder this? A different, but interesting question.
author=Jparker1984
I was simply wondering how humans survived and dinosaurs didn't. I personaly feel that they were better suited for long term survival then us.
Dinosaurs lived for millions of years before going down. Humans haven't even done one million yet, and there are lot of reasons to believe we won't even make it to the first million.
So... where do you have proof that we're better suited for long term survival?
[RM2k3] "Label Loop" Issue -- Will sometimes exit loop by itself?
As long as the event script with the charging is handled in a parallel process which is independent from other scripts, then it shouldn't cause lag.
Erase picture doesn't cost as much as show picture, since there is file loading involved in it.
Erase picture doesn't cost as much as show picture, since there is file loading involved in it.
[RM2k3] "Label Loop" Issue -- Will sometimes exit loop by itself?
You're problem comes from a defect in how rm2k3 handles input from certain keyboards, not from the label looping (or the other looping for that matter). For some (not all) keyboards, it will not register you holding down the button, despite it being down, and thus cause a premature release.
What I've done in the past to solve the problem myself is to have a kind of "buffered release". Basically, check for key input multiple times with a 0.0 wait in between if the key has actually been released. If key is held down, you go straight to your usual code, if key is not held down you do another check and do the same thing. I would personally recommend having 6 checks with 0.0 waits in between, since that's about as fast as a player can react anyway ( 0.1 seconds ), and it makes a premature release very unlikely.
This of course means, that you should go back to using labels for your loop, since it just more reasonable than copy pasting the same code many many times.
The reason a 0.0 wait works, is that internally it will stop reading the event script for that frame as soon as it encounters a wait of any kind. In the next frame it will then check if the event has waited long enough. In the case of a 0.0 wait, this will be exactly 1 frame, i.e. 1/60th a second (assuming no lag is preventing the fps from staying at 60).
What I've done in the past to solve the problem myself is to have a kind of "buffered release". Basically, check for key input multiple times with a 0.0 wait in between if the key has actually been released. If key is held down, you go straight to your usual code, if key is not held down you do another check and do the same thing. I would personally recommend having 6 checks with 0.0 waits in between, since that's about as fast as a player can react anyway ( 0.1 seconds ), and it makes a premature release very unlikely.
This of course means, that you should go back to using labels for your loop, since it just more reasonable than copy pasting the same code many many times.
author=Liberty
But yeah, with 2k/3 the Wait 0.0 is great for eliminating lag. I have no idea why it works because, frankly, it shouldn't - but it does.
The reason a 0.0 wait works, is that internally it will stop reading the event script for that frame as soon as it encounters a wait of any kind. In the next frame it will then check if the event has waited long enough. In the case of a 0.0 wait, this will be exactly 1 frame, i.e. 1/60th a second (assuming no lag is preventing the fps from staying at 60).
Games - Tester
Games - Other
