[RM2K3] BEST WAY TO MAKE A VARIABLE-COMPARING CALCULATION?

Although I never directly used it myself, I know a mathematical way to do this with variables: It will result in a "priority" system. However, it will become much more complicated if the number of characters in battle is higher, as a large number of characters and enemies will result in a lot of calculations that need to be done. It is also not extremely simple, but I'd try to decribe it as precisely as possible.

So, how many participants can be in a battle at maximum?

Well, it depends on how much time and work you are willing to put into it. With a maximum number of 10 partcipants in battle, you will have to set up at least 200 Conditional Branches - although you can just copy/paste and then slightly modificate most of them.
It would still work, but if it sounds like too much for you, that's understandable.

Just for clarification: This is intended to be used in a custom battle system, right? Because using it in the regular battle engine probably wouldn't work well.

bugmenot, that solution sounds a thousand times better than what I had in mind. I did not know this:

author=bugmenot

<> Change Variable: [0024:VC_Value] = Var[V[0021]] value

was possible in RM2K3. If such a function to call a variable ID specified by the value of another variable exists, that's a huge advantage. (I use RMXP which has no such function by default, so I was oblivious and wanted to do it all manually.)

s_w, just forget everything I suggested and use above solution.

author=s_w
Also, RMXP can't do this VarA=VarB?

You'd have to know some Ruby or someone that knows Ruby to get that working. (Probably... dunno)
Also, it's about getting a variable_ID into VarB so VarA is set to the contents of the variable that is referenced in VarB.

author=s_w
I am still trying to understand how it works.

Sorry. I need to up my software documentation skills.

Let's go by the Var_IDs I stated in my first post here (you can, of course, change them). Let's say you have your participants' SPEED values in Var[0385] to Var[0394] and only 3 participants in battle:

A = Var[0385] = 10
B = Var[0386] = 8
C = Var[0387] = 9
D = Var[0388] = 0
...
K = Var[0394] = 0

Var[0021:VC_ID_First/Now] should be set to the first variable that has to be considered (= 385 in this example) and Var[0022:VC_ID_Last] should be set to the last variable (= 387 in this example).
That's why it might be a better idea to assign 'ID_First/Now' and 'ID_Last' before calling the CallEvent / function.
Yes, the event code cycles through the variables from 'ID_First/Now' up to 'ID_Last' and only memorizes a variable_ID if its value is higher than the previously memorized one.


1. You set 'ID_First/Now' and 'ID_Last' (to refer to where any values that you want to get the highest value from are stored in variables).

2. You call the Event with the VarCheck FUNCTION (either CommonEvent or MapEvent if on a CBS map).

3. The result gets written into Var[0023:VC_ID_Memory], which states the variable that contains the highest value amidst 'ID_First/Now' and 'ID_Last' (= 385 in this example).

4. You have your turn order in, for example, Var[0501] and the consecutive variables. You make a
So Var[0501:TOrder_1st] = 1(A)

5. To get the next highest number you have to knock the already tested values out of the system by multiplying the variable that is referenced in Var[0023:VC_ID_Memory] by -1.

6. 'ID_First/Now' and 'ID_Last' stay the same as in step 1. and you call the Event with the VarCheck FUNCTION again, which outputs 387 in Var[0023:VC_ID_Memory] this time.

7.So Var[0502:TOrder_2nd] = 3(C)

8. Multiply the variable referenced in Var[0023] by -1, and rinse and repeat until you get to the last participant.

X. Multiply every variable in the range between 'ID_First/Now' and 'ID_Last' by -1 to get back to the initial SPEED values, so you can work with them normally again.


Bear in mind that this event code FUNCTION thingy considers only positive values.
(you would have to change the first conditional branch after the <Label> to ask for another digital cue... for example if a value is still within -1.000.000 and +1.000.000 when working with 6 digit numbers... marking negative numbers by reducing them by 1.000.000 and marking positive numbers by adding 1.000.000 to them. Like, thinking up an easy way to make variables into pseudo-booleans without making it too complicated (like comparing it with what's already in the TOrder list))

author=s_w
when I got the highest value, which say, var3 = [9]
I just multiply it by -1 so it becomes -9, and gets ignored?

Indeed. Reusable and revertable (instead of wasting other variables to make backups of values to work with 'em)

Likewise you can use this to ignore variables beforehand that interrupt the range of values you want to test (for example you have the participants stats not ordered as "SPD(A) SPD(B) SPD(C) ..." but in a sequence of "ATK(A) DEF(A) SPD(A) ATK(B) ...")

author=s_w
but this line

<> Change Variable: [0501:TOrder_1st] - 384

Why is this necessary (-384)?

If you have listed all the SPEED values after Var[0385], this will get the participant_ID / Battler_ID that belongs to the referenced SPD value. Yes, to show the player what moves next. In hindsight... this would lead to something like a "global turn" in which the fastest battler would get another turn after everyone else already did. Then the next global turn starts.

author=s_w
I just need to change the "greater" comparison to "lower" right?

Yes. Or lower/equal to not have A be considered slower than E if their SPD is the same (prioritize the player).

author=s_w
Your code is amazing.

Nah. It's just simple. And it does not seem to help making a smooth turn order.

author=s_w
how to create similar battle system like Grandia

Haven't played Grandia, yet.

author=s_w
" ACT gauge" based on character's speed, but since the value varies the icon would probably jump

A solution might be to get the average SPD of everyone participating (everyone still alive, that is) in battle and basing the increase in a battler's "ACT gauge" on the quotient of battlerSPD x100 divided by AvgSPD x10 getting a decimal value times 10 (or else there would only be 0|1|2 ...)

SPD(A) = 10
SPD(B) = 8
SPD(C) = 9
SPD(D) = 8
SPD(all) = 35
AvgSPD(x10) = SPD(all) x10 /4
AvgSPD(x10) = 350 /4
AvgSPD(x10) = 88 (the decimal would be AvgSPD = 8.75)

So in an ACT+ cycle (every 0.5 second or so):
ACT+(A) = SPD(A) x100 / AvgSPD(x10)
ACT+(A) = 1000 / 88 = 11 (= 1.1 times faster than the average)
... and so on. Adding ACT+ to someone's ACT value.

Let's say someone gets a turn when their ACT value reaches 100. It would take up to 10 seconds + turn execution time until someone that's half as fast as the average has its turn. It might be a good idea to have the ACT+ increased by an additional x2.0 when nobody has an ACT value above 40(%) so it's faster. Increase ACT+ by x1.5 when noone's above 60%. Factor x1.0 when someone's above 80%.
That's where the sorting FUNCTION can help (getting the highest ACT value). And it can be used to get the participant that is the furthest down the shared "ACT gauge" to highlight its icon or whatever.


That's just an idea. And it sure needs work.

edit:
As it is, low SPD against high SPD will not get sufficient turns... maybe have the amount at which the ACT value is filled be somewhat logarithmic:
SPD = 1 = 10 ACT+
SPD = 2 = 15 ACT+
SPD = 3 = 19 ACT+
SPD = 4 = 22 ACT+
SPD = 5 = 24 ACT+
...
SPD = 8 = 28 ACT+
SPD = 9 = 29 ACT+
SPD = 10 = 30 ACT+
(Or the other way around, meaning that the higher the SPD the more ACT will be filled. You did say that there are abilities that lower SPD, so it would have a bigger effect on fast enemies/allies when shot in the foot (or what can be considered a foot) whereas the slow 'n' steady units will more ore less shrug it off.)


Or add +3 to SPD before calculating the AvgSPD to avoid B getting a turn after A finally had 9 turns in case of:
A : 10 SPD +3
B : 1 SPD +3
So that it's 2 or 3 turns.