llSetPrimitiveParams, and you.

Hello all,

I am working on LSL, and have come across some bugs in llSetPrimitiveParams. While fixing some of the bugs, I ran into the problem that PRIM_TYPE_TUBE does not take a top shear, or advanced cut. In order to resolve this issue, I would have to change the number of parameters this constant uses, and possibly break scripts that use PRIM_TYPE_TUBE.

Is anyone actually using this constant? Would you rather me keep it out, and not break things, or would you rather fix a couple scripts and allow for setting these values?

Don

Don, I think you should fix it. I believe those who are using llSetPrimitiveParams with tubes knew that the PRIM_TYPE_TUBE was broken and therefore either avoided it, or coded using a kludge (one prim for every top shear/adv cut).

Why not make the *new* PRIM_TYPE_TUBE constant a different integer value. This allows old scripts using the old constant, with the old integer value, to stay working.

I'd just like this bug to be fixed

Plus, I want to be able to manipulate the shape of the hollow part of a prim!

I would favour correctness over convenience. Having llSetPrimitiveParams work properly (and forcing a rewrite of some scripts) is more valuable than leaving it broken.

Also, as noted here, there's still no way to set the hole shape. I realize that as it stands, it's not TOTALLY hard to get around, but it's inconvenient. Also, fixing it would necessitate a rewrite of EVERY script that used llSetPrimitiveParams, which would obviously upset far more people. Still, I think it should be fixed. At the very least, we should get something like "llSetPrimitiveHoleShape" to compliment the featureset. That wouldn't require a rewrite of any scripts, and while hackish, would finally complete the edit functions.

That's a good idea, but technically, wouldn't it still work until you recompiled the script? And if you're compiling a script, doesn't it stand to reason that you're also editing it? And if you're editing it, isn't it a relatively minor change?

Um... wasn't this the reason for my suggestion?

I think she's saying that it doesn't matter what the constant is in old scripts, because they're already compiled.

However, I have to agree with Chris on this one, Catherine. Since LSL runs in a VM, there's a very good chance that constant values matter, and aren't just compile-time enumerations.

They could leave the exising tube constant and functionality in the VM, but remove it from the compiler, then assign the new, correct functionality to a different constant value which the new compiler supports.

Well... yeah, I guess I'm making assumptions about the way the VM works.

Thanks for the input, all. llSetPrimitiveParams and llGetPrimitiveParams are both working now; even the broken negative twist problem. However, 'fixing' this to act as stated in the docs may cause any scripts using PRIM_TYPE_TUBE or PRIM_TYPE_TORUS to act differently. Just a heads up; those scripts might need to be slightly modified.

Don

That suprised me as well.

Hrm, looks like all the torus shapes on the XyObject scripts are going to break =/. Ah well, I'll deal. On the plus side, maybe I can get rid of half the input panel now, hehe.

Xylor

now i should say as to what i think llGetPrimitiveParams syntax should be
llGetPrimitiveParams(list flags)
where flags is a list of flags ie
[PRIM_BUMP_SHINY, PRIM_COLOR, PRIM_MATERIAL, PRIM_PHANTOM, PRIM_PHYSICS, PRIM_POSITION, PRIM_ROTATION, PRIM_SIZE, PRIM_TEMP_ON_REZ, PRIM_TYPE, PRIM_TEXTURE]

(and when i call llSetPrimitiveParams([PRIM_TYPE]) i want *all* the shapes attributes not just the ones it's allowed to have.)

I do use PRIM_TUBE as i like how it is broken only way to get tubes with hole sizes greater then 0.45 (my tests have shown the shapes to be stable)

why do you want to fix it now? it's been broken for ages.

PS: Don play with the code below.

PSS: can we get some new flags too?

EDIT:
llGetPrimitiveParams([PRIM_POSITION])
should return llGetLocalPos if it is not the root prim instead of llGetPos

EDIT2:
It would be nice if we could have total control over all the prim shape attributes not just the normal ones; like the syntax for my llSetPrimitiveParamsAdv with PRIM_TYPE_ADV (but with a hollow shape field too)

default
{
    state_entry()
    {
        llSay(0,"running");
        integer type        =   PRIM_TYPE_TUBE;
        vector  cut         =   <0,1,0>;
        float   hollow      =   0;
        float   twist       =   0;
        vector  topsize     =   <1,1,0>;
        vector  topshear    =   <0,0,0>;
        vector  advanced_cut=   <0,1,0>;
        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_CYLINDER, cut, 0, twist, topsize, topshear]);
        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_TUBE, cut, hollow, twist, topshear.x]);
//        llRemoveInventory(llGetScriptName());
    }
}

advanced cut is the devil in the details.

/me dances in the streets!

since you are fixing tubes. could you add support for advanced cut too ?

pretty please

if you add it i'll forgive you for fixing the hole size.

I think I found a bug. Link up 3 prims, have 2 of them set their sizes at least once. After the 1st primitiveparam change, they don't seem to be able to resize any longer. Plus, when you delink the set and try to relink, you get a message that the prims are too far apart to relink. It is like it changes the root prim somehow. If you substitute a new prim for root (in the exact same location), you can relink everything.

Have you reported it in-world?
Without submitting a bug report there is no guarantee that LL will ever see it.

*sigh*
llSetScale


I was beginning to get use to the bugs in llSetPrimitiveParams