KAZESUI'S PROFILE
Search
Filter
Tracking AI Help [2K3]
Yes there are plugin(s) for this.
Following the hero without getting stuck in terrain should be possible with anti-freaks pathfinding plugin. To see if the hero is within the visible field of the boss can be done with my line of sight plugin, however you'll have to add event code yourself to prevent the "not just behind a tree" scenario from happening, possibly by checking how far away the hero is as well.
Following the hero without getting stuck in terrain should be possible with anti-freaks pathfinding plugin. To see if the hero is within the visible field of the boss can be done with my line of sight plugin, however you'll have to add event code yourself to prevent the "not just behind a tree" scenario from happening, possibly by checking how far away the hero is as well.
Whatchu Workin' On? Tell us!
Been working on a revamped version of my Particle Effects Plugin. I didn't really like the old one, because if you'd try to create streams of particles with it, it would often start lagging. That, and the identifying the effects by a number, which could be different from each playthrough, depending on when and where you save didn't seem quite ideal to me as well. So that was changed into actual names, similar to that of the text plugin, and the new version supports both single bursts of particles as well as streams, which you simply need to start once, and they will run until you give it a stop command.
Through tests, I noticed that my computer could handle a stream of until around 24,000 particles before the fps started dropping below 60 ( when using now picture file, and when all particles are only 1 pixel big that is ).
Here's a tiny video demonstrating the new version.
Through tests, I noticed that my computer could handle a stream of until around 24,000 particles before the fps started dropping below 60 ( when using now picture file, and when all particles are only 1 pixel big that is ).
Here's a tiny video demonstrating the new version.
What's the Longest You've Needed To Stay Awake?
Probably around 85 hour-ish, cuz military can be a bitch.
Towards the end of the mandatory military service, we had to go through the dreadful Hell Week, which basically meant doing rough outdoor military exercises for around a week with no food or sleep ( with the "week bit" luckily being cut down to 3 and a half day.. roughly.
One time event though, and never been close to that since, thankfully.
Towards the end of the mandatory military service, we had to go through the dreadful Hell Week, which basically meant doing rough outdoor military exercises for around a week with no food or sleep ( with the "week bit" luckily being cut down to 3 and a half day.. roughly.
One time event though, and never been close to that since, thankfully.
[RM2k3] Need help with step counter!
Yes, using the trigonometric event solution to check every tile is probably going to be a rather bad idea. You would have to make several clever optimizations for that to work, and even then there's no guarantee it would be efficient.
As for DynPlugins, you could indeed say they are working "outside" the rm2k3 engine. Calling a the plugin with a comment or so is not entirely free though in terms of performance, but I suppose you could still try.
As for DynPlugins, you could indeed say they are working "outside" the rm2k3 engine. Calling a the plugin with a comment or so is not entirely free though in terms of performance, but I suppose you could still try.
[RM2k3] Need help with step counter!
Nope, you don't. The regular loop is not just a little faster, it's tremendously faster than the parallel process. Within a loop, it can execute 10,000 commands within a single frame before it times out. If you reach the limit of 10,000 commands within one frame, it's time to rethink the code (probably even way before that).
Assuming you execute 10 event commands per tile, that would mean 3,200 commands, which is a lot, but still significantly below the limit. At this point, you really really want to tell rm2k3 that it can stop executing this code, such that it can move on to other event scripts. If you don't you'll be executing 6,800 more lines of code which does practically nothing useful before it can move on to the other event scripts. This is very likely to cause lag.
Assuming you execute 10 event commands per tile, that would mean 3,200 commands, which is a lot, but still significantly below the limit. At this point, you really really want to tell rm2k3 that it can stop executing this code, such that it can move on to other event scripts. If you don't you'll be executing 6,800 more lines of code which does practically nothing useful before it can move on to the other event scripts. This is very likely to cause lag.
[RM2k3] Need help with step counter!
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.
[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.













