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
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
+++ DYNRPG - THE RM2K3 PLUGIN SDK +++
Posts
drenrin2120
View playlists
Close
TheNecromancer
3160
In 2k3 when you tell an event to move, it's coordinate is instantly changed while the sprite moves at whatever speed set in the event. Which is pretty much always slower.
Is it possible to change this in any way? or is that outside of what Dyn can do?
I want to control how long it takes an event to be considered in the next tile, for hit detection. Just a random thought I had.
Is it possible to change this in any way? or is that outside of what Dyn can do?
I want to control how long it takes an event to be considered in the next tile, for hit detection. Just a random thought I had.
I actually prefer this behavior for a variety of reasons. Most notably it rids latency associated with any sort of coordinate tracking you're doing.
What I'd suggest doing for your desired behavior is do your tracking as normal, and then if it detects a hit, wait some time (say 0.1s) and check for collisions again. The wait time depends on how fast your events are moving.
What I'd suggest doing for your desired behavior is do your tracking as normal, and then if it detects a hit, wait some time (say 0.1s) and check for collisions again. The wait time depends on how fast your events are moving.
ENI
39
Iorana guys.
I have a little problem.
I'm making some sort of "interesting" plugin (comming soon), but I have an issue with onComment callback.
I get a String by parameter here; i don't have any problems getting and handling common plain Strings ("hi", "1234" ,"f******ck xD"), but if I try to get a String by Hero name (N7, NV8, etc...), i just obtain a zero-length String.
Obviously, I'm doing something wrong, but I don't know what. A important fact, I'm not know much C++, so i'm developing my plugin most in ANSI-C (I'm parsing the string at char* ). Anyways, here is my code where I'm getting the string:
It's weird, beacuse this works fine with plain strings.
Any ideas?
Maururu... bye
I have a little problem.
I'm making some sort of "interesting" plugin (comming soon), but I have an issue with onComment callback.
I get a String by parameter here; i don't have any problems getting and handling common plain Strings ("hi", "1234" ,"f******ck xD"), but if I try to get a String by Hero name (N7, NV8, etc...), i just obtain a zero-length String.
Obviously, I'm doing something wrong, but I don't know what. A important fact, I'm not know much C++, so i'm developing my plugin most in ANSI-C (I'm parsing the string at char* ). Anyways, here is my code where I'm getting the string:
//text variable is already declared in this way: const char *text;
text= (char*)(parsedData->parameters[0]).text;
It's weird, beacuse this works fine with plain strings.
Any ideas?
Maururu... bye
Kazesui
5797
You're not the first one to get trouble with it. Didn't work for me either when I tested it. You can do the same as me and create work arounds though, creating special commands within a string which you format into hero names, making use of
That's what I did. By similar means you could get skill, item and condition names (and descriptions).
doesen't seem to work. Maybe that's why the the N1 for hero names isn't working?
Also, although not related, I think the casting the text into a char pointer is superfluous, since it's already a char array in the parsedData object.
RPG::dbActors[n]->name
That's what I did. By similar means you could get skill, item and condition names (and descriptions).
RPG::actors[n]->name
doesen't seem to work. Maybe that's why the the N1 for hero names isn't working?
Also, although not related, I think the casting the text into a char pointer is superfluous, since it's already a char array in the parsedData object.
ENI
39
author=Kazesui
...Also, although not related, I think the casting the text into a char pointer is superfluous, since it's already a char array in the parsedData object.
GCC warns me that I need to cast it, ( I Think GCC doesn't like const char* to char* conversion), so, here it is.
Yeah, i think that's the problem ( it's a little stupid obtain the hero name for scratch, isn't? ). Anyways, it's not SOOOO important this function ( really, I only needed it for the demo, allowing users to test custom values), but yes, important or not, this is a bug, ( i guess).
Well, little happy to see that's not my fault.
Maururu... bye
Well RPG::dbActors->name will give you the name of the hero IN THE DATABASE. If the name was changed, you will still get the old name.
RPG::actors->name does return the current name, but only IF IT WAS CHANGED. It returns "\x01" when it wasn't changed (i.e. when it would be the same as RPG::dbActors->name".
That's why you should use RPG::actors->getName() instead, this does the dirty work for you. (But this still doesn't explain why N1, etc. doesn't work in onComment. I will check it, though.)
RPG::actors->name does return the current name, but only IF IT WAS CHANGED. It returns "\x01" when it wasn't changed (i.e. when it would be the same as RPG::dbActors->name".
That's why you should use RPG::actors->getName() instead, this does the dirty work for you. (But this still doesn't explain why N1, etc. doesn't work in onComment. I will check it, though.)
Can anyone do script that allows to use icons (16x16 png images) for messages/items/etc.? Pretty much like icons in VX.
I mean, there are lots of things you can do with EXFONT, but it still is 1-bit and doesn't always look good. Icons would be invoked by \i and will be stored in PROJECTDIR/Icons. Extension would be not needed as it would be using pngs anyway.
I mean, there are lots of things you can do with EXFONT, but it still is 1-bit and doesn't always look good. Icons would be invoked by \i and will be stored in PROJECTDIR/Icons. Extension would be not needed as it would be using pngs anyway.
TheNecromancer
3160
I'm working with the Date & Time plugin made by elvissteinjr. I dunno if this is something I would need to contact him about, or if somebody else can change this, or instruct me how to change it(unless it's overly complicated).
I'd like to see the in-editor command altered so that instead of:
@GetDateFromTimestamp 13000000, 1, 2, 3
I can use:
@GetDateFromTimestamp \v{4}, 1, 2, 3.
That way I can set and manipulate the Timestamp with other events and have it give that date.
I had a good idea of how to use the plugin to create an in-game flow of time, but it ended up not working because the commands don't let me use a variable reference for getting a date from a timestamp >.>
Also, the size of the number required to show today's timestamp is so large that any attempt to get a date from it will cause an overflow error. It can't take negative numbers, either. So you can't get a date before 1970 directly from a timestamp.
It's still a cool plugin, just not as flexible as I would have hoped.
I'd like to see the in-editor command altered so that instead of:
@GetDateFromTimestamp 13000000, 1, 2, 3
I can use:
@GetDateFromTimestamp \v{4}, 1, 2, 3.
That way I can set and manipulate the Timestamp with other events and have it give that date.
I had a good idea of how to use the plugin to create an in-game flow of time, but it ended up not working because the commands don't let me use a variable reference for getting a date from a timestamp >.>
Also, the size of the number required to show today's timestamp is so large that any attempt to get a date from it will cause an overflow error. It can't take negative numbers, either. So you can't get a date before 1970 directly from a timestamp.
It's still a cool plugin, just not as flexible as I would have hoped.
Kazesui
5797
Most likely, you should be able to write V4 as parameter to send in the value of variable 0004. This will typically apply to every plugin which uses the comments as an interface.
That won't help you with the size of the ingame variables though, as you'll probably end up limited by the 7 digits you can use within a variable.
That won't help you with the size of the ingame variables though, as you'll probably end up limited by the 7 digits you can use within a variable.
TheNecromancer
3160
author=Kazesui
you should be able to write V4
Ah, I didn't think to write it like that. It works. Thanks!
I'm going to offset the year so luckily I don't need the high numbers.
I'm using the Particle Effect plugin and the explanation of setting the angle is a little vague.
@effect_angle ( start angle, end angle )
Sets the angle for the particle spray.
IMPORTANT: the start angle has to be lower than the end angle.
Say you want a particle spray between 15 degrees and 345; This should be done
by using the values 345 and 375.
It doesn't specifically say where the starting point is. Which direction is 0 degrees? Yeah, I can test to find out but it should be stated.
Shouldn't it say "Sets the angle range for the particle spray"?
Also, what you are saying as IMPORTANT doesn't immediately make sense to me. You are saying the start angle has to be lower than the end angle. From the example 15 seems to be lower than 345, so what's the problem? I assume by "lower angle" you mean more acute but without any points of reference I can't determine that without blind experimenting. I can't visualize anything.
That also assumes that I know that if you go more than 360 degrees, it will loop back around and that is acceptable. These kinds of things should be explicitly stated for those who aren't familiar with this stuff.
In your demo for particle effects in one of the commands for setting a color you typed in 0, 255, 255, 255. Was that an error? Also, there is no instruction so when I loaded the game I didn't know what to do. I had to open it in the editor to figure out I can press shift to scroll through the maps. Which, btw, you didn't include them all in the shift pressing. I had to move the hero start position to see the others like the monster with flaming farts xD
This plugin is fun to play with!
Kazesui
5797
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)
gadesx
307
I remember that I tried make a rain effect with your plugin Kazesui,
but lol, its not possible hehe. I have made some other things like "lava particles" that go up the screen and work well.
but lol, its not possible hehe. I have made some other things like "lava particles" that go up the screen and work well.
Kazesui
5797
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
TheNecromancer
3160
author=Kazesui
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).
What I meant by starting point is a 0 degree angle. Which direction is it? I know now that it's East. If I want to know what numbers to use to shoot particles in a certain range I would need to know where the starting point is, 0, to determine which direction 30 is and which direction a positive increase will take me. Right now, I have to make an event to test things out. Not that it's, omg, a big deal, but it would save some time to have it all laid out.
So what I'm suggesting is that you put in the description that a 0 degree angle will go East, with an example that a 90 degree angle will go North. Maybe that a 360 degree angle will go East as well, with an example that a 450 degree angle will go North.
Does a positive increase make it go clockwise or counterclockwise? I don't actually know yet. These are the kinds of things I would like to see in the readme.
So basically, the example was meant to explain you can't write 345 to 15
It's a little confusing(to me, at first, not having worked with angles much in my life), so maybe a better example should be used. When I think of shooting particles between 15 and 345 that could mean shooting to the large range between 15 and 345 or the small range between 345 and 375. I don't know what usual behavior for this kind of thing is.
So maybe explain that particles will start shooting in the first number and go clockwise(or whatever) until it hits the second number so if you want a low numbered angle to be the end number just add 360 to it. To make it clear how the plugin will operate.
@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).
The error I see is that the readme says there are 3 parameters, for RGB, but in that event you put 4 parameters 0, 255, 255, 255.
@effect_color( red, green, blue )
Sets the initial colour of the particles. the values for red, green and blue components range from 0 to 255
Also, if there are other things which seem horribly vague in the readme, do by all means tell me.
Oh, no worries there heh I'm getting really into using these plugins, so I'll be using them a lot from now. I'll have stuff to report.
Actually, I'm having a strange issue with the Text plugin drawing something I didn't ask it to. The text string has something like
"\v[5]:\v[6]"
Kazesui
5797
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.
