Grr...More restrictions found on the stats screen


Alright, so it’s okay to use a *gosub_scene within the stat screen, but if you THEN use a choice and a *goto within that *gosub, suddenly the whole thing breaks seemingly. When I then click return to game, it only returns me to the stats page, and then I’m stuck there forever.

Now why is that? Going on the name, *goto, one would think it actually jumps to a piece of code within the scene. But instead, it seems it creates a new iteration of the page you’re on, so it doesn’t move you through space, it destroys and recreates space under you? Honestly, this stats screen is causing me grief to no end. I’m sure I’ve seen other stat screens with encyclopedias and what not, have they all just kept the code within the stat_screen scene and used *goto and labels rather than *gosub?

How big a size can the stat screen scene get without causing serious lag, kb-wise? How many characters? I was hoping to keep it as clutter free as possible.

I also tried a hot-fix, putting the *choice menue inside the stats screen, but it just seems like there’s something about the combination of *gosub and *goto that just Fs everything up. Which is really strange because I’ve used it before to good effect, so what is misfiring…hmm. It could be a double *goto that’s the problem perhaps…But again, why? What does *goto DO? Or could it be the double choices…

*label top

    *goto Gallery

*label Gallery

    *gosub_scene stats_gallery Family
    *goto top

And inside the stats_gallery, I’ve got a *page_break and a *return, so to try and avoid any extra confusion.

Can variables be changed in the stats menu?
Hiding Stats: Making two separate stat screens for two different main characters (RESOLVED)
Bug Report for CS

First of all, I’d advise you try not to capitalize labels/goto parameters, it shouldn’t cause any issues as CS is case-insensitive, but javascript (which it’s built on) is - so it doesn’t hurt to be consistent in that regard.

Using *gosub_scene within the stats screen can cause issues and is a confirmed bug, and a fix doesn’t seem to be coming anytime soon:

Most people who have encyclopaedias in their stats screen have just used a *choice and labels within the stats screen scene, with gosub and goto (both of those will work just fine). Long story short, using either *gosub_scene or *goto_scene (so essentially trying to manipulate the scene) will cause problems whilst you’re within the stats screen.

Unless you’re planning to write an entire separate novel inside of the stats screen I wouldn’t worry about the size.


I see… I really wish there was more work being done on the engine, if I knew java, and obviously in a more than adequate way, I would volunteer to do so myself. Part of the fun of coding is finding work-arounds, but I wouldn’t really call it a work-around if you have to scrap the whole thing and go a completely different route. Hitting all these walls aren’t very good for creativity, as I’ve probably mentioned before.

I read somewhere that 1500 characters or so was close to what was prudent, but perhaps that was a while back…

Thanks for the quick response and the label tip, I’ll have to remember that. Still have a lot to learn. :(|) There’s no reading book emoticon so that’ll have to do. :stuck_out_tongue:


I had once a stats with more 5,000 words and worked fine so no worry


Oh? Well that bodes well then at least.


It’s Javascript, it’s not really related to java in anyway shape or form, despite the name.
Although I think there was/is maybe a Java branch for some platforms…

I don’t think COG are really open to user-contributions to the source code, I’ve tried before (I’ve still got an open pull request for a *gotoscene_ref command). I guess I can sort of understand why, but I know what you mean. The stats screen in particular is one part of CS that I feel could really do with an overhaul.


@CJW What would a *gotoscene_ref be for?



Stop you needing horrible lists of *ifs when you’re wanting to swap scenes dynamically:

*if (var = "scene1")
  *goto scene1

*if (var = "scene2")
  *goto scene2

*if (var = "scene3")
  *goto scene3

Instead you can just…

*set var scenename


That does indeed sound handy. Anything to reduce the amount of code needed. I myself dislike that you have to add a *goto or similar just because you’re using *else. There are times when if-else works better than just if-if-if, mostly because setting them up so they work as elseifs can be a pain. When you want it to cycle through a list and stopping at just one option anyways.


I agree, I don’t at all like mass lists of *ifs but it’s definitely favourable to having a redundant label, i.e:

*if (condition)
   *set something to_this
   *goto useless_label
*elseif (another_condition)
   *set something to_that
   *goto useless_label
   *goto useless_label

*label useless_label
Do I really need to be here...?

I like falling out of stuff :stuck_out_tongue:


@MutonElite if this issue isn’t solved, I had a similar issue. I wanted to show the user the stat screen, but then go back to the game (instead of simply asking the player to click “stats”). What I did was make a “statsshow” variable, set to false. When I wanted to show the stats screen I would type this:

*set statsshow true
*gosub_scene choicescript_stats

Then the choice scripts stats would have this (before 
any choices; this would limit the stats to only the con-
tent before any extra pages you created in stats):


*if statsshow = true

     #Relationships, etc.

I hope that helps? I don’t know about setting references and variables. I’d really like to learn that because it would probably save me a lot of time in another very detailed game I’m working on…


@CJW You’re good people CJ. :slight_smile: …Coding-wise anyways. :stuck_out_tongue:

@CitizenShawn I have to say, I don’t really get your solution. What happens if someone presses the Show Stats button? Doesn’t it sorta go into that suspended mode anyways, which would ruin *gosub_scenes?


I just pushed a new version of ChoiceScript to Github that should now work correctly when you *gosub_scene in choicescript_stats.

Note that you still can’t update any stats in the stats screen; that’s a separate problem. (I’ll write more about it later, at some point.)


Thank goodness! I knew that I wasn’t doing it wrong! I thought that was just me…well and my jacked up computer. xD
Glad to know it’ll work now.


(Looks like I accidentally posted as @dfabu, now posting as @dfabulich correctly.)

Actually, it turns out “some point” is right now. :slight_smile:

I’ve been putting some more thought into this topic and wanted to write down some of my musings.

A lot of the weirdness of choicescript_stats has to do with the “refreshability” goal of ChoiceScript.

Note that in published games on, if you refresh your browser while playing the game on the web, it remembers where you left off (assuming you have cookies enabled). Something similar happens if you quit the downloadable apps (iOS, Android, and Steam apps) and reopen them.

Suppose you have code like this:

*set leadership %+20
Now your Leadership is ${leadership}.

When I first implemented ChoiceScript, when you set a stat, we’d update your stats right at that moment. This created a bug where if you refresh the page on code like this, your Leadership would keep going up and up and up.

So, instead, the policy is to accumulate all temp/stat changes and only actually save them when the player clicks “Next.” Suppose you start with Leadership 50, so %+ 20 gives you Leadership 60. When you see the “Next” button, your saved Leadership score is still 50; it would only increase to 60 at the moment you click “Next.”

If, instead of clicking “Next,” you refresh the page (or quit/reopen the app, or whatever) we’d restore the game based on your old Leadership score of 50 (since the stat bump wasn’t yet saved). We’d then re-apply the stat bump, giving you a Leadership of 60 again; only once you click Next would the changes stick.

That worked pretty well, but it created a major bug on the stat screen, which I then had to work around: if you check your stats right after your score goes up, you’d see the old Leadership score (50), not the new one (60). It was especially embarrassing when the text just told you what your new score is, but then you’d check the stats screen and it would already be out of date.

To work around this bug, I created two saved games, one “regular” save that would be used for refreshing and restoring the main game, and one “temp” save that would be updated immediately after stats changed. In the regular save, Leadership would be set to 50; in the “temp” save, Leadership would be set to 60. Then, the stats screen would use the temp save. When returning from the stats screen, we’d refresh the game based on the regular save.

But that created a new problem, which, at the time, I thought was pretty minor: you can’t *set any permanent stats on the stat screen, because anything you *set would be set in the temp save, which would be lost when you navigated away from the stat screen.

I still don’t have a good way to handle this. What should happen in this case?


*set leadership %+20
Your Leadership is ${leadership}.
*if Leadership > 70
  Your leadership is high enough.
  Your leadership is too low. You lose reputation.
  *set reputation %- 20

*label start
  #Boost leadershp
    *set leadership %+30
    *goto start
  #Boost strength
    *set strength %+30
    *goto start

Today, main.txt won’t truly save the stat bump until you click “Next Chapter,” and the stats screen will show Leadership=60. If you bump Leadership on the stats screen, it will appear to work, but the changes will be lost when you dismiss the stat screen.

Suppose I tried to let you modify stats permanently on the stats screen. If the stat_chart shows Leadership 60, then presumably Leadership %+ 30 should give you a Leadership of 72. But what should main.txt say when you return from the stat screen? Should it still say “Your Leadership is 60; too low”, even though it’s now 72? Should it undo the reputation change? How would it know to say 72 and not 77 (72 %+ 20)? What should we show/do if you then refresh the main page/game?

In a very real way, letting you set stats on the stat screen means you’re playing the same game in two panels at once (especially on iPad, where both panels are visible simultaneously), where neither panel is strictly “primary." What should happen to the left panel when the right panel changes something, and vice versa?


Very interesting analysis of the problem. I have tended to think of the stats screen as a snapshot of the game at the moment I consult it, not an action screen where I can change things. I would put actions and options that can change my stats into the main line of the game.

