|
History
| Log In
|
|
|
|
|
|
[
Permlink
| « Hide
]
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.
if we got llGetLinkPrimitiveParams, I fail to see the need for most of those. That, plus llSetLinkText would be fine.
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) 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 ? 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. 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.
@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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
LSL Features: llGetLink*()/llSetLink*() extensions
