Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
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
Requesting RPG MAKER 2003 Help - Key Input and Conditional Branch Issues.
Have you considered using an "auto-start" event to limit the movement (and simply adding in possibility of accessing menu and whatever else per key input)?
Path Finding
author=Streak
The enemy AI is probably the toughest part of this system. I've tried to build something but the AI is very difficult to do. Aurora Wings AI is very complicated and confusing to understand, I am still trying to figure out how the author build it.....
I'm pretty sure mine won't be any less complicated. If anything, it will be even more complicated, just that I'll hopefully have a tutorial up and running beside it at some point, explaining most of the peculiar sides of it.
+++ DynRPG - The RM2k3 Plugin SDK +++
Yes, and I was just emphasizing the trickiness of finding a way to word it in a non ambigous way which is still easy to understand.
Either way though, I should have included that the range goes clockwise, and probably that 0 degrees equals "east", no disagreeing there.
I "think" that it's possible to use negative numbers, but I wouldn't be surprised if they didn't (I don't remember the exact implementation of the randomizing right now).
Something I should probably add as well, especially if it turns out not to be possible.
As far as I know, Cherry is the one dealing with uploading of stuff onto his site, so that's out of my control, and not sure why. A guess could be that it's related to how the particle plugin was finished earlier and Cherry getting real busy sometime after that, so he's probably just not thought of it to put it up there yet, or something.
Either way though, I should have included that the range goes clockwise, and probably that 0 degrees equals "east", no disagreeing there.
I "think" that it's possible to use negative numbers, but I wouldn't be surprised if they didn't (I don't remember the exact implementation of the randomizing right now).
Something I should probably add as well, especially if it turns out not to be possible.
As far as I know, Cherry is the one dealing with uploading of stuff onto his site, so that's out of my control, and not sure why. A guess could be that it's related to how the particle plugin was finished earlier and Cherry getting real busy sometime after that, so he's probably just not thought of it to put it up there yet, or something.
+++ DynRPG - The RM2k3 Plugin SDK +++
Ah, a thing I forgot to mention in my reply up there, and also took for given since within mathematics, 0 degrees is generally always at "the east" and then typically going counter clockwise around. In the computer wordl however, y is often reverse of that of a typical mathematical function with postive y going downwards rather than up, meaning it should be going clockwise around here. Stuff which might not be as intuitive I guess.
Also at the confusing part of the size of the numbers within the parameters, there pretty much has to be a trade off between being fully understandable, and also actually being correct. Exactly because 15 and 375 degrees are pretty much equivalent, it could be just as confusing to another person to say that the spray would simply continue clockwise until it hit the second parameter, since it's often typical to think of angles as number between 0 to 359 (depending on application of course), which could bring about people thinking that 345 to to 15 degrees would work, which it plain just don't because the number 15 itself is lower than the number 345, eventhough they are equivalent as angles.
This is pretty much just a problem for the ambiguity when going when cross the 360 degree threshold. Choosing any range from 0 to 360 gives no problems when the lower number is given as the first parameter. 0 to 10 works perfectly fine for example, despite being low numbers.
Also yeah, that would probably be a mistake.
I think you're supposed to prefix the effect number you wish to configure in front of every attribute you wish to change, so.... any attribute not having the "effectID" as first parameter is probably lacking that (... might be quite a few, and I think I even forgot it sometimes in the demonstration project as well. I think I fixed it, but I'm not entirely sure I remembered it for all the various effects)
@Text plugin trouble, have you tried adding another paramter just called end after the last one in whatever command you used? It's not explictely stated in the readme for the @write_text command, but if you don't use any of the optional parameters, you should still end it with and end or just end it with a comma. This is because of a bug with the SDK. If the last parameter is a text string, the string isn't terminated properly and might contain additional letters.
If this shouldn't fix your bug, then checking the project would be a cool way of finding what's wrong. Also, are you using the latest version of the Text plugin?
Earlier version might include bugs which were fixed later on.
Also at the confusing part of the size of the numbers within the parameters, there pretty much has to be a trade off between being fully understandable, and also actually being correct. Exactly because 15 and 375 degrees are pretty much equivalent, it could be just as confusing to another person to say that the spray would simply continue clockwise until it hit the second parameter, since it's often typical to think of angles as number between 0 to 359 (depending on application of course), which could bring about people thinking that 345 to to 15 degrees would work, which it plain just don't because the number 15 itself is lower than the number 345, eventhough they are equivalent as angles.
This is pretty much just a problem for the ambiguity when going when cross the 360 degree threshold. Choosing any range from 0 to 360 gives no problems when the lower number is given as the first parameter. 0 to 10 works perfectly fine for example, despite being low numbers.
Also yeah, that would probably be a mistake.
I think you're supposed to prefix the effect number you wish to configure in front of every attribute you wish to change, so.... any attribute not having the "effectID" as first parameter is probably lacking that (... might be quite a few, and I think I even forgot it sometimes in the demonstration project as well. I think I fixed it, but I'm not entirely sure I remembered it for all the various effects)
@Text plugin trouble, have you tried adding another paramter just called end after the last one in whatever command you used? It's not explictely stated in the readme for the @write_text command, but if you don't use any of the optional parameters, you should still end it with and end or just end it with a comma. This is because of a bug with the SDK. If the last parameter is a text string, the string isn't terminated properly and might contain additional letters.
If this shouldn't fix your bug, then checking the project would be a cool way of finding what's wrong. Also, are you using the latest version of the Text plugin?
Earlier version might include bugs which were fixed later on.
+++ DynRPG - The RM2k3 Plugin SDK +++
Yes, it's currently horrible at "particle streams". It doesn't like it if you start too many instances of any given effect, which is typically what you'd do for a stream of particles like that of a fire or rain (a single burst of 500 particles seem to work far better than 10x bursts of 50 particles)
It might be possible to be clever about it, in terms of starting a new instance of a particle effect less often, and just increase the amount of particles with a large random x, y offset.
This is pretty much one of the biggest reasons I want to rewrite the Particles plugin though, such as to make "streams" far more performant
It might be possible to be clever about it, in terms of starting a new instance of a particle effect less often, and just increase the amount of particles with a large random x, y offset.
This is pretty much one of the biggest reasons I want to rewrite the Particles plugin though, such as to make "streams" far more performant
+++ DynRPG - The RM2k3 Plugin SDK +++
Didn't notice this edit until now.
Thanks for pointing out some of the more vague stuff which I just don't think of when I'm writing these readme files.
I'm working on some Pretty big changes of that particular plugin (pretty much rewriting it) to fix some stuff I'm not satisfied with. A lot of the commands will probably stay similar though so I'll make sure to make some changes to the readme.
While I'm at it though, I could explain some of the stuff here
Yep, should probably have been "angle range".
Also, there is no "starting" point. You can use any degree you like from as a high a negative number you can get from 31 bits to an equally high positive one (Note, I "might" be wrong about the negative number part, but I think it's implemented).
The "Important part" is in referring to how you can't leave the higher angle as the first parameter, because the plugin don't handle cases like that. Doing so will most likely end up with no particles showing on the screen
So basically, the example was meant to explain you can't write 345 to 15 degrees to only get the 30 degree spread between them (cuz then, the higher number would come first), so you'd have to write 345 to 375 to get an equivalent range (15 to 345 would you give you a 330 degree spread instead). Mathematically, 375 degrees is pretty much equivalent to 15 degrees, which is why it can be used instead.
@color error? I don't have the demo here atm, so I can't say for sure if it's right or wrong, but I don't see a problem with it as shown there. It would set the color (either start or end) to white of effect #0 (r,g,b components all having their maximum value, 255).
Also, that was actually my original intent, at having people place the hero starting position at different maps to view the different effects, since you were supposed to play around in the rpg maker editor anyway to view the event containing the set up of the effects to better learn them. The shift thing was only added in later for the sake of the video (This should also be why the flame farting monster shouldn't haven been included in the "shift" teleporting if my memory hasn't failed me)
Also, if there are other thing which seem horribly vague in the readme, do by all means tell me. I could most likely need some straightening up in terms of writing those (Mostly written in a hurry once I'm done with all the technical stuff anyway, so probably very prone to all kinds of obscure stuff)
Thanks for pointing out some of the more vague stuff which I just don't think of when I'm writing these readme files.
I'm working on some Pretty big changes of that particular plugin (pretty much rewriting it) to fix some stuff I'm not satisfied with. A lot of the commands will probably stay similar though so I'll make sure to make some changes to the readme.
While I'm at it though, I could explain some of the stuff here
Yep, should probably have been "angle range".
Also, there is no "starting" point. You can use any degree you like from as a high a negative number you can get from 31 bits to an equally high positive one (Note, I "might" be wrong about the negative number part, but I think it's implemented).
The "Important part" is in referring to how you can't leave the higher angle as the first parameter, because the plugin don't handle cases like that. Doing so will most likely end up with no particles showing on the screen
So basically, the example was meant to explain you can't write 345 to 15 degrees to only get the 30 degree spread between them (cuz then, the higher number would come first), so you'd have to write 345 to 375 to get an equivalent range (15 to 345 would you give you a 330 degree spread instead). Mathematically, 375 degrees is pretty much equivalent to 15 degrees, which is why it can be used instead.
@color error? I don't have the demo here atm, so I can't say for sure if it's right or wrong, but I don't see a problem with it as shown there. It would set the color (either start or end) to white of effect #0 (r,g,b components all having their maximum value, 255).
Also, that was actually my original intent, at having people place the hero starting position at different maps to view the different effects, since you were supposed to play around in the rpg maker editor anyway to view the event containing the set up of the effects to better learn them. The shift thing was only added in later for the sake of the video (This should also be why the flame farting monster shouldn't haven been included in the "shift" teleporting if my memory hasn't failed me)
Also, if there are other thing which seem horribly vague in the readme, do by all means tell me. I could most likely need some straightening up in terms of writing those (Mostly written in a hurry once I'm done with all the technical stuff anyway, so probably very prone to all kinds of obscure stuff)
Path Finding
It's two different algorithms. Mine is Dijkstra and the one of the plugin is A* (pronounced A star). Basically, A* is faster in finding a path from point a to point b, however Dijkstra is better if you have a bunch of points and you wish to know which is closer to a point a.
Although the C++ will probably give a considerably performance speed even when searching individually (depending on amount of potential targets) I don't think it has an actual way of determining the amounts of steps needed, which is kind of crucial for this kind of system, since accuracy of the actions themselves are more important than performance (i.e. unlike an ABS for example, you can allow yourself some "thinking time" for the AI of a turn based tactical system).
I might make my own pathfinding plugin based on Dijkstra's algorithm sometime in the future (but my plugin list to write is starting to grow, and there's lot of stuff to do aside from that as well).
Although the C++ will probably give a considerably performance speed even when searching individually (depending on amount of potential targets) I don't think it has an actual way of determining the amounts of steps needed, which is kind of crucial for this kind of system, since accuracy of the actions themselves are more important than performance (i.e. unlike an ABS for example, you can allow yourself some "thinking time" for the AI of a turn based tactical system).
I might make my own pathfinding plugin based on Dijkstra's algorithm sometime in the future (but my plugin list to write is starting to grow, and there's lot of stuff to do aside from that as well).
Path Finding
The immense technical aspect of tactical battle systems would be of the reasons why they are that rare, yes. I've seen a few tbs for rm2k3, but they're usually restricted to by step by step movement, and AI who can't walk around obstacles, pretty much because you'd have to implement something like explained in this tutorial to avoid it (for generic situations anyway).
So basically, yeah, this is one of the most complicated systems you can attempt to build if you want to do it "right" (i.e. typical movement selection + an AI which can make some sensible choices, given some complexity to the options available)
Will see at demo. Wanted to have a few skirmishes prepared before doing so, but ended up never happening thus far.
So basically, yeah, this is one of the most complicated systems you can attempt to build if you want to do it "right" (i.e. typical movement selection + an AI which can make some sensible choices, given some complexity to the options available)
Will see at demo. Wanted to have a few skirmishes prepared before doing so, but ended up never happening thus far.
Path Finding
The plan has been to still complete, just that I haven't really had the neccessary time to do it yet, since these behemoth tutorials require quite a bit of time.
Also, while AI movement and attacks was part of my plan for the part 4 of this series, I wasn't planning on doing much more than explaining how to make it move and attack directly, and on range.
While it would be very possible to include healing, support and aoe attacks (which my actual version does), alone the basic AI is probably going to be considerably complicated to explain (probably quite more so than this one, part 2, even)
Also, while AI movement and attacks was part of my plan for the part 4 of this series, I wasn't planning on doing much more than explaining how to make it move and attack directly, and on range.
While it would be very possible to include healing, support and aoe attacks (which my actual version does), alone the basic AI is probably going to be considerably complicated to explain (probably quite more so than this one, part 2, even)
Games - Tester
Games - Other
