This will not allow ANYTHING that can't already be done. It will simply make things cleaner, simpler, and less of a strain on the sim frim hundreds of scripts.

There is NO potential for abuse. I can already create a script that copies itself to every prim, then can simply set scripts to running in selection. This would do nothing more than taking 5 seconds work out of the equation, which makes no difference in that regard.

Lyndyn and McCabe are wrong.

This function will be one of the savior function for most of us!

I don't consider myself an expert, but i can see that adding this function would offer little or no more opportunity for abuse than already exists.

When users expect a function to have a logical twin (get <-> set) it should therefore exist. .. if for no other reason than to stop us using numerous and excessive function calls to achieve what we need to do.

That said, considering the load my llSetPrimitiveParams and llSetLinkPrimitiveParams experiments have put on the server/sim, perhaps this is the reason for the apparent null, but possibly just delayed LL response on this function set.... Because having a nice single function to get info, would logically result in more scripts that set info.. thereby exacerbating a sim load issue they are trying to resolve. ...maybe?

I don't agree with Darien at all on this issue. The holes in SL which allow content duplication are all over the place. I give away an item that allows it to be done trivially in several places inworld (don't ask) because the ability to manipulate prims and copy across pre-existing alignment info s an extremely powerful builders tool and can save days of work on complex projects. It's a scientific fact that DRM can never be complete - ask any cryptographer not hired by the RIAA. There will always be holes. The best protection you have for your work is to actually declare copyright and license - which costs nothing, and gives you a stick to wave (albeit impotently) if anyone tries to duplicate your work. But one that is legally binding, unlike the implied rights of linden DRM.

However - the workarounds for getting prim info - regardless of the lag induced, are hideously complex and brittle. About the only thing they're useful for is copying existing objects as they require the assistance of the avatar. This means that any legitimate use get functions for prim state, be it for pupeteering, building tools, alignment of parts on avatars, furniture customization or a heap of other things - well they're all too hard.

There is one surefire way to ensure that Dariens argument isn't an issue is this. The only legitimate reason to llGetPrimitiveParams is if you have modification rights on an object so you can then set them. There's two tiers here:

Full no mod: All calls to the function should return a null list or failure of some kind.

Implied no mod - this is when you can set textures but can't move prims or rename. Calls to get texture should pass - calls to get prim state should fail. If you don't have the texture in inventory the key does you no good anyway.

This way the function can only be used to get information about an object you are allowed to manipulate. One can argue that it still leaves those who offer mod rights on objects more open to abuse - but if you're doing that you're already open to abuse to anyone unscrupulous enough to go looking for a dupe script.

So this addition really presents an opportunity to simplify code a lot and do these things directly without resorting to metaprogramming or spawning master/slave scripts for the purposes of getting anything done. The current system only allows for one-off processes like copying objects and can't really be integrated well into products that do anything much more useful than that.

I'm both a content designer and scripter too so am aware of the possibility of folks copying stuff. It makes no sense though to restrict the elegant evolution of LSL because of the possibility of enabling copying when the threat is already there. Anyone clever enough to code a copier is already clever enough to develop their own product. If they aren't the script kiddles already have access to things that do this. Hobbling the language due to fear of it's misuse on issues like this does a dis-service to scripters.

Availability of llGetLinkPrimitiveParams would enable Emma Nowhere's fix small prims script above to be rewritten in about ten lines of code, and that without needing the av to hold it's hand or spawn possibly hundreds of subscripts and rely on the messaging overhead this creates in order to do a simple task.

On the other hand, the current system prevents scripts that need rapid or frequent updating of the information being practical. One project I abandoned some time ago was a vehicle which calculated its moment of inertia so that it could properly calculate its energy usage during turns, treating prims as point masses - this function would have been precisely what I wanted, given that there were frequent changes of structure. And that's a fairly simple example - I'm sure that polling the scripting community could come up with far more esoteric applications.

