llSetPrimitiveParams syntax error

Any idea why this will give a syntax error on PRIM_TEXTURE

llSetPrimitiveParams( [PRIM_COLOR, i, c, a, PRIM_BUMP_SHINY, i, shiny, bump, PRIM_FULLBRIGHT, i, fullbright, PRIM_TEXGEN, i, texgen, PRIM_TEXTURE, i, texturestring, < texscale_u, texscale_v, 0 >, < texoffset_u, texoffset_v, 0 >, 0]);

but this won't (the difference may be hard to see because of no formatting--the above line has been broken into two calls):

llSetPrimitiveParams( [PRIM_COLOR, i, c, a, PRIM_BUMP_SHINY, i, shiny, bump, PRIM_FULLBRIGHT, i, fullbright, PRIM_TEXGEN, i, texgen]);
llSetPrimitiveParams( [PRIM_TEXTURE, i, texturestring, < texscale_u, texscale_v, 0 >, < texoffset_u, texoffset_v, 0 >, 0]);

i is an integer, c is a vector, a and all other variables are floats.

Also, this won't give a syntax error (the only difference is all i's have been replaced with ALL_SIDES):

llSetPrimitiveParams( [PRIM_COLOR, ALL_SIDES, c, a, PRIM_BUMP_SHINY, ALL_SIDES, shiny, bump, PRIM_FULLBRIGHT, ALL_SIDES, fullbright, PRIM_TEXGEN, ALL_SIDES, texgen, PRIM_TEXTURE, ALL_SIDES, texturestring, < texscale_u, texscale_v, 0 >, < texoffset_u, texoffset_v, 0 >, 0]);

I've found other instances where llSetPrimitiveParams gives a syntax error on combined lines but not when broken up. It may not seem like a big deal except this function has a 0.2s delay.

My first thought given the symptoms was that you might be exceeding the 72 item limit on list literals in your code, but examining the code you look like you're way under that. Can you post the error it is giving you?

I don't get any syntax errors on compilation when I copy/paste your first example into default state_entry and declare the global variables used.

Couple of things I can think of:

1) The script editor in SL will sometimes... flip out

I've run into this like 50 times. Its like it inserts some invisible or hidden character in somewhere when editing, using undo or cut/paste, I haven't figured it out. But the number of times I've typed in the EXACT line just below it and removed the first and have it suddenly work is amazing.

Now that you mention it, an easier way would be to cut/paste into notepad or other editor then back into the LSL editor, that might silently remove the problem.

2) Another possibility is that you just freaked out the parser with exactly the right combo of parameters and even merely rearranging their order might fix it. There are other stupid syntax tricks you can get the compiler to fail on as well that should be perfectly legal.

Farallon, I tried copying to notepad and back and it didn't solve the problem. However, moving the code to its own function above its original function worked. Moving it anywhere else didn't work, and would fail on a different argument. Also of interest, undo tended to trash those lines of code in their original position.

So, I've solved the problem but still don't know why it happened.

Crap. I ran into this problem again, and no amount of moving of the code is making it magically disappear this time.

Just go ahead and download SLEditor. Running either the built in syntax checker or using lslint as a plug in will find any problems and clicking on the error will bring you to the line and place the cursor on the error.

Plus you have the added bonus of being able to script faster and offline.

Conversely, you could also just paste your script into lslint here:

http://w-hat.com/lslint/

I tried lslint and found my problem was parser stack depth. After cleaning up a few unused variables and a couple duplicately defined variables, also found with lslint, the stack depth problem went away, and so did the syntax errors. Thank you, Jesse

default
{
state_entry()
{
integer i;
vector c;
float a;
integer shiny;
integer bump;
integer fullbright;
integer texgen;
string texturestring;
float texscale_u;
float texscale_v;
float texoffset_u;
float texoffset_v;

llSetPrimitiveParams( [PRIM_COLOR, i, c, a, PRIM_BUMP_SHINY, i, shiny, bump, PRIM_FULLBRIGHT, i, fullbright, PRIM_TEXGEN, i, texgen, PRIM_TEXTURE, i, texturestring, < texscale_u, texscale_v, 0 >, < texoffset_u, texoffset_v, 0 >, 0]);
}
}

This compiles for me in SL, using the current Windlight First Look viewer. I suspect they've cleaned up some compiler bugs since the client you're using or something?