Can not call use '==' operation on String and List

If I’m using a word (string) for a variable, I’m supposed to put it in quotes, right? e.g.:

VAR current = "spy"

But if I have that same word defined as part of a list:

LIST completed = spy, heist, noir, truth

Then it seems to let me get away with NOT having my variable be in quotes—I think because now it isn’t viewing it as a string but as a value in the list?

The starting state for my ‘current’ variable is NOT defined in a list, and so it MUST be in quotation marks. But when events happen to change that variable, it lets me use either

~ current = "spy"

or

~ current = spy

Today, seemingly out of nowhere, it started giving me error after error that basically want me to add quotation marks from my variables anytime I test against them. This happened to me once before, but in the opposite direction (removing quotation marks around variable string names) and I’ve already gone through all my code once changing “spy” to spy (no quotation marks) because of this “Can not use ‘==’ operation on String and List” error.

I thought it was all fixed (that was like a month ago, probably more, and it’s been fine) but now it’s happening again but wanting me to add the quotation marks back in. Here’s an example of the offending code:

{
     - current == spy && not inquire_at_each_bank:
         <- inquire_at_each_bank
     - current == heist:
         <- go_peoples_bank
 ...

If I make them be == "spy" and == "heist" the error clears.

Where I give the “current” variable its new value, those are all in quotation marks: current = "spy". current = "heist", current = "noir" etc. I think I did that as a part of the last time I had to change everything? But, if I take the quotation marks off there, it clears the scads of errors that suddenly appeared.

Can anyone explain what is happening? Does it matter whether the variable state is a string or is using the value of a list item? Should I not be using the same names for the variable states as I do in the list? (Also, I don’t understand why it was fine and not it wants it back the other way, though that’s of less importance I guess)

I really don’t care one way or another, I just don’t want to continuously be going through all my ink code changing it back and forth! :S

The string "spy" is an entirely different type of value from the list item spy. If you assigned a new value to current using quotation marks (e.g. ~current = "spy") then the value of that variable is now a string, and thus you can’t compare it with spy (no quotation marks), which is a list item rather than a string.

Technically, you can convert a list item to a string if you want, using "{current}", but it would be better to just consistently use list items rather than strings. So assign ~current = spy and compare current == spy, and never use quotation marks unless you have a specific reason to convert the variable to a string (like if you’re going to print it or something).

TL;DR: spy and "spy" are two completely unrelated things with no relationship between them. Figure out which one you want (probably the former) and just use that consistently

EDIT: To elaborate further, it sounds like you’re having problems because you’re trying to assign a string value to current at first, but then switch to using list items later. At any point in time, if current is currently a string, then you’ll get an error if you try to compare it with a list item. But if it’s currently a list item then you’ll get an error if you try to compare it with a string. So you really should just make up your mind about what type of variable current is going to be (probably should be a list item), and commit to it. This might mean you need to define a list to contain the starting value, if you don’t already have that.

2 Likes

THANK YOU!! That’s all makes perfect sense, and I’m not sure where I went wrong initially. From what you describe, I probably left some of the old string versions of spy etc in place, but maybe hadn’t been through that bit of content in a while to trigger it, hence it’s sudden “reappearance” today.

I’ll do a find and replace to make sure there aren’t any more string versions, and should be gtg :slight_smile:

And again, thank you for your help!

EDIT: it also occurs to me that you’re probably right that maybe I tried comparing a list item value to a string value in current and that made me think it needed to be a string. Or vice versa. So thanks for taking all that time to explain!

1 Like