|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 11/Apr/07 09:19 AM
This kind of thing is fraught with complications. What if the child prim in question is no-modify? Normally you wouldn't be able to add a script, and therefore you wouldn't be able to modify the item using a script. This could possibly let you get around that. For that matter, llSetLinkPrimitiveParams might too. Huh. I think I'll go check that.
omg this would so complicate LSL. Every set & get function would need to be overhauled.
Besides the required work on most functions, I don't see a good reason why this shouldn't be implemented. Sure it will complicate scripting but I don't see that as a reason not to implement it. It would complicate debugging for new users. Couple ways to implement this: To ease in debugging there should be a llGetEffectiveLinkNumber as well.
Strife: have you actually seen the server code? Because it seems unlikely to me that the internal LSL functions could be implemented at all without parameters referencing the script and the prim the script is contained in, and these parameters would simply be set to the effective link information. The llSetEffectiveLinkNumber call would save and update the existing data, and the validation of the parameters would take place in that call.
Certainly llSetLinkScriptState() would be an easier call to implement, but the complexity of llSetEffectiveLinkNumber should not be so great as you're anticipating. llSetLinkPrimitiveParams() seems to cover MOST of the cases, but not all.
Probably enough to make llSetEffectiveLinkNumber overkill. But there's still a need for something equivalent to llSetLinkScriptState(). As I posted in
llSetLinkScriptState() is important enough and seems to have universal support in the comments, I'm taking the more powerful call out of the proposal... leaving it here for reference:
Sets the "effective" link number of the curent script for the remainder of the current event. After this call, all LSL functions that effect the current link effect the link provided. If link references multiple prims, then calls to *get( link information will either fail with an error or return the link information for the actual link the script is in. The "effective link" would revert to the curent link at the end of the event, or if it's called again with LINK_THIS as a parameter. I'm building a HUD and I could really, really use llSetLinkScriptState() right now, as it's impossible to call llSetText() on a linked item. The only alternative I have is to add 50 scripts that all have to be running, all the time, just waiting for a linked message to set the text. What I really need is llSetLinkText(), but, failing that, llSetLinkScriptState() would allow me to only turn those scripts on as and when I needed them.
Here are the functions that I have wanted to apply to linked prims:
llSetLinkText(integer link, string text, integer alpha); Any more that are really used? I think these three cover virtually everything I have to do in little helper scripts in links that aren't already covered by llSetLinkPrimitiveParameters. Ehm, only one I can think of to add off the top of my head would be:
llSetLinkTextureAnim(integer link, integer flags, integer x_frames, integer y_frames, float start, float length, float rate); This one would be useful for doing neat things with animated HUDs and such. Good call, I should have thought of that one.
In regard to these requests, I have noticed a certain number of mod items that are utterly destroyed if they are re-linked. This is undoubtedly caused by having to pre-calculate the link numbers for child prims and the inevitable reshuffle that occurs on re-links. All of the tools here are excellent additions to the language, but at a minimum, being able to name and retrieve that name from a child prim would allow reliable access to your children, and re-linking would no longer be a death sentence for such scripts.
Making this work would require the script to index numbers and names, but that seems preferable to manually calculating the names and the fragility that produces. You can already retrieve the name from a child prim: llGetLinkName(). Having a maintenance routine that gets run from appropriate events to recalculate the link numbers is pretty routine.
Ahh yes! Pardon my noobishness, I looked for something like that for an hour and couldn't find it on the wiki, Thank you!
I do still support the ideas here though. requesting :
llGetLinkColor(integer link, integer face) llGetLinkAlphainteger link, integer face) llGetLinkDesc(integer link, string name) [without needing to use the fairly cumbersome syntax of llGetObjectDetails and as a logical partner to llGetLinkName()] llSetLinkDesc(integer link, string name) a common-use example for all of the above would be in HUD buttons, specifically where their color/alpha state could be instantly referenced between multiple scripts/prims without the need for additional state-storing variables and a nightmare of linkmessages. I'm voting for this JIRA, but I disagree with the implementation. There are serious design defects in LSL, and just giving a raft of llLinkedThingie commands won't solve that. What has to happen is that the dot operator needs to be expanded, to give objects actual object-orientation.
For instance, if you want to reset a script in child prim 2, you do this: me.child(2).llResetOtherScript("scripty"); If you want to animate a child prim you do this: me.child(3).llSetRot(ZERO_ROTATION); And if you want to keep a reference, you do this: prim foo = me.child(3); or you do this: object_rez(key id) { prim theThingIRezzed = llKeyToPrim(id); theThingIRezzed.llSetColor(<0,0,0>, ALL_SIDES); }And then, given that this model makes sense, scripting is better and more fun and more efficient and probably solves global warming and makes everyone think of cute kittens. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Script control for link sets (linked prims).