When building objects with many prims, often is the case that some will be too small, preventing the object from being scaled down.

This would allow writing a convenience script that could find and fix minimum size prims in the object, allowing it to be scaled farther.

As others have noted, there are a lot of things you could do with this function that is just infeasible without it, getting the same data via link message is just too slow for many purposes, plus requires a bunch of state saving/resuming if you need it in the middle of a complex set of operations, or a lot more memory to cache all this data. Thus, the lack of the function either makes things impossible or causes scripts to use way more resources than they ought to need for a simple operation.

On the flipside, not having the function does absolutely nothing at all whatsoever to protect content. One of the things passing data via link message or chat is not too slow for is cloning scripts, those exist today and work perfectly fine without this function.

I can see the performance difference in my estate tools when I have an object with one script rather than an object with a script in every prim – it's that dramatic. In general, one of the reasons why user experience is as bad as it is in SL is poor sim performance, and lack of tools like this, forcing authors to resort to complex and costly alternatives, is a major reason for that. It's particularly sad when the reason for not having this tool available is, in fact, completely spurious.

That said, I'm one of the supporters of this function - it would be very convenient, without compromising permissions security at all.

Yes, I'm well aware of how llSetTexture works. My point was that you can already get the texture key using llGetTexture or llGetPrimitiveParams, but that both of these functions return NULL_KEY if you don't have the appropriate permissions. I would expect llGetPrimitiveParams to be consistent with this model, so adding this function shouldn't cause any (additional?) security issues.

Our point is that: the taking of UUIDs is currently a moot point in the context of this discussion. It can be done. It is trivial.

The aquisition of texture UUIDs is currently NOT impaired nor assisted by the addition of the function being requested in this jira #.

I can think of many valid uses for this, and the system resource benefits far outweigh the content security concerns as they can be performed without this function.

>> I can think of many valid uses for this, and the system resource benefits far outweigh the content security concerns as they can be performed without this function.

>> anthony reisman

What he said. So I vote yes. There are many houses out there with 80 to 100 idle scripts in them, which still have an impact on server resources, just to tint the windows and walls. This command would enable scripters to not have to take up those resources, and help to reduce lag further, helping to ensure a good impression of Second Life for those coming into it for the first time, and therefore the success of the whole undertaking.

For the tin foil hat people who are worried about it being used as a tool to reproduce objects, get a grip. Any person with a reasonable command of fine motor skills can eyeball something on the screen and reproduce it from scratch, anyway. And, if lag in SL gets to the point where it drives away 999 out of every 1,000 people that try it, ain't going to be anyone around to steal your stuff anyway.

Pros : Makes scripting so much simpeler, faster, and less laggy when you want to read the appearance of an object.

Cons : None! (See Below)

With this new function it will not be nessisary to give out your products with MOD permissions.

Lets use hair as an example of an object currently provided with MOD permission for proper fitting, resulting in people stealing it with the existing laggy scripted methods.

With this function your hair will come with a simple HUD that can change the size, colour, even texture of your hair. It will save and restore different styles, all while your hair is set for NO MOD permissions, thus blocking all the current scripted methods for stealing it that relies on the hair being MOD.

Selling new hair styles can be like real life too. Go to the hair shop, sit in a chair and the shop loads a new parametor notecard into your existing hair, instantly adding a the new style to your HUD. How much fun would that be!!! You could even try before you buy with the hair style deleting itself when you leave the shop without buying it.

Adding this function will not let us do anything we can not already do the long way, but it will make it possible to stop people doing stuff we dont want them to do.

Darling

That entire complicated system could have been replaced with one simple script, if we had llGetLinkPrimitiveParams.

Regarding content theft concerns: doesn't an object already have to have modify permissions for you to drop a new script in it? Unless I'm wrong, the only objects you could "steal" using llGetLinkPrimitiveParams are objects that you already have modify permission for, in which case you can already see the prim parameters yourself, or put any scripts you want in the child prims.

