Yes I know, but then what purpose does attribute serve - its essentially a nerfed version of numeric expression?

So, yeah, what the difference between the two when stating the condition for a rule?

instead of booleans for each type of action, I prefer to have one integer state attribute:

(Quote)

You'd have two options really. The first is essentially what you said - but instead of change attribute you'd have a "working" table, and you'd copy the randomly chosen table into th

I tried by creating a game attribute (text, not sure about this) and randomly assigning a table to it, but I guess you can't assign a table name as a text value and then use that attribute when loadin

(Quote)

Set your text opacity to a low value like 2% or 5%, add a Replicate behaviour, set 'Spacing' to 0, you can now control the opacity of your text with the 'Copies' attribute.

(Quote)

(Quote)

You may need to wrap the change attribute in a short timer to ensure that it's firing correctly. You won't have to do this in Creator 1.25 as we will have the ability to run behavior sequentially; we

The new better collisions checkbox will remedy this.

Make attribute game.snakerow = 1

It's 1/60th/sec. Constrain = Do this once every code cycle. Code Cycle =1/60th/sec.

The self-constrain is another interesting way to do this. Hmm...

Collisions below the speed of 70.7pps don't work correctly.

Constrain x to x+0.01666666666667

A good flexible clock is a rotating actor, stick a little actor somewhere off camera, open its angular velocity attribute and enter '1'.

The device clock and the attributes game.Time, scene.Time, and self.Time are like real time. They don't stop. At least until someone builds a time machine. Because it's built-in, it's an easy thing

Yeah, no need to constrain magnitude, use it like any other function, so a better comparison between the two approaches would be: