Why is the next state not starting?

Does not got to 'state tail' when prompted from the loop:

{code}
default
{

state_entry()
{
llSetTimerEvent(0.1); // needed so you can get the touch_start to interupt the timer and turn it off!
llSetLinkColor(1, <255,255,255>, ALL_SIDES);
}

timer()
{
if (on == TRUE)
{
for (x = 0.3; x < y; x+=0.1)
{
llSetLinkPrimitiveParams(LINK_ROOT, [PRIM_GLOW, ALL_SIDES, x]);
llSleep(t);
}
on = FALSE;
state tail; // doesn't seem to execute, the glow loop just keeps running.
}

else if (on == FALSE)
{

for (x = y; x >0.3; x-=0.1)
{
llSetLinkPrimitiveParams(LINK_ROOT, [PRIM_GLOW, ALL_SIDES, x]);
llSleep(t);
}
on = TRUE;
}

}
}

state tail
// tail code here

{/code}

Any ideas?

I'm just started trying this coding for the child prims... I have this script in the root prim that is trying to control the child prims...

the tail script goes like this:

{code}
state tail
{
state_entry(){
for(a = 2; a == 13; a += 1)
{
llSetLinkColor(a, <255,255,255>, ALL_SIDES);
llSetLinkColor(a, <247,255,0>, ALL_SIDES);
}
state default;
}
}
{/code}

Just thought this might be appropriate, is there anything that I need to do to the child prims? Is that maybe why the script isn't working? just firing ideas here thanks

What are global variables x,y,t and ON declared as up at the top?

for(a = 2; a == 13; a += 1)

Sure you don't want a <= 13?

ah yeah n00b mistake there, forgot it was a test and not a limit.

Well after a wee bit fiddling I realise now that the state does actually execute but it's the for loop that is not running:

{code}
state tail
{
state_entry(){
for(a = 2; a < 14; ++a)
{
llSetLinkColor(a, <255,255,255>, ALL_SIDES);
llSetLinkColor(a, <247,255,0>, ALL_SIDES);
llSleep(t);
}
state default;
}
}
{/code}

Anybody see any faults there?

float x = 0;
float y = 0.9;
float t = 0.1;


x, y and t as requested

:0 wait, you mean you're trying to get a script in the root prim to command a child prim script to jump state?? :\ can't do that directly... you'd need to use linkmessages and have the childscript do the actual statejump itself. (hope that helps i'm just sight-reading the script but from your description, sounded like that's what you're trying to do...)

ah ignore the message about the child prims, im not trying to change the script I'm just trying to control the child prims in the root prims script. I found out shortly after that I'm talking absolute rubbish here...

Now my only problem is the for loop is not running... any ideas?

this bit?
for(a = 2; a == 13; a += 1)

:0 i think the last bit, a+=1, should actually be a++ or a+1. i've never seen += - seems like an error the validator should pick up. code experts, does += actually do/mean anything?

for(a == 2; a <=13; a++)

I think ...

hmmm gna start a new thread things have changed too much now.. thanks for your efforts tho folks.

a+=1 == a = (a+1) == a++

"a += 1" is the same as "++a".

just putting "a+1" would have no effect, so I assume you mean "a = a + 1", which is the same as "a += 1".

Already mentioned above is the problem: this loop will never execute because it fails the "a == 13" test immediately and never executes the controlled clause.

ah, and that's perfectly right - the 'all in one' for/next thing still always gorks me up. never knew all the rest of those syntaxes... lol i try to stick with just a few patterns; gets confusing.

No harm in that! I avoided these terse operators when I switched from Pascal to C, but after 2 decades or so they've sunk in.

The all-in-one for loop control clause is worth learning well, because it collects the 3 parts of controlling a loop into one place and can help improve code consistency.

The shorthand operators are really little more than that, and generally don't provide significant value that offsets their obfuscation to a newcomer. In the early days of C programming -- before say 1990 -- they helped the compilers optimize, but those days should be long gone. Oops, with LSL, they might still help, though not with Mono. But IMHO, that's the wrong way to optimize except in special cases.

Obviously, YMMV, but I've found some newcomers understand the terse operators better
My father used to struggle understanding

10 LET x = x + 1

. In his words, "a number can't be equal to itself plus one. three isn't equal to four!"
I would have to write

10 LET temp = x + 1
20 LET x = temp

to keep him happy.

If Spectrum Basic had offered an increment keyword like

10 INCREMENT x

he would have got it first time.

IMO, many people understand x++ better than they grok setting a variable in terms of itself.

... and comparing "x+=3" to "x=x+3":
isn't it more natural and intuitive for us to think "add three to x" than "make x equal to its old value plus three"
anyway - just my two cents worth