Difference between revisions of "Talk:LlSetPrimitiveParams"
Line 51: | Line 51: | ||
:: 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". --[[User:Christopher Omega|Christopher Omega]] 02:05, 30 March 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". --[[User:Christopher Omega|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'. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 23:22, 30 March 2009 (UTC) |
Revision as of 15:22, 30 March 2009
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
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)