Weighing the pros and cons here is like weighing a hippo against a field mouse.

One lil sneaky way around this is to use llGetObjectDetails() on child prims, but I consider that to be a crude solution and it only works if you are interested in the prim's orientation. It still doesn't address all the other parameters I might want to read.

-Thief puts an invisible, wandering cube 1 meter below the ground in every sandbox, and all mod-permitted items used in every spontaneous team effort ever gets copied at every hour... NOT! The thief is stopped because he doesn't have the permission to alter the link state of even "full perm" items with a script - he lacks PERMISSION_CHANGE_LINKS. So he can't have his evil cube link to everything to steal the data automatically (or even in person)!

So there is no thief-type downside to llGetLinkPrimitiveParams! And it is less laggy than having to stick a script in every prim!

P.S.: If you want to see the current 1 drag and drop, 2 clicks per prim as a thief deterrent, perhaps we should add 3600 clicks to the login screen for everybody so that thieves lose an hour per login... that's the logic keeping the 1 drag and drop, 2 clicks in.

I think those who are against it might be looking at it a little too one-sided. Scripters copying the objects for "fair use" or "personal use" or more devious and illegal purposes, would not be the only ones using it. The content creators could also use it, do combat the very thing they would fear others using it for.

The main advantage therefore is still in being able to change linked-prims using llSetLinkPrimitiveParams /without/ having to store details of the prims you're editing in your script. For example, if all I want to do is change the hollow setting of a prim, I shouldn't need to know and have on-hand details of what shape it is, taper etc., should just be able to fetch the data, slot in the new value and be done with it. It becomes more useful in even more complicated scenarios where you have a script using llSetLinkPrimitiveParams to change multiple aspects of a linked-prim, and don't want to have to track them all.

I'm also not seeing any security issues, if someone can drop a script into an object with llGetLinkPrimitiveParams() inside it, then they can already do this with a script containing llGetPrimitiveParams().

What I would really like to propose is a function such as llSetLinkListPrimitiveParams() with a list of link numbers to change, instead of having to use single links, or LINK_SET, or LINK_ALL_OTHERS, etc. That way you could change a few specific prims simultaneously, instead of having to do one after the other, or using separate scripts to make sure both fire at once.

Or we could have the built-in 200ms delay removed, so that calling a series of llSetLinkPrimitiveParams() functions would cause every link to transform within a single sim frame. The built-in delays of certain script functions are silly and generate unnecessary overhead, since people avoid them by adding extra scripts to their objects.

PS: re:
>>"if all I want to do is change the hollow setting of a prim, I shouldn't need to know and have on-hand details of what shape it is, taper etc., should just be able to fetch the data"
Perhaps if llSetLinkPrimitiveParams were able to be fed some kind of information that implied the existing parameter be used, it would go half way towards what we want here.
eg:
llSetLinkPrimitiveParams([PRIM_TYPE_SPHERE, 3, AS_IS, AS_IS, 60.0, AS_IS, AS_IS]);
llSetLinkPrimitiveParams([PRIM_TYPE_SPHERE, 3, NO_CHANGE, NO_CHANGE, 60.0, NO_CHANGE, NO_CHANGE]);

BETLOG, the ability to specify a constant like that certainly would be interesting, however it would have to specify a value that can't possible ever be used by an integer value. I suspect this may be possible as I'm unaware of any integer value that doesn't use a very specific range of values, so some big negative number would probably suffice. Values which are not integers can simply check if the value is an integer and if it's the constant. This would certainly be useful in the case where you don't want to change parts of an item, as it removes the need to fetch data first.

Personally , i can't see any real security issue with this kind of function in the first place, but I suggested the above as a way to possibly mitigate any such concerns for those who may have them.

