[RM2K3] XENOMIC'S HELP TOPIC

Just have branches in the code that increments the variable checking if the ID is one of the ones it can't be, and if it is add the value that would take it to the next one in line instead of 1.

Is there a reason any of the other characters would ever have the Rain Dance condition if they're not in the party? Trihan gives you the correct way to get around your problem, but I'm not sure if I follow why it is a problem in the first place, since only those characters with the given condition should ever be affected.

If you want me to read through it, sure. I haven't read what you've posted already since you've already said you've changed it.

As for what I was saying with not having the checks for characters that will never be inflicted with Rain Dance:

First off, if they'll never be inflicted with Rain Dance, then the rest of the code will never trigger and the only cost is the variable you'll never use. I don't see a major downside to that. Running out of variables could be a problem, but the English release gives you 9999 variables, and if you're using the older version you can use a patch to get 9999 variables, which I hope would be sufficient. You won't include the big list of checks to see if someone is inflicted with the Med1 - Med6 condition for these people either, so literally only the unused variable matters.

More importantly, though, if you skip the extra checks for missing characters you'll speed up the code overall, which will matter if it's running every turn in battle. And finally, it'll keep your overall code more to a minimum and easier to read, which is really nice. All in all, I see it as a better way to manage it.

Edit: Forgot you were using 2k3, ignore this.

You don't need to duplicate the code for Reimu's passive. You could try something like the following instead:


Var [2503:Character Variable] = 1
Var [2504:Condition Reference] = 2472
Label: 1
Variable Oper: [2505] Set, Var [V[2504]] Value
Var [0187:Random] = 100
Branch if Var [2503:Character Variable] is 1
<> Var [0187:Random] = 1...100
End
Branch if Var [2505:Temp Variable Auto-Med] is 1
<> Branch if Var [2503:Character Variable] is 1
<> <> Var [0187:Random] / 2
<> Else Handler
<> <> Var [0187:Random] = 1...100
<> End
End
Branch if Var [0187:Random] is 20 or less
<> Change Cond: V[2503] Poison Remove
<> Change Cond: V[2503] Blind Remove
<> Change Cond: V[2503] Silence Remove
<> Change Cond: V[2503] Slow Remove
<> etc.
End


Notice that the green section is now NOT under the conditional branch checking if the character has Auto-Med. This allows it to be used both for Reimu's passive and the Auto-Med condition. To ensure it doesn't get triggered erroneously, I've added in the orange line which sets Random = 100, or large enough so that the green branch which checks if Random < 20 never triggers by default.

What I'm doing in blue is to first set random to 1...100 for Reimu in all cases (whether or not Reimu has Auto-Med). This sets the passive to 20%, like you had in the code above. If you wanted it to be 10% like you originally said, just set the random to 1...200 instead.

Next you'll notice that I divide Random by 2 if Reimu has Auto-Med. This in essence doubles the chance for the Auto-Med passive to trigger. If again you originally want the passive to be 10% instead of 20%, you'll need to divide by 4 instead.

This won't make the code run any faster, but it'll allow you to not need to duplicate the Change Cond. At the very least it'll give you some more information on how you can manipulate your code to make it easier for you to write.

Otherwise it looks good. I still recommend you increasing the number of variables you dedicate to this and then check every one rather than jump over them like you're doing, but what you're doing right now should work regardless.

Out of curiosity, how large is this game? 50 characters is MASSIVE!

Changing conditions or equipment in battle will make your battlers get stuck in their movement. There is no fix to this. There are four ways to try to mitigate it:

1. Don't have battle movement. So no "move forward" or "move to enemy" or what-not. No movement means no one gets stuck.

2. Don't use "Turns Elapsed" but instead use another event. I don't remember off hand which one works, but basically there are events that triggers before a character takes their turn (like Turns Elapsed) as others afterward. If you choose an after one then you guarantee that the character will deal damage to the intended target, even though they may sometimes get stuck in the middle of the map. In other words, you can get it to function correctly in terms of game play but it will still have the graphical glitches.

3. Do your best to have it happen as rarely as possible. So in your Hollowed Caverns example, check if the person is inflicted with the condition first before you try to give it to them. Hopefully then it'll be only after someone dies that you'll have any chance for the glitch.

4. Avoid the commands "Change Equipment" or "Change Condition." For your Hollowed Caverns, an alternative could be to change the battle commands for characters so that they don't have access to the Magic command, for example. There's a "no auto-battle" patch available if you're using Alternative or Gauge for your battle layout, thus preventing people from using "Auto-battle" to gain access to magic anyway. The risk with this, of course, is that you really need to be careful to ensure there's no way the player could bypass whatever trigger restores their magic.