One workaround for those wanting to allow actions there would be to put a big, honking WARNING onscreen that the stats on the stats screen and those displayed in the main screen may not match until you end the scene. Doesn’t really feel like smooth game play, though…


@dfabulich Ah, it’s great to see you replying. I was wondering how you viewed this idea. That does sound complicated, CJW mentioned something to that effect… I shouldn’t really even try to come up with a suggestion as I don’t know enough of JavaScript, and I don’t know what you’ve tried either, buuut, what about adding another permanent variable then?

The temporary one gets set to the first permanent one yeah?
Then what about setting a second permanent one to the temporary one when you leave the stats screen, and then setting the first permanent one to the second one as you return to main?


*set temp_var one_perm_var (entering statsscreen)
*set second_perm_var temp_var (leaving statsscreen)
*set one_perm_var second_perm_var (entering game)

I dunno if this is at all feasible, just trying to be of help. I’d love to see the option of having a “living” statsscreen, that you can update in real time, realized.


@MutonElite I’m not sure I understand your suggestion.

Concretely, how would you answer the questions I asked for the second example above? What should the game say when you return from the stat screen? I can think of only two possible answers.

Answer 1: Immediate refresh. It should say, “Your Leadership is 72,” and the reputation hit should be undone, which should be immediately reflected on the stat screen (e.g. on iPad, where the stat screen and the main screen are visible simultaneously).

Answer 2: Delayed effect. It should say what it said before, “Your Leadership is 60; too low.” Stat bumps on the stat screen shouldn’t affect the main game right away, but only take effect when something else happens, e.g. when you click “Next” in the main game.

I’m afraid that Answer 1 may result in infinite loops. To pick a perverse example, what if the game looks like this?

*set switch not(switch)
Switch is ${switch}.

*set switch not(switch)
Switch is ${switch}.

If the stats screen can affect the main game, which can then automatically update the stat screen, which affects the main game… where does it end?

Answer 2 won’t result in infinite loops, I think. In the perverse example above, if the Switch variable starts off false, then main.txt would say “Switch is true,” and the stat screen would say “Switch is false.” After you click “Next” in main.txt, the main game would see that the Switch is now false again.

It won’t result in infinite loops, but it seems like a bug that the main game would continue to say “Switch is true” even when the Switch variable is actually false, or rather, it will be false as soon as you click “Next.”

Answering these questions really requires us to figure out what exactly why people want to set stats directly on the stats screen. Examples I’m aware of include:

a) Tin Star lets you set a “display mode” variable on the stats screen, determining how your stats are displayed. The default (IIRC) is *stat_chart mode, but you can switch it to be a purely textual description, instead. Unfortunately, every time you leave the stat screen, it forgets your preference, so if you prefer the other mode, you have to manually switch into it every time you visit the stats screen.

b) Putting ambient/alternative choices in the stat screen. For example, the player might have an inventory of collected items shown on the stats screen; you might want people to select an inventory item on the stats screen to use it in the main game.

In (b), Answer 2 (Delayed effect) would clearly be unacceptable. But I don’t think the stat screen is the right way to handle that anyway. Indeed, ChoiceScript is not at all designed to let the player choose to do something that isn’t an #option in a *choice. I feel like this would/should require a totally different approach to scripting the game. You’d want a scripting system that felt more like Inform or AGS.

I’m not aware of any other reasons to set stats on the stats screen. Are there others?

As a closing aside, @MutonElite mentioned, “I’d love to see the option of having a “living” statsscreen, that you can update in real time, realized.”

I’m not totally clear on what you mean by that, but maybe that’s exactly what we already have on iPad? On iPad, the stats screen is always visible (if you hold the iPad in landscape mode) and the stats screen instantly refreshes when stats change in the main game. Of course, the main game never changes in response to stat screen changes, because the stat screen today can have no effect on the main game.


For ref, here’s what Muton earlier said he’d like to do with choices in the stat screen:

See in particular the first and last posts.


@dfabulich What about instead of trying to modify the stats in the stat screen, you had another screen specifically for things like inventory and stat modification (if the game is set up for it)? Or basically adding another button next to the “stats” button. This screen could have built-in slots for items and such, and you could modify the stats if the author has that enabled. Maybe something like this

*inventory health_potions health - 1

Like maybe at the top of the scene file each element could have a true/false switch of some sort, which could be then enabled by the author or whatever. I know something similar can be achieved with *gosub_scene and such, but the player would only be able to access it when they have the option put in, whereas with this the player could access it at any time just like the stat screen.