pos = llList2Vector(llGetObjectDetails(llGetLinkKey(link), (list)OBJECT_POS) , 0) - llGetRootPosition()) / llGetRootRotation();
rot = llList2Vector(llGetObjectDetails(llGetLinkKey(link), (list)OBJECT_ROT) , 0)) / llGetRootRotation();

but setting it be

llSetLinkPrimitiveParams(link, [PRIM_POSITION, pos, PRIM_ROTATION, rot]);

?

And yes, it would make writing CopyBots fractionally easier - but honestly once somebody's determined to use scripts to copy objects you're not likely to be able to stop them. If we really needed a solution to this, the server could do occasional scans for illegal copies of objects (i.e. as soon as it detected another object with the same prims with all the same properties, it generates some sort of alert or automatically deletes the object - but of course that's pretty easy to circumvent by deliberately ensuring your copy is slightly different in a way that's undetectable by the human eye). However to be honest I'm not sure why designers are too worried about this - how many people actually rely on the fact that if, e.g., somebody wants to make a forest with 100 of your custom trees they have to buy 100 copies of your model? And if you're really determined that nobody should be able to copy your model, you're just going to have to mark is as non-modifiable. Actually personally I would never buy something that was modifiable but not copyable, because I'm not prepared to modify something I don't have a backup of.

If I were a thief, the 15 minutes (or less) to setup such a script to copy a work would be negligible next to the potential profit from the stolen item.

HOWEVER the amount of inconvenience to legitimate customers because I can't provide certain service in my products is HUGE. For instance... this function would allow me to make resizers with ONE SCRIPT. Currently resizers need AT BEST one script in EVERY prim. Think of the lag reduction! Right now resizers are in most attachable objects these days.

That example alone should sell this idea. Not to mention the hundreds of other examples of where this function could improve products. I am a content creator, and I see nothing but benefit from this. The "potential risk" is just in the minds of people who don't understand the issue. People can easily copy anything modifiable RIGHT NOW. Don't like it? Vote for JIRAs that allow for scale changing permissions only or mark it no mod. Sure, it's a pain to your customers, but it is necessary - I do this myself. This product doesn't affect that issue either way. The only thing not implementing this issue does it allow for the propagation of laggy scripts and prevent valuable new products. That's the ONLY thing. I invite anyone to challenge this assertion who is willing to actually debate the issue rather than just throw out "YOU AREN'T RIGHT BECAUSE I SAY SO!"

Personally I agree with your point. You might want to look at SVC-2885 though, a JIRA I created a while back (and have updated a few times since) to allow the resizing and getting the scale of an entire linkset. That at least would allow us some functionality, without compromising prim property information (as easily compromised as it is already, as you pointed out).

Edit:

This is (as you all already know) already supported in the GUI using the drag boxes, but there is no equivalent for LSL. Furthermore, it would allow us to resize objects without needing to worry about which prim was biggest, or which was smallest, or have to resize it one prim at a time.

Right now, I can write a script that call llGetPrimitiveParams() and passes them out to an external script which reconfigures a prim based on those values. It's fairly straight forward to write a script injector that can put a script into every prim in a link set, You have to take that link set into inventory, drop it, and then use "Set Scripts to Running in Selection" to actually start the scripts, but it works.

This function does not make things any less secure. It merely means that for scripts which need to deal with values on other prims in the link set (for example, I have a re-colouring HUD that wants to use the color of the prim that was clicked), instead of one script per prim we can use one per linkset.

Every client out there already knows all the primative parameters for every prim it sees, and can very easily do whatever it likes with them.

We both know that, but the people concerned about llGetLinkPrimitiveParams are not concerned about clients, or copybots, they're concerned about those who don't have the resources or knowledge to use one, but do use scripts.

That being said, I proposed SVC-4252 because I felt that it was a good solution, which has its own benefits in addition to allowing us to do things that a llGetLinkPrimitiveParams function would not. Even if the "security they desire" doesn't exist, it's still what they desire. "PRIM_RELATIVE_*" flags answer both sides, and as I pointed out, can be used in conjunction with one another when/if we eventually do get a llGetLinkPrimitiveParams function.

