The problem with resize scripts...

As I understand it, the problem with resize scripts is that they generally require an active but mostly idle slave script in each prim of the linkset, and that this is because there is no llGetLinkPrimitiveParams function available to let a script in another prim get the necessary information about a prim's size and position to use in an llSetLinkPrimitiveParams call.

Would it work if one used a self-deleting slave script in each prim that reported its base or starting size and position to a master script, which then chatted a hard-coded list declaration that could then be pasted into a resize script?

The resize script could then use this data to make llSetLinkPrimitiveParams calls that set absolute sizes and positions for the prims in the linkset. This would eliminate drift caused by accumulated rounding errors as the absolute sizes and positions for each resize event could be calculated from the base list each time. This would also make it simple to prevent scaling errors by checking that none of the calls would involve an attempt to make any of the prims larger than 10m x 10m x 10m, or smaller than 10mm x 10mm x 10mm.

So why aren't things done this way?

There is also the 0.2 second delay imposed by llSet(Link)PrimParams - the customer would have to wait 20 seconds per hundred prims, best case, every time they poked at the size.

What you suggest would indeed work but would still run into the delay.

It could be done that way, no doubt and it should be the object/clothe maker that should do it before selling the stuff.
How do you know that it isn't already done that way? I certainly have some items with data note cards in them

My statistically significant sample of three resizable items (hair, shoes and glasses) all have a script in each prim Also, everybody goes ballistic at the mere mention of a resize script: surely it's not possible that almost the entire population of SL are in a frenzied panic over what ammouts to pure BS?

The hair scripts can be deleted with a menu option (and it is moddable) but this isn't available for the glasses or the shoes, which also include a scripted colour change. Hmm; the glasses are no copy, and I do sometimes change the colours, so I guess those scripts have to stay, but the shoes are copyable but no mod. Is there a way to remove or deactivate scripts in no-mod objects?

Yeah, I'd forgotten about that, and I guess 20 seconds is beyond the level of acceptable performance for a resize. But this might still be useful for less primmy objects, so I guess it's something to go on my list of things to do when I haven't got anything better to do.

You can resize all prims in one operation without having a script in all of them: llSetLinkPrimitiveParams(LINK_SET,[PRIM_SIZE,<>,PRIM_POSITION, <>]);

For the last 6+ months, regions have been totally locking up when people TP into or out of them. This is widely thought to be caused by those people (the ones TPing in/out) having a silly number of scripts attached.

See also: http://jira.secondlife.com/browse/SVC-3895

It's not really that resize scripts are inherently evil, though I think poorly-written ones sorta are, but that they have such a huge impact on everybody else.

It's easy to see. Find any high-traffic region (look for clubs without lots of bots) and fly constantly around in circles - just hold the up & left keys down. When the sim stalls, client-side prediction takes over and you go flying off in a straight line. When the sim wakes back up, you snap back to where you were.

Or find a totally empty region and ask somebody that's heavy in scripts/prims to TP in & out while you fly in circles. You'll be surprised, I (almost) guarantee it.

I understand this is mainly due to the process involved in handing mono-complied scripts over from one sim to another: a single mono script takes a lot more time than many LSL ones because the 64K of data available to a mono script must also be reinterpreted into a script state, whereas an LSL script handover just involves copying 16K of data and picking up where it left off without any messing about.

That comment was a bit sarcastic; from what I've seen of the RA forum there is a distinct bandwagon-jumping tendency which applies to opinions on technical matters as much as to ones of fashion and taste. Mention mono script handovers and you'll get a blank stare; mention a single LSL resize script and the mob starts lighting up the torches.

actually, no not all those scripts need be running when they are not needed....

I outlined a design that would allow them all to be inactive when not being used.

preload all the prims with scripts that set a remote load prim and have them shut off. the root, a copy of the individual resize scripts sits in the root also turned off.

when the function is activated it uses remote load to send that script to each child prim and activate it (which replaces the scripts in place already). those can set a new pin (or not) and when they are done with their job they also switch themselves off.

Now that's a useful thing to know; I wasn't aware of that remote load thing - I'll try playing with it.

