Discussion: llSetLinkPrimitiveParams vs. speed

So we have now llSetLinkPrimitiveParams and we can lower our number of scripts. Good.

Just tried to cut my script number from 37 to 1 in my xyText display. It uses 5-character cells (one texture) for a 6 lines x 30 chars display, so the total of 36 cells scripts + 1 master script = 37. Easy to upgrade : just copy the cell script in the master script and change llSetPrimitiveParams for llSetLinkPrimitiveParams. Here the results:

Old method, 37 scripts, full display update : 1 second
New method, 1 script, full display update : about 15 seconds

This is in best conditions, empty sim, no time dilation. In crowded sims, update times use to be much longer. Not sure it's a good deal.

Yep. Making it so you can only target a single prim makes it worthless if you want any form of unified updates.

I guess like everything else it all depends. I'm about to rescript my vendors (which set far fewer textures and can probably cope with a <1s delay), for something like your script family a set that is one per prim might be the only acceptable answer. Something like one per row or column - 7 scripts rather than 37 might be a workable compromise, no?

How about having all 37 in the main prim, but inactive. To run them, activate each script and and run it via a link message. As each finishes, it deactives itself.

There will be a short period when you've got all 37 scripts running (or most of them), but then you'll be back to just 1 in a very short time.

That's a clever idea.

Are there any known glitches with activating a script not working, or lagging? I have some things that need fairly tight synchronization between all the prims, and I've been wondering about how I could use these functions to reduce my script count.

Yeah, the new functions are marvelous, but still not helpful for implementing text displays using texture manipulation.

Nice idea, Ralph. Using llSetLinkPrimitiveParams to move the scripts from the child prims to the root and being able to fire them when needed. That's the technique I use for my mailer bank. I will try it as soon as I can find the time. Thanks.

Alright, so, if we were to ask for a new function similar to llSetLinkPrimitiveParams that allowed us to set lots of params on lots of child prims all at once, how would it work? There were a few suggestions in the original thread that announced the new functions, but I don't think the community ever really nailed down what would be the best interface.

I'd like to avoid having a huge slew of various functions with different calling conventions like llSetLinkPrimitiveParamsWithFriesAndACoke(), but it seems to me that people would like the ability to set individual parameters on multiple link children, but we'd also like to be able to set one parameter on a specific subset of link children, not limited to just LINK_ALL_CHILDREN.

I have yet to see a recommendation for a new function/syntax that really encompasses these goals. Maybe if we could come up with a nice, elegant new function, we could get LL to implement it for us. Ideas?

 
llSetLinkListPrimitiveParams( list links, list parameters);

Example:

list gChangeLinks = [1,5,7,12];
llSetLinkListPrimitiveParams(gChangeLinks,[PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,PRIM_COLOR, 0, <0, 1, 0>, 1.0]);

Edit:

The other suggestion was to allow Lists of SetLinkPrimitiveParams to be sent.

 
llSetListPrimitiveParams( list LinkPrimitiveParams);

Example:

