• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: MISC-268
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Kaluura Boa
Votes: 32
Watchers: 11
Operations

If you were logged in you would be able to see more operations.
4. Second Life Misc Issues - MISC

LSL Features: llGetLink*()/llSetLink*() extensions

Created: 06/Jun/07 08:25 AM   Updated: Yesterday 03:30 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Issue Links:
Relates
 


 Description  « Hide
I realized that the informations a root prim can know about its linked children is very close from zero:

llGetLinkKey()
llGetLinkName()
llGetLinkNumber()

And that's all. On the other hand, you can totally alter a linked child from the root prim:

llSetLinkAlpha()
llSetLinkColor()
llSetLinkTexture()
llSetLinkPrimitiveParams()

What I would like to have in LSL is:

*llGetLinkAlpha()*
*llGetLinkColor()*
*llGetLinkPos()*
*llGetLinkPrimitiveParams()* (This one would be the bare minimum.)
*llGetLinkRot()*
*llGetLinkTexture()*
*llOffsetLinkTexture()*
*llRotateLinkTexture()*
*llSetLinkText()* (Would be very useful for texts on HUD buttons!)
*llSetLinkTextureAnim()*

And eventually --though we already have llSetLinkPrimitiveParams():

*llSetLinkPos()*
*llSetLinkRot()*

Why? Because the only way to move/rotate children prims is either to hardcode their positions and rotations in the root prim script(s), or else to add a script in every of the children prims. IMO, it's very illogical that the root prim can change the position and rotation of its children but that only them can determine their relative position and rotation. (The same applies to the alpha, color and texture.)



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Wolt Amat added a comment - 22/Aug/07 12:11 PM
This related loosely to the two other feature requests for a link subset hierarchy and addressing subsets of children for link messages. A revamping overall of the object link concepts is probably in order.

WarKirby Magojiro added a comment - 04/Sep/07 02:09 AM
if we got llGetLinkPrimitiveParams, I fail to see the need for most of those. That, plus llSetLinkText would be fine.

Elwe Ewing added a comment - 13/Sep/07 10:23 AM
Even if I think that all "Set" instructions should have "Get" counterparts (so the issue is interesting), there are reasons if all can't (or should can't) be driven by root's script.
Scripts are used efficently if they're thin and quick: it seems to me that huge, traditional programs goes beyond the target of LSL (making a SIM laggy for instance): they are "scripts" not "applications".

So, to give a real example of this... you can have a plane with retractable landing gear: retraction can be made in two ways.

1) plain (old) "central application" mode: the root's script apply all the landing gear's parts movement, while trying to make the plane fly, controlling the gear fully.

2) the "scripting way": root's script (mostly the "engine") tells the landing gear to raise (via LinkMessage) -> landing gear's script make all necessary movements (while engine's script make the plane fly) and signals back "gear up". Engine's script can record gear's status with a flag (landing_gear_down = false)


Cago Hax added a comment - 16/Sep/07 05:28 AM
I agree with WarKirby, allmost useless except this llSetLinkText(), and i would suggest that this one would be used for linked primitives object's floating text ability for a fast implementation that permits to void the use of llMessageLinked command to get a simple floating text to display above any linked primitive object, since you can already edit any texture to apply on your HUD button, and design whatever static or dynamic text you would need for those buttons's labels you discribed....
That gives me idea to beg for extended llSetText parameters, i mean to give the possibility to set the floating text able to display above,below,on the right,left, behind, in front or even reverse the side of the output floating text, and the cherry on the pie> animate the floating text in order to make it able to rotate or pulse/flick without make it from the primitive itself (floating text binded to a single orbitting prim for ex), shall i post a detailed new feature request for that ?

Jacek Antonelli added a comment - 05/Nov/07 05:44 PM
As a professional scripter, I have had projects recently where llGetLinkTexture() would have reduced the number of running scripts in the object by about 10, as well as made the code structure of the main script easier to follow. So, these functions would definitely be very useful.

Consider, for example, a HUD which allows you to customize the textures of a complex object, by simply dropping new textures onto prims on the HUD. With these new functions, the HUD would only need 1 central script, and could collect the textures of the linked parts. As it is now, without the functions, you need 1 extra script for every thing that could be changed. Similar examples exist for the others; alpha, color, pos, rot, etc.

And although it's true that having llGetLinkPrimitiveParams() would allow us to emulate the other llGetLink* functions, but which would you rather write (and then read 6 months later)?

> texture = llList2String( llGetLinkPrimitiveParams( 5, [PRIM_TEXTURE, 0] ), 2 );

> texture = llGetLinkTexture( 5, 0 );

There's value in simplicity and ease of use.


Alidar Moxie added a comment - 13/Dec/07 06:28 AM
Along with what Jacek is saying, if I want to apply the same processing to multiple objects each with dozens of linked objects, not only would the number of scripts decrease dramatically but the sheer ease of use (drop in 1 script vs maybe a hundred) would increase significantly.

Brandon Shinobu added a comment - 05/Mar/08 10:34 AM - edited
@Elwe:

I agree with you completely. Sorta. Yes, scripts are supposed to be slim and fast, yes, sometimes scripts should have their operations split up for memory and speed reasons. That is hardly true in every case though. As many here have said, many scripts would be far more manageable if we could avoid making calls to other scripts in order to accomplish work. A script in every_prim is not a good solution, but it is the only solution we have at this point unless you want to do a lot of math with region coordinates and rotations (and that can only povide you a partial solution). In fact, being able to accomplish the things mentioned here through functions in the root would dramatically decrease the bloating of some scripts, and reduce lag. I created a similar issue elsewhere requesting llGetLinkPos andllGetLinkRot to get te local versions of both, which I'll mark as duplicate once I get to another computer. Lastly, scripts are mini applications. They run programs, like widgets, and they should be able to run efficiently. Getting information for child prims in a single script is a natural step towards efficiency.


Tomm Olifone added a comment - 23/Oct/08 10:44 PM
Added llSetLinkTextureAnim

Chalice Yao added a comment - 25/May/09 02:56 AM - edited
I linked the issues SVC-224 SVC-2367 SVC-3360 and the closed SVC-4302 to this, as it is kind of a meta issue for all link-related functions.

These functions are very, very important. They basically allow alot of functionality that currently only can be achieved with putting a script into every child prim that needs it. Currently the need to do so causes

1. Script memory overhead for every script added to the object. in the case of LSL scripts, the full 16kb.
2. Script time overhead, a minimum of 0.003ms. In objects that need 50+ scripts due to having to apply alot of functionality in child prims (and/or creators not knowing better), this can easily cause an overhead of 0.4ms. This is alot.
3. Overhead in the script VM/sim script management code, due to the high increase in script amounts in the sim.

Examples:

One of my huds has 17 scripts in it, which is already kind of low for its kind of combined functionality. With a function like llSetLinkText, this would be instantly reduced down to...7.
Another example is a sim stat grapher a friend made, which uses a total of around 73 scripts due to a lack of adding particle and text functionality to child prims via a central script. If llSetLinkText and llLinkParticleSystem existed, this whole set could be reduced to 1 (one) script. I wish I was kidding.
Yet another example is the object described in SVC-4302, where an 11-script object also gets reduced to a single script.

A llGetLinkPrimitiveParams function would enable no-mod clothing creators to have their resize/recolor functionality easily be implemented in a single script. Currently the most widespread solution is to add a script per prim, which easily can result in 600+ scripts in a whole outfit or more (I am not exaggerating this), and despite often included scripted delete functionality for the scripts, most users of such outfits simply do not know about this.
Those 600 scripts easily add a script time overhead of 1 or more ms in the sim. if you don't know, a sim has a total of around 22.2ms per frame for physics, agents, simulation, physics and networking combined, not just scripts.

Add the fact that script memory pools will be coming on a per-parcel and per-avatar basis sooner or later, along with the list of advantages above these functions would allow an easy lowering of memory needed, which makes sure that the current functionality of products can stay when those memory pools finally come.


Pae Sinister added a comment - 03/Jul/09 03:30 PM
With llLinkParticleSystem, I could reduce my Willow fireworks round from 10 scripts to one, and my Skylighter could go from 140 scripts executing all at once to at least a third of that. My Salute howitzer presently has five scripts that could be knocked down to just one. I'm all for more efficiency and having as low of an impact on the sim as I possibly can, so you've got my support.

Of course, we need to fix the mono rez problem over at http://jira.secondlife.com/browse/SVC-3895 before we go adding things ....