Talk:LlSetPrimitiveParams

Glow support in LSL

In Windlight there is support for a new parameter called "Glow." Is this in LSL yet? I want! ;D -- Cron Stardust 16:09, 1 January 2008 (PST)

Weird Happenings

For some reason this doesnt work

llSetPrimitiveParams([ PRIM_TYPE,PRIM_TYPE_BOX,00,<0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>,PRIM_MATERIAL, PRIM_MATERIAL_STONE, PRIM_SIZE, <1.0,1.0,1.0>, PRIM_PHYSICS, TRUE]);

the prim doesnt change Is this a bug, or did I miss something ? Anylyn Hax 01:33, 8 August 2007 (PDT)

Was it a 1x1x1 box to start with? If so you might not notice the change and if it were a smaller shape sitting on the ground, making it larger would have it penetrate whats under it, and not be able to enable physics. Try changing PRIM_TYPE_BOX to PRIM_TYPE_CYLINDER. On style concerns, you could change 00 in the third position to PRIM_HOLE_DEFAULT but thats pure style and up to your conscience. -- Strife Onizuka 12:41, 8 August 2007 (PDT)

no, it was a virgin prim 0.5,0.5,0.5 a BOX, ... just make a small script and drop the code in. its wired, if I remove the PRIM_PHYSICS, TRUE, it works. Anylyn Hax 04:58, 9 August 2007 (PDT)

It changes prim properties - but the prim isn't affected

Running a script to change a prim to flexi whilst running, and then back again at the end fails:-

llSetPrimitiveParams([PRIM_FLEXIBLE,FALSE, etc])

Turns flexible off, but leaves it as phantom.

Adding:

llSetPrimitiveParams([PRIM_PHANTOM,FALSE])

Turns phantom off according to the object edit window, but I can still happily walk through it. Toggling flexible in the edit window restores a solid object, but that isn't much use. —The preceding unsigned comment was added by Roken Price

Please submit a bug report on Jira. -- Strife ^{(talk|contribs)} 00:39, 15 October 2008 (PDT)

Slang Can Be Hard to Translate

What is a 'sharp function'?

I see we say llSetPrimitiveParams is a 'sharp function'.

Could we improve the text by saying just 'powerful function' rather than 'powerful & sharp function'?

-- Ppaatt Lynagh 17:39, 24 December 2008 (UTC)

It's a subtle warning. "sharp" in this context builds on the metaphor of a knife. It means that the function needs to be used carefully, that if you make a mistake it will not be forgiven (you will cut yourself). The user must be careful. -- Strife ^{(talk|contribs)} 17:55, 25 December 2008 (UTC)

Clear now, thank you, for me a completely new usage of the word 'sharp'. -- Ppaatt Lynagh 03:51, 1 January 2009 (UTC)

The first time I read this it did strike me as awkward. Perhaps 'finicky' or 'nit-picky' would be a better adjective. Unless misuse of the function could cause serious damage, I don't think it deserves "sharp". --Christopher Omega 02:05, 30 March 2009 (UTC)

It is conceivable that if the user were to make a mistake, an integer value could be interpreted as a PRIM_* instruction. While unlikely it is possible that the malformed instructions could parse without an error message, resulting in something the user didn't and no warning. I've been thinking that a footnote or tooltip would be appropriate to describe what is meant by "sharp". I would opt for 'bites-the-hand-that-feeds-it'. -- Strife ^{(talk|contribs)} 23:22, 30 March 2009 (UTC)

Is there a byte saving or other benifit?

I noted the comment about keeping the params listing thin and wondered if it was for more than aesthetics? Always eager to learn -- Eddy ^{(talk|contribs)} 01:51, 16 June 2009 (UTC)