Am I saying that the "paranoia" is justified? No, not really. But for both sides of this issue, it has some attractive features. I never posted it to start an argument about whether or not there was a security issue Please don't think that I am arguing that point. My only goal was to offer another point of view that would be attractive to both sides.

I would be happy for a llGetLinkPrimitiveParams function, but until that point, I think that the "PRIM_RELATIVE*" flags are a good alternative, and are definitely better than nothing, especially since it would have its own unique set of benefits

*******

We are entering into a a time where linden labs is going to limit the number of scripts, memory, and cpu that can be used on a parcel, and/or attached to an avatar.

Now is the time to have llGetLinkPrimitiveParams so that unnessisary scripts can be removed.

Again, I'll reiterate, I'm not arguing the security, Brody I was simply pointing out that those against the llGetLinkPrimitiveParams, for whatever reasons they have, wrong or right, have no reason to fear the proposal I made in SVC-4252. Now, before you say, "they don't have a reason to fear anyway", allow me to say again that I know that, and you know that, and I agree the security is a non-issue. We know that, but it's still taking other people a bit to get used to the idea.

So in the meantime, I'm proposing a set of llSetPP flags that can give us some of that functionality, and more that llGetLinkPrimitiveParams could not, such as setting specific parameters without changing the rest of the property (setting the color but not changing the alpha, or vice versa, for example) in one function call, and eliminating many times where the position/rotation need to be stored in order to do relative calculations for positioning of entire objects.

Not only that, but it would also allow us to perform many functions without needing to get the properties of the other prim, which is handy in itself as it would save you 0.2 of script time, crucial in many scripts. It would allow you to achieve in one function call what would otherwise need to be done in two function calls, with the llGetLinkPrimitiveParams.

Just to Clarify What I proposed in SVC-4252 is separate from this, but it does give some of the same functionality. I'm not against llGetLinkPrimitiveParams myself, I am for it, and I think both the new constants and this function could be used very creatively alongside one another, since they both have different benefits, and I will be the first to say that there are things we could do with llGetLinkPP that we could not with my proposal, but both would be good to have.

Do we have an understanding now?

Can I query the belief this method is being held back by content creators? LL are extremely slow to add LSL functionality, I'm not sure this isn't simply a case they haven't got around to it. There's some serious no-brainer stuff like https://jira.secondlife.com/browse/SVC-635 (which is a case of FIX YOUR MIME TYPE SUPPORT, LINDEN LABS) that isn't getting done, I think LSL is considered extremely low priority for functionality addons unfortunately.

As to giving content creators an illusion of security; I think this is actively dangerous, as it masks the actual risks without in any way reducing them. SL content protections are little more than a license agreement, in what they actually stop a determined user doing to anything the client sees, and should be treated as such.

My aim is not to provide them with a false sense of security. My aim is to get through a set of constant flags that would greatly enhance our scripting ability, even if llGetLinkPP did come – neither could entirely replace the other. I do not believe it's necessarily "dangerous" as you say, since the people using these constant flags would be scripters, those who understood the "security issue." If you read the post I made just before your latest one, I think you'll see the benefits my proposal has to stand on its own feet

I really would encourage you to read through the proposal. It may not address the specific case you're trying to solve right now, but I'm certain that case is not the only case you've faced in your scripting career. My proposal in SVC-4252 has many, many applications that I'm sure you would find useful at some point, perhaps even something you could have used in the past.

Yeah, you're pretty much right on. I just want to gain as wide a voting base as possible, especially since it does answer so many needs we have right now, with the script limits coming in.

Somthing as simple as llSetLinkText or a llSetLinkPP that can set text would remove the need for scripts in child prims of anything with buttons!

