History | Log In     View a printable version of the current page.  
  • 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've 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: 19
Watchers: 7
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: 13/May/08 01:33 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!)
 
 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 - 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 - 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 - 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 - 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 - 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 - 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 - 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.