Autumn, I assume you're calculating 51 seconds from the 0.2 second delay per prim you get with llSetLinkPrimitiveParams. But that wouldn't work for a resizer because you need to read the position and size of each prim.

I suspect -- and I will be happy to be proved wrong -- that stages 1 to 8 are about using llSetRemoteScriptAccessPin so that the end user can send running, self-deleting, scripts through the linkset with llRemoteLoadScriptPin when they're actually trying to resize it.

Which is all very well, but means it would take end users 3 seconds per prim, or 12 minutes, 45 seconds to resize a 255 prim object.

The best way to do this, to my mind, if you've got to use resizer scripts, is to supply the objects to customers with a script in each prim that you can delete when you've finished (or that deletes itself after the object's been rezzed for an hour or so).

Customers can always rez a new copy of the object if they to resize it again, or, if it's no copy, you can leave a resizer in the root prim and have them propagate using the steps outlined in the article.

The other real issue with resizer scripts is that people who don't know any better compile the damn things in mono, thus causing the problems outlined in jira issues SVC-4196 and SVC-3895 (basically freezing the whole sim for 30 seconds or so).

ETA -- on second thoughts, I think I can see another way to do it, at least in theory, if you store everything in a strided list and do a lot of calculations each time you resize the linkset. That would, I think, mean you could use llSetLinkPrimitiveParams, but it's a horribly complicated way to do it.

Neil's unwillingness to publish his code does raise a few questions.

It would be rather poetic justice, I suppose, if it transpires that all the people who've been using his viewer to rip content find they've also been sending him their passwords and log-in details...

Stroker has now updated his post on SL Universe to apologize to Damen and say that he's come to the conclusion Damen was framed. See http://www.sluniverse.com/php/vb/general-sl-discu...
Might be an idea to update the main story here?

Can't offhand find the exact reference, but I'd thought Stroker said somewhere over in the SLUniverse thread that the items were full perms in inventory but reverted to their intended permissions when rezzed.

Do you say that some of the items have actually had their perms changed permanently?

As I understand it, this makes a very big difference in figuring out how the exploit was done, so it can be prevented in future.

I only know Damen from the scripting groups, but I can't believe someone who's put so much in the way of resources and his time and expertise into helping people in SL would be involved in something like this.