[RM2K3] XENOMIC'S HELP TOPIC

More like this:


The commands dealing with Extend don't need to have parameter 4 modified. Also, make sure the Branch If commands get parameter 2 modified, whereas the Change Cond commands should have parameter 1 modified. To deal with the clusters, you have a bunch of Branch If commands which check whether you just ran off the end of a cluster, and if so skip to the start of the next cluster.

EDIT: Noticed and fixed a mistake in the code.

Not sure what you mean by the "proper" Branch If sections. -.-a But the whole idea is, the commands which are checking for, removing, and re-inflicting "Haste" on "Reimu" aren't actually doing exactly that; they're doing it with whatever status condition is currently represented by ConditionNumber, on whichever hero is currently represented by Hero Extend Variable. DynParams is a hack which replaces key parts of the command that comes right after @dynparams_overwrite_next. In this case, they're replacing the hero and the condition. So that one check for "Reimu" and "Haste" covers all the possible heroes and conditions you might want, as long as you loop over it while putting Hero Extend Variable and ConditionNumber through all the values for those heroes and conditions.

By the way, I spotted and fixed an error I made in the code above: the @dynparams_overwrite_next comment commands for the "Haste" remove and inflict commands were in the wrong place. Also, with that many conditions to check for on that many heroes, I wouldn't be surprised if this would cause some lag. If it does, you might want to check out Kazesui's tutorial on "Good" rm2k3 event coding. It has a section on doing loops using Labels and Jump to Labels, which while not good programming practice in general, weirdly seems to perform significantly faster than RT2K3's default Loop/End Loop command.

Prrrrrobably? I could see it being useful for checking for and counting up status effects. It would probably get a little complicated if you're trying to rig up a system that decides what the highest-priority item to use is and on which hero, but it could be done.

I don't see anything wrong with it. I tried testing the basic theory just now by setting up a battle in my DynBattleDisplay project that removes and inflicts Blind on the whole party every turn. It seems to hold the number of turns remaining at 3 in general, but occasionally it dips lower, maybe due to multiple battler actions happening "at once". That could be problematic for you.

Reimu being there or not shouldn't really make a difference. All the references to Reimu in the code above get overwritten by the Hero Extend Variable's value, which should cycle through the database reference numbers of all the heroes in turn. You could have any hero listed in those commands and it should work exactly the same.

Have you tried adding Message commands in the code to help you trace its behavior? You could, for example, add a Message that says,


right after the Conditional Branch which checks for Extend. That would tell you whether the detection of Extend is working properly.

I'm not going to be of any help with the DynRPG questions, but here are some plain old rm2k3 responses:

The problem though is this: I found out that Switch skills will NOT appear in Skill Subsets, but only in Skills. Meaning I have to turn any skillset that is a Subset into a Skill so that it appears. However, in doing so, things that are SUPPOSED to be in another Skill Subset will also appear in that Skill set too.

The best trick I've encountered for this is to track MP consumption. Check if a character has used the skill sub-set, and then check how much their MP decreased. Assuming you make that MP amount unique (so that only one of their available abilities cost that much MP), you now can check which ability was used and run scripts appropriately.

Setting current MP amount for the character can be done on-turn (such as, Character has taken 1x turns), since that triggers prior to MP reduction. Then you can check for how much MP they have after using an ability in a "Hero HP between 0-100" trigger, since that occurs after MP has been reduced. I'd further suggest you place the condition "Hero has used x command" to prevent it from triggering constantly (as the Hero HP trigger is run after every action from monster or ally). You can't use the "Hero has used x command" trigger since that occurs before the MP is reduced. You must use the condition check within another trigger/event.

If you use the "halve MP cost for spells" as an item, you can simply also check for half of the original MP consumption, assuming that it is also unique.

It's worth noting that I've actually given up using sub-sets due to this problem, but in a singular case it's not too bad to create the extra triggers and events to handle it.

Another option is quite a bit more risky but very doable, which is to track monster HP or MP. You can set your skill to do 1 damage and ignore defense, meaning it will always do exactly 1 damage. Then you just check if a monster has lost one HP. The problem is that there's a small chance for a false positive. But remember that the condition "Hero used x command" is available in all triggers, so you should only get a false positive if the hero in question has another ability that could accidentally do a single point of damage. All damage formulas are known, so you can actually check this and be 100% certain on it.

Alternatively, if you want to remove the MP stat for all monsters and make all of their skills free (not exactly recommended, but totally doable), you can make skills that damage MP an exact amount, and then check if their MP is reduced by that amount to call special events.

**Good Omen: Absorbs all damage equal to target's Max HP, then disappears. Will not work on damage that exceeds target's current HP or any effect that instantly kills target. Each level increases HP threshold by 20%, up to 200% Max HP.

I think I'm missing something here, but in case I'm not, here's what I would do:

In the "Turns Elapsed 1x" trigger, set the character's current HP to an unused variable.
In the "Hero HP between 0-100" trigger or the "Party Exhaustion between 0-100" trigger (as either of these occur after damage is dealt), set the character's current HP to another variable, and then calculate the difference to find the damage dealt.
Then check which is larger: the remaining shield (another variable) or the damage dealt. If it's the damage, add the amount of the remaining shield to the character HP. If it's the shield, subtract the damage from the shield amount and add the damage amount back to the character HP.

Reimu Extend Ability

Sadly there is no easy way to check if a character has a condition. So even though there's an easy way to inflict or remove conditions from characters, there's no easy rm2k3 method to solve your issue.

One thing I do want to ask is how often the script runs. Changing conditions in rm2k3 is extremely laggy, so doing it multiple times in the same script can be a serious problem. But the most series it when it runs when it doesn't have to. There is no way to avoid the lag to my knowledge, and the only way to reset the duration of a condition is to remove it and reapply it, as you are doing. Sorry I can't be of more help here.

Iron Duke
This is how it is on all of the accessories that increase stats by % amounts (weapons also do this with stats too, but nothing else except accessories right now does it with HP/MP). Is there a better way of handling this? Or am I just...kinda screwed with it doing things like this? The Common Event is a Call event that's called by another Parallel Process common event (that calls all of the map events, such as HP +10%, HP +20%, Equipment Abilities, etc.)

My recommendation here is to keep track of character's max HP and MP in variables and then always reset the actual HP and MP to match those variables when making adjustments for equipment and what-not. That way when you equip something that has an adjustment, such as +60% max HP, you can do something like follows:

Set maximum HP to the value of the variable
Set a new variable equal to 60% of the variable
Add the new variable to the maximum HP

You can then also add in new lines for whatever extra equipment may need to be adjusted.

As for tracking levels, a new level simply adds to the maximum HP, so you can check what the maximum HP was before and after a level, know how much the level added, and adjust the base HP variable appropriately (hopefully that made sense).

You don't necessarily need to do it that way, but the variables for the characters stats (I like to include not only HP and MP but also attack, defense, etc) can be used for a lot of other custom code as well.

author=Xenomic
*FFor playable characters, it is since I have MP Regen and MP Sap as statuses, so those can mess with those easily, as well as some skills that take a % of Max MP to use. ^^;

Technically you can add extra code to account for conditions, but the % MP would break it, yes. Certainly eliminating skill sub-sets is the safer (and easier) option.

Iron Duke

The key is that you never set your HP variable to your current HP. Instead you're setting your current HP to your HP variable. So more like this:

(I don't know what "Marisa Access" means, so I didn't include it.


We first begin by recording the current HP of Marisa. This is necessary because we may be decreasing Marisa's Max HP value below her current HP value, and we don't want her to lose HP before every battle or after every equipment screen. This step has to be coded for each character who's HP you're tracking.

Next we reset Marisa's max HP to the value of a stored variable that holds her base HP amount. This should be a simple Set command, but rm2k3 lacks such a basic option. My backup plan was to decrease max HP by 9999 and then increase it by one less than the amount needed. That's simple, but amazingly rm2k3 actually tracks NEGATIVE max HP values. Seriously. It'll display a 1 for your max HP, but it'll remember you're actually -5000, for example, and if you increase max HP by say 2000 afterward it will have no effect.

As a result we're stuck with a somewhat convoluted setup where I must identify first if the stored variable max HP is higher or lower than Marisa's Max HP. If it's higher, I add the difference to Marisa's Max HP. If it's lower (the more likely case), I subtract the difference. This step, like the prior one, must be done individually for each character.

The third step is to check equipment and any other status that a character may have that affects maximum HP. If you use only equipment in this step you can actually process this in a big loop, meaning you only need to code it once and then loop it for each character, rather than individually set it for each character. Just set a variable to the character's equipment value, run the loop, and then repeat. Conditions, however, need to be individually programmed.

Whether you loop it or not, however, the step is relatively straight forward. Just check for the equipment and then adjust the maximum HP value accordingly. The advantage of this method is that it's now really easy to layer multiple pieces of equipment or effects on top of each other without significant extra coding.

The last step is to set Marisa's current HP value to what it was before we changed everything. This is fortunately a lot easier than adjusting the max HP value because rm2k3 does not record negative current HP values. Therefore we can just subtract 9999 to set the current HP to 1, and then add in one less than our originally stored current HP value to get back to the correct current HP value.

Note that we do not alter the variable that holds Marisa's base max HP anywhere in the above code. That variable should only be touched upon level up, or any other time when the base value needs changing.

To handle level ups, you can either custom code your level ups or track how much Marisa's max HP changes from the beginning to end of battle (as that would be from her level up). A single variable for Marisa's pre-battle HP would be all you'd need to add in addition to the script to track and make changes.

You would run the level up check after each battle first, then the code I wrote above.

---

Option 2:
After writing out all of the above I got to thinking that maybe there's a way that might be easier for you. The concept here is that you should track the CHANGE in maximum HP from equipment, etc. rather than the actual maximum. The advantage of this method is that there's less scripting and you don't have to worry about level ups. The downside to this is that you'll have less freedom in changing maximum HP values because there isn't a backup variable that you can rely on. Still, this might be the better way to go.


EDIT: Corrected some formulas.