+++ DYNRPG - THE RM2K3 PLUGIN SDK +++

Posts

author=Corti
Question:But how would you detect that it was drawn that frame?
RollOn1 and RollOn2 don't really do anything. Probably because most windows are not shown with an inflateRect().
[...]window->image->width or [...]window->image->height are both zero when an RPG::Window is not present or was deleted.

bool winPresent;
if (scene == RPG::SCENE_MENU)
{
if (RPG::menu->winSkills->image->width != 0)
{winPresent = true;} else {winPresent = false;}
} else {
if (RPG::battleData->winSkill->image->width != 0)
{winPresent = true;} else {winPresent = false;}
}

author=Corti
Question 2:What is that tooltipp window with the item/skill-description on top called and is there a pointer to it?
In battle the winSkill has the same structure as RPG::menu->winSkills but doesn't use the pointer stemming from RPG::SceneMenu. The RPG::menu->winSkills and (->winItems) is not initialized / used in battle (or BattleTest, at least).
It is probably just linked to the basic RPG::Window structure in the headers.

Open BattleData.h and go to line 70. Replace
Window *winSkill; with WindowMenuSkill *winSkill;
And in line 71 replace
Window *winItem; with WindowMenuItem *winItem;

Access with RPG::battleData->winSkill->winInfo->image->height or other stuff.
Hey, bugmenot, I believe I send you mail, but barring a massive RPS+ overhaul...

Is there any way to make it so when I use Item (or some other command), it always executes first, before the monster turns? This would be a quick fix possibly for the fact that it craps out after checking (assuming this isn't a lag causing the order of events).
@PepsiOtaku & Bugmenot: Thank you :-D That helped!

Edit @PepsiOtaku:
Window->getSelected() fits best for checking if the window is shown.
I noticed that choiceTimer is reset for a frame when scrolling to rows that are not in the visible part of the window.

Edit @bugmenot:
In the VisuMenu-Fix, you gave this line:
Skill(Entries per row, battle)=4A0E92,%2
In my case, this leads to an error in battle. The main-menu version works.

author=Maker
AccessViolation in Module RPG_RT.exe in with address 004A0E92 and offset 00000 of type Write occured.

One more thing:
Cherry once gave me this:
Offset 0xC8431 (1 Byte, signed): Skillmenuheight. Change from 0x50 (4 Lines) to 0x60 (5 Lines).
Your VisuMenu seems to overwrite that. If i change that after VisuMenu is applied by using *reinterpret_cast<unsigned char *>(0x4C9031) = 0x60, the game crashes when calling the menu.




Is there any way to make it so when I use Item[...]
Sounds like the entire battle engine would need to be ripped out and replaced to get most things done that you and other people want. I thought the battle sequence lists all actions done / to-be-done in battle in a list that fills up consecutively when someone / the enemy decides their turn? Shifting the order around might cause problems, or at least I do not know how that thing is structured. Yet.


author=Corti
Skill(Entries per row, battle)=4A0E92,%2
Sorry, a typo, I was tired I guess. It needs to be:
[QuickPatches]
Skill(Entries per row, battle)=4A0E93,%2

author=Corti
Offset 0xC8431 (1 Byte, signed): Skillmenuheight.
[QuickPatches]
VM:SkillMenu(width)=4C9026,#320
VM:SkillMenu(height)=4C902B,#80
VM:SkillMenu(y)=4C9032,#64

An appropriate callback might have caused less of a mess than this Visu-something did. Might have spared me that all-nighter, too. Sigh...
Remind me to do that. Somehow. Someday.
Well, that's true. But since I'm already getting issues (whenever item is used before an RPS skill, the "event script referenced an item that does not exist"), you can try it as long as it's a quickpatch or something I can remove.



(It always triggers if I use item before an RPS skill and it uses afterwards, I tested it. If I wait until the skill does its thing and then use Item, it runs fine and says the item exists)

At the very least, some research to figure out how to get it to do turns in order versus multiple enemies using skills in rapid succession (some of which interrupt switch skills). Or simply fail the use of such a skill if an RPS skill would interrupt it.
Hey, thanks!

The row typo fixed it. item-rows was the same, increased it by one as well, now it works.

VM:SkillMenu(height)=4C902B,#80
VM:SkillMenu(y)=4C9032,#64

Those two work fine:

VM:SkillMenu(width)=4C9026,#320
This works from 320 to 256px. Dercreasing the value to 254 or below and the width gets:
#256 = 256px
#255 = 511px

255 = 011111111
511 = 111111111

This works:
VM:SkillMenu(width)=4C9026,C800
a little-endian hex-tippex, i guess O_o

author=Wise man once told me:
Die Art und Weise, wie der dynloader mittels Größenangabe % und # im RAM patcht is scheinbar anfällig gegen Updates / Sicherheitsupdates seitens Windows / OS.

Oh, that was you!

author=bugmenot
Might have spared me that all-nighter, too.

I appreciate your nights :-p
author=Corti
Dercreasing the value to 254 or below and the width gets:
#256 = 256px
#255 = 511px
Those # and % are acting up again.
The numbers @ 4C9026 are 40 01 00 00 (= 320, little endian). For some reason the # overwrites only the first byte FF 01 00 00 (= 511)

Replace the QuickPatch with this line in some plugin:
*reinterpret_cast<int *>(0x4C9026) = winWidth;

author=Corti
This works:
VM:SkillMenu(width)=4C9026,C800
Yes, but doing that with every little thing would be a pain. Trashing the QuickPatch feature from the dynloader.dll and replacing it with a working quickpatcher plugin is a pain, too. I can try to brush up on necessary C++ knowledge...

author=Corti
Oh, that was you!
Oh, that was me! Thought I was paranoid when the dynloader.dll changed itself by itself.
Thanks again!

btw. that command Window, ( BattleData->winCommand ), since that is of class "Window" too, does that have an "Entries per row"-initialisation somewhere too?
No, but you can make one:
[QuickPatches]
CmdWinBig=4950C2,C6400401EB07,4950CF,684C00000068440000006A008BCF90
CmdWinBig(CmdsPerRow)=4950C5,01
CmdWinBig(width)=4950D0,#76
CmdWinBig(height)=4950D5,#68
(These are not meant to be used seperately.) (Height needs to be adjusted when switching small/big windows.)

Some patches (VisuCommands.ips and VertiCommands.ips) are in the way (code-wise), so this won't work in those cases (someone is going to stumble into that problem).
Hello, is there any way to change the position of heroes in battle?

My game consists of 100+ heroes (it's a pokemon game), so i'm using automatic battle placement.

But the angle of the heroes isn't what i want.
Using the terrain menu, i can only make the alignment like: | or \ or anywhere in between. I'm trying to look for a way to align like /.

Thanks

Or fiddle around with RPG::terrains[ID]->gridInclination

author=raonak
Hello, is there any way to change the position of heroes in battle?
Anyhow, download dyn.20 if someone is gonna submit a plugin or not.

You can also try to reverse the angle of inclination. Apply the dyn.20 patch, open the DynRPG.ini and add the following below [QuickPatches]:
RevInc=47FB33,44,47FB72,44,47FBA3,44,47FBE4,44,47FB4B,00,47FB8A,00,47FBBB,00,47FBFC,E0
The blue numbers are a change of the x coordinate towards the left. 8 bit hexadecimal values. 00 -> 7F is 0 -> 127 and 80 -> FF is -128 -> -1
First blue one is for back attack, 2nd = surround (left flank), 3rd = surround (right flank), 4th = normal/initiative.

edit:
This doesn't apply to autoplaced enemies.
That kinda scrunches everyone in a line to the left.

Is there a way to get a sharper angle instead? With me, I have room because my monsters are all on one side, so I could conceivably have characters halfway out on the screen. Instead, it's like the party likes to step on teammate's heads, and I don't get to see their lower sections without manual config.



(Black is the line, red is where it could actually extend to)

Still looking for a quickpatch to avoid the item crash bug. It's kinda an annoying issue (doesn't come up that much, but in boss battles, this is a thing that can break the battle when I go to heal MP).
But bulma i and ghostrider a couples of weeks ago links the patch for that error
and the skill error.
http://www.mediafire.com/?k5rqk4kdvbync4b
author=bulmabriefs144
That kinda scrunches everyone in a line to the left.
... what?

Are you using the 'loose formation'?
[QuickPatches]
LooseFormationInc=47FAE7,803E0000
TightFormationInc=47FAF1,C05D0000
HexConverter
Put decimal into the right box next to "(big-endian)". Copy left box next to "(little-endian)" and put it instead of the blue digits.

... I could've sworn the # thing worked before Windows updated an hour ago. And the problem is not even tied to the dynloader.dll version or something.
author=kaine87
But bulma i and ghostrider a couples of weeks ago links the patch for that error
and the skill error.
http://www.mediafire.com/?k5rqk4kdvbync4b

It doesn't seem to work.

I have both that and the LinkToEvent bugfix. Neither one takes against this specific issue. It could be the setup of my computer or something else, but anyway.

I'll explain battle order, and you guys can see if this is even the same issue.

Turn 0: Music, Battle start events, etc.
Turn 1: My character gets their turn. I use Item, to test.
Turn 2-5: Item doesn't use on this turn. Instead, monster attacks. Monster (a Mantis) uses Claws (15 base damage, 1 Atk, 4 Var, Slashing/%3/%4/%12).
Turn 2-5: Error

It happens if I use Item on Turn 1, and the monster follows it whenever with a skill that is %. It does not happen if the skill does not have % (which due to my reliance on Min damage, is very few of the skills anymore). It might be okay if the other heroes take a turn in between, not sure. If the character uses Item with no RPS+ in between, this does not happen, nor does it happen if Item activates first, . It doesn't appear to fail for skill anymore (Link To Event appears to have fixed that one, along with battle action).

This seems to be a symptom of a larger issue. Normally, Item does activate first, if you use it before the monster's turn. But the first few turns of battle appear to have a weird lag. Getting rid of the intial lag may fix the issue, or making it not crash some other way. Not sure.

Where does it talk about loose formation? I just see Manual and Automatic. Big Endian? What?
VM:SkillMenu(width)=4C9026,#320
VM:SkillMenu(height)=4C902B,#80
VM:SkillMenu(y)=4C9032,#64


Is there a way to apply the same adjustments to the item menu in battle?
If so, does anyone have the quickpatch commands?
I may have forgotten to add the addresses / quickpatches to the VisuMenu readme, since they are using some stuff from the InfoDisloc.ips:
[QuickPatches]
VM:ItemMenu(Width, battle)=4C88C0,#320
VM:ItemMenu(Height, battle)=4C88C5,#80
VM:ItemMenu(y, battle)=4C88CC,#64

Or default stuff (without using either InfoDisloc.ips or VisuMenu.ips) for whatever reason:
[QuickPatches]
ItemMenu(Width, field)=4C8870,#320
ItemMenu(Height, field)=4C8876,#208
ItemMenu(y, field)=4C887D,#32

ItemMenu(Width, battle, large)=4C88C6,#320
ItemMenu(Height, battle, large)=4C88CB,%80
ItemMenu(Width, battle, small)=4C88DC,#320
ItemMenu(Height, battle, small)=4C88E1,%68
ItemMenu(y, battle, trad/alt)=4C88A0,#160
ItemMenu(y, battle, gauge)=4C88B3,#64

SkillMenu(Width, field)=4C8DCE,#320
SkillMenu(Height, field)=4C8DD3,#176
SkillMenu(y, field)=4C8DDA,#64

SkillMenu(Width, battle, large)=4C902C,#320
SkillMenu(Height, battle, large)=4C9031,%80
SkillMenu(Width, battle, small)=4C9042,#320
SkillMenu(Height, battle, small)=4C9047,%68
SkillMenu(y, battle, trad/alt)=4C9006,#160
SkillMenu(y, battle, gauge)=4C9019,#64

And these should work in either case (changes the MP-Window in the traditional battle layout):
[QuickPatches]
MP-Window(Width, large)=4C8CD4,%60
MP-Window(Height, larged)=4C8CD6,%32
MP-Window(y, large)=4C8CDA,#136
MP-Window(x, large)=4C8CDF,#260
MP-Window(Width, small)=4C8D3C,%60
MP-Window(Height, small)=4C8D3E,%20
MP-Window(y, small)=4C8D42,#154
MP-Window(x, small)=4C8D47,#260
(fun fact: the MP-Window is initialized in the field menu in the traditional layout as well, but not drawn / updated)

Or enable the MP-Window in the other layouts as well:
[QuickPatches]
ForceMP-Window=4C8CAF,EB04,4C94A1,9090

# is an 8-digit number (e.g. #320 is 40010000 in hex) and % is a 2-digit number that only goes from -128 to +127 (e.g. %68 is 44 in hex). The # / % stuff is broken (for now) so put up with that little-endian garbage if you don't want to get your players or yourself be pissed off just because my stuff is broken by definition.
Any word on whether or not the next DYN update will be for rm2k3 1.10a? Or is that not a cool question?

Is there a place I can follow the main devs? Like twitter handles or a blog.