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
PepsiOtaku
View playlists
CloseI use FRAPS version 2.9.9 (anything later doesn't work with rm2k3 from what I recall). I then use VirtualDubMod Surround to convert the video to xvid, and resize it to 640x480 for youtube.
Whoa. I found F9, the Fraps record hotkey, is also the system debug. F4 is windowing mode, and F12 seems to be a reset button.
I have a debug code, as part of my System menu already. Is there a way to disable these keys? Especially the F9, because I don't want people just randomly editing numbers. Or better yet, some way to intiate this, so it can be called. Although it's cool to see the variables, I'd like to have this called by event/comment/something other than the key, if it's called at all. Well, if not, some way to shut it off from key input.
I have this code instead (making it redundant, not to mention mine also does teleporation by variable and call event: local event/page by variable).
Anything I can do?
(Something like this, only probably the opposite, if I'm reading this right)
I have a debug code, as part of my System menu already. Is there a way to disable these keys? Especially the F9, because I don't want people just randomly editing numbers. Or better yet, some way to intiate this, so it can be called. Although it's cool to see the variables, I'd like to have this called by event/comment/something other than the key, if it's called at all. Well, if not, some way to shut it off from key input.
I have this code instead (making it redundant, not to mention mine also does teleporation by variable and call event: local event/page by variable).
Anything I can do?
(Something like this, only probably the opposite, if I'm reading this right)
Yes, the RPG Maker hotkeys are:
F4 - Windowed <> Fullscreen
F5 - 640x480 <> 320x240
F9 - Variable/switch editor (IN TESTPLAY ONLY!)
F10 - Stop current event (or restart, if it's an autostart event) (IN TESTPLAY ONLY!)
F12 - Go to title screen
SHIFT - Skip message (IN TESTPLAY ONLY!)
CTRL - Walk through walls (IN TESTPLAY ONLY!)
The F10 feature is sometimes quite useful. Example: I am testing a game and accidentially talk to an NPC which triggers a big fight - and I don't want that. What I do: While the message (e.g. "Hoho, let's have a fight, you losers!") is shown, I press F10 to cancel the event.
The debugging features are only enabled in test play. You can prevent the game from entering test play mode in DynRPG using "RPG::isTestPlay = false;" and you can call the F9 menu manually by using "RPG::system->scene = RPG::SCENE_DEBUG;".
F4 - Windowed <> Fullscreen
F5 - 640x480 <> 320x240
F9 - Variable/switch editor (IN TESTPLAY ONLY!)
F10 - Stop current event (or restart, if it's an autostart event) (IN TESTPLAY ONLY!)
F12 - Go to title screen
SHIFT - Skip message (IN TESTPLAY ONLY!)
CTRL - Walk through walls (IN TESTPLAY ONLY!)
The F10 feature is sometimes quite useful. Example: I am testing a game and accidentially talk to an NPC which triggers a big fight - and I don't want that. What I do: While the message (e.g. "Hoho, let's have a fight, you losers!") is shown, I press F10 to cancel the event.
The debugging features are only enabled in test play. You can prevent the game from entering test play mode in DynRPG using "RPG::isTestPlay = false;" and you can call the F9 menu manually by using "RPG::system->scene = RPG::SCENE_DEBUG;".
Thanks, Cherry.
I think if I'm closing testplay, I'll give a strong hint on how to enable debugging with my mode.
Um... testPlay wasn't a valid member of RPG (neither is TestPlay, despite there being part of the arguments). I typed around, and TestPlayer popped up, which I promptly entered. Which gave me its own error, unqualified id before token. I put it right in onStartup, if that makes any difference. The only thing I can think of is rebuilding all DynRPG codes from scratch and removing TestPlay from as many of them as possible.
I think if I'm closing testplay, I'll give a strong hint on how to enable debugging with my mode.
Um... testPlay wasn't a valid member of RPG (neither is TestPlay, despite there being part of the arguments). I typed around, and TestPlayer popped up, which I promptly entered. Which gave me its own error, unqualified id before token. I put it right in onStartup, if that makes any difference. The only thing I can think of is rebuilding all DynRPG codes from scratch and removing TestPlay from as many of them as possible.
Ah, wrong memory.
It was RPG::isTestPlay
You better put it in onInitTitleScreen, because then the test play will be active until the title screen is shown and thus it will still skip the Enterbrain logo (to make testing faster)
It was RPG::isTestPlay
You better put it in onInitTitleScreen, because then the test play will be active until the title screen is shown and thus it will still skip the Enterbrain logo (to make testing faster)
I don't a title screen. I'm using BetterAEP.
Weird, I guess I do have a title screen. That worked, onStartup didn't.
Thanks Cherry.
Weird, I guess I do have a title screen. That worked, onStartup didn't.
Thanks Cherry.
Yes, onStartup won't work anyway because:
If you want to do anything involving RPG objects on the start of the game, use onInitFinished. But in your case, onInitTitleScreen is better because of the logo skipping.
Do not try to access RPG objects from this function, since the game hasn't been initialized yet.
If you want to do anything involving RPG objects on the start of the game, use onInitFinished. But in your case, onInitTitleScreen is better because of the logo skipping.
It also does it in battle tests. (Which is kinda weird)
Which is the ideal callback for battle if you have no other variables getting returned? Well, I could try them all.
Nevermind, the other one (onInitFinished) works for battle testing.
Which is the ideal callback for battle if you have no other variables getting returned? Well, I could try them all.
Nevermind, the other one (onInitFinished) works for battle testing.
I was trying to make a mouse shooter, similar to what link2112 made.
Kinda like this.
Then I was stumped, because I didn't figure out if it was possible to make a DynRPG plugin that checks if the line of fire was obstructed by a certain terrain id (a wall, in this case)
Kinda like this.
Then I was stumped, because I didn't figure out if it was possible to make a DynRPG plugin that checks if the line of fire was obstructed by a certain terrain id (a wall, in this case)
Couldn't you do that with events though?
I haven't messed with the mouse plugin, but I dabbled in it with the Power mode patch, so I assume the dynrpg version is similar. The Mouse X/Y would probably get stored in 2 variables, and change depending on where the mouse is onscreen. This would be required to display any kind of crosshair or mouse pointer.
You could use 2 more X/Y variables to store the pixel coordinates of the area you shoot at, and additionally 2 more to store the actual tile coordinates (which should be the previous variables / 16), as well as another variable to store the terrain ID. Using those, you should have all you need to make something like that.
The logic would be something like:
When the gun fires, compare the Mouse X/Y with the pixel X/Y
-Using the pixel X/Y, divide by 16 to get the tile's X/Y, and then using those values, "Store Terrain ID" into another variable
-Conditional branch if Terrain ID = wall
-don't do damage
I haven't messed with the mouse plugin, but I dabbled in it with the Power mode patch, so I assume the dynrpg version is similar. The Mouse X/Y would probably get stored in 2 variables, and change depending on where the mouse is onscreen. This would be required to display any kind of crosshair or mouse pointer.
You could use 2 more X/Y variables to store the pixel coordinates of the area you shoot at, and additionally 2 more to store the actual tile coordinates (which should be the previous variables / 16), as well as another variable to store the terrain ID. Using those, you should have all you need to make something like that.
The logic would be something like:
When the gun fires, compare the Mouse X/Y with the pixel X/Y
-Using the pixel X/Y, divide by 16 to get the tile's X/Y, and then using those values, "Store Terrain ID" into another variable
-Conditional branch if Terrain ID = wall
-don't do damage
Useful functions (since this functionality is not in the SDK yet):
In your case, you would use:
function getLowerLayerTileId(RPG::Map *map, int x, int y) {
int ret;
asm volatile("call *%%esi" : "=a" (ret), "=d" (RPG::_edx), "=c" (RPG::_ecx) : "S" (0x4A80CC), "a" (map), "d" (x), "c" (y) : "cc", "memory");
return ret;
}
function getUpperLayerTileId(RPG::Map *map, int x, int y) {
int ret;
asm volatile("call *%%esi" : "=a" (ret), "=d" (RPG::_edx), "=c" (RPG::_ecx) : "S" (0x4A80F4), "a" (map), "d" (x), "c" (y) : "cc", "memory");
return ret;
}
function getTerrainId(RPG::Map *map, int tileId) {
int ret;
asm volatile("movl 20(%%eax), %%eax; call *%%esi" : "=a" (ret), "=d" (RPG::_edx) : "S" (0x47D038), "a" (map), "d" (tileId) : "cc", "memory");
return ret;
}In your case, you would use:
int terrainId = getTerrainId(RPG::map, getLowerLayerTileId(RPG::map, x, y));
TheNecromancer
3160
i used an event and branches to set ranges of the mouse x and y that result in not hitting the target.
so if you shoot, there's an event that checks if your mouse is between 40 and 56 x and 40 and 56 y. which would mean that your mouse is over a blocking tile, so you can't hit a target that's behind it.
it would be nice to have some kind of automated process, instead of setting ranges for every tile you can't shoot through.
so if you shoot, there's an event that checks if your mouse is between 40 and 56 x and 40 and 56 y. which would mean that your mouse is over a blocking tile, so you can't hit a target that's behind it.
it would be nice to have some kind of automated process, instead of setting ranges for every tile you can't shoot through.
Well, I just posted code to get the terrain ID (and even tile ID in both layers)... You could try that^^
This is awesome. I'll use these for my minimap plugin. (Before it was hacked with event data passed from the editor with comment callbacks.
I want some targetting leeway so I can exact target objects (like click on treasure chests and have them get opened, or maybe a movement control for a character, with half of their body being the "same". (I'm showing this number for reference, it's usually hidden)
I've got it set up to move if the X and Y are different. So, two things, first, I need to know the vertical and horizontal diameter X/Y (it's by screen X/Y, I think) of a character, meaning I need to know if the average sprite is 20 by 12 so I can create a hit detect range for the character not to move.And second, the mouse itself is off center. Nvm, I centered it.
Still need the range.
I've got it set up to move if the X and Y are different. So, two things, first, I need to know the vertical and horizontal diameter X/Y (it's by screen X/Y, I think) of a character, meaning I need to know if the average sprite is 20 by 12 so I can create a hit detect range for the character not to move.
Still need the range.
