|
|
|
[
Permlink
| « Hide
]
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.
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. I linked the issues SVC-224 SVC-2367 SVC-3360 and the closed
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. 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. 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. 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. 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
LSL Features: llGetLink*()/llSetLink*() extensions
