Strangest Bug: Opposing pair breaking/Not showing correctly

Game Development ChoiceScript Help
1

So, for some reason, one single line of code keeps messing up, no matter what I put there. My opposed pair is showing no other side on the first line, however the second opposed pair shows up fine. If I swap them out the same thing happens to the one that used to work, and the one that didn’t now does?

I’ve tried swapping, restarting, remaking, spaces, indents, tabs, idk what is wrong.

Not sure what’s goin on here, but here is the code.

*label rep
STANDINGS:
*stat_chart 
    opposed_pair Slave
        Freeman
        
    opposed_pair Viking
        Rebellion
    
    percent Jarls
    percent Commoners
    percent Godsrep ${Gods}
    
*choice
    #Return
        *goto Main_Menu
1 Like
2

Saw this before. Does writing them like this work:

*stat_chart
   opposed_pair var
      Var title
      Other title
1 Like
3

Well, it broke the other one, but I’ll just do it like that one and that should work.

We gucci. :+1:

4

Hmm. I don’t know what the exact problem is, but I have a few things you might be able to try.

First is making sure you’ve done a *create in startup for both Godsrep and Gods with a value for each.

Secondly would be checking capitalization, because that matters- and why it tends to be common practice to not use capitalization for variables. I don’t think capitalizing within { }'s would cause a problem… but I haven’t done so and thus don’t know for sure.

And third might be making sure Godsrep is
*set Godsrep (dollarsighhere){Gods} within the stats screen before displaying percent Godsrep. Then you’d only need percent Godsrep, and could leave out the (dollarsignhere){Gods} after it. So for instance, you’d likely put this in after the label, before the STANDINGS:
It’s a workaround, might work.

1 Like
5

This seems solved, so I’ll close it.

7

The cleanest way to do your opposed pair would be like this

*stat_chart
   opposed_pair slave
      Slave
      Freeman
   opposed_pair viking
      Viking
      Rebellion
1 Like
8

@rinari better to rely on the ‘mark as solution’ feature on the correctly advising post, rather than close the discussion. People may come back with related or similar issues. Generally we only tend to close threads when any further discussion is simply not going to be relevant/appropriate (resurrecting dead threads, off-topic tendencies etc). Although in this case, a renaming of the thread (to something more indicative) might not be a bad shout.

2 Likes
9

I took the liberty to change the title. will this do?

2 Likes
10

Ah oki, this is pretty old, so when I first made it how I was doing it before worked fine. Maybe some updates passed by and its better to do that now, which is fine.

11

@CJW ah then that’s my mistake. Generally I was under the impression that it’s better to lock technical threads when they’re solved according to @Gower’s Moderating Norms thread, but next time I’ll use more prudence!

12

This is a good point, and I will make that change to the Norms. Thanks!

2 Likes
13

Do we have a “commonly encountered errors” thread?

didn’t i start one once???