Implications of having multiple copies of a mono script?

I'm writing the scripts for an item comprising about 30 prims that is to include the facility to resize the linkset by script.

In the past when I've written resizers based on the example at http://lslwiki.net/lslwiki/wakka.php?wakka=llSetScale I've copied the slave script from the root to all the child prims at the start of the procedure and deleted them at the end, leaving a copy in the root so that I can propagate them again if the item needs resizing in the future.

Do I need to bother with all this propagating and deleting, though? I ask because the wiki tells me that Am I right in thinking that this means it won't place any extra burden on the sim if I simply leave the scripts in place? None of the slave scripts have any listeners or timers or anything; they just sit there waiting for a link message.

That's how I have always understood it.

But it would also be possible to use the number of links in the linkset in a loop to create a list to feed to llSetLinkPrimitiveParams. One script in the root prim that will resize the whole linkset.

I might have a chance later in the day to cobble up an example of this.

but how will you get the scale of the links? as far as i can tell, you can only find the position and rotation of the link using llGetObjectDetails. the only way to get the size of an "object" other than itself is by using llGetAgentSize, and of course that only works for avatars

llSetScale works the same way as selecting a linkset in edit, holding ctrl/shift and dragging a white corner square to enlarge or make the linkset smaller, the whole linkset.

mmm, where'd you get that idea? any script i've used in the past it only works on the prim it's in, and i just read lslwiki.net and the secondlife wiki, both say the same thing

Nevermind Neither llSetPrimitiveParams or llSetLinkPrimitiveParams PRIM_SIZE works exactly like llSetScale. Actually I think the wiki is wrong in even referencing llSetScale in this regard. It would have been nice because you could have used this simple script to rescale everything:

float scale = .3;
default {
    state_entry() {
        llSetLinkPrimitiveParams( LINK_SET,[PRIM_SIZE, <1,1,1> * scale]);
    }
}

Linkset scaling by script will still have to scale each prim, no?
If so the script must know the size of each prim before starting and then it can't be done with 'llSetLinkPrimitiveParams' alone.

that's what i thought too. unless of course all the prims are the same scale, but then you still have to factor in moving them to keep the same relativity

I was referencing how scale works in edit mode and how llSetScale works for an individual prim if you call llSetScale(llGetScale() * scale); and how this would have worked if llSetLinkPrimitveParams PRIM_SIZE would have actually changed scale per percentage but it does not.

EDIT if you think about it, even llSetScale is really a misnomer. If it would have been up to me it would have been called llSetSize.

lol, right, or the setprimitiveparams call should have been PRIM_SCALE, i often find myself writing that instead of PRIM_SIZE

Idle scripts would still eat a little sim time, the scheduler still has to pop in and check if there are any events to feed them. Upcoming we are also going to have the script memory limits that will make even the variable space a more valuable commodity. So there is still some use in making unused scripts go away, at least if the resizer isn't likely to be needed often.

Partially right - the scripts will still each take up a bit of memory. The sim has to remember that they're there, what state they're in, values for global variables and stuff like that.

It's just the code space that's shared.

Also, though it would be very smart of LL to create a repository of byte-code, using the compiled assembly to check for duplicates with other scripts and using a quick hash to make the lookup and comparison process inexpensive, it is unlikely they are doing that. More likely you have to copy the script after it is compiled, and ANY recompilation (even if it results in the exact same byte code) will not take advantage of the code sharing. But who knows. Maybe we could get a Linden's comment on it at some point.

They did tell us about that one. Code sharing is based on the asset ID, so even an identical recompile will break the sharing.

Every script would be in a potentially different state, so LL would have to serialize each one on Region Crossing. Sharing bytecode would help with memory on the sim, But you would still have all the associated issues with too many scripts on region crossing, and still be using a lot of resources otherwise.

You're doing it the best way, remove them when not in use. (And you should just ask me, you should know by now I know best )

I would love it if we could at least do it with notecards. Imagine the applications! Updating all your products from your own notecard for configuration? Such as telling the owners of your product that there is a new version out, instead of polling an external website... basically utilizing the power of Linden Labs' own network of servers.

Thanks all. I thought it couldn't be a good idea to leave the scripts in, but -- other than it looked untidy -- I didn't quite understand why. Now I do.

I'm not sure what you're getting at here.

Separate instances of a script have to have individual states (memory, active state, permissions granted, etc.) That's not in question here.

Instances of the same source can share code space. Currently, with Mono, they do, but only if the asset ID matches. Hewee's point that they could use a bytecode hash is worthy of consideration, but applies only to the bytecode -- and presumably, if bytecodes match, the same asset ID would be used, so this process would occur only during recompilation, not on code asset loading. Therefore, there would be no new issues on sim crossing.

Hewee's suggestion would also mean that you wouldn't get a new asset ID if you recompile a script and it compiles to the same byte code, such as if you recompiled it without changing it, or if you changed only whitespace or comments. It could even happen in rare cases when you make code changes that happen to compile to the same byte code. No doubt some geek somewhere would find an amusing application of this tiny nit.

I'm just answering the original question, I think she's interested in how it works now, not how it could be better. I didn't say there were any new issues, I only said it would be subject to existing issues.

Innula is a friend of mine, so I was just giving her a little hard time to boot.

Aha, I see what you're saying now.

:0 does that bytecode sharing work with an 'updater box' and a set of vendors? curious...

i was just experimenting with procedure - i find that you can't recompile a script mono in inventory (at least, i don't see the checkboxes, or via tools menu), so i presume it's
1) save your scripts mono, inworld/in a prim
2) drag these scripts to inventory (to a special folder most helpful)
3) drag these scripts into prims (back into orig prim, if orig scripts deleted first?)

is this how it's supposed to work?

p.s. :0 oh no, nevermind, i think i understand now that it's just for the one 'exact duplicate' script, if dragged and renamed... zat right? :\ well anycase that might help with something anyways.

Yeah, you can drag them around between avatars and objects, and as long as there are no recompiles/re-saves, the executables lurking within should have the same ID and be eligible to share code.

:0 kewl, thanks! i think i grok it now then... i'll give it a try, sounds nifty - good trick if it helps!

This is all good discussion - but how many scripts do you have running concurrently on a single sim - enough to make a difference to the sim? I have only one or two scripts that justify or really benefit from mono (most obvious of which is a box vendor script that may run up to 500-1000 copies on a sim).

My point is don't get over-worried about mono. There's benefits to mono for a number of very particular circumstances, but in general, LSO was/is equally as good for many, even most, in-world apps.

/esc