Being able to read the shape, color, alpha, texture, size, position, etc of a prim in a set so that it can be altered in the desired fashion without the need to insert scripts in all the prims that will eat up memory and lagging the region.

Setting the name and description of prims in a linked set without needing to have a script in the object is also missing.

...and dont get me started on passing parametors by reference instead of value. Especialy when they are passed into a LL function call. Why on earth do we need to pass them by value into a LL function call? Are we trying to eat memory?

....hmm... 1:30am... and I am ranting... best sign off now.

So, here is my suggestion. Lets "break" the ability of this to work as a drop in. I.e., you can't drop someone "else's" script into your object and have it work, nor can you drop yours into a build you own, but where only "one" prim in the set is modify allowed. If you create the build, and then you drop in your "own" script, with this function, it will work as intended, with "all" prims in the set that you yourself created. The only thing this is likely to effect is script that someone else makes for you, since their script would be "different creator". Mind, there may be other ways to pass the data along to other scripts, which doesn't limit misuse entirely, but... there has got to be some way you can get something like this to allow "something".

Ironically, if we llGetScale and llSetScale worked on the entire link set, and we had llSetLinkScale, this would be less necessary. But...

Oh, and another alternative, failing all else, if Linden *really* wanted to limit misuse, would be to make a special set of "Builder" functions. I.e., something like, "llBuilderGetLinkSize(integer link_number)", which would **only** function if you are both the owner "and" creator of the object. Many things these functions are used for involve trying to get something to work as intended in the first place. Once you have to completely, the functions become redundant, or when needed, and be simply stored as predetermined values. But, often we may need to know what the "exact" place a prim is, in relation to the overall build, and having a "single" script do this, instead of like 40 of the, in 40 prims...

However, while this later cases is useful when building, there are legitimate times you need to be able to get at this data, and one thing causing "massive" increases in script use comes directly from people having to find 50 different work arounds for something that could use 2-3 commands, if they "existed". And, that includes being able to do something like "llGetLinkPrimitiveParams", then changing that size, then using "llSetLinkPrimitiveParams", to set the new one, without having to take up data space "in" the script, to track what every single thing in the build is doing at any given moment.

as it has already been stated over and over again, it is already easy to copy primwork, adding difficulties to this functions is kinda like the "Adult Only" age verification thing, it gives a false sense of security, gets in the way of people using things normally, and doesn't provide any additional security that didn't exist before

So, here is my suggestion. Lets "break" the ability of this to work as a drop in. I.e., you can't drop someone "else's" script into your object and have it work

Not only no, but hell no.

That would break so much existing content. All the people using Cubey's plane script. All the people scripting megaprims, everyone sticking my HUD scripts in their own prims because they don't like mine, all the people using Franimation Overrider, ZHAO, etcetera...

No. Hell no.

And Tigro is correct, you can't have a linkset with just one mod prim.

Anyway, just an idea. There has to be some reason, and the most common one I tend to hear from "detractors", seems to be "security and non-copyability". This would hose any pretense at protecting content, without "some sort" of restriction.

there is no need to cripple this any further

Kagehi, the case where owner = creator is the one case where we DON'T need this function. (Or at least me personally)

I would want to use this function in resizers in products I release where owner never equals creator.

