Temperamental llSetPrimitiveParams exceptions

Okay, this one has me stumped - and I think it's due to a system problem as opposed to one at my end.

I've been testing my Universal Permissions Suite from time to time, to see if I can break it and whether or not it needs a fix. While I've identified a couple of "maybe" fixes, one has me stumped completely.

Apparently, when setting the parameters for multiple prim faces, like color, alpha, etc, occasionally the script will perform the operation successfully and throw an error on rule 2: Not Integer Command. Occasionally, this operation will not work at all.

Of course, in this case there is no Rule 2... so it's expecting the wrong thing.

I believe the problem is related to how properties for multiple faces are formatted via llGetPrimitiveParams and, in the reverse sense, added via llSetPrimitiveParams. This format can take many forms, ranging from [PRIM_COLOR,ALL_SIDES,<0,0,0>,0.1,<0,0,1>,0.3,...] to the more functional [PRIM_COLOR,0,<0,0,0>,0.1,PRIM_COLOR,1,<0,0,1>,0.3,...]. Note that both of these do roughly the same thing.

Enter my question: When using the first format, has anyone else experienced this nuance? If so, what is a good way to solve it aside from reading the data, face by face? And, if you use the first behavior, have you been able to solve things such that you do not get any errors?

Furthermore, LL may be needed to address this issue. While minor, it's quite an annoyance to worry if my script will or will not function properly under what appear to be ethereal circumstances.

if you are talking about the what is returned by llGetPrimitiveParams with respect to ALL_SIDES you will not be able to feed that back into llSetPrimitiveParams without having to reformat the data. As the format returned is not valid.

The comments at the bottom of the page of llGetPrimitiveParams or llSetPrimitiveParams on the wiki touches on this problem.

Here is some code that will let you use ALL_SIDES and do the formating.

list GetPrimitiveParams(list input)
{
    list output;
    integer c = -llGetListLength(input);
    integer flag;
    integer side;
    while(c<0)
    {
        flag = llList2Integer(input, c++);
        if(llListFindList([PRIM_BUMP_SHINY, PRIM_COLOR, PRIM_TEXTURE], [flag]) + 1)
        {
            side = llList2Integer(input, c++);
            if(side == ALL_SIDES)
            {
                side = llGetNumberOfSides();
                while(side--)
                    output += [flag, side] + llGetPrimitiveParams([flag, side ]);
            }
            else
                output += [flag, side] + llGetPrimitiveParams([flag, side ]);
        }
        else
            output += [flag] + llGetPrimitiveParams([flag]);
    }
    return output;
}

Try it.

My question is whether the ability to do so is a bug or a feature. If a feature, it needs fixing.

Correction: Oddly enough, I believe I know the problem here, and yes, it is with formatting. The confusion stems from PRIM_COLOR and a few other constants not throwing the error when set from llGetPrimitiveParams under 1.5. This was "fixed" in 1.6, and only selectively works now under the poor formatting.

I'll be correcting for that. Thanks for the response.

After doing further testing, and remembering that data from some earlier texture tests said otherwise, I went and tested again under 1.6.1.

Apparently, the first format I mentioned does work, unless PRIM_TEXTURE is somehow formatting differently now. It's a quite confusing to me, and I think there is a systemic contradiction somewhere in there that I need to root out.

Anyway, I'll be testing further as time permits.