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)

Whitespace?

I noted the comment about whitespace and the params listing shape is changed and wondered if it was for more than aesthetics? The simplification for the equation is great (lol(you should really see my scripts. I gotta feeling you would cringe)). Can you give a little explanation about the whitespace please Strife? Always eager to learn (sorry bout all the edits) -- Eddy ^{(talk|contribs)} 02:10, 16 June 2009 (UTC)

The whitespace is so that people don't have to scroll horizontally; it's a real problem when using the client's built in browser. It's better to avoid long lines when possible. I used PRIM_SIZE because of the script delay. llSetScale and llSetPrimitiveParms both cause a 0.1 script delay; by combining them, we keep it down to 0.1 seconds instead of 0.2 seconds. Now, the LSL compiler is stupid, when it sees an integer constant being used where a float is expected, instead of doing the conversion at compile time, it inlines an implicit typecast instead; which costs more bytecode and is slower to execute. -- Strife ^{(talk|contribs)} 03:40, 17 June 2009 (UTC)