So players have a couple of times now reported they’re getting Not a Number popping up when they play my game.
I cannot for the life of me either replicate the errors or work out why it’s throwing that message:
The code here is posted below. Line 5522 specifically is *if (archease > 0), but the same error with Not a number: true has popped up for someone else on 5533 *if (archconnections > 0)
TEXT
*label informmenu
*choice
*if (ama)
*disable_reuse #Architect's motives. @{(archmotives = 2) Keep to myself that I don't think he's saying everything.|}
*set ama false
*set given true
CHOICE TEXT
*goto informmenu
*if ((archmotives = 2) and (ama))
*disable_reuse #Architect's claimed motives, and my belief he's putting on an act.
*set ama false
*set given true
*set archmotives 4
CHOICE TEXT
*goto informmenu
*disable_reuse #My observations on Architect and Wyrd's @{fighting_style combat expertise.|strategic abilities.|powers.|}
*set given true
CHOICE TEXT
*selectable_if (inform1 < 5) #@{(inform1 < 5) The hideout, and its ownership.|It's too dangerous to tell her about the hideout.}
*disable_reuse
*set given true
*set hideout 2
CHOICE TEXT
*goto informmenu
*if (archease > 0)
*disable_reuse #The odd leadership dynamic between Architect and Wyrd.
*set given true
*set archease 2
CHOICE TEXT
*goto informmenu
*if (archconnections > 0)
*disable_reuse #Architect's suspiciously developed web of contacts.
*set given true
*set archconnections 2
CHOICE TEXT
*goto informmenu
I’m really baffled. As stated I cannot get these errors myself. When I play, the options appear normally and proceed as expected. The same thing happened last chapter with this code, only saying ‘Not a number: true’ on *set interest_alistair true:
*if (aro != 4) #But I think I'd like to get closer still. Wait. Oh no. @{ftone [Flirt, passive]|}
*set interest_alistair true
*set flirt_alistair +1
archease is created with *create archease 0
archconnections: *create archconnections 0
interest_alistair: *create interest_alistair false
Both of the former are only *set with *set [var] +1 or *set [var] 2, the latter isn’t even touched before that specific line.
Is there any way you can run randomtest? To see if you can get the error yourself.
There doesn’t appear to be anything wrong at first glance, everything looks fine?
You could also ask if whoever is reporting errors is editing stats or save editing, I’ve seen a number of reported errors being the result of editing stats to invalid values.
Randomtest is something I’ve gotta patch up at some point - believe I need to use the code that sets something specific otherwise the randomtest gets (I think) caught in a confirmation loop after name input
Can you check if you have that variable set as True or False. You’re using it as a number variable, but it might be set in the start-up page as true or false
If I had time to help, I would open all the code in a browser and use the search function to find every time those variable names are used, and check that they don’t get set to anything wrong at any point.
Then, as @dreamofeden said, ask your players if they manually changed the value of these variables. There’s no reason why they would change from integer to boolean on their own.
I remember seeing once Choicescript sometimes gets confused about 0 as a value. Can you try establishing it as 1 instead of 0, and seeing if that changes anything? You would also have to probably change the >0 to >1. (I suspect this won’t make a difference, but it’s worth a shot.)
I’ve not seen this, and I’ve got a ton of 0 variables. CS can struggle with negative numbers, due to the inability to distinguish e.g “set stat to negative two” from “set stat minus two”…might that be what you’re thinking of?
My first guess would also be that your players are editing their stats to set archease to false – worth double checking with them on that.
Also why are you using disable reuse this way? Putting it once before the choice block should disable it until you turn reuse back on. I didn’t know what having the disable reuse inside the choice itself will do if people are selecting things multiple times. (Probably allow then to select it twice? Unless they’ve already hit disable commands elsewhere.)
I haven’t hit issues with stat=0 type commands, although I’d also recommend using stat <1 (if that’s not another option) in case the stst gets messed up somewhere and causes it to drop below 0 (either via an author or modding issue.)
Yup. But I thought hitting that command in the text of a choice statement (which happens in one of these) would do that too? And I think all of them carry the disable_reuse in some way (apart from the one that’s in the text inside the choice for the selectable if one so maybe that’s why but I can’t see a reason for it unless the author plans to add more variables that will change the text if it’s reselected again instead of one of the other choices in this block?) Otherwise I’d probably just turn them all off above the *choice, then enable it again after the choice block. Anyways, probably not the error here, but I just thought it was oddly coded. I’d be more worried about the lack of tabs on the selectable if choice being out.
That indent (fortunately?) is actually a transcription error here. It’s at the same indent as the other options.
tbh I used disable reuse like that because previously it wasn’t playing nice when I used it in conjunction with selectable_if and if, and the choice didn’t actually disable.
I did run into that mentioned multireplace issue previously but this isn’t the same thing.
I may try setting the variable as a 1 by default instead of 0, though because of how it’s used it will be kind of annoying to shunt every reference to it along (and there are a lot of variables that are created as 0, so I hope that it’s not the problem!) - maybe I will give >= 1 a shot instead
It’s just such a weird error: players seem to get it in similar spots, but then some of them don’t get it at all. One player had the error when using the skip function, which entails a goto_scene, and then not when not using skip, but neither variable is ever mentioned in the skip code.
Oh, and just going back to the examples I have had, it also happened on a line which was just *set interest_alistair true
Try creating it as a string instead of an integer.
*create myVar "0"
JavaScript will convert it to Number under the hood at the first instance of an arithmetic operation and it should prevent ChoiceScript from converting it to boolean. Though, I’m not convinced that’s the real problem. Did you confirm with your players if they manually changed values?
Just a brief update - it’s looking like the culprit is players using old dashingdon saves from the previous build(s), as several of the reports have had that in common, and seem to be fixed on a fresh start.
I wouldn’t have thought of that, but it’s a pretty common problem.
For the future, you can create a variable version and increment every time you update the dashingdon files. Print the version on the stats page. When someone reports an issue like this you can ask them for the version as well. You can use Semver for that.