Now.. From your statement, I have to say that, yes, a big part of the problem is the "all or nothing" mentality of permissions. There are a few jira around, one suggesting "option for resize only", and another involving an extension of permission flags, since each one would logically only take up a single bit (and the integers they store those flags in can't "possibly" be using all 32 bits yet, such that you could set "precisely" which permissions you want to allow and which ones you do not. This would solve some of the problems right there. Though, not this one.

But, ok, dealing with your specific problem. How about this compromise, the function would *not work* unless: (owner == creator || (script == no_modify && object == no_modify))

In other words, they can't hook into your script to "read" the information themselves in any way, nor put in their own, which uses the function to steal the information. However, something prebuilt by you, since neither the object, nor script is accessible to the new owner, could use the function. While building and testing it, it will work, since you have full perms anyway. Otherwise, the guy getting the final product has to have a no-mod object, with a no-mod script, or it stops working. That way, the only way they could "steal" data on the sizes from the object is if you "designed" your own script to give them the information in the first place. Otherwise, your script can get it, and use it, but they can't jack into the script, add their own, or otherwise gain the same information about the build.

Mind, I do find the idea that you can't have "some" parts of a build modifiable and others not, annoying, by itself. Had a door design that you could set the angle and direction it opened, only by "moving" the parts, then "setting" them. I since modified it so you can "nudge" it, by touching one side or the other, to the right angle. I did that to make it less annoying to set it, not because I was aware of the restriction. Now... Am am real glad I thought of the solution, since anyone buying a build with it would have come back and asked, "Why can't I set the door?"

Honestly, if you want to resize something, I made a JIRA for set of functions that would get and set the scale of the entire linkset, SVC-2885 which would be far more practical than setting it prim by prim anyway. llGetLinkPercentScale isn't really going to help people a lot, especially if the lindens enable megaprims on estate parcels as Andrew Linden has said they would.

I'd rather see a regular llGetLinkPrimitiveParams in use, along with llGetObjectScale and llSetObjectScale to take care of resizing.

Yeah, adding mega-prims would make it a bigger complication, but, frankly, that just brings up the same issues with respect to who gets to "see" the data. In that case, it would still be useful to make functions that return such information to a script, so they can work only if someone other than the creator can't "take advantage" of them by getting information they shouldn't. I.e., the object "must" be no-mod, and the script too.

Other than that issue, it really doesn't matter "how" you get the information, but yes, the ability to scale the entire object would be nice, as would to scale the individual ones, and for a script, when in the "right" conditions, to get and use both.

There is no need for any security on this at all. The effect can be simulated using one script per prim already. This JIRA is about doing it with ONE script, thus saving lots of memory and CPU time.

If you send your products out with no-mod permisisons then they cant use this method or any other in-wordl to copy stuff.
If you send your stuff out with MOD permissions people can already copy them. Even if it is manualy reading the numbered in the edit box.
If they use a copybot or one of the openGL hacks they can copy your stuff no mater what you do.

I know memory and cpu dosnt sound like it is important, but we are about to have a major change to all content in SL, a change that may render lots of things useless. All because LL needs to lower memory and cpu usage. It has never been more important to add functions that permit creaters to lower their scritps memory and cpu requirments.

We've already established that prims can be copied trivially RIGHT NOW. Nothing this function does or does not do will change that. Add to that many of the changes you are proposing involve sweeping changes to the permissions system that I severely doubt the lindens will ever implement. If we add a lot of complexity to a request they are increasingly LESS likely to implement it.

This issue is about what new things we'll be able to do. Please don't mistake my argument- I am INCREDIBLY in favor of content protection, but as a scripter of many years I intimately know the ins and outs of LSL. So, please believe me when I say this implementation will only add the ability to create new more efficient content.

anyway, if each prim got at least one script in it, you then would be able to get al the info too, and if the scripts communicate the prim parameters between themselves and the root, you would only need to edit one script

edit: or opposite to what some one i don't feel like checking the name said, you can't save scripts inside a no-mod object?

I don't believe so. Since scripts are server-side and not clientside, the client wouldn't be able to access scripts it didn't have permission to. It might be able to open a script window, but no information would be downloaded or uploaded.

P.S.

I can confirm, you can't even open scripts that are in no-mod objects. You can take scripts out of no-mod objects, but that doesn't help you any if you're trying to copy the object.

But, given that fact, obviously there is *absolutely* no reason at all for not giving us the functionality to do these things. The only thing we could get from it is stuff we already "can" see anyway. Still, there are times when more permission granularity would be nice. Like, if I made a door, I wouldn't mind the new owner being able to rotate the "one prim" in the set, that needs to be adjusted, if they want to change which direction it opens. Yeah, I made semi-nice work around, but... its damn stupid to have to. Same might be true if its using "size" to open/close a door, so I want that prim to be sizable in "that" direction only. And, that is without even mentioning annoyances like being unable to make a "forcefield", or anything similar, in, say a ship, you intend to have move, due to the whole thing going phantom, if you needed "one" prim to have that feature (or other similar situations). Some of the limits we have make no sense to me at all.

But, that is a side issue. In this specific case, we are forced to either have a idiot number of scripts, or use what ever memory we have in the one script we are using, to track every single one of those prims. And, that is not quite as bad as 100 scripts, but gets damn close.

and for the adjusthing the door thing, an idea I came up with for a product I ended up never making, have your product rez a full perm prim for the owner to adjust, and have that prim report it's data to the no-mod object thru hidden channels, this way you give the user full access to the prim editing tools without having to make your actual product +mod

Its ironic that, in a system intended to offer "build anything" realism isn't a criteria. lol

Hmm. Just thinking.. Wind is one of those things.. Wind changed direction, the entire sim experiences it at once. If you wanted to, you could script "some" things to apply "force" based on the wind, but "delay" it, so that the "effect" happens based on how far from the edge of the sim the wind is coming from the object is. More realistic, but.. you have to plug in more script to do it. Not sure of the overhead of the sim reported it based on position by default, instead. Oh well..

No offence to anyone, but can we stay on topic?
These topics are at constant peril of being filled with so much barely relevant comment and almost-advertising that I'm hardly surprised the lindens can't/don't process them effectively.

Also:
Existing function: llSetRemoteScriptAccessPin(); - to pre-prepare prims for scripted insertion of scripts AND/OR retrieval of parameters
Existing function: llRemoteLoadScriptPin() - to actually DO the script push AND/OR parameter retrieval.... with:
Requested function: llGetLinkPrimitiveParameters(integer link, integer PIN, list params); with function delay 0.0 seconds

Image attached: linkmessages/sim being badly effected by unknowingly overscripted avatars.

People who are ripping content have no reason to care if the workarounds are costly because they are not the ones paying the cost. Therefore there is no reason to limit it in any way. None. Zip. Zero. You are doing nothing but muddying the waters. You are not moving this proposal forward by drumming up more complex and more limited alternatives in this JIRA. If you are having any effect, it is to delay implementation by creating the appearance that there is a reason to oppose it as it stands.

*********************************************************

FINAL SAY

No one, and I mean NO ONE uses LSL scripts to steal content. It is all done using a modified viewer program running on their own home computer.

Anyone here talking about this function as if it is a pirating tool is a fool and should stop participating in the jira until they understand the issues. No offence, just the painfull truth

This function has the potencial to significantly lower lag and improve performance for everyone. Noone wants to be stuck with a skirt or hair that prevents them from attaching their flight assist due to the upcomming script limits per avatar. So get with the program people. Do some research before opening your cake hole!

This tantrum was brought to you by too much caffein combined with too many silly people.

*********************************************************

So, yes. Lets get rid of the unnecessary lag not having it causes. Sorry for the off topics though. Just a few things that bug me, and the solutions are, like in the case of the topic of discussion, less than optimal "in the current design", and also add lag you don't need. Seriously, scripting 200 bushes to flex when you walk through them? Even if it works, its a stupid solution, no offense. The point of the entire post was "something we need that can prevent lag", not, "More ways to add it." lol

Are there any Lindens out there who can Champion this feature? Why isn't this already done?!!!

llEndRant();
llUnSit;
llDie;

LMFAO!!

llEndRant();
llUnSit();
llDie();

You rock!!

The shame is that it is funny because it is EXACTLY how I feel. I slump every time I come here. LL is bad for my posture.

TY BlackLotus. Really laughed.

Rev