I wonder how many other (potentially) useful functions and facilities there are in LSL hidden away in that wiki. Maybe one day, when I'm really, really bored, I'll have to sit down a read an alphabetical list of them all

please note, I haven't tested the stability of pins across sim resets, sim crossing or such... though it does survive script not running, and script deletion.

@ Peter: http://wiki.secondlife.com/wiki/Category:LSL_Functions

@ Void: In my experience PINs are stable. I've never lost one without the script(s) actually changing it. That's "normal usage" though, I haven't actually tried to stress it. Being a prim property I think it's as safe as the colour or size of the prim and it seems to be, so far.

problem is we only know that it's a prim property by inference.... namely in that you can stop of remove the initiating script and it remains...

but as with the running not running state and it's current execution spot (which is normall preserved, even on inventory takes, but fails on sim crossing and sim resets, defaulting back to the unexectuted stage

Void if I understand your idea correctly in something like hair with 100+ children in it the result could be a scenario like the following:

One root prim with a master control script and an inactive (or couple of inactive) scripts. When the owner initiated an activity such as touching it or chatting the master script would (or could)

1. Set a PIN for all children
2. Remote load the appropriate script out of the root prim and set them running.
3. Initiate action in the children presumably through a link message.
4. When all actions complete send a command to all the children to stop the scripts and delete them all.
5. Return to original state with a minimal number of listens (like one?) in the master script and all the children empty (with whatever PIN was set still a property of each child).

I suppose you could even set it so that the children are preloaded with the script initially and on rez they start a timer waiting for the owner to initiate any action and the end of that time automatically stop the script and delete itself (or is that delete and then stop??).

That way every time someone rezzed the object they wouldn't have to wait for the item to load all the children and could make changes then it would clean itself up with the option of
making further changes farther down the line if they wished.

I'm a neophyte when it comes to LSL so I may be assuming a lot of impossibilities here.

Don't do anything. Since Void's last message Babbage has announced they're adding two new functions for this.

llGetLinkPrimitiveParams()
llSetLinkPrimitiveParamsNoDelay()

Wait for these instead of spending any time on a solution you'll have to throw away anyway.

The most recent hair (and one building!) with resize that I've seen only has one script in the root. I assume these use llSetLinkPrimitiveParams; there is indeed noticable delay, but since this is generally done in the context of getting dressed, it's insignificant.

.

Regarding prim drift: In general, avoid doing relative resizes, because, as was said, rounding error will accumulate.

The simplest way to do it is to record the relative "default" local position offset and size of child prims from the root, then use a scaling factor to set the position and size based on that default.

More or less:

on reset:
1. Obtain prim local positions/scales and store them.
2. Set scale to 1.0. (reference only)
3. Do a "default resize" at the default scale. (optional)

on resize:
1. Set local position to stored position * requested scale.
2. Set size to stored size * requested scale.

The major issue is how to get the local positions/scales from child prims. It can be solved one of several ways (not an exhaustive list):

1. Scripts in every prim (please don't compile to mono!).
2. llGetObjectDetails() can be used to get the position from the root, but scale would require at least a temporary script in every prim to obtain the scale.
3. Retrieve the default data from another source (notecard, for example; child prim names/descriptions via llGetLinkName or llGetObjectDetails(llGetLinkKey(link_number),[OBJECT_DESC])).

Then, the minor issue of setting the local positions/scales to the child prims:

1. Scripts in every prim using llSetPrimitiveParams (overkill).
2. Single root script servicing all child prims using llSetLinkPrimitiveParams.
3. Multiple root scripts servicing an equal share of all child prims using llSetLinkPrimitiveParams.

In the case of 100 prims, 20 seconds for a resize isn't really all that bad, if you only have to do it once. If you have to do it regularly, figure out an acceptable timeframe, and use the number of slave scripts in the root which will accomplish the task in that timeframe:

10 seconds = 2 scripts
5 seconds = 4 scripts
2 seconds = 10 scripts
1 second = 20 scripts

Anything faster will quickly approach negating the gains against scripts in every prim.

Also, as Argent said, in an upcoming version, llGetLinkPrimitiveParams() and llSetLinkPrimitiveParamsNoDelay() will pretty much solve these two issues; the only question is if one can wait for them or not. At the very least, plan for upgrades.

@Dante:
pretty close...minimally, it's two scripts A(master) and B(slave). B is preloaded into all prims to be changed, and along with A wherever it goes (assume root).
B Sets a New Pin when it's loaded, some default, then stops running after a timeout.
A detects user input, and loads new copies of B into all the children, which should report back that they are active, where A collects those msgs, and waits until all are ready, then sends commands to all the B's. when A sends out new copies of B it could also update the script pins via the start parameter (remote load replaces copies, so you're effectively waking non running scripts)

