New LSL Commands in 1.13.4

These seem to have slipped from the release notes, but i know quite a few have been looking forward to these.

Currently on the aditi beta grid.

llSetLinkTexture(integer link_pos, string texture, integer face)
Sets the texture of face for link_pos

llSetLinkPrimitiveParams(integer linknumber, list rules)
Set primitive parameters for linknumber based on rules.

Each with a 0.2 second sleep and rules as per their non link counterpart.

I bet there will be some happy scripters about this.

OMFGZOMGWTFBBQ!!!1!!!!1!11111!oneoneone!1!11!!!

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU

*does the happy Dragon dance*

wait a minute...

*checks calendar*

nope.. April 1st is still over a month away...

*goes back to dancing*

Oh, this is awesome: will drastically simplify, speed the inter-object communications I've needed for setting prim parameters in linked sets... Memory requirements will drop a HUGE amount, not needing to "package" texture / face info into tagged lists...

Yes, this is another happy scripter


BTW, OMGWTF I understand, but BBQ?

What he said

Could there be any doubt whatsoever? Hell yeah there are some happy scripters!!!

*dies*

Wow. Just... wow. This is really going to help.


Now, before this goes out, can I BEG for a smallc hange in llSetLinkPrimitiveParams()?

People may still be inclined to use a whole slew of scripts in each prim of a link set rather than llSetLinkPrimitiveParams, llSetLinkTexture, or the other llSetLink* functions because that would be the only way to get a bunch of changes on a bunch of prims to happen all at the same instant. This is a real pain for the sim, because having so many scripts really hurts the sim's Script Time stat. So can you change it so that the link number is specified in the parameter list for llSetLinkPrimitiveParams for each rule?

Example:

llSetLinkPrimitiveParams([LINK_THIS, PRIM_COLOR, <1,1,1>, 1.0, 3, PRIM_COLOR, <1,1,1>, 1.0]);

That would change the color for the current prim and prim 3 all in one call.

I suppose it's probably too late, but whaddya say?

I also have a question about llSetLinkTexture(). I'll try to get into Beta and test this when beta's up, but in the mean time: what happens if you specify the name of a no-copy texture in an object's inventory when using this function? For example, if I have a no-copy texture named "fred" in the root prim of an object, and I call this:

llSetLinkTexture(2, "fred", 1);

Will that set the texture fred onto side 1 of prim 2? Will that move the no-copy texture to prim 2? If the no-copy texture is already applied to the current prim, will it be unapplied in the process? Or did I just find a crack in the permissions system that allows you to use a texture multiple times even if it's no-copy?

Yeah, adding the enforced delay kinda taints it a little; after all llSetLinkColor/llSetLinkAlpha do not have a sleep. Not sure why these would. Do the Color/Alpha changes not send out much data as compared to Text/Params? I was under the impression that any prim properties changing forced an update of the whole prim dataset to the client. If so, then the delay makes no sense (and didn't really with the regular non-link versions).

oooh can't wait to try these. It should reduce the amounts of scripts used in a build for sure.

ALMOST there. Still needs "llSetLinkListFoo(list links, ...)" to get rid of the 200-script wings and the like. But... bravo bravo bravo! Three cheers and a tiger!

(still waiting for llTeleportAgent() and llAvatarLookAt())

Nah, this effectively gets rid of the 200-script prim attachments. Granted, you may have to put around 10%-20% of the slave scripts in the root to change it in around a second, but meh, I will take it as-is for now and hope they will drop the forced delay at some point.

Just curious, Milo, what, exactly, IS the rationale for the enforced sleep penalties?

Yay!

Milo, i would like it if you post things like this on the blog. It was my understanding that the Lindens have abanded the forums regarding the posting of news. And i'm actually quite happy about it because it saves me a lot of time, i only heard about this by accident. So could you please in the future just update a blog post or make a new one. It will be much appriciated.

*Does a happy dance for new functions*

Sweet! This is gonna save me about 50 scripts in my current project.

What's needed to make this REALLY powerful is a way to apply some rotation or some position modifier to one or more prims in a link-set.

e.g apply a rotation of 5º to all prim's rotation and position. Allowing a link-set to rotate around a point without a ton of scripts.

But yeah, this is looking cool, might not reduce scripts in many of my projects, but will reduce the number of link-messages I have to use for some to work.

*glee*

omg.

this is... lovely.

perhaps it's too greedy to ask for more, but as pointed out the built-in delay spoils things a little here... so one thing that could really help to make people switch from 200+ scripts in separate prims is ability to apply changes to number of prims at once... maybe something along lines of:

llSetLinkPrimitivesParams(string linkname, list rules )

... which would apply supplied list to each prim in the set that has name matching supplied 'linkname'? This way a builder could use prim names to internally divide an object into parts and then script could easily alter attributes of selected part with single call ... the alternative way to it pointed out in this thread

llSetLinkPrimitivesParams( list link_numbers, list rules )

... could do nicely, too o.O;

<pedant>missing specification of which face to apply the colour to</pedant>

But seriously, something like this would be really useful. If only there were some way to combine this with Joannah Cramer's suggestion, which would also be useful. Lex's is more general, but I can see the command list getting ludicrously long under some circumstances, when a list of the prims to apply the command to would work nicely.

In any case... yay!

Yayy!!!

Only one other thing to ask for.. llSetLinkText!

No, I'd much rather see llSet[Link]PrimitiveParams([PRIM_TEXT, "foo", <1,1,1>, 1.0]); which would kill two birds with one stone.

Any chance we could get a matching llGetLinkPrimitiveParams() call?

Wow - great!

I was about to ask the best way to keep child scripts quiet/low footprint. I only needed them for updating textures at startup/reset. This nicely does away with that.

(still wants "touch_xyz(vector hit_point, integer face)"

Excelent adition to LSL!!!!! I can wait to use it in the real grid!
That opens a lot of doors and simplify a lot my work. Finally wont be necesary to use lots of linked messages and the amount of scripts running should be reduced in complex objects resulting in less lag.
Thanks for this!

What I'd like to see is llSetLinkScriptState(link, name, state) so we can have scripts in prims to do whatever but only activate them when needed. Often they are only there to do something once in a while when something else happens, but there's no way to turn them off so they keep sucking sim resources even though they aren't doing anything.

You have too much faith in the dedication of programmers. Particularly ones who are not primarily programmers. Like the builders who make 200 prim attachments.

I mean, not only does this make the scripting much more complex, there are people who put separate scripts in the same prim in attachments to change the texture, color, and alpha. Seriously. The only way to get people to switch is to make the llSetLinkFoo() stuff *better* than the scripts.