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
XGB's Message Box (RPG maker 2000)
I'm pretty sure he already knows about this plugin (he commented in the original thread). He's probably more interested in the custom font as a png bit, which you don't find in the text plugin.
I've been meaning to add a way to change the font in the plugin (among way too many other things), but not in png format. Having to handle the mapping between symbols manually is not appealing too much to me at the moment.
It's definately possible to do it with dynrpg as a seperate thing, but I think you'd have trouble to use the same font for the default stuff, like default message command, the text in the default menu and so on.
I've been meaning to add a way to change the font in the plugin (among way too many other things), but not in png format. Having to handle the mapping between symbols manually is not appealing too much to me at the moment.
It's definately possible to do it with dynrpg as a seperate thing, but I think you'd have trouble to use the same font for the default stuff, like default message command, the text in the default menu and so on.
Fix direction system (2k3)
@link
You should consider adding some buffering to that event you show in the image.
By this I mean that you should add some 0.0 waits each followed by a key input process where you again check if the input is still 0.
The reason for this is that rm2k3 has some trouble reading certain keyboards and will issue a 0 eventhough the key is clearly being held down, which in this case could lead to player walking unintendedly.
You should consider adding some buffering to that event you show in the image.
By this I mean that you should add some 0.0 waits each followed by a key input process where you again check if the input is still 0.
The reason for this is that rm2k3 has some trouble reading certain keyboards and will issue a 0 eventhough the key is clearly being held down, which in this case could lead to player walking unintendedly.
PepsiOtaku's DynRPG Plugin Emporium!
author=gadesx
So face a direction meanwhile you use only a key is impossible, you have to
use another key for disable the direction fixed, or the same key
pressed one time for fix the direction and another one for disable.
I'm having some trouble getting exactly what you're trying to say here, but I can assure that it is very much possible to create an event script which will allow you to only change face direction whilst holding down a button (I have already done this before).
I don't recall exactly how I did it, but you should be able to do this by using two key input processes, (both with wait until key is pressed unchecked). One will be used to check if the button which locks the player is held down, and the other will check for the directional keys. If a directional key is used, you use a move event facing that direction + a wait in the move event commands. If no direction key is used you just use the move command wait.
Once the locking key is released you will also want to make another move event command which is entirely empty. This will erase the tiny delay of the previous wait such that you can move more or less right away.
that's the gist of it anyway. might be details I forgot.
Insufficient Memory [RM2k3]
write_text only works once per tag, so if you have a text with the tag "option1" then you won't be able to write again using write_text and "option1".
However, you can mix in the text commands into the tag text, meaning you can create variable names with ease.
example:
If you create a loop, where you increase variable 0 with 1 each time, you now get different tags in each iteration. Also, if you trade "text" with
You could easily write some item names from the database depending on variable 1. And of course, there's nothing stopping you from just creating some items in the database which cannot actually be found in the game itself.
There are a couple of other options as well, using hero names, skill names as well.
That's gist of handling this in a loop fashion, and saving some work. If you have several instances showing the same kind of options, this could also be a good way of making sure you only have to change the item names, to make sure the change is done everywhere, where the draw_text is used
However, you can mix in the text commands into the tag text, meaning you can create variable names with ease.
example:
@write_text "option\v[0]", "text", ...
If you create a loop, where you increase variable 0 with 1 each time, you now get different tags in each iteration. Also, if you trade "text" with
"\i[\v[1]]"
You could easily write some item names from the database depending on variable 1. And of course, there's nothing stopping you from just creating some items in the database which cannot actually be found in the game itself.
There are a couple of other options as well, using hero names, skill names as well.
That's gist of handling this in a loop fashion, and saving some work. If you have several instances showing the same kind of options, this could also be a good way of making sure you only have to change the item names, to make sure the change is done everywhere, where the draw_text is used
Insufficient Memory [RM2k3]
Basically what link_2112 said, such specific stuff would be better on the corresponding comment field.
Either way, I took a quick look at it, and there's definately a bug in there which I haven't noticed so far. It has nothing to do with the refresh rate, but rather some kind of memory problem, where the memory usage exponentially grows with each append_line. It works fine as long as you don't use append_line more than roughly 4 times, but after that it gets a bit nasty.
I don't really have time to fix this right now though, so the bug fix will have to wait for a tiny while. You could always try to simply use several "write_text" commands instead though if you don't want to wait for the fix. If you make some heroes, items or skills with the name of the custom menu options, you should be able to easily make them with a loop, similar to that shown in the lower left event in the demonstration project.
Either way, I took a quick look at it, and there's definately a bug in there which I haven't noticed so far. It has nothing to do with the refresh rate, but rather some kind of memory problem, where the memory usage exponentially grows with each append_line. It works fine as long as you don't use append_line more than roughly 4 times, but after that it gets a bit nasty.
I don't really have time to fix this right now though, so the bug fix will have to wait for a tiny while. You could always try to simply use several "write_text" commands instead though if you don't want to wait for the fix. If you make some heroes, items or skills with the name of the custom menu options, you should be able to easily make them with a loop, similar to that shown in the lower left event in the demonstration project.
dynrpg advanced camera control?
It should be perfectly possible to make a plugin like that... to some extent anyway, which would reproduce the effect which you want.
I want to mention that you can still have control of the camera even without a plugin though. There are 2 ways of doing this:
1. Recreating the entire maps as pictures themselves, and you move the image and objects therein rather than the hero
2. Moving the camera alongside an invisible hero, where the hero is following the movements of the picture based hero closely.
In the latter solution, you will still be constrained to having the camera move in entire tiles, but with the addition of some algorithms to compensate for the movement of the camera, there's nothing limiting you from having maps bigger than 20x15 tiles while using pixel based movement
I want to mention that you can still have control of the camera even without a plugin though. There are 2 ways of doing this:
1. Recreating the entire maps as pictures themselves, and you move the image and objects therein rather than the hero
2. Moving the camera alongside an invisible hero, where the hero is following the movements of the picture based hero closely.
In the latter solution, you will still be constrained to having the camera move in entire tiles, but with the addition of some algorithms to compensate for the movement of the camera, there's nothing limiting you from having maps bigger than 20x15 tiles while using pixel based movement
Whatchu Workin' On? Tell us!
Not at the moment, but that's mainly because it's a prototype. Shouldn't be too hard to make it work like the text plugin, such that you have control which pictures are drawn above and below the mode 7 like rendered texture.
Once I get time, I might add something special for the background though, such that it is wrapped "correctly" a la super mario kart. That, any many other tiny nuances which needs to be dealt with before the plugin can be released
edit
Tilting is not possible at the moment, would have to look into that.
Zooming however is perfectly possible in the current version
Once I get time, I might add something special for the background though, such that it is wrapped "correctly" a la super mario kart. That, any many other tiny nuances which needs to be dealt with before the plugin can be released
edit
Tilting is not possible at the moment, would have to look into that.
Zooming however is perfectly possible in the current version
Whatchu Workin' On? Tell us!
It's not quite any of those. Basically, an image is loaded directly into the plugin as a texture, and then a very simple raycasting is used to go from 3d space to 2d space. The essentially means to divide stuff by the z value for the sake of perspective.
It has 4 degrees of freedom, you can move along the three axis (including up), and you can rotate the xy-plane. You can simulate another kind of rotation to a certain extent by manipulating the point of horizon. In short, yes, you can change the perspective
It has 4 degrees of freedom, you can move along the three axis (including up), and you can rotate the xy-plane. You can simulate another kind of rotation to a certain extent by manipulating the point of horizon. In short, yes, you can change the perspective
Whatchu Workin' On? Tell us!
+++ DynRPG - The RM2k3 Plugin SDK +++
include the libraries time.h and stdlib.h,
use the onInitFinished callback and write the line "srand(time(NULL))" in it.
now that this is done, the rand() function will work fine.
So simply use the loadGame callback and write something like
This will write a value between 0 and 99 into variable 69
I'm not entirely sure if this will work though, since the game variables might not have been loaded yet at this point. You might have to just set a boolean variable to true, which waits until you're physically ingame, and then set the random variable once.
The above mentioned should be the only difficulties though
use the onInitFinished callback and write the line "srand(time(NULL))" in it.
now that this is done, the rand() function will work fine.
So simply use the loadGame callback and write something like
RPG::variables[69] = rand()%100;
This will write a value between 0 and 99 into variable 69
I'm not entirely sure if this will work though, since the game variables might not have been loaded yet at this point. You might have to just set a boolean variable to true, which waits until you're physically ingame, and then set the random variable once.
The above mentioned should be the only difficulties though
Games - Tester
Games - Other
