Check the section “Temporary Variables” and “Permanent Variables” - Temporary ones are made with *temp, and permanent ones with *create (which is a deprecated method; you should rather use mygame.js to create permanent variables):
Aah. I forgot we have a wiki. Ouch. That white on gray is very hard to read; had to zoom in just to make the text clear.
So, temp variables aren’t carried through. Will have to rely more on *selectable_if (Belligerence > 50) conditions, then.
Thanks.
Wiki says *create may eventually be removed. For compatibility’s sake, all possible variables that will be used must be placed in mygame.js and assigned a value? It may be simpler to not have to double up on *create and *set, but it seems convenient to be able to *create new variables as the story may require on the fly.
Well, that’s my impression of it so far.
I vote the second…We don’t need to know how we were to make a personality of ourselves…
@bluepencil I actually find it more convenient to simply define a permanent variable & default starting value in mygame.js like so…
,belligerence: 10
as opposed to the archaic *create command (or even new *temp commands, for that matter).
Besides, ideally you should be opening all your game files together (as a “Workspace” in Textpad, or “Session” in Notepad++, for instance), then it’s really not a problem to just switch to the mygame.js tab and add a new variable as & when needed, on the fly.
Well, not necessarily; you could make a string variable called “first_stat” and you’d just give it a value according to what the player chooses. It’s easier to just define a variable in mygame.js that you KNOW it exists, instead of just making a variable that will exist only IF the player makes a certain choice in the game, and so when you want to check the value of that variable, if it is not created, you’ll recieve an error “Non-existent variable” (that applies only for “custom” variables, created only if certain things happen in-game).
The point is, in my opinion, making more variables that might not be used throughout the game is easier and more error-free than making less variables, but with a greater error-encountering chance.
EDIT: Ninja’d ^^
@AlexCorsarca :ar!
@bluepencil Also, not sure I entirely understand your comment re: *selectable_if as it makes no difference where *temp, *create or mygame.js is concerned.
The variable belligerence (note: no Upper Case letters permitted in variable names) can be used in *selectable_if whether it’s a temporary or permanent one. In effect, there is no actual difference in how the two types of variables can be used, only in how they are created in the first place (and, of course, the fact that *temp variables are indeed only temporary, existing in memory only until the game loads a new scene .txt file).
Um, Uppercase letters seem to be working fine here, though. It didn’t break the editor’s pre-run check, at least.
Still, when relying more on perma-variables instead of temp-vars, it’s fine just using lowercase when the actual variable has an uppercase first letter?
In customizing stat chart, I saw:
That’s because, in ChoiceScript, variables are case-insensitive, so “strength” and
“sTrEnGtH” mean the same thing.
This applies ONLY to the stat screen? Therefore I should lowercase all variables and capitalize only how I want it to look in the stat screen.
Thanks for your input Vendetta, it’s an honor.
@AlexCosarca
Also my thanks. I’ve long been fascinated by your highly customized game. Mind if I ask you a few questions about it?
Uppercase letters in variables don’t work when you define them in mygame.js. If I’m right, JavaScript doesn’t support uppercase letters (so that uppercase letters are read by Javascript as lowercase letters), but ChoiceScript does, so that when you write a variable called “Belligerent” in mygame.js, the actual variable is “belligerent”, so that if you call it “Belligerent” in your CS code, it just turns out as a non-existing variable (but, I am only guessing this may be the cause of those errors; perhaps I’m wrong).
Also, feel free to ask, but ask in a PM 
I enjoyed the first intro more than the second one, though the second had more a first-person-esque quality.
One thing – you need to set a starting value for title or a game-ending error occurs when you hit stats before title is set. I always hit the stat button when I first load a game, just to see what it looks like.
As a fan of civilization sims and post-apoc themes, I look forward to this game.
@bluepencil They’ll work within your scripting until you use mygame.js more. That will even allow capital letters (i.e. mygame.js won’t itself error with capitals in variable names) but when it reaches the point in your scripting where you’re referencing a permanent variable in mygame.js, and have used Upper Case in both your scripting and mygame.js stats list, it will then return a “non-existent variable” error, at that exact point in your scripting. If you look at the error itself it will actually show you that it’s looking for a variable name all in lower case, despite how you’ve typed it in both files!
This can be very confusing, so I’d always advise not using capital letters in variable names at all, either in scripting or mygame.js.
*stat_chart is an exception to the rule, because with that command it’s actually printing the variable name “as text” in whatever fashion you specify, rather than printing a variable name per se . . . if you see what I mean.
Javascript IS case sensitive, choicescript ISN’T - So writing “StReNgTH” in choicescript will search for the variable “strength” in javascript - although it’s possible to define a variable called “Strength” - Which you’ll be unable to access via choicescript.
(Co-author of Tyrant Dawn)
How do code a ‘Health Bar’ or something similar so that it is perpetually displayed in the text page so that the player doesn’t need to check the stats page every time?
The Bar would be used to display ‘popularity’ with the populace, something that could change with every choice or just with time.
@cilvercat You can use *stat_chart in any scene .txt file, not just in choicescript_stats.txt, so you could have the health bar (or whatever) appear as often as you like. If displaying more than a line or two it might be better done as a *gosub as needed.
Looking good. Assumption we have a family relations thing in the future? Not a stat based one but based on decisions taken? Like with the younger sister, I’ve just rp’d her as the apple of the eye, haha, I guess there would be consequences for that?
But yes I’m looking forward to seeing how this evolves. I might be an extremely harsh critic if there happens to be any legal stuff in there though (I study law at the moment) but I assure you I’d be purely academic! Lets not allow the real world to get too far in the way of a good read/game. =)
could you add a idk good guy dictator who does good things for the good of his people?
Experimenting now with a persistent status bar.
Ugh. It appears to break immersion. But having a
Date: 2596.021 Location: wilderness
Task: Find a source of clean water.
- should reduce a LOT of confusion later on.
The feedback bar at the bottom is for those who like to see how their stats increased or decreased. Maybe we should offer at the start a choice of Novel mode, for those who want to treat it as a straight narrative; or Display Mode, for those who who want progress updates.
Cool
Wow, I’m practicly speechless with amazement…
That thing when say tryant, are we talking about does coup of old goverment, or start his own Deposte?
Call me crazy…but I actually like your original intro piece slightly better, reminds me of the Fallout franchise just with an implant with an intergrated AI taking the place of the pip boy. Now, granted the code sequences can be somewhat annoying but with some humour I can see lots of room for improvement there.
I hope you keep the implants concept even in the new intro, you stated that our character was adopted so it leaves open the possibility that are walking around with dormant implants.