Because of this glitch I always make sure any custom battle mechanics don't use in-battle condition or equipment changes to work. Your Rain Dance would be an exception, since the condition itself is inflicted via a normal ability and not a script.

While I'm on the topic, assigning too many conditions to something is also a problem. I don't remember the number, but I think it starts to glitch when you assign more than eight conditions at once to the same character or monster.

EDIT: While we're talking custom stuff in rm2k3, if you do anything with text in pictures you may want to check out my picture text creator. It basically allows you to type text out normally and then save it as a PNG for use with RPG Maker. It's fairly robust, though right now I don't have very good instructions for it.

If you're interested:
http://rpgmaker.net/engines/custom/utilities/78/

The maximum conditions you can have on a character or enemy before things get wonky is just a number of conditions and it doesn't matter how they got there. It's never been a concern of mine unless I start using conditions for custom battle mechanics. As a result, I no longer use conditions for custom battle mechanics.

The "Picture Text Creator" isn't an add-in. It's just a utility that allows you to convert text into a PNG file outside of game for use, via the show picture command, in the game. If you want to actually draw text in game you'll need DynRPG. Unless I'm misunderstanding you, which is possible.

There's a patch for rm2k3 that allows you to reference an image by a variable. So for example you could have the following three image files: Bio_0001.png, Bio_0002.png, Bio_0003.png. Using this patch you can reference these images by changing a variable, like Var[2000:Bio Image]. This then allows you to do some nifty things to help automate menus.

Take your Dictionary/Glossary thing. I noticed that you have multiple "pages" for each entry. Rather than code all of that out specifically you can do it all via images. Like's take the character of Akyuu. She has four sections: the bio, what is the character up to, battle resists and weaknesses, and special abilities. Let's call these pages 1, 2, 3, and 4. She's also the 5th item in the list. So we can convert that information into four digit numbers with images, namely:

Glossary_0501.png
Glossary_0502.png
Glossary_0503.png
Glossary_0504.png

So let's make up some variables:

Var [0188:Temporary Variable] <-- this will be our picture number
Var [3001:Glossary Entry]
Var [3002:Glossary Page]

Now do some key input processing.
- Pressing down increasing V3001 by one. Pressing up subtracts one. Pressing either resets V3002 to one.
- Pressing enter selects the entry.
- Once the entry is selected, pressing left decreases V3002 by one. Pressing right increases it by one.
- Pressing any key show the proper picture using the following logic:

Variable Oper: [0188] Set, Var [V[3001]] Value
Var [0188:Temporary Variable] * 100
Var [0188:Temporary Variable] + Var [3002]'s Value
Var [0187:Random] = 48
Show Picture: 50187, Glossary_0501, (180, 120)

The picture 50187 isn't a typo. That's how the patch knows to look at V0187 for the picture number (48 in this case) and that it needs to look at the next variable, V0188, for the proper image number (like 0501, 0502, etc).

Using this method, you can code your Glossary once and then just name your pictures properly and everything will just work very cleanly and easily. Hopefully that made some sense.

You could use a similar set of logic to code your bestiary, if you don't mind typing out all the stats for each monster.

If you DO mind typing out all of the stats, there is a way around it, but it's pretty variable intensive and not advisable. Here's the basics of it:

- Each bestiary entry is only available once you see the monster in battle.
- Each monster must have a given amount of MP.
- You'll need six variables per monster in the game. Thus this method can easily use up your total supply of variables.

When you enter a battle, the Turn Elapsed triggers and does the following:

- Store the MP of the monster to a variable. This is the monster's unique ID. You can have this value equal to the variable number that stores whether or not the monster has been seen. Alternatively, you can just have MP = 1001 for the first monster, 1002 for the second, etc.
- Regardless of how you use MP to find a Monster ID, you now can use that ID to reference six variables for that monster: have_encountered, Max HP, Atk, Def, Int, Agi.
- Now that you can reference all six variables, set the monster to having been encountered and then use the Change Variable settings from within the battle commands to set the other five variables to the value of the monster.

Now that you have all the correct stats to each monster you've ever encountered, you can reference them in your bestiary. The advantage of this method is that it allows you to change the stats of each monster whenever you want without having to edit images to reflect those changes. The downside, as mentioned, is that it can easily consume thousands of variables.

There is one other alternative. Since variables can be seven digits long (up to 9,999,999), if you restrict monster stats to max out at 999, you can store two monsters stats per single variable, plus the have_encountered flag. That compresses the six variables down to three variables, and allow you to have 1000 monsters while using only 3000 variables.

Anyway, it's up to you which method you want to use. I figured I'd throw this out there though as it's a pretty nifty way to build a dynamic bestiary within the constraints of rm2k3.