llSetListPrimitiveParams([1,[PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,PRIM_COLOR, 0, <0, 1, 0>, 1.0],5,[PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,PRIM_COLOR, 0, <0, 1, 0>, 1.0],12,[PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,PRIM_COLOR, 0, <0, 1, 0>, 1.0]);

If I had to choose, I'd go for option 2 please.

It lets you set all kinds of things differently, but one big call rather than 2/3 different ones. It would make your change flow smoothly because it would all change at once rather than in bits.

That said... I had someone asking about tweaking prim hair with scripts. Can you imagine the hammering the poor sim would take?

I've used a bunch for non-physical moves, turning them on and off as needed and it was very fast.

Thanks, that's good to know. Next product rev will probably re-implement everything this way.

I'd take the 2nd suggested form of the function too, since in my case each prim needs its own set of parameters, so a "list of prims", "list of params" won't work for me.

While on the subject - is there a 'get' equivalent, even in the current form? I don't think I saw it in the announcement. Is there any way to find the scale/texture/position/rotation of a child prim?

The main reason your merged XyText scripts are so 'slow' is because each llSetLinkPrimitiveParams call forces a delay of 0.2 seconds -- When you use the seperate scripts, they're being called in parallel.

The single script makes serial calls, one after the other, with the delays intact, IE:

llSetLinkPrimitiveParams
0.2sec
llSetLinkPrimitiveParams
0.2sec
llSetLinkPrimitiveParams
0.2sec

Versus firing them all off at once and getting a single 0.2 sec delay with a linked message and multiple scripts.

It's a tradeoff, I know. I would also have liked to pass a List of linknums to update multiple prims in a single pass; maybe in 1.15...

Can't work that way, you can't have lists of lists. You'd either need to have an extra prim index for EVERY parameter:

llSetListPrimitiveParams([1,PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,1,PRIM_COLOR, 0, <0, 1, 0>, 1.0,5,PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,...]);

Or a new parameter for llSetPrimitiveParams:

llSetPrimitiveParams([PRIM_SELECT,1,PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,PRIM_COLOR, 0, <0, 1, 0>, 1.0,PRIM_SELECT,5,PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,...]);

Another suggestion someone made was to do it by name:

llSetNamedLinkPrimitiveParams("Curtains",[PRIM_COLOR, ...]);

And two other interesting suggestions that came out of the same discussion:

1. llSetLinkScriptState(integer link, string script_name, integer running);

Farallon Greyskin noted to me in-world that this can be implemented by having scripts disable themselves and using script PIN loads to reload them running again... albeit at a huge cost in delays and lag and complexity.

2. A mechanism to run a code block as if it was in another link in the same link-set.

Okay, I'll go in order.


Thraxis' llSetLinkListPrimitiveParams() is nice, but it doesn't help with, for example, XyText displays, because they need to set different parameters on each link in the set.

As Argent pointed out, llSetListPrimitiveParams isn't any good because lists don't work that way.

I actually really like Argent's PRIM_SELECT idea... it's one we haven't heard yet. Could we perhaps also have PRIM_SELECT_CSV, used like so:

llSetPrimitiveParams([PRIM_SELECT,1,PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,PRIM_COLOR, 0, <0, 1, 0>, 1.0,PRIM_SELECT_CSV,"5,12,13",PRIM_COLOR, ALL_SIDES,<0, 0, 0>, 1.0,...]);

Can anyone think of a less kludgy way of doing something similar?

As to llSetNamedLinkParameters... I think this would probably be woefully inefficient in the backend, and it seems to me like it would greatly obfuscate coding. I'd rather numbers were specified in the llSetWhatever calls, because at least there's a chance that someone could use constants in their script to make things more clear.

Then there is always the option to have a few extra scripts that all they do is update prim parameters. Then just cycle thru the scripts. I know it is sort of an ugly method but hey what what would have taken me 216 scripts now only takes 4.

So for example in a text display you could setup a script per line. Which would reduce your update time by a large amount. and reduce the number of scripts from what you had before.

Well, PRIM_SELECT_CSV covers PRIM_SELECT in the degenerate case where the CSV string has one entry in it, so I don't think you'd need 2 separate defines. I wouldn't mind writing ..., PRIM_SELECT_CSV, "1", ... And if they do that then something like PRIM_SET might be a better name.

I forgot you couldn't put a list inside a list

Regarding llSetLinkScriptState - what does that achieve that can't be done by turning scripts on/off in the root prim, broadcasting link messages to them, and having each one handle one child prim? It seems to be that you'd have the same number of total and active scripts. I can think of one possible difference - I don't know if there's an llGetLinkPrimParams... if not, then that's one advantage of having the script in the child prim itself - it can find out information about its prim that a script in the root prim cannot.

I would! That's a pretty seriously confusing limitation to place on what's probably already a fairly arcane function calling paradigm if you're new to LSL. These functions are very sensitive to type. In llParticleSystem, if you pass one of the parameters as an integer when it's expecting a float, the call fails and the function returns an error, because the backend implementation can't be arsed to cast to a float for you. Requiring passing a number as a string is pretty confusing.

Well I like it because it means that you're not limited to what llSetLinkPrimParams can do for one thing.

It also allows much simpler coding if you need to do several things to the prim together since many operations can be done with no delay and you'd need multiple scripts in the main prim all coordinated to get the same effect. In the prim, there would just be a single script executing the operations in sequence Chaining operations in the setprimparms is fine, but they don't all work together.

The final argument, and the original one, is that this single function ends any further need to keep adding more linkprimxxx functions to the language as more stuff is added. Anything you can do is there and can be put into any prim, but only activated as needed.

At the risk of repeating my previous comment, I'll suggest that having to rely on llSetLinkScriptState() rather than getting more llSetLink*() functions could lead to more heavily obfuscating the code we write. I think a complex script system would probably get pretty confusing to understand if it involves awakening and freezing what are essentially remote execution threads on a constant basis.

I wouldn't mind llSetLinkScriptState(), but I don't think we should be expected to rely on it completely for this kind of thing.

Well, without turning scripts on and off, whether in the same prim or remote prims, you're going to have serious delay issues in many cases since the .2 sec delay is cumulative.

For a lot of actions you need much faster response, so you'll need multiple scripts in the same prim and a controller to turn them on and off as needed. This is exactly the same code as needed to turn on remote prim scripts and is needed to get parallel execution.