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)

Shadow parameter

Since there's a lot of work being done on the shadow code buried in the viewer (and turned off by default), is it likely that the PRIM_CAST_SHADOWS value might once more become useful? TaraLi Jie 02:01, 28 July 2010 (UTC)

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)

Sharp can mean and basically does mean incisive. Take for example to "Have a sharp mind" or to be "sharp witted". Both are common terms that describe an instinctive or highly defined attention to detail that results in an accurate return. The function does exactly that and it does it very well too. I think sharp is a very appropriate word. -- Eddy ^{(talk|contribs)} 07:18, 17 June 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 llSetPrimitiveParams 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)

Wow, cool, wow and cool. I have adopted the method you showed me for the list of params (I didn't think of the delay (I stupid) but the list can cover a lot in one hit!!). So with the maths... even if it is plain maths inside brackets if there is an integer there the compiler gets upset? eek... I need to review all my scripts now :( I get you about the whitespace now. I try to keep them short where I can but didn't think about the inworld (rubbish) browser and forget that not everybody is widescreen etc. I will be more compact in future. Hi btw and thanx again. -- Eddy ^{(talk|contribs)} 03:48, 17 June 2009 (UTC)

Zai told me off (lolz kinda) for editing comments. But I am hoping this time you don't mind Strife. I strikes me as ridiculous to ask you to do it. -- Eddy ^{(talk|contribs)} 05:46, 17 June 2009 (UTC)

Editing comments is tough. Writing comments is just as tough. You have to consider your audience... and I mean really consider it... and probably justify it in the edit summary. It's something we don't do often enough (consider the audience). Commenting code is a balance between explaining what the code does, and letting the code explain what it does. I think a good way to comment code is:

1. You make the code as expressive as you can, with good variable names, functions and breaks.
2. Then you have the comments explain what the code is having trouble expressing. Don't worry if there is overlap, but you really don't want to be writing your program twice (the second time as comments).

-- Strife ^{(talk|contribs)} 06:43, 17 June 2009 (UTC)

Ooops sry Strife. I was referring to the addition of the letter "a" in "llSetPrimitiveParams" in your comment above last. Typos happen (lots of 'em in my case) and the link was thus unfortunately broken. Zai is of course right to point out that editing talk page comments is bad behavior but I thought (correct me if I am wrong) that on this sort of occasion the fixing of a spelling would be ok. As for the orange comments I am on board with your instruction 100% (eagerly waiting to see what you make of my addition to llSubStringIndex). BTW... Other than something like ((5/100)*90) to get 90% how do I get the result more efficiently? Sorry for being a pain it just crossed my mind. -- Eddy ^{(talk|contribs)} 06:54, 17 June 2009 (UTC)

F*#$, I had this great response I was just about to post and my browser went berserk on me and ate it (<.< maybe using a Nightly build wasn't such a good idea). I shall try to recreate.

I had just found the referenced comment from Zai and came back here to find your comment. Oops.

I should have checked the link, I wasn't awake. Thanks for fixing it.

As to efficiency...

Imagine your audience could understand anything you wrote no matter how complicated the vocabulary or grammar as long as it was properly constructed. You would be free to write it any way you wanted. To describe the paths of logic to the finest detail or cover them with broad brush strokes. You would be empowered.

Now imagine that same audience having having to slave away at dictionaries, taking notes to work out the meaning of your magna opus. You would try to make it easier for them, you wouldn't use the complicated vocabulary, you would shun the complex grammer. You would turn your back on the empowerment that set you free. You would be enslaved to their ignorance and mental limitations.

It is for this reason LSL is a dead language, it doesn't empower. If you want to do anything remotely interesting you have to dive into it's guts and learn how it works. You have to waste your time and mental faculties to dodge it's limitations. You can learn how to write faster code, less wasteful code, but it won't set you free.

As to your addition to llSubStringIndex, it's a bit too complex. If you are going to make an interactive example, you need to supply some explanatory text about how to use it. When dealing with multi-line comments, they should be above the code they reference. -- Strife ^{(talk|contribs)} 08:34, 17 June 2009 (UTC)

As to editing comments, on the wiki there isn't much in the way of personal space. Sure there are user pages but even they aren't entirely off limits. Comments are really the only personal space there is. -- Strife ^{(talk|contribs)} 08:44, 17 June 2009 (UTC)

Wow. I feel like a soldier being given that final pep talk..."once more into the breach dear friends"... If by "guts" you mean the code under the code, eek. I still dunno all the functions (http gives me chills) but where are the guts? I am fascinated by the logic of programing. "Take 8 switches and put them into groups ..." I mean somewhere inside all this there is a system supporting a system supporting a system. I can't help but lol at the idea that my example is too complex. That's ironic. I started out trying to figure a relevant way to describe the method I developed for searching the string from the end (going backwards) but realized that (not only could I not find a way to give it a use without including loads of extra scripting) it would be so complex that it would be the very sort of script example I was afraid of when I started out. I'll add some more oranges. I do like the basic idea cause it uses llSubStringIndex in a few different ways and describes a way to get around one of the limitations.

As for writing loads of words and browser crashing. That sucks. I feel for you there. I have experienced that myself and lost hours of work (in world scripts (painful) and typed out comments here in fact (but not through crashes, through network problems)). I hope that you realize how grateful I am for your advice and comments. Queue violins I haven't felt this driven and worthy for too long. Having a cause and a goal (in world and here) have turned my life around. Having a friend here watching and guiding is awesome. Thanx Strife. -- Eddy ^{(talk|contribs)} 16:56, 17 June 2009 (UTC)

Set just color, or just alpha, using params

I know there's llSetColor and llSetAlpha, but it would be nice to also be able to set just the color, or just the alpha, using the params-style functions, without having to read the one you don't want to change in order to not change it. (PRIM_COLOR needs both color and alpha; maybe a PRIM_ALPHA and a PRIM_JUST_COLOR? :) ) Dale Innis 20:12, 5 August 2011 (PDT)

Reference to link parameter

llSetPrimitiveParams has no link parameter but this article has references to LINK_ROOT and LINK_THIS
The references should be removed but I dare not do it. I fear to ruin the other PrimitiveParams articles if I try
Dora Gustafson 10:09, 7 August 2013 (PDT)

llSetPrimitiveParams has no link parameter but PRIM_LINK_TARGET does. What you have picked up on is that the emphasis and layout is wrong. The link information should be wrapped in the context of PRIM_LINK_TARGET for this article. I'll see what I can hack together but I fear this may be impossible without the PrimitiveParams documentation redesign, which is still in the planning phase. -- Strife ^{(talk|contribs)} 13:46, 7 August 2013 (PDT)

P.S. Why aren't you using llSetLinkPrimitiveParamsFast? -- Strife ^{(talk|contribs)} 13:50, 7 August 2013 (PDT)

P.S.S. Maybe we should merge the llSet*PrimitiveParams* articles. There really is no different between them except the delay and the link parameter. -- Strife ^{(talk|contribs)} 13:50, 7 August 2013 (PDT)

Your last suggestion is very sensible, the three articles should be merged. Dora Gustafson 14:28, 7 August 2013 (PDT)
I use llSetPrimitiveParams when I can

• For nostalgic reasons
• It's simplicity when I need no link
• The delay is often convenient
  

Dora Gustafson 14:28, 7 August 2013 (PDT)

Caveat in connection with llSetKeyframedMotion

Sometimes llSetLinkPrimitiveParamsFast is too fast for for the server <lsl> llSetLinkPrimitiveParamsFast( LINK_THIS, [PRIM_POSITION, basePos, PRIM_ROTATION, baseRot]); llSetKeyframedMotion( KFMlist, []); </lsl> In this example the prim is not in place before the key framed motion starts, so the initial conditions are bad resulting in an unwanted motion <lsl> llSetPrimitiveParams([PRIM_POSITION, basePos, PRIM_ROTATION, baseRot]); llSetKeyframedMotion( KFMlist, []); </lsl> This code with the included delay, works smoothly. Dora Gustafson 10:29, 18 August 2013 (PDT)

I've put in the llSetLinkPrimitiveParamsFast caveat and tried to explain why it happens. It's a great opportunity to introduce people to "asynchronous" and "synchronous" terminology (because they are a pain to learn and you have to start somewhere). If I had to guess, it's probably executing them between script timeslices. -- Strife ^{(talk|contribs)} 09:16, 20 August 2013 (PDT)

I've done some playing around with this lately because I was having issues with llSetLinkPrimitiveParamsFast() being asynchronous as well, and I discovered that you can make it much more reliable by emulating a forced delay, using "llSleep(0.022);" between each function call. 0.022 is one server frame, if memory serves, so this may force the function to synchronize. I've tested it with 100 loops of subsequent colour changing, fullbright & glow changing on linksets with 100+ prims, using llSetLinkPrimitiveParamsFast() and so far I haven't experienced it desynchronizing. If anyone could help me confirm this, & it indeed makes the function more reliable, it will still be much faster in execution than the llSetLinkPrimitiveParams()'s forced delay. -- Tenaar Feiri 04:21, 17 September 2013 (PDT)

TWIST

I can't see where to insert this:- The figures required by the vector TWIST differ from those shown in the client view. The conversion seems to be:- script twist value = client value divided by 360. e.g. client twist of 11 requires 0.03055 in llSPP. Omei Qunhua 07:43, 5 January 2014 (PST)

It's degrees. Used to be a decimal value though, afaik. Not sure when that changed. -- Kireji Haiku 07:47, 5 January 2014 (PST)

Eh? The client value may be degrees, the script value is the proportion of a circle. (apparently). Omei Qunhua 08:16, 5 January 2014 (PST)

It is in the tooltips in the "Flag PArameters" column, and on the pages for each constant. Maybe the flag parameters header needs a subtitle to point out that there are important tooltips in there? --ObviousAltIsObvious Resident 08:49, 5 January 2014 (PST)