Specifying Different Sides (NOT ALL_SIDES)

Hi Everyone,
I have a simple texture animation on a cube working as I want it (with the animation actually only appearing on sides #2 and #4), but I know there must be a way to specify the face #s w/ their respective alpha texture without multiple calls, as in the following. I keep getting syntax errors when I try to combine the face #s in a single line of llSetTexture, so duh, I am clueless. Also, note that I only have set the texture for "mytexture" on face #2, but it shows on both #2 & #4...which is what I want, but, it's strange...?) Any help appreciated:

default
{
state_entry()
{
llSetStatus(STATUS_PHANTOM,TRUE);
llSetTexture("mytextue", 2);
llSetTexture("alpha", 0);
llSetTexture("alpha", 1);
llSetTexture("alpha", 3);
llSetTexture("alpha", 5);
llSetTextureAnim (ANIM_ON | LOOP, ALL_SIDES, 2, 1, 0, 0, 25.0);
}
}

For that matter, I suppose one could SetTextureAnim for specifc faces as well, but it doesn't matter to me or not if it animates all sides, as the other sides are alpha anyway.

You have to give individual calls...you could also run it through a loop if you wanted, but with the script you posted, I don't see much benefit from throwing the set into a loop.

So is this the best optimization, then? Also, can anyone tell me why the texture (not the alpha) appears on face #2 & #4, when only #2 has actually been set?

And lastly, is there a way to horizontally flip the image on one of the faces? (As can usually be done in EDIT mode, but not in this case, as a it's scripted and ignores those settings...)

You should checkout llSetPrimitiveParams it can be a bit of a beast but you can set nearly every single primitive setting - simultaneously - including individual faces.

For your immediate requirement looks at PRIM_PHANTOM and PRIM_TEXTURE. However, you're stuck with llSetTextureAnim.

Oh yes...been friendly w/ the wiki! Not always easy to understand and frequently ommitting any example of proper syntax to use in a script, but...

Also, re: llSet PrimitiveParams, (or any other texture-setting...settings), I have yet to see a single example of multiple/different face textures being set. Everyone seems to be using ALL_SIDES, so it's really hard to see how I would combine the face #s using proper syntax. Maybe a list? If someone could show me an example anywhere in-world or out, of a script w/ individual faces set, I would greatly appreciate it!

PRIM_TEXTURE, integer face, string name, vector repeats, vector offsets, float rotation

llSetPrimitiveParams([
    PRIM_TEXTURE, 0, texture1, <2.000000, 0.060000, 0.000000>, <0.500015, 0.469985, 0.000000>, 1.570840,
    PRIM_TEXTURE, 1, texture2, <-2.000000, 1.000000, 0.000000>, <0.500015, 0.000000, 0.000000>, 0.000000,
    PRIM_TEXTURE, 2, texture3, <0.100000, 1.000000, 0.000000>, <0.599994, 0.000000, 0.000000>, 0.000000
);

The easiest way I've found to unravel llSetPrimitiveParams is to go the other way...

default
{
    touch_start(integer total_number)
    {
        list TEXTURE = [];
     
        integer iSides = llGetNumberOfSides() - 1;
        integer i = 0;
        for (0; i<=iSides; i++)
        {
            TEXTURE += [PRIM_TEXTURE] +  + llGetPrimitiveParams([PRIM_TEXTURE, i]);
        }
    
        llOwnerSay (llList2CSV(TEXTURE));
    }
}

You can do this for any of the llSetPrimitiveParams settings to get an accurate idea of what the parameters look like. It's also the easiest way to 'record' the settings of a prim.

Thank you!!! So even in llSet PrimitiveParams you have to list each prim face individually, w/ a separate PRIM_TEXTURE call... Interesting. For a super simple text animation script (no texture repeats, offsets, etc.), is there really any advantage/significant difference then, using llSetPrimitiveParams vs. what I had originally written?

Only that using llSetPrimitiveParams will update all the faces simultaneously, whereas using separate llSetAlpha calls might noticably update the faces sequentially, depending on lag.

Thought for what you're doing, it might be easier to assign the "alpha" texture to ALL_SIDES, then "mytexture" to side 2, depending on what type of prims it is and how many faces you want "visible"

<tangent>
It would have been nice if they'd implemented face numbers as a bitfield rather than whole integers, since I don't think even the most mutilated of tortured prims has anywhere close to 32 texture faces. Then you could do something like

llSetTexture( "mytextue", 0x4 ); // side 3
llSetTexture( "alpha", 0x2b ); // sides 1, 2, 4, and 6

Though for the sake of clarity, they'd probably have assigned constant tags such as:

FACE_BOX_TOP
FACE_SPHERE_HOLLOW
FACE_TORUS_PROFILE_CUT_BEGIN

etc, which could then be ORed together:

llSetTexture( "alpha", FACE_BOX_TOP | FACE_BOX_LEFT | FACE_BOX_RIGHT | FACE_BOX_BOTTOM );

And of course, making such a change at this point would break all existing code. WouldaCouldShoulda... </tangent>

Oh, as to your earlier question about flipping the texture through script, use a negative number for repeats.

Yes! Yes! Yes! If you look at the prim face table in the LSL Portal you can see a lot of commonality across prim types. In the end there would only be 9 bit-field bits, but each one would have multiple names (FACE_BOX_TOP = FACE_TORUS_PATH_END, FACE_CYLINDER_PATH_END = FACE_TORUS_PROFILE_END = FACE_SPHERE_DIMPLE_END, etc). I make objects that change shape and the renumbering of prim faces is a huge PITA.

edit - I added this as a feature request in JIRA. You can find it here. Go vote for it!

There's a slight optimization you can do with your list fuction that will greatly speed things up and reduce memory. I don't know why it works, but Strife Oz could go into details:

for (0; i<=iSides; i++)
{
TEXTURE = []+TEXTURE+ ([PRIM_TEXTURE] +  + llGetPrimitiveParams([PRIM_TEXTURE, i]));
}

Yes, I believe you're right... it was discussed a little while back. However, when doing small example scripts it can confuse things using obscure constructions; which is why I generally avoid them in the interest of clarity. It can be a difficult choice sometimes though.

The "optimized" list concatenation syntax is:

SomeList = ( SomeList = [] ) + SomeList + NewElement;

However, it really only matters for scripts so short on memory (and/or storing a lot of data) that they are potentially in danger of a stack/heap collision. And this is a memory conservation tactic, I doubt it speeds execution. It probably slows things down a bit.