0007062: utterly mystifying Syntax error (parsing error in vector math?)

(0025461)
AliciaRaven (manager)
2014-03-18 08:27

Hi Mata Hari

There seems to be something wrong with the compiler, it doesnt like adding two vectors and taking away one in one go, so..

This will fail...

pos1 + pos2 - pos3

It can be fixed by putting a bracket around the first two. So to fix your code would be...

adjustSit(key who, vector pos, rotation rot)
{
    if (who==NULL_KEY) return; // make sure we didn't somehow call this with a NULL_KEY sitter
    vector size=llGetAgentSize(who);
    if (size==ZERO_VECTOR) return; // make sure we aren't trying to move a phantom
    vector localpos = ZERO_VECTOR;
    rotation localrot = ZERO_ROTATION;
    if(llGetLinkNumber() > 1) //if this function is in a script in a non-root prim we need local values
    {
        localrot = llGetLocalRot();
        localpos = llGetLocalPos();
    }
    integer linkNum = llGetNumberOfPrims();
    do
    {
        if(llGetLinkKey(linkNum)==who) //this is the avi we want to move
        {
            //according to LL best fit coef for avi is <0.008906, -0.049831, 0.088967> plus the base offset of sit targets of z+0.4
            float fAdjust = ((((0.008906 * size.z) + -0.049831) * size.z) + 0.088967) * size.z;
            llSetLinkPrimitiveParamsFast(linkNum,
                [PRIM_POS_LOCAL, ((pos + <0.0, 0.0, 0.4>) - (llRot2Up(rot) * fAdjust)) * localrot + localpos,
                 PRIM_ROT_LOCAL, rot * localrot]);
        }
    } while (--linkNum);
}
default
{
    state_entry()
    {
    }
}

Hope that helps :)

(0025462)
Mata Hari (reporter)
2014-03-18 08:38
edited on: 2014-03-18 08:44

I have now logged into SL and compiled the above without issue so it would seem to be an Opensim issue rather than a viewer one (or blonde moment)

EDIT: thanks Alicia!

I seem to recall that there was a recent refactoring of compiler messages so perhaps something got borked during that process and needs to be fixed

EDIT 0000002: can confirm that it now compiles properly by making the change suggested by Alicia

(0026642)
Mata Hari (reporter)
2014-07-30 06:42
edited on: 2014-07-30 06:45

Did a little more investigation on this compile error

vector v1 = <1.0, 1.0, 1.0>;
vector v2 = <2.0, 2.0, 2.0>;
vector v3 = <3.0, 3.0, 3.0>;
default
{
    state_entry()
    {
// vector v4a=<1.0,1.0,1.0> + <2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>; // this line throws error on compile
        vector v4b=(<1.0,1.0,1.0> + <2.0, 2.0, 2.0>) - <3.0, 3.0, 3.0>;
// vector v4c=<1.0,1.0,1.0> + (<2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>); // this line throw error on compile
        vector v5 = v1 + v2 - v3; // interestingly this line does not throw an error
        vector v6 = v1 + v2 - <3.0, 3.0, 3.0>; // nor does this one
// vector v7 = v1 + <2.0, 2.0, 2.0> - v3; // but this one does!
        vector v8 = <1.0, 1.0, 1.0> + v2 - v3; // and this one doesn't
// vector v9a = v1 + <2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>; // this line throws error on compile
        vector v9b = (v1 + <2.0, 2.0, 2.0>) - <3.0, 3.0, 3.0>;
// vector v9c = v1 + (<2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>); // this line throws error on compile
    }
}

(0026737)
maurizio55 (reporter)
2014-08-11 14:51

looking at the test, apparently the error happens only when the second vector is explicit.

(0026739)
kcozens (administrator)
2014-08-12 13:06

I ran some tests the problem is a little stranger. As long as you are only adding multiple vectors in a single statement the parser allows it. You get a parser error the moment you try and subtract two explicitly declared vectors. I have attached a file called vector-math.lsl that shows the errors.

(0026740)
Mata Hari (reporter)
2014-08-12 13:27

@kcozens: my attempt above with vector v7 = v1 + <2.0, 2.0, 2.0> - v3; also failed so it would seem that one explicitly declared vector can do it too. Enclosing either (v1 + <2.0, 2.0, 2.0>) or (<2.0, 2.0, 2.0> - v3) removes the error.

(0026958)
Mata Hari (reporter)
2014-10-21 09:21
edited on: 2014-10-21 09:21

Here's a (probably related) mystifying one I just encountered:

This line will not parse:
llSetLinkPrimitiveParamsFast(link,[PRIM_POS_LOCAL, <0.0, 0.0, 0.4> - (llRot2Up(ZERO_ROTATION) * fAdjust),PRIM_ROT_LOCAL, ZERO_ROTATION]);

But simply enclosing the initial vector in parenthesis lets the line parse
llSetLinkPrimitiveParamsFast(link,[PRIM_POS_LOCAL, (<0.0, 0.0, 0.4>) - (llRot2Up(ZERO_ROTATION) * fAdjust),PRIM_ROT_LOCAL, ZERO_ROTATION]);

(0029513)
UbitUmarov (administrator)
2015-10-18 08:54

as in mantis 7688 the sequence "> -" will fail to parse correctly most time.
enclosing vector constants in () is the best option, since a fix is not expected soon.

Issue History
Date Modified	Username	Field	Change
2014-03-18 08:11	Mata Hari	New Issue
2014-03-18 08:27	AliciaRaven	Note Added: 0025461
2014-03-18 08:38	Mata Hari	Note Added: 0025462
2014-03-18 08:40	Mata Hari	Note Edited: 0025462	View Revisions
2014-03-18 08:44	Mata Hari	Note Edited: 0025462	View Revisions
2014-07-30 06:42	Mata Hari	Note Added: 0026642
2014-07-30 06:43	Mata Hari	Note Edited: 0026642	View Revisions
2014-07-30 06:45	Mata Hari	Note Edited: 0026642	View Revisions
2014-08-11 14:51	maurizio55	Note Added: 0026737
2014-08-12 13:04	kcozens	File Added: vector-math.lsl
2014-08-12 13:06	kcozens	Note Added: 0026739
2014-08-12 13:27	Mata Hari	Note Added: 0026740
2014-10-21 09:21	Mata Hari	Note Added: 0026958
2014-10-21 09:21	Mata Hari	Note Edited: 0026958	View Revisions
2015-08-18 19:09	Mata Hari	Relationship added	related to 0007688
2015-10-18 08:54	UbitUmarov	Note Added: 0029513
2017-11-08 09:35	kcozens	Summary	utterly mystifying Syntax error => utterly mystifying Syntax error (parsing error in vector math?)
2017-11-23 12:16	Mata Hari	Status	new => resolved
2017-11-23 12:16	Mata Hari	Resolution	open => won't fix
2017-11-23 12:16	Mata Hari	Assigned To	=> Mata Hari
2017-11-23 12:17	Mata Hari	Status	resolved => closed

Notes
(0025461) AliciaRaven (manager) 2014-03-18 08:27	Hi Mata Hari There seems to be something wrong with the compiler, it doesnt like adding two vectors and taking away one in one go, so.. This will fail... pos1 + pos2 - pos3 It can be fixed by putting a bracket around the first two. So to fix your code would be... adjustSit(key who, vector pos, rotation rot) { if (who==NULL_KEY) return; // make sure we didn't somehow call this with a NULL_KEY sitter vector size=llGetAgentSize(who); if (size==ZERO_VECTOR) return; // make sure we aren't trying to move a phantom vector localpos = ZERO_VECTOR; rotation localrot = ZERO_ROTATION; if(llGetLinkNumber() > 1) //if this function is in a script in a non-root prim we need local values { localrot = llGetLocalRot(); localpos = llGetLocalPos(); } integer linkNum = llGetNumberOfPrims(); do { if(llGetLinkKey(linkNum)==who) //this is the avi we want to move { //according to LL best fit coef for avi is <0.008906, -0.049831, 0.088967> plus the base offset of sit targets of z+0.4 float fAdjust = ((((0.008906 * size.z) + -0.049831) * size.z) + 0.088967) * size.z; llSetLinkPrimitiveParamsFast(linkNum, [PRIM_POS_LOCAL, ((pos + <0.0, 0.0, 0.4>) - (llRot2Up(rot) * fAdjust)) * localrot + localpos, PRIM_ROT_LOCAL, rot * localrot]); } } while (--linkNum); } default { state_entry() { } } Hope that helps :)

(0025462) Mata Hari (reporter) 2014-03-18 08:38 edited on: 2014-03-18 08:44	I have now logged into SL and compiled the above without issue so it would seem to be an Opensim issue rather than a viewer one (or blonde moment) EDIT: thanks Alicia! I seem to recall that there was a recent refactoring of compiler messages so perhaps something got borked during that process and needs to be fixed EDIT 0000002: can confirm that it now compiles properly by making the change suggested by Alicia

(0026642) Mata Hari (reporter) 2014-07-30 06:42 edited on: 2014-07-30 06:45	Did a little more investigation on this compile error vector v1 = <1.0, 1.0, 1.0>; vector v2 = <2.0, 2.0, 2.0>; vector v3 = <3.0, 3.0, 3.0>; default { state_entry() { // vector v4a=<1.0,1.0,1.0> + <2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>; // this line throws error on compile vector v4b=(<1.0,1.0,1.0> + <2.0, 2.0, 2.0>) - <3.0, 3.0, 3.0>; // vector v4c=<1.0,1.0,1.0> + (<2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>); // this line throw error on compile vector v5 = v1 + v2 - v3; // interestingly this line does not throw an error vector v6 = v1 + v2 - <3.0, 3.0, 3.0>; // nor does this one // vector v7 = v1 + <2.0, 2.0, 2.0> - v3; // but this one does! vector v8 = <1.0, 1.0, 1.0> + v2 - v3; // and this one doesn't // vector v9a = v1 + <2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>; // this line throws error on compile vector v9b = (v1 + <2.0, 2.0, 2.0>) - <3.0, 3.0, 3.0>; // vector v9c = v1 + (<2.0, 2.0, 2.0> - <3.0, 3.0, 3.0>); // this line throws error on compile } }

(0026737) maurizio55 (reporter) 2014-08-11 14:51	looking at the test, apparently the error happens only when the second vector is explicit.

(0026739) kcozens (administrator) 2014-08-12 13:06	I ran some tests the problem is a little stranger. As long as you are only adding multiple vectors in a single statement the parser allows it. You get a parser error the moment you try and subtract two explicitly declared vectors. I have attached a file called vector-math.lsl that shows the errors.

(0026740) Mata Hari (reporter) 2014-08-12 13:27	@kcozens: my attempt above with vector v7 = v1 + <2.0, 2.0, 2.0> - v3; also failed so it would seem that one explicitly declared vector can do it too. Enclosing either (v1 + <2.0, 2.0, 2.0>) or (<2.0, 2.0, 2.0> - v3) removes the error.

(0026958) Mata Hari (reporter) 2014-10-21 09:21 edited on: 2014-10-21 09:21	Here's a (probably related) mystifying one I just encountered: This line will not parse: llSetLinkPrimitiveParamsFast(link,[PRIM_POS_LOCAL, <0.0, 0.0, 0.4> - (llRot2Up(ZERO_ROTATION) * fAdjust),PRIM_ROT_LOCAL, ZERO_ROTATION]); But simply enclosing the initial vector in parenthesis lets the line parse llSetLinkPrimitiveParamsFast(link,[PRIM_POS_LOCAL, (<0.0, 0.0, 0.4>) - (llRot2Up(ZERO_ROTATION) * fAdjust),PRIM_ROT_LOCAL, ZERO_ROTATION]);

(0029513) UbitUmarov (administrator) 2015-10-18 08:54	as in mantis 7688 the sequence "> -" will fail to parse correctly most time. enclosing vector constants in () is the best option, since a fix is not expected soon.