Need help coding a main stat when using opposed pairs

Hi there! I’m pretty new to coding Choicescript, and everything is going pretty swimmingly, but I’m a bit stumped on how to code a main stat when using opposed pairs. I’ve seen some very helpful posts about how to code a main stat, but most of the examples I have seen only work when using completely separate stats.

I’m using opposed pairs because I like the way they look and function in the game, but, because the opposed stat in a pair does not technically exist, I’m not sure how to factor that in to determining a main stat.

One forum post I read suggested making the opposed stat a hidden stat that is calculated alongside the real stat in the opposed pair. The problem with that is, if using fairmath, the hidden stat % and the opposed pair % will not always match up unless by some miracle the two numbers end up being the same. Unless there is something that I am overthinking or not understanding about that solution.

Now, I could, in theory, make two routines, one to determine the lowest stat and one to determine the highest stat. The challenge then comes with comparing the two results. If I go this route, how would I determine if the lowest stat is closer to 0 than the highest stat is to 100?

How have other people coded a main stat when using opposed pairs for their stats? It would be very helpful to see example coding of what has worked for others in this situation. Thanks in advance for the advice.

Like you said, opposed pairs are actually and in fact just one variable. The threshold (or neutral ground) is always 50. If the variable value is below 50, then then the “right” stat is greater than the “left” stat. Likewise, when it’s above 50, the left stat is greater than the right stat.

You can use this reference for checks in your game. Take for example the opposed pair shy-bold. If it’s above 50, then the character is more shy than bold, but if it’s below 50, then the character is more bold than shy.


The idea of using two variables for each stat and only “joining” them on display is not to use fairmath at all, but let the variables grow unbounded on their own. And when you want to display them, just pick the left side of the opposed pair and divide it by the sum of both values, then multiply the result by 100. This should give you a percentage value that you can use in the *stat_chart command. You can use it even if you use fairmath. They don’t have to match at all.


*temp shy  175
*temp bold 300
*temp shy_bold_display round((shy / (shy + bold)) * 100)
Shy: ${shy} | Bold: ${bold}
	opposed_pair shy_bold_display



Say, you have 70% Bright vs. 30% Dark, but you want an event to trigger when you’re at least 25% Dark. This is how you code it in.

At least Dark 25% is the same as Bright lesser than 75%
*if bright <= 75%
   It's so dark here
1 Like

I appreciate the time you took to respond, but this isn’t quite the dilemma I’m having. Determining the strongest value in one opposed pair is relatively simple by this logic. The problem comes when, for example, I have 5 sets of opposed pairs. For the sake of this example, I’ll say these are personality traits. Between these 5 opposed pairs, I have 10 personality traits, and I need to determine which of these 10 traits has the highest stats. In the way I am currently coding, because I am using opposed pairs, I only technically have 5 personality stats, since the other 5 don’t actually exist. I need a way for the other 5 traits to have measurable values so that I can then compare them with the others and determine which of all 10 traits has the highest value.

So, just make sure I am understanding this correctly…

This method means that I track a pair, in this case shy and bold, as two unique variables, rather than only tracking shy as a variable. Then, when it comes to creating my stats page, I would use the coding as you provided in your example to effectively combine the two stats for the sake of an opposed pair stat chart. Meaning throughout my game, I would be making additions or subtractions to each variable separately, whether by fairmath or static value.

Assuming I have understood and summed this up correctly, this does seem like a more efficient method. Even though it would mean tracking more variables in my startup document, it would involve more simplified coding for determining the main stat in any .txt files that need it and solve my problem of needing a value for the opposed stat. Thank you for your advice, this is very helpful!

You summed it up perfectly. But just to be clear, even if you use 5 variables for the 10 stats, it’s relatively easy to figure out which is the greatest. I’m afk rn, my last reply was literary the last thing I did before turning off the pc.

The basic gist would be to loop through your 5 variables and check for the highest and the lowest. Then, check if the difference between 100 and the lowest is greater than the highest stat. Not sure if that was clear. :sweat_smile:

For example, let’s say your highest variable is shy with 75. And the lowest variable is funny (in the opposed pair funny-serious), with 10. Then you check the opposed of the lowest, in this case, serious: 100 - 10, which is 90.

Ninety is greater than 75,which was the hiest stat previously. This means that “serious” is the actual highest stat, even though it’s “invisible”.


So I could also use basic subtraction to determine the opposed “invisible” stat instead of actually tracking it. So if I have tracked variables “cautious”, “timid”, and “trusting”, as well as opposed stats to match, I could write the beginning of the main stat subroutine like this:

*temp daring (100 - cautious)
*temp confident (100 - timid)
*temp skeptical (100 - trusting)

Thereby creating temporary but measurable values for those invisible stats, and then I would proceed with the subroutine to determine the main stat as normal. I believe this should also work, yeah?

1 Like

Remember that temporary variables reset when changing scenes (files) … if your subroutine is within the same file, you should be ok, but if you tell the script to go to another scene, I do not think the temporary variables will stick.


For sure. Since the mainstat is something that can potentially change throughout the game, I predict reusing this subroutine within all files where it becomes relevant, so it should be okay if the variables are temporary. I don’t foresee needing them to exist outside of this subroutine.

1 Like

I’m sure *gosub commands open in a new instance of the “screen”, so it won’t necessarily alter anything unless you specifically use *set command in the subroutine.

Yeah, you could create the temporary variables only for the checking. I think that would be slightly easier.