I'm aware that there are JIRAs addressing the need for llGetLink* extensions, but I'm making a separate JIRA because I want to support these specific functions only (I explain below). I've been persuaded by other JIRAs I have read that the need for functions to help decrease the load and number of scripts used is very great and very real, and so I'm setting this JIRA as "Major". I think this is extremely important, considering the upcoming script limits the lindens have planned. vector llGetLinkScale ( integer iLinkNumber) – returns a vector that is the scale of the link number specified. vector llGetLinkPos ( integer iLinkNumber) – returns a vector that is the local position of the link number specified (and works in attachments, relative to the attachment root). rotation llGetLinkRot ( integer iLinkNumber) – returns a quaternion that is the local rotation of the link number specified (and works in attachments, relative to the attachment root). If any of these functions are used on the root prim, they would return the region coordinate equivalents of the object, or in the case of attachments, the local coordinates relative to the attachment point. Why am I promoting these three specific functions? The biggest concern for those against llGetLinkPrimitiveParams or a full set of llGetLink* extensions is script-copying of modifyable products. These functions, even used in conjunction, are generic enough that they won't allow the copying of objects, since it does not copy color, alpha, texture, prim type, prim type properties, glow, shiny, flexibility, light or any of the other prim properties necessary. However they are functional enough to give content developers themselves the capacity to develop scripts that can make their products that much more useful, without the need for a script in each prim, or the terribly inflexible hard-coding of prim properties. The lindens are planning on script limits: much of the reason script limits are needed right now, is due to our inability to achieve certain common operations efficiently and quickly, and so in the effort to provide functionality, we sacrifice efficiency for script load and number. In most instances, and especially in this case where I propose llGetLinkScale, llGetLinkPos, and llGetLinkRot, it's required to use a script in every single prim in order to achieve the same functionality. As sensible people, we prefer efficient and quick ways to do things, rather than force LL to crack down on script performance, and I am thoroughly convinced that if we are provided functions which can ease the load and number of scripts we have to use, that the need for scripting limits will also lighten. Perhaps the scripting limits will still be needed in some cases, but we will have ways that allow us to preserve the creativity and usefulness of LSL without being a burden to the linden servers, and be able to achieve said creativity in ways even better than before. I would also recommend those in favor of this JIRA to look at SVC-2885 - a proposal for a function to get and set the size of an entire object (a linkset) via LSL.