I think I understand… Though this setting only applies to the code-editor, it will not have any affect on the size of the text in your game. Any ‘Run’ session will use CoG default, if that helps. As for actually seeing what your game looks like on a mobile phone, you might want to check out: https://developers.google.com/web/tools/chrome-devtools/device-mode/
Am I on the right page here?
Yes; the run-feature is nice and I do utilize it but “knowing” via raw code and prose is just as nice - I just try to be as efficient as I can because I’m so inefficient elsewhere, that time put in is paid back in time saved in future editing and revamping … again, sorry to bother you.
Edit: I’ll have to look for that tool for Firefox … should exist since it too is an open-source app.
Never be sorry for making a legitimate suggestion or request, I’m happy to hear them. I do think that particular request is a difficult one to implement (accurately), Google, FF and others spend a lot of time/money on developing their emulators.
That said, there are two things we can do with CSIDE:
You can use the ‘popout’ option on a running game and resize that manually. That might give you a very rough idea, how ‘wall of text’ a page can get in a smaller screen/window.
It is possible to use choicescript.github.io/web on mobile phones. It’s far from a perfectly pleasant experience, but it is workable. You could try running your project through that (if it’s stored in Dropbox). Again, use the popout functionality!
I like the increase in font size options! Would it be possible (or reasonable) to have a dropdown for the font size as well as a slider? Depending on the device/computer I’m using, I really don’t like messing about with sliders, particularly if I have a definite end result (i.e., ‘I want font size ten now’) in mind.
Also would it make sense to change ‘reliability’ to ‘stability’ under the ‘Update Channel’ description? That would make more sense (and sound less alarming), to my mind anyway.
And finally…is it really necessary for the Update Channel to have a great big yellow warning pop up every time I open CSIDE? I close the app when I’m not using it, because of my computer being the way it is, and I use CSIDE daily…I can see why notifying on restart once might be useful, but every time, it’s just rather annoying. Maybe that’s me being nitpicky, though? Apologies, if so.
The whole point was to streamline the change, adding both control methods would add to the clutter. Now that the there’s more options for font size (and room for yet more if there is demand), I figured a dropdown would prove overcrowded.
If you’re not happy with it, we should look at changing the method entirely or improving it somehow. Would adding a current value indicator to the slider help, for example? Alternatively, a text box approach might be more suitable?
The description suggestion is good, I’ll make that change.
I agree that it’s rather annoying, but I do want people to be aware they’re on that channel. Perhaps a tidier way to do this is to provide the actual update message with a yellow background and noticeabale [development] statement?
I suppose some of it may be that I’m not used to a slider for setting a limited range of numeric values. What about a drop-down/text box combination where, when you click, you can either type the number in or select a number from a list? A bit like a word processor. Barring that, I’d still prefer a drop-down if there are only going to be a handful of options, but again maybe that’s just me.
Also, a lot of text editors seem to have CMD/CTRL +/- hotkeys as a way to increase or decrease text size whilst in the editor window. Would that be an additional possibility? Those hotkey combinations seem to be free, unless I missed them on the list somewhere.
That sounds lovely, and then it would only be a visible sea of yellow when it’s immediately relevant—which I would think is the ideal time? A pop-up that always appears becomes something to ignore after a while, at least for me. (Although this one is pretty hard to ignore…I guess that’s good, given the function?)
I wanted to thank you for building this awesome tool, and report something.
I can’t seem to “unachieve” achievements. Even as I restart the game, or close the app and remove the code, the achievement is still considered as having been achieved.
Glad to hear you like it Snowpanther, and thank you for the bug report. That sounds like a very plausible side effect of state being saved for restoring to pop-out windows.
Should be a simple fix 
Just want to note that the Quicktest packaged in v1.1.0 is broken, and will report being unable to find scenes. v1.1.2 on the development channel has the fixed version of ChoiceScript. Please update to this if it’s proving a problem for you. Sorry for any inconvience, and thanks to @Nocturnal_Stillness for reporting!
Super random question! I sometimes use the (wonderful, brilliant, fabulous) console as a calculator to check my fairmaths. I noticed that even if I type *temp var 50 into the console, the action is not permitted if I’m not currently running a game.
It makes sense, as console is meant to navigate a game, not magic things out of thin air. However, I like the calculator function. It’s somewhat inconvenient when I have an in-process broken game that won’t run at all as my only open project; I’ll generally not want to stop and fix it, as I just want to play calculator with the console for a moment. Would there be any possible solutions for this?
I’ve fallen foul of this myself a few times. It would be great if the console was open to basic expressions at all times, it’s just a matter of making sure that the connected instance is always transparent to the user.
What about a prefix, much like the username in traditional terminals?
@projectName: *temp n 50
@projectName: *set n %+ 5
@global: …
It also begs the question as to when we’d “clear” the global state (would variables persist indefinitely?) and how you might access it if a game is running.
Currently, if a game is running and you try to use a console in another tab, it’s disallowed, if only to keep things straight forward for the user.
Would automatically connecting deactivated consoles to the global interpreter be transparent behaviour, or would it confuse people when their changes aren’t taking effect in the game window?
It seems to me that you guys are overthinking things. Why not incorporate a calculator function as a stand-alone feature, useable with or without a project running?
A separated window just for calculations of fairmath and such would both be desirable by many and understood by most - a more complicated console would only confuse people like me more.
A lot of complexity in software actually comes from complexity or deficiencies in its user interface. Where would we add this extra calculator? If we add it, we’d also have to add similar requests: space and management of components then fast becomes a problem.
I.e. the console already does a good job as a fair math calculator, and is easy enough to use (assuming you understand choicescript, which I think is a fair assumption) - if you disagree, and struggle to use the console, please tell us why. I’d much prefer to address issues in current components rather than create new ones to perform functionality that already exists.
I don’t subscribe to the slippery slope theory here; guarding against creep in all elements is a norm of development.
Stating that one pop-up window added to streamline an already (unintended) used function within another feature would necessitate the automatic acceptance of all future requests is something I’ve heard so much from developers everywhere it loses its shiny elements over time.
I already use the Windows calculator as necessary because it is more straightforward and less confusing then trying to adapt the console to perform a function outside of its original vision. Adding more functionality in this case only would further confuse simpletons such as myself; especially demanding prefixes and such to accomplish the goal.
I very much struggle with the console but I’ve given up trying to provide feedback - the pure vision as executed seems unable to accommodate such as me going forward.
This is probably because it’s a complication only developers tend to see: if we write another component, that takes time. On top of that we then have to continue to support and improve that component for the foreseeable future.
The great bit about the console is that it largely just plugs straight into the ChoiceScript interpreter, and doesn’t require much in the way of maintenance. As fairmath is an integral part of choicescript, and the console is a gateway to using choicescript interactively, I don’t think it’s outside of it’s original vision.
I admit the automatic acceptance is a bit overdramatic, you can of course refuse future requests, but you always end up having to upset someone.
Now, with all that said, you do have a point about complexity. From the start we’ve tried to keep CSIDE as flexible as we can, that’s why the console is tucked away. If you don’t want to use it, you shouldn’t have to (though I would still very much appreciate your feedback on how it might be improved!). I remember there was a fair math calculator wrote as a choice script game posted on the forums, author permitting, would including that as a project template be a fair compromise? That wouldn’t affect the cside code base, create additional dependencies or take time to build, test and support - yet it would provide you with a way to use a calculator in-app, without resorting to the console.
All I’m doing is trying to steer the ship in something resembling a sensible technological direction. There is no pure vision, and your feedback is very much important and appreciated - you’re definitely not the only one who will want to avoid the console!
EDIT: If you really do feel a specific calculator feature is the only way to go, I’d be happier waiting to implement it once I’ve sorted out configurable tabs (the ability to close/add different functionality panes). It would fit nicely into that format, I think.
I do. I also agree that it would fit nicely into that format.
If you like (don’t feel obliged), feel free to post any specific requirements or ui ideas you have here (or to me via PM), and I’ll see what I can do.
Here is a little better, if only so others can have a chance to make their say
I’ve started using it and I’m finding it lovely. Thank you so much for creating this!
Very glad to hear it! Please let us know if you think of any ideas for improvements 
Sometimes I like reading back through this thread to go over old ideas and feedback, and I just happened to notice that I never responded to this. I know it’s a bit late now, but it’s an interesting question that might prove useful to others.
Try creating a new scene file called testing.txt (or whatever you fancy)
*label track_var_set_xyz
*console_track var1 var2 var3 var4 var5 var6 var7 var8 var9
*return
Now in startup.txt:
*comment *gosub_scene testing track_var_set_xyz
And now just uncomment that line whenever you wish to track, and comment it back whenever you wish to publish/test outside of CSIDE
On a related note, if anyone has ever asked a question and I’ve not seemed to answer it, please don’t be afraid to remind me or ask it again! I sometimes skim over responses on my phone and on the go, and end up innocently missing things (it’s never intentional!).
@Alexandra Code folding is also now in the local development version 
Next priorities on the list: