Say I have a bubble gum machine and each time you hit it a piece of bubble gum spits out and lands on the floor. I want to keep track of how many times this has happened. Is it simply a case of adding something like this to the script:

bubblegum.floor + 1

And do I have to create that attribute somewhere first or does Quest do that automatically if I just do something like above (which I'm sure is wrong but on the right track).

What you have there is an expression that will add one to the existing value, but you then need to assign that to something (itself in this case). However, it would be better to keep count on the machine, rather than the bubble gums, of which there could be many, their names will all be different, and presumably some or all could be eaten.

bubblegummachine.floor = bubblegummachine.floor + 1

So this will set the value of the "floor" attribute of the bubblegummachine to whatever it was previously plus one.

When you assign a value to an attribute, Quest will indeed create the attribute for you. However, in this case, it will first look for the old value, find it missing, and object that you cannot an integer to null. So yes, you will need to set an initial value. Either have this in the start script:

bubblegummachine.floor = 0

Or go to the attributes tab, and create a new integer attribute there (this is the way I prefer as it keeps everything collected together on the one object).

Thanks. I couldn't find anything in the documentation explaining that. Basically I'll have an object called a piece of bubblegum (hypothetically) and an object called a couple of pieces of bubblegum and then one called a pile of bubblegum. I've already got that aspect working but then decided that I want the info relayed dynamically:

{if bubblegummachine.floor>=3:a pile of bubblegum is at your feet.}

But also if the player picks up a piece of bubblegum I'd need to know which scenery object should be present and switch accordingly.

With regards to the above, is a Boolean also a 'value' or does the value have to be numerical? For example would this work:

{if player.sick=true:you've felt better than you do right now.}

yes.

{if player.sick=true:you've felt better than you do right now.else if player.sick=false:you feel really great right now.}

(I'm not sure if this is the correct syntax, but it should otherwise work, as the text processor should have this functionality: a quicker and more simple structure of coding)

with Boolean usage, the quest engine understands, the shortened form:

'player.sick=true' ---> 'player.sick'

quest's engined is programmed to understand that 'player.sick' is the default short form of 'player.sick=true', so if you want to tell the engine that a Boolean has the Value of 'false', you must write '=false', unless you're bypassing this via using an 'if' Script's 'else' functionality, hehe.

so, Jay especially, would prefer this structure instead of the one above (lol):

{if player.sick:you've felt better than you do right now.else:you feel really great right now.}

Thanks. The 'else' part of your text processor script won't work though as it's not supported in Quest. I was more checking whether a 'value' has to be numerical or whether 'true' is also a 'value'.

Oh right, so I don't even need the 'value'. As long as player.sick = player.sick = true then this will work:

{if player.sick:you've felt better than you do right now.}

I think...

in code form, the quest engine is programmed to be able to determine (?parse?) the Attribute Type from its Value.

'set a variable or attribute' Script:

Object_name.Attribute_name = Value_or_Expression

the Value forms:

= "xxx" ---> String Attribute
= ### ---> Integer Attribte
= xxx ---> (except 'true' and nor 'false' ) ---> Object Attribute
= #.# ---> Double Attribute
= true ---> Boolean Attribute
= false ---> Boolean Attribute

otherwise, you can use the:

'set' Script:

set (Object_name, "Attribute_name", Value)

and lastly, you can convert between String and Integer Values (which thus converts between String Attributes and Integer Attributes):

get input {
// you type in a number, which will be the Attribute's Value, making~setting the Attribute be an Integer Attribute:
player.strength = result
// but now you changed your mind and want it to be set to a String Attribute:
player.strength = ToString (player.strength)
// but wait, you changed your mind again, wanting it to be back to an Integer:
player.strength = ToInt (player.strength)
// and then back to a String again, just kiding ... hehe

Okay, so now I understand integer and boolean. Can you give any practical examples of where a string or double attribute would be used?

here's an analogy

if I were to say 'redneck'

you would immediate default that this person is a(n American) conservative or that they support the 2nd Amendment

when you type in:

if (orc.dead) { script }

quest is programmed to default that this is: orc.dead=true

so, if you want to set the Boolean to the Value of 'false', you must write~type it in, as otherwise quest will think it's Value is '=true', so you type it in:

orc.dead=false

so, it's just a way of saving time, not having to write~type as much, and with (often) it being used within an 'if' script, it reduces possible clutter confusion, which is what Jay likes:

if (orc.dead) {
-> script1
} else {
-> script2
}

no clutter

whereas, I personally like the 'clutter', as it helps me understand what's going on:

if (orc.dead=true) {
-> script1
} else if (orc.dead=false) {
-> script2

But how does that explain what a string attribute is?

Only for a Boolean WITHIN AN 'IF' Script and having a 'true' Value, do you not need to write~type it in, all other Values must be written~typed in, as quest has no way of knowing what the Value is otherwise.

String Attributes:

if (player.condition = "poisoned") {
-> player.hp = player.hp - 50
} else if (player.condition = "confused") {
-> party_member_1.hp = party_member_1.hp - player.damage
} else if (player.condition = "stunned") {
-> player.turn_skipped = true
}

Double Attributes:

I haven't worked with these yet, but they're just working with decimal numbers:

3.478798
2355.19
7.5
0.00001
-0.00001
-7.5

instead of 'whole' numbers like Integer Attirbutes:

-1
0
1
5
100

You already use strings. The descriptions for rooms and objects are strings (unless you they are scripts). If you let the player type in a name for herself, you would story that as a string. You could assign your bubblegum a random flavour when the machine produces it, and hold that in a string.

As for doubles, I have never used them in Quest, and rarely anywhere else.

String Attribute:

if (orc.dead = "0") {
-> script1
} else if (orc.dead = "1") {
-> script2
} else if (orc.dead = "2") {
-> script3
} else {
-> script4
}

{if orc.dead="0" msg ("hi")}
{if orc.dead="1" msg ("bye")}

Integer Attribute:

if (orc.dead = 0) {
-> script1
} else if (orc.dead = 1) {
-> script2
} else if (orc.dead = 2) {
-> script3
} else {
-> script4
}

Boolean Attribute:

if (orc.dead = true) {
-> script1
} else if (orc.dead = false) {
-> script2
}

Object Attribute:

if (orc.dead = apple) {
-> script1
} else if (orc.dead = banana) {
-> script2
} else if (orc.dead = lemon) {
-> script3
} else {
-> script4
}

String Attribute:

if (orc.dead = "apple") {
-> script1
} else if (orc.dead = "banana") {
-> script2
} else if (orc.dead = "lemon") {
-> script3
} else {
-> script4

Ah, HK the 'else' script in the text processor is:

{if not object.attribute:text}

They have to be done separately though afaik.

{if object.attribute:text}{if not object.attribute:text}

The text processor is well handy! I'm glad I turned up when I did and not years ago.

ah, so you just need to use the 'not' condition, plus another segment of typing... would be nicer if Alex could program it in to recognize 'if else' and 'else' instead... but I'm sure it's not easy (or because he can't do so), or he'd have done it in the first place, hehe.

the text processor is just a faster way to write~type it in, but the same logic is being done.

if (orc.dead=true) {
-> msg ("hi")
} else if (orc.dead=false) {
-> msg ("bye")
}

is the same as

{if orc.dead msg ("hi")} {if not orc.dead msg ("bye")}

or if Booleans worked with 'else if' in squiffy:

{if orc.dead msg ("hi"). else if orc.dead=false msg ("bye")}

or with 'else' too:

{if orc.dead msg ("hi"). else msg ("bye")}

He's done {else:text} in squiffy apparently. But for a boolean if not works just as well. Jay won't be happy!

Any attribute whose form is just text is a string attribute. As Pixie said, descriptions are strings unless you add a script to them.

As for using them in some useful way, HK shows it off above. Let's say you have a character, Bob, and an attribute, mood. You make it a string attribute and set it to 'happy', because Bob is usually a happy guy. But if something in the game can change and make Bob angry, you'd change the value of Bob.mood to 'angry'. Then you could have a different description/behavior/response based on whether Bob.mood="happy" or Bob.mood="angry". NOTE: You don't surround it in quotes when putting it in the field, but you DO put it in quotes whenever you invoke it. So you'd just type happy, no quotes, in the string attribute field, but to use it in a variable you'd need to put Bob.mood="happy". The quotes tell Quest to look for a value that's a string.

It's just an easy way to have a variable with numerous possible states that can be explicitly named, so you, as the writer, know which attribute it which. You could do the same exact thing with integers if you wanted, having 1 represent happy, 2 angry, 3 sad, etc.; but using strings prevents you having to remember what value means what.

Making it a string also has the added benefit of letting you display its value in game. So you could use the text processor and write "Bob looks {Bob.mood}", and it would spit out "Bob looks happy" or "Bob looks angry" automatically.

Thanks for that. I've had a leap in understanding today.

A few months ago I was like wtf at HK's posts. I probably need to go back over them all now lol. Penny has dropped.

have fun with that, all 1376 posts! (lots of posts of mine with code, laughs)
(if you find some certain posts~codings of mine that I've been looking for, let me know! just teasing, I'm having some fun here, hehe)

Silver wrote:He's done {else:text} in squiffy apparently. But for a boolean if not works just as well. Jay won't be happy!

Hey, you use what you have.

quest's engined is programmed to understand that 'player.sick' is the default short form of 'player.sick=true', so if you want to tell the engine that a Boolean has the Value of 'false', you must write '=false', unless you're bypassing this via using an 'if' Script's 'else' functionality, hehe.

Actually, it's not the "short form". Using the "=true" is redundant. "player.sick" is already a boolean expression. "player.sick=true" is also a boolean expression, but with the exact same value as "player.sick". The "player.sick" variable is already true or false. Adding "=true" just generates an expression which is again identically true or false. Here's a truth table:

player.sick  |  player.sick=true
---------------------------------------
false        | false
true         | true

Another way to look at it: if you do

b1 = player.sick
b2 = (player.sick=true)

then b1 will *always* equal b2. "player.sick=true" will be true or false identically to "player.sick". You not only gain nothing by adding the "=true", you also harm the readability of the code.

As you can see, "player.sick=true" has the exact same value as "player.sick". Which has the exact same value as "(player.sick = true) = true" which has the exact same value as "((player.sick = true) = true) = true" which has the exact same value... (to infinity).

By contrast, you must use something like "x=0" to generate a boolean expression, as "x" is not already a boolean. The key thing is that this is not specific to an "if". You can use boolean expressions just like any other.

happy = player.happy
overjoyed = player.overjoyed
reallyhappy = happy and overjoyed

(which could be: reallyhappy = player.happy and player.overjoyed)

poisoned = player.poisoned
sick = player.sick
rich = player.rich

player.unhappy = (poisoned or sick) and not rich
-or-
player.unhappy = (player.poisoned or player.sick) and not player.rich

Imagine how horrible that would be to read if you had "=true" and "=false" all over the place!

Similarly, you'd never see "value = false" unless you're using a language doesn't support booleans properly. You'd just see "not value". Stuff like that.

So If player.sick doesn't need a 'value' as that expression alone means true.

I'm having a great day.

Actually, is it an expression? I got confused at that bit. The adding an = makes it one or something.

Well, more like: "if" needs a boolean value passed to it. "player.sick" is already a boolean value. You don't need anything else. (And I added some stuff up there in my earlier post, if that helps. lol)

Yes, "player.sick" is a boolean expression (assuming player.sick is a boolean attribute). You can only pass boolean expressions to "if", so you need to, uh, "express" such a condition by using comparisons, etc for non-boolean values to turn them into one.

And by readability, I mean that

if (player.sick = true)

reads as if it's asking if the player.sick variable has the value true. Whereas

if (player.sick)

reads as if it's asking if the player is sick. I think people typically care about the latter. I'm probably being too esoteric, but it's so clear in my head.

I'll probably come unstuck when I try using it. I wasn't thinking about the brackets for starters. Do I set the boolean without the brackets though?

player.sick = true

If (player.sick) {
}

Yes, you'd set it just like any assignment:

player.name = "John Doe"
player.age = 21
player.sick = true

Cool, thanks.