|
|
|
Voted yes.
My comment below is not very well thought out, but i felt some alternate syntax might be worth consideration. (Yeah I know, lists inside lists ~= arrays) ...or getting even more silly.. linknum bitmasks anyway.. for discussion. While they would be nice features to have BETLOG I'm afraid lists within lists isn't very likely any-time soon, unless we went into the more complicated syntax of defining lengths (i.e - first value tells the sim how many prims you're going to specify, thus it can count these then know when to start interpreting commands). However that can get very unwieldy very fast.
As for bit-masks, that only works if the links are all number as powers of two (1, 2, 4, 8, 16 etc.) and would reduce us to only 32 primitives in a linked set. I think for now the best thing we can hope for is a basic llSetLinkListPrimitiveParams() function, and maybe getting rid of the 0.2 second delay and replace it with a more useful throttling system (e.g if a script is sending too many object updates per second then it starts to get throttled). Of course, who then defines "too many"? I'd be a proponent of that instead of a delay, but just the same, it would be most useful for extensive changes, such as in avatars when changing looks. You might need a series of them to change several groups.
Absolutely agree on the need for this, as currently it's simply not possibly to adjust the positions/rotations etc. of multiple prims simultaneously, making prim animation very restrictive (or at least, looking very messy).
My suggestion is a single list with a delimeter constant indicating the end of adjustments for a particular prim. Technically like this you don't even need a new function name, as if you don't use the delimeter, it's the same as llSetLinkPrimitiveParams. E.g: llSetLinkListPrimitiveParams([2, PRIM_POSITION, newPos2, PRIM_ROTATION, newRot2, NEXT_PRIM, 3, PRIM_POSITION, newPos3, PRIM_ROTATION, newRot3, NEXT_PRIM, 4, PRIM_POSITION, newPos4, etc. etc...]); either that or two new functions: llBeginAdjustPrims(); that basically queue up all the adjustments and fire one simultaneous change event at the end. Glad to see others have raised the need for this function. But to be truly useful a llGetLinkPrimitiveParams() function is definitely also needed. Hmm, while I do like your suggestion you seem to be going more for sending multiple different llSetPrimitiveParams() requests to multiple different child-prims in a single action. While this is desirable, I feel it may be better placed as its own issue, as really this is for applying the same, single set of parameters to multiple primitives. This has the advantage that the list-size is much smaller, and in theory processing it (on the simulator's side) should be a lot easier, as the changes for one primitive should be identical to the changes to another.
True, so I guess ideally the same function would support either...hmm, how about
llSetLinkListPrimitiveParams([LINK_LIST_START, 1, 2, 3, LINK_LIST_END, PRIM_POSITION, newPos, PRIM_ROTATION, newRot, NEXT_PRIM, LINK_LIST_START...LINK_LIST_END would be optional - you could simply specify a (positive) prim number if you were only applying the changes to a single prim. This wouldn't be all that useful for what I want to do because while I am moving/rotation a bunch of prims together, their actual positions are all subtly different. Also, I realised this isn't the same syntax as llSetLinkPrimitiveParams, which takes two parameters, the first being the single link number, the latter being the list of changes to make to it. Following the brainfart i posted above, I think the simplest way would be:
llSetLinkPrimitiveParams( [5, 6, 8], [ PRIM_POSITION, position ,PRIM_SIZE, size ,PRIM_FULLBRIGHT,ALL_SIDES,TRUE ] ,[6, 8], [ , PRIM_SIZE, size ] ,[8], [ ,PRIM_FULLBRIGHT,ALL_SIDES,TRUE ] ); This is semi-consistent with the existing function too. That assumes you can have functions taking variable numbers of parameters, which I don't think LSL supports.
Rereading what Zaphod has said, I have to agree. If you cut that down to just two parameters (one list for links, and the second list for prim properties) we'll be good as gold. Sure, it would be nice to set different properties to different sets of links all at once, but unless that's feasible in some manner I'm not aware of, I don't think it'll happen. See my suggestion in the first comment of the JIRA:
" llSetLinkListPrimitiveParams( [5,6,8] , [PRIM_FULLBRIGHT,ALL_SIDES,TRUE] );" So basically: llSetLinkListPrimitiveParams( [link list] , [property list] ); Please, get as many people as you can to vote on this. If for no other reason, it'll get more people aware of the need for it, and get people asking LL for a development team on it. Does anyone know an opensource dev who'd be able to write a patch for this feature and attach it? Yeah that's what I think is best as originally proposed; the main reason I think that we can use LINK_SET etc. in llSetLinkPrimitiveParams() is that it only has to process one list of parameters, which can then be applied to all links in one-go, whereas with different lists for different links really what you're asking for is for the current 0.2 second delay to be removed.
Added a link to SVC-4252 as I suggested a similar function based on a new llSetLinkPrimitiveParams proposal.
Ok, i might be missing something here, but it seems all suggestions allow a way to set prims params without the 0.2 seconds delay impact. Instead of inventing all kind of ways to give link numbers to llSetLinkPrimitiveParams, simply remove its 0.2 penalty? We can than simply call the same function multiple times for multiple linknumbers.
The only argument i find against it would be if SL would process all the changes to the prims instanteniously, making it a single PrimUpdate message to the viewer(s). If they however handle it sequentually internally, resulting in multiple PrimUpdate messages, there wont be much to gain by make "smart" llSetLinkPrimitiveParam's. @Iskar
Simon Linden actually confirmed through some of his own research that scripts using loops to call a function multiple times actually do have a fairly high cost on script time and processing, whereas setting prim properties all at once was a quick and relatively painless process for the server (such as can be done with LINK_SET or LINK_ALL_OTHERS with the current llSetLinkPrimitiveParams). That aside, writing for loops tends to be kind of painful anyway, and if we were able to specify in one function what we need done, rather than have to worry with a for loop each time and iterating all of the variables needed, that would be much easier for scripters alone. What we're asking for here isn't really anything new. You can already set a bunch of prims with the same properties at once as I pointed out earlier, using LINK_SET and LINK_ALL_OTHERS. What we can't do, is specify which prims we want to make those changes to. That's where llSetLinkListPrimitiveParams would come in. It would let us do the same thing, but only to specific prims in the linkset, greatly reducing the work the script needs to do, and reducing the time it takes to do it. As per Andrew's instructions on Nov. 19th's office hours, I'll be changing priorities on the issues linked to MISC-3007 to make things easier for the lindens who will be working on this issue:
[17:13:13] Andrew Linden: Go ahead and change the priorities on the list. That might be helpful. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
llSetLinkListPrimitiveParams() for setting multiple, specific linked items
llSetLinkListPrimitiveParams( [5,6,8] , [PRIM_FULLBRIGHT,ALL_SIDES,TRUE] )
To set 5,6 and 8 to fullbright.
Summon Qarl!