Talk:LlSetLinkPrimitiveParamsFast

What's the catch?

When these fast functions are introduced we should just convert? Or is there a catch? I mean, will there be times when we shouldn't use the fast version? -- Fred Gandt ^{(talk|scripts|contribs)} 16:38, 9 March 2010 (UTC)

Hi, there is no catch! The old functions are not changed so old scripts using them do not break if they depend on the delays. --Cerise Sorbet 18:44, 9 March 2010 (UTC)

Sometimes too good to be true really is. *remains sceptical* But thanks for the positive response Cerise. I look forward to seeing the objects this will allow; especially in tandem with llGetLinkPrimitiveParams OMG!!! llGetLinkPrim... LLGetLINK!!! >>> LINK <<< *faints* ;-) -- Fred Gandt ^{(talk|scripts|contribs)} 22:57, 9 March 2010 (UTC)

The catch is that the delay turned out to be more costly. The idea with the delay was to discourage people from resource abuse. The thing is that people used multiple scripts to get around to the delay... the overhead of running multiple scripts was more then just not having a delay. At least that is my impression (and it sounds about right). -- Strife ^{(talk|contribs)} 02:38, 10 March 2010 (UTC)

The cost was particularly onerous for attachments during boarder crossings. -- Strife ^{(talk|contribs)} 03:08, 10 March 2010 (UTC)

I'm shocked to hear that the delay was fake. I assumed it was unavoidable. What a bizarre idea. -- Fred Gandt ^{(talk|scripts|contribs)} 22:19, 10 March 2010 (UTC)

... All of the script delays documented (in the right hand summary floater) are artificial. If you are bored at some point I recommend you read the LSO VM source code. They were always about discouraging abuse. The script delay is on top of what ever amount of time it takes to execute the function.

That said, there may be delays that do (or more likely did) something useful. In the days of old when Havok1 roamed the earth and avatars could walk the grid in 24 hours (a popular hobby when I was a noob), I wouldn't be at all surprised if there were crashing bugs that were fixed by adding script delays. I know a number of PRIM_TYPE restrictions were added to stop me people from crashing sims. -- Strife ^{(talk|contribs)} 02:11, 11 March 2010 (UTC)

So we could hope that many more of these applied pauses will be removed as time goes on. I can understand how delays make some sense for example spamming being avoided by the massive and tiresome 20.0 second delay of llEmail but 20 scripts with link messages would undo the point of the delay and isn't there a throttle anyway?? I can't help thinking that adding delays where there are none is a little backward. Smooth running and fast acting has got to be better than jerky and awkward. As you said Strife..."The thing is that people used multiple scripts to get around the delay". They are sure to continue trying to work around any restrictions kept in place too. And look at the mess that makes. Scripted hair anyone?? -- Fred Gandt ^{(talk|scripts|contribs)} 07:52, 11 March 2010 (UTC)

You gave me visions of llSetTextureAnim hair (which I have seen). Don't forget the minimum event delay. The limit of the number of slaves you can have is proportional to the number of prims you can stuff them in. They may not have implemented it in Mono, I don't know. I never got around to writing the documentation about it on this wiki (so much had changed since the last time I worked on it that I didn't trust what I knew and what was written elsewhere). Between the function delays, the event delays, the bugs and the memory limits; there is plenty in LSL to drive you crazy. -- Strife ^{(talk|contribs)} 22:03, 12 March 2010 (UTC)

"isn't there a throttle anyway?" Yes! There are throttles now on things that can be very bad. Some throttles came after the delays did not work and that is how they want to handle abuse and mistakes from now on. All the function delays might be removed in the future but they will not decide before we can have library versions. --Cerise Sorbet 01:41, 13 March 2010 (UTC)

With Strife people causing all kinds of bother around the grid it is a good job LL are paying attention *grins* -- Fred Gandt ^{(talk|scripts|contribs)} 04:00, 13 March 2010 (UTC)

Hey, it's not my fault their mass calculations produced negative numbers, which gave negative masses, which made the simulator unstable. -- Strife ^{(talk|contribs)} 19:51, 13 March 2010 (UTC)

Sounds like a lot of newtonian fun!! -- Fred Gandt ^{(talk|scripts|contribs)} 05:22, 14 March 2010 (UTC)

And if you linked them to a vehicle, the vehicle would fly up! -- Strife ^{(talk|contribs)} 22:45, 14 March 2010 (UTC)

Have found a caveat that may need to be added to the list of caveats. Damen Hax asked for help with a script that calls SLPF and it was failing on rez, but not when worn. Seems that calling PRIM_POSITION for child prims will cause PRIM_SIZE, but nothing else, to fail for all child prims affected. It makes sense that the PRIM_POSITION for the child prims would fail on rez, but not PRIM_SIZE alone. -- Ryu Darragh 04:04 16 December 2010 (UTC)

Possible to create smooth motion for non-physics vehicles

Would I be correct in thinking that with this function, it would now be possible to generate smooth non-physical motion; i.e., using this function and the PRIM_POSITION functions to get around the llSetPos delay limitations? Suddenly all kinds of possibilities arise... Reynard Baroque 21:46, 1 October 2010 (UTC)

Further to my previous post, if one uses llSetLinkPrimitiveParams or llSetLinkPrimitiveParamsFast with the LINK_SET constant, in order to set PRIM_POSITION, how does it interpret the coordinates? Regional? Local? Regional for the root prim and drags the child prims with it? Reynard Baroque 01:31, 3 October 2010 (UTC)

Hi, I've added a caveat to avoid combining PRIM_POSITION with LINK_SET. If you want to move the whole link set in one go, use LINK_ROOT instead. --Cerise 04:07, 17 December 2010 (UTC)