I do note however that llGetLinkPrimitiveParams was SVC-224 and this is SVC-4252. Does this mean that nearly 4000 issues have been logged since the debates about providing these types of functions began?

Copybotting has been around since the beginning, and the only value differentiation between a copied product and an original is in the uncopyable scripting. This is a useful function but it doesn't replace others which deal with linksets - indeed it appears to provide functionality which we would get for minimal extra effort should SVC-224 come to pass.

With a good suite of tools for dealing with linksets (which includes this, 2105 and 224 in my wildest dreams) we could make products far more elegant and interesting than simple prim ripoffs. Please give us the tools to make stuff that has more value than pirated copies.

Firstly, I think this issue should be distanced from llGetLinkPrimitiveParams; the idea has its own merits and is while related to that function, it isn't an integral part of this issue. I'd recommend removing that from the description/title and just propose this idea as it is. Also I think that this feature isn't really suited to the critical rating.

Secondly, and the main thing that I think may stop this is that relative operations will require each prim being adjusted to be considered by the simulator. Sure that's exactly what llGetLinkPrimitiveParams() scripts would need to do anyway, but the point is that it may break the llSetLinkPrimitiveParams() methodology which is simply to set-values on one or more prims without any regard to their existing or other values, which gives a minimum of processing overhead. In the end this would certainly simplify scripts, but may be hiding the more complex nature of the operation, as setting values is easy, and can be done in bulk quite quickly, but adjusting values requires examination of them which is slower.

Hmm. In light of what you've said, would you be more in favor of a separate, dedicated function like the one I proposed at the end of the JIRA, llSetLinkRelativeParams? I suppose I should also add llSetRelativeParams() to that, if such were the case.

As for the critical rating, I placed it as such basically out of concern, and gauging it by the llGetLinkPrimitiveParams function JIRA. From my perspective, I see the script limits coming closer, with no (visible) effort on LL's part to bring us functions to help us reduce script load on our side. I really do believe that most of the script load we have these days is due to our own inefficient tools, and that if we were given more efficient tools to work with in scripts, the script load on servers would decrease dramatically. Trying to limit scripts before giving us ways to decrease the load ourselves by greater efficiency seems . . . like putting the cart before the horse. I'm very concerned that we are at least given ways to compensate for however the new limits effect us.

As for its relation to llGetLinkPrimitiveParams, I see your point. When I originally came up with this, it was immediately associated with that issue in my mind, since its main purpose (for me) was to solve the functionality we were missing from a lack of llGetLinkPP, and I had hoped that those in favor of llGLPP would also be in favor of this. At the same time, it does have its own distinct characteristics and benefits. I was afraid that it would be largely ignored unless people saw a plain reason to be in favor of it.

This might be useful, but it;s not capable of replacing even MOST legitimate uses for llGetLinkPrimitiveParams(). And the "problem" it's supposedly avoiding is a non-issue: anyone who wants to violate copyright isn't going to have the slightest compunction over briefly adding to sim load by propagating their cloning script through a linkset.

PRIM_REL_PATH_CUT? I'd suggest going with current standards that address the entire property and not a single parameter you can take care of that just by using PRIM_RELATIVE_TYPE and the proceedure I described above for changing only a single parameter. Very handy, isn't it?

I'm very glad you agree that it's useful However, I'm not sure I understand your reasoning for saying it can't replace "most legitimate uses" for llGetLinkPrimtiiveParams. It's purpose was never to completely replace it, as I said myself in the proposal, but it does provide us with a large amount of functionality that we are missing by not having llGetLinkPrimitiveParams, plus other things that llGetLinkPrimitiveParams could not provide.

As for the security issue, this proposal was never meant to solve any security issue, nor have I ever once stated that llGetLinkPrimitiveParams was a security issue, but simply be pallatable to both sides.

The performance notes I made were just benefits that this proposal has in and of itself, since it would allow us to perform in one function call many operations that would otherwise require two. It's relation to llGetLinkPrimitiveParams is purely that it provides us with some of the missing functionality. It would allow us to help decrease server load. I really am not talking at all about anyone who might or might not misuse llGetLinkPrimitiveParams.

I really wonder why people keep feeling they need to defend the argument that llGetLinkPrimitieParams is not a security threat, when I've never once suggested that it was, and in fact have said I'm of the opposite opinion multiple times?