CORTI'S PROFILE

I found the cause of that. It's simple but i didnt see it. I literally didn't see it, because the standard skill menu is hidden and i'm drawing my own.

The cursors can go back to the top whenever the skill menu is not able to scroll the visible part of the list. The standard skill menu allows 4 rows (RPG::Window->rowsPerPage). I'm using a hack that makes it one column instead of two, so for anyone without hacks, the breakpoint would be 8 skills.

Since my skill menu is invisible anyway, i increased the RPG::Window->rowsPerPage, so it works with more skills now. Yay!

Scroll up, read my post. ;-)

author=AubreyTheBard
Instead of trying to manually call or simulate the target selection system, I'm going to make a plugin that records to variables the results of the various window choices in battle. That way we can just create regular skills that do nothing in the default combat system, and use the skill choice, targeting data, etc. from that in custom systems. Or even just add extra effects to skills that do make use of the default combat system. It won't allow for really intricate stuff like choosing multiple targets for a single skill, but it's better than nothing and I think it'll be sufficient for my own project's purposes.

Try Battler->Action. It contains all you need. You don't need the windows and it's choices, you get the the executed action, the skill-ID, the item ID and the target and target type from the RPG::Action of the battler.

onDoBattlerAction (RPG::Battler *battler, bool firstTry)
onBattlerActionDone (RPG::Battler *battler, bool success)

The callback parameters are slighly misleading. Both are called multiple times. The firstTry parameter is bugged. The success parameter is set on the last call of onBattlerActionDone, it's the right point to remember a battler action.

If you want to override a command, onDoBattlerAction is the place to do it. You should create you own "firstTry"-mechanic. Use a bool that is set on the first call of onDoBattlerAction, so you know the following calls are just duplicates. Reset that bool on onBattlerActionDone when success is true.

You can execute code after actions are done by setting a switch that activates the event page.
There are conditions, where that does not work, the event page just won't execute. For example when the actor is using defend, an item or a skill that changes conditions on the caster ( and some othe weird conditions ). In that case, you can force the event page to execute, by calling RPG::updateBattleEvents. That function is documented as "experimental" for a reason. Calling it outside of onDoBattlerAction/Done-Callbacks can cause strange errors. Don't call it onFrame or any other drawing methods. Calling it when the event page would have been called anyway do the same. So this code:


This can be used to execute the switched event page only exactly when things are done, that don't trigger the event page anyway. I know it's complicated. However, the ATB can interfere and delay the execution in the next battler has chosen but not done his next action.

author=AubreyTheBard
I have a debug popup in onBattlerActionDone (also tried onDoBattlerAction) that shows the currentChoice values of all the windows in battleData, and they're a little inconsistent. I get 0s where I should get something else. More importantly, winMonTarget->currentChoice always seems to be 0, which is the most important thing for making this useful.

winMonTarget->currentChoice does not show you if the window is active. try window->getSelected(). If it returns -1, the window is inactive. onAction is a the wrong callback to output this kind of data, since actions should not happen when the windows is used. Monsters in atb_active mode could trigger it, but that shit is crappy as hell anyway.

Some code example:
I'm using this to draw numbers on screen. It's ugly and damn useful.
http://share.cherrytree.at/showfile-24668/showdebugnumbers.zip

author=AubreyTheBard
Sometimes they work exactly as you'd expect, other times (especially when using actors with higher ID numbers)

The value in currentChoice is the party index, not the database ID It can be 0 to 3.

author=AubreyTheBard
What is surprising is that the onBattlerActionDone function started reporting values accurately, including that of winMonTarget. Heisenbug? Maybe, but it kept reporting accurately even when I commented out the onFrame function.

No heisenbug. Just 2k3's strange programming. The windows itself don't tell you the state of the battle system, you need to take all windows into consideration. In gauge mode, the partySelectionwhataver window is used to select heros when targeting skills even if its not shown while the skill window is open in the background while shown ( traditional afair ) or not ( gauge ). At the same time when selecting skills, you skill window is shown but in the party selection window, the current hero is selected.

If you want to override those menus, you need to take more than one windows' data into consideration.
If you want to track action, just use onBattlerActionDone.

~have a nice day~

@FlyingJester:
Your post reminded me, that code needs to be in code tags, or else, content within square brackets like

does not show.

However, starting the for-loop with i=0 is not right. RPG::commonEvents is a RPG::NamedCatalogPtr<RPG::CommonEvent *> and those NamedCatalogPtr-Types, that are used to access arrays in the database are not using zero-based indices.

Question for bugmenot and/or pepsiotaku:
The WindowMenuSkill class has a field called, which contains a filtered version of a heros learnedSkills data. ( DList< int > * skillSubsets )
The WindowMenuEquip class works similar, it shows all items of one type, so there has to be a filtered version of the inventory data, probably a DList< int > * as well. Does that exist? Where can i find it?

author=Giznads
Anyone have the quickpatch command to remove the MP cost from skill menu in battle?

// Here's the dynrpg version. I don't have a quickpatch for that.
RPG::Window *winMP = (RPG::Window*)( reinterpret_cast<int *> (RPG::battleData->winSkill) );
winMP->x = 320;

Edit:
Not needed anymore. The given data in WindowMenuEquip is enough to manually extract a matching filtered list from the inventory.