the whole method will be almost obsolete with the new functions (although there are other things it might be useful for, like multiprim particle displays)

@void

Ok, I got it, I was thinking about something along those lines instead of running a large for loop to run through all the prims in a linkset to implement changes to color and such. I don't mind the idea of using link messages for a few prims but not something like a fine chain.

I've never really paid attention to the server versioning and I see that Babbage was speculating (with lots of caveats) on 1.38 being the potential release version with the new functions. Do they implement releases 1 at a time or two at a time? If its going to be several months before they land then I'll just go ahead with this idea and implement an update when the time comes. At the least its good scripting practice for me.

I wouldn't expect the new functions before summer. so if you need this now, go for it =)

@Argent: Why would you have to throw it away just because new functions arrive? Void's solution would continue to work.

@Void: Interesting solution that I'd have never have thought of as usual.

@OP: To answer your question (which as far as I know, no one has), is because up to this point, there's never been any script limitations, and, no one accuses the typical LSL scripter of being particularly concerned with script efficiency. It's much easier to just dump 100 scripts into something to "make it work" and not care what the consequences are to the systems these scripts are running on. Since day 1 I've wondered why there seemed to be absolutely no limit to how many scripts a resident could run. A friend of mine (a coder as well) mentioned the same thing.

When they announced script limits coming, I wasn't at all surprised. The complete lack of coding standards along with the poorly constructed scripting language (which is now finally getting functions to allow scripters to improve efficiency in an easier way) has brought SL to the point where the sheer volume of poorly coded scripts running in world is starting to take it's toll.

In the end though, it will be a good thing. LL's not looking to clamp down on script usage so much as script abuse. Once implemented, 95 percent of users should not even be affected at all, and since shoppers will become more aware of the 'cost' of a particular script, this will force coders to write tight, efficient code, and come up with "Void-like" (yeah, I said it) solutions to problems rather than just 'solve' the problem with 100 more scripts. This combined with a wider range of link functions, as well as improved implementation of mono on the system as a whole will make SL a better place for everyone.

Another thing to consider is the eventual release of LLMedia. Soon, instead of static snapshots of web pages on a prim we'll be able to interact with web pages, click links, and interact with java and flash applications via the web. This will open up a whole new world of code execution on external web servers served through standard web pages that can be interacted with by clicking on a prim. The affect will be astounding. No longer will residents be tied to using scripts only, or scripts tied to external web services via scripts. Along with that, much of the load carried by in world scripts will shift to the web, expanding the computing capabilities of SL exponentially. Can't wait

Because you would *want to*.

I'm going to agree with argent on that... at least for this usage... it'll be preferable to replace it with the new functions ASAP (even if you just switch to a centrally located bunch of scripts that start and stop for reasons of speed)... it won't cease to work, but it won't be the most efficient option by a longshot.

also script pins present a possible vulnerability to items when they are left constantly in place, even if you update on every usage.

I have another paradigm, based on similar sized obects that could work similarly, based on my color changing script (it's on my user page and linked to library in the portal), which would only require one script per same sized prim (essentaily it would generalize all same sized prims), but that requires very specific construction.

for some things that can't either be set or written from a different prim those paradigms will still be useful, but (thankfully) those cases will be fewer with new function access making things much more efficient for the majority of cases.

note that there are tradeoffs, since remote load has a 3 second delay, which means a wait at start up, but near instant changes once that's done... extra "push" scripts can speed that, and they also can shut down.

we do know that idle scripts take script time on the VM, but we don't know if non-running scripts will be counted towards memory limits. (and there may yet be a way around that too).