New LSL Commands in 1.13.4

Oooo... that might have a bit more internal overhead, but it would be SO much easier for people to use that I think I'm going to say your suggestion beats my suggestion.

Either of them would do, though.

Remember who you are talking to here. (Wearer of Daryth Kennedy's 600-800 prim quadraped Dragon avatars.. )

I think as advertised, it is better than the script-in-every-prim. We're already looking at ways to incorporate it most effectively in Daryth's avs so we can get rid of 80-90% of the scripts and not lose much functionality. Getting rid of the delay would be the best thing; I can already deal with the link selection issues pretty well.

Why LL continues to cling to script delays I will never know. Everyone knows how to get around them, and the workarounds end up causing more problems (lag, poor performance, etc) than the issues they are supposed to solve.

You do realize that takes up a good half of a sim's nominal script processing power, right?

Erm. Yep! The scripts in the latest gen are actually very lean as it is (only one listen per attachment; rest are controlled via link messages), but there are a lot of them.

Hence why we are on a crusade to further reduce their impact on sims.

I suspect that you're already using less CPU per script than the worst offenders, and probably less CPU total even if you have more scripts.

So even if you drop completely off the radar, I'd still like to see Joannah's suggestion implemented. It would make it actually *easier* to do things the right way than to have a script in every prim.

I agree, but if we're going to do it the "right way", ultimately, we need customizable avatar meshes/skeletons.

EEeeeeee!!!! I'm going to have to redo lots of my scripts because of this. But I'm happy with it!

I'm now stopping an project until 1.13.4 is released. Hurry up, please.

I take a step out of Beta for one week and this happens!!!!

Woooooohoooooooo! *head explodes*

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

Wondering out loud.. I am guessing these do not happen in parallel, so if I
am updating 20 prims, I get a delay of 4 seconds??

Seems like this will lead some hacks.. linked messages to helper scripts
that take on 5 prims apiece ...

further thought.. freeing up some scripts from individual prims will lead to storing
more state info in root/controller scripts. Give us 64k, for crying out loud!

(feels silly to be asking for 64k in 2007...)

Precisely why we're discussing ways to specify multiple prims at once.

Nope get an error "Texture not copiable". good thinking Lex.

64 kb * 5000 scripts in a sim * 4 sims per machine... ~1.2 gb of memory purely to store the scripts, nevermind everything else the server has to handle ^^

Ya, I know.. it's very useful - just would be good to hear from a Linden why
it would be different from a linked message.

Next up.. quicktime cut scenes while the object behind it is busy getting updated

Only if you send a LINK_SET or LINK_ALL_OTHERS; or cross a sim boarder (or if every script has a listen... or a timer...) .

Have you quantified that?

I've thought that a lot of people are taking the "active scripts" numbers too seriously, and that a script just waiting on link messages shouldn't be using that much time, but I haven't tested it so I've been mostly holding my muzzle shut. If you've got some figures that'd be really nice.

Well, I guess that's pretty much what I expected, although it would have been nice if it actually did attempt to move the texture over to the child prim or something. Thanks for testing this for me, Gearsawe!

No, actually, what I meant was that "dormant" active scripts still take up a lot of Script Time. Here's a link to my research:

/54/8f/105133/1.html

1) it's not an additional 1.2 gb of memory from what we have now

2) if you are running far fewer scripts, because you dont need to split up amongst multiple 16k segments, that's a win.. overall script memory footprint on a Sim could actually go down...

3) less context switching

!

it's been a long time coming milo! i never really understand why llsetlinkcolor didn't have this sister function in the first place.

many thanks. =)

*Agrees on this one*
For rotating parts of a linked set around a point (but not the whole linked-set) and things like that, this would be EXTREMELY useful with a corresponding llGetLinkPrimitiveParams() call. That way I can get the params of my objects, process through them, then apply all the changes at once. e.g:
llGetLinkPrimitiveParams(list links, list params) could return a list containing the values for each parameter you specified, with each 'row' being for a single link you specified in the links list.

1) Not every script *needs* 64k. Virtual memory allocation techniques can be used to control how much memory is really used by scripts. Allocating in the normal 4k page size would probably give enough resolution to at least halve that figure, on average.

2) 1.2GB on *server* machines these days is a drop in the bucket. 8, 16, and even 32GB of memory on servers is not entirely uncommon.

That depends. iirc the class 4 machines have 2gb RAM, which equates to around 512mb for each sim, minus overhead for all the stuff the simulator needs besides scripts.
So with 1.2gb of active scripts (that's where I'm assuming the figure of 5000 scripts comes from) then they need to be kept in RAM as much as possible in order for them to be any decent amount responsive, if they're constantly being fetched from the hard-drive then it just becomes impossibly slow.
IMO they should of course have more RAM really, as 512mb is barely anything when it comes down to it, especially for fairly fast machines as there simply isn't enough data in RAM to process and the result is that the processor spends far too much of its time idle.
I did post back on the old Linden answers forum but never got a response on any potential for a RAM upgrade in future. As really the class 3 and class 4 machines don't have that much difference, except that I think the class 3's had less RAM per core, if upgraded then both would perform far better. And even ECC (standard for servers) ram isn't that expensive these days.

If i understand it right the forthcoming version of LSL based on Mono has some ability to allocate/free memory for scripts in smaller chunks (and dynamically adjust it on the fly) but that's still yet to come, and in the meantime the current version allocates fixed space per script no ifs and buts about it.



Like pointed out, LL's class 4 servers are equipped with 2 gb of memory. Class 5 doubles that, for 4 gb per server.

My point was really that it's not some outrageous amount of space that the servers cannot currently handle, but rather to address the "what is 64 kb nowadays" sentiment. A single instance of 64 kb is indeed trivial and not worth fussing about, but this approach completely overlooks just how many instances of such small chunks the server actually has to handle ^^

As far as I knew, the request for 64kb was a "wishlist"-type request. I didn't read it as a "now, just do this next using only what you got right this second". ("asking for 64kb in 2007", I believe the OP said).

I am WELL AWARE of how the current version allocates space for scripts, thanks. That DOES NOT mean it can't be changed. It's software, remember? Maybe it is better to wait until we have Mono, but maybe it CAN be changed to be more efficient in terms of memory-management.



Expandable to how much? How soon?



I don't think it was a matter of overlooking anything. It was a simple "would be nice"-type request. Yeah, maybe it couldn't be done by the next update, but there's nothing saying it can't be looked at (and maybe it is; who knows?) in the near-term to see if it would be possible to do.

One of the many issues with SL is that you have to write hugely inefficient scripts in multiple pieces to get something remotely resembling a very efficient script which would fit in maybe double the space. So, which is better: A 32kb script limit, or everybody using up 64kb in 4 16kb scripts to approximate what they could get done with one in 32kb?

Personally, I think that sims should be coded to have a fixed max # of scripts, with the sim owner(s) scripts having priority over anyone else's. Then you can raise the memory limit, and lower the max scripts active, and many people would be happy. yeah, some folks with their 500-script gadgets or avs would hate it, but tough (and that comes from a 700-prim/script Dragon av owner here). I would MUCH rather have a less laggy / more stable simulation which is telling people "no you can't run anymore scripts, sorry".

Point is, there are tons of optimizations they COULD do to ease some of the restrictions on script size and execution, all without breaking very much existing functionality (if any at all). However, they are putting all their eggs in one basket, Mono, and have been for a couple years now. hopefully Mono will be the shiznit everyone thinks it is (I have my doubts, of course), but we can hope for some relief from the problems in between now and then.

I mean, we got llSetLinkPrimitiveParams, didn't we? That was a huge pipe dream of mine.