llGetLinkPrimitiveParams() ??

does that function exists (i can't find it on the lsl wiki, so i think it doesn't)??

if it doesn't, go and vote for http://jira.secondlife.com/browse/SVC-224 to maybe have LL implement it at some point.

No, it doesn't exist. And implementing it would save Linden Labs SO MUCH sim script memory.

And maybe not since mono scripts share code space The downside of letting one script do all the work is a longer execution time. Still I shout with you: "Let's have the 'llGetLinkPrimitiveParams()'"

That'd let people make lsl copybots.. It'd be a nice function to have but it'd need to be careful about permissions.

Yeah that is the old argument and it is a very tired one and nonsensical. Stupid to go through all of the hoops to make an lsl copybot when it would be much easier for anyone to just use libsl.

Code space for a link listener relay script is pretty minimal, it's the data space that matters... especially given how space-inefficient Mono lists are.

Code space for a link listener relay script is pretty minimal, it's the data space that matters... especially given how space-inefficient Mono lists are.

This function is not required to let people make LSL copybots. An LSL copybot can distribute itself using llGiveInventory followed by the user selecting "Set scripts running in selection". There are no permissions issues with this call that do not already exist in llGetPrimitiveParameters().

I'm sure content creators will be happy to hear that.


/me blinks. What?

You can make a copybot in lsl with llGiveInventory?

It does not matter what people want to hear, it is just a fact. llGetLinkPrimitiveParams() would not make SL less secure then it already is and the alternatives are more user friendly for breaking perms.

I disagree. With llGetLinkPrimParams and 20 minutes, I could make a copybot that'd work on anything that had mod permissions. Many, many people could. Far fewer can actually make a copybot.

BS, you don't have to make a copybot. All you do is download it through a google search or download a precompiled libsl. Either take zero minutes to make and will still be easier to use then your LSL copybot for non techies and it does not matter what the perms are.

Fine. We disagree.

Maybe LL should open up access to the asset servers too, since copybots are so easy to get at?

Perms on anything but scripts have always been porous as I am sure you are aware. Buisiness continues to thrive in SL thou. We are all old enough to remember the Copybot furor and yet SL is still here and people are still making money. Surely in your explorations you have at least tried libsl at some point or another? LL's stance is clear; having the means, such as GLIntercept or Copybot or libsl to break perms is not a problem or a violation of the TOS. Actually using a tool to break the perms is. Each of those listed also have legitimate uses.

You have Google, take a look for yourself.

As much as you can with llGetLinkPrimitiveParameters(). Just have the script distribute a helper to every prim in the object using llGiveInventory(llGetLinkKey(i), ...) in a loop. Then pick up the object, re-rez it, and select it and "Set Scripts Running In Selection".

Then your copy program is almost identical to the one with with llGetLinkPrimitiveParams(), using link messages to the helper scripts to tell them to chat their parameters to the clone prims instead of calling llGetLinkPrimitiveParams() and chatting the parameters to the clone prims directly.

[leaving lots of detail out, I haven't written such a script because I don't have a need for it... but if I needed to I could do it in half an hour or so. It's not rocket science.]

PS: And now you can do it without waiting for llGetLinkPrimitiveParams(). Or you can buy a backup tool on XStreetSL that will download everything in an object into an XML file, including prim contents and non-full-perm textures, in five minutes. Which is what anyone actually interested in cloning stuff would do.

PPS: I'm not saying that this is good, I'm saying that the horse is out of the barn, knocked down the fence, and raised a family in the forest. Not only is it too late, but now (since Mono) the barn's on fire and you're trying to close the barn door while there's livestock still inside.

BTW not trying to give you a hard time here Sindy. Your various contributions are held in high regard. Just demonstrating that the arguments against llGetLinkPrimParams really don't hold much water when looked at in the light of reason.

I have to agree with Jesse, why code a copybot in LSL that only copies stuff with mod permissions when you can use libSL to copy anything.

The major problem with llGetLinkePrimitiveParams that I can see, is going to be memory vs computation. This function will be abused/used a lot for jewelry and hair, and those high prim attachments. If this function is implemented like llGetPrimitiveParams() then you'll have a HUGE list if you try and get all the params of the child prims in one call (most likely filling up the allowed memory for an avatar, depending on what it's set at) or you'll run into long execution times of grabbing each individual prim's params and manipulating them in a loop. Yes, we'd all love to see this function, but I'm afraid of how much memory, or execution cycles that a large link set will take up.

Nobody has proposed such a possible usage, and none of the other llGetLink*() calls allow it. The parameters will be the same as llGerPrimitiveParams, with the addition of a link argument, and it will ONLY return the parameters for the specified link.

People are already using hundreds of scripts in a linkset to get the same effect of llGetLinPrimitiveParameters. Switching to a single script, even with a single time-consuming loop, would STILL reduce the overall memory and script time usage of any such scripted object.

Just all depends on how it's implemented, if it's implemented. iIf it allows for instance LINK_AL_OTHERS as a link argument as llSetLinkPrimiticeParams does, then you will be using a lot more memory then just resetting a value in the loop. But we are talking all hypothetical, and it all depends on the implementation of it, which we have no real control over.

not only are people already using huge amounts of scripts to duplicate the functionality, but as an alternative, you must store the last set parameters in the main script (which is vunerable to script resets and manual prim changes). so as far as implementation is concerned, it's really not a huge difference compared to the already status quo. I'm sure they'd limit it to single prims just so as not to compile huge lists, but that may not be as helpful as it sounds.

as for an inworld 'copybot' (it actually has a different name others will remember, and was originally designed for the shoe and attachment industry), not only was it already done, but after thinking about the problem it took me less than 20 minutes to outline the structure, and build my own basically from scratch... and that was WITH checks and limits for creator vs owner complete with distribution. it's actually a really simple problem, just tedious. adding get link would mean the whole thing takes 5 seconds to get to work instead of 10. in the meantime, legitimate use could drastically reduce script count, size, and quite possibly overall script time.

of course I still want script read and build edit access to all those other hidden prim paramters... there are so many that can be set, but not retrieved, and then only by script. wouldn't it be nice to open an advanced panel and directly input some of these permanent effects? sounds, particles, axis locking, text, sremote load pin, etc, etc...

Lazink, Your point is definitely worthy of serious consideration. I tend to agree with the others that in the case of scripts I'm familiar with, the workaround for the missing function is worse than the missing function would be -- far worse, especially in the case of objects with huge numbers of prims. (And that's the worst case for your argument as well.) Regardless, it's a meaningful point to raise and consider.

But, cheer up, I have excellent news that renders your point immaterial.

Before long, we'll have per-parcel script memory limits in SL.

At first, this will be a huge adjustment and it will cause a furor of upset. It'll take a significant adjustment on the part of script writers, content creators, and residents. But it will solve the problem of "the tragedy of the commons" with respect to script memory, and if they execute it reasonably well, SL will be considerably more stable as a result.

It will mean that content creators who waste script memory will not have a market for their products, because people will find that if they rez just one SuperWidgetDeluxe, they'll have to shut down their favorite bed, stop wearing their AO, etc., etc.

And when we also have Top Script time reporting for parcel owners, the marketplace will be able to make the time/space tradeoff judgements. That tradeoff will be different for different users, and they'll be able to choose products that suit their purposes.

I am one that is actually looking forward to the script limits. I have always preached conservation of sim resources and this is going to shine a spot light on the best scripters instead of a script "that just works". I am also expecting a renewed interest in the forum here also as people come back to learn the best way to do something.

And in regards to the market, people will have to start putting the memory usage of the items. It is definitely going to thin the herd.

OH, I was just thinking of worst case, and was just interested in what the cost would be. As I said earlier it all matters on how it is implemented, and we don't know how it would be, if it is even done at all. I'm not afraid of what responsible scripters will do with the function, because they will think about it, but in all honesty, how many responsible scripters are there really out there? Those that don't know all the workings of LSL, and just want their product to work, and don't think, or care about the load it will cause on the sim.

As for the switch, with the memory pool, it will be interesting to see what happens. I was in a region today that I could see my own avatar script time, and was shocked at how much it is actually taking, without only a few scripted attachments and 2 huds. Handy information but really tells me nothing besides my script time, not how much memory is being used, which is the important one.

Just remember, that since about the late 90's early 2000's, it has been said that "memory is cheap." when coding and creating content. It will be an adjustment for those that learned under that way of thinking, to actually think hard about memory usage

Yeah I have been bugging the Lindens on updates as to when the UI which will show script memory will be available. Babbage still did not have anything new to add as of just a couple of days ago. Kind of sucks, especially since this is specifically what we are supposed to be testing in the beta server right now. I've been there a couple of times just to see if my scripts still worked but then left. What is the point if you are blind?

What would also be useful, and just thinking out loud, is a way to turn scripts in a link set on and off, that wouldn't cut down on total memory used, but would cut down on script time. And while I'm thinking about it, give me a simple boolean type!!!