Script limits per parcel, and per total attachments, may be in the pipeline

After reading that I do not know if we should cheer or fear.

The only scripted objects i wear are:

- Huddles Deluxe
- Mystitool
- RLV Relay

I suppose this is a great thing to stop those 'edge' users as Babbage calls them...the people that use 1000+ scripts on a 512m2 parcel.

This should definitely help reduce lag across the Mainland Grid.

Perhaps this will be the end of resize scripts.
Which they could have ended AGES ago if the'd given us llGetLink______

Has anyone seen or heard any further information of when we will be able to get our scripts sizes. Babbage mentioned it several times but never put a timeline on it.

I heard about this as well. My question is. How do I remove the scripts that have been
placed in jewelry I wear? I removed them from content and checked each individual
link. Still when I log in I get a message that the scripts are running. Sorry I am clueless about how scripts work so forgive me if this is a stupid question. Is there a script that can be dropped into the necklace that removes them and then removes itself?
Any Help would be greatly appreciated.

There sure is, contact me in world and I will give it to you

Thanks Dora I sent you and im )

From http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2008_12_03


...and then later on in that:



...keeping in mind that "next year" is now "this year".

So, the project is blocked on the viewer support for now, and the timeline will sort of depend on whether or not the stats panel makes it into 1.23 and works.

These are some of the worst ideas I've ever heard of. It's like going back to the old days of having to buy CPU time on mainframes. I'd like to go forward thank you, not backward. How much memory will I have for my script? 64kB? No. It'll depend on how much land you have. Okay, so should I even bother developing scripts for people? Nah, not unless you're a rich landowner yourself. Ah, okay. Gotcha. Bye bye SL.

As for the first change, I'm guessing it means we'll have to be going back to old hacks like:

myList = (myList=[])+myList+value;

Thanks LL. Always on the bleeding edge of durfing your users. :-/

EDITOOOOPS Sorry Heewee, I have been bouncing around the different scripting changes threads and you were not the one working on a game when I hit reply. That was Darkness Anubis in the other thread.

First off, that hack will not help any with MONO. But I have an idea you already know that

I see this as a very good thing and I would definitely encourage you to keep working on that game of yours. In our present system one person can walk into the simulator and not only nerf that games of yours but affect the other 3 sims on the same server. Just as in the MONO rollout, this isn't going to be some mindless and nameless Linden setting policy. Babbage, Soft, Vector and the others would be involved in the change. They all have a track history of listening. This also isn't going to happen overnight but would be in Aditi and evolve over several months time and will give everyone interested a chance to test, test, test and report everything to Jira.

The ability to actually see the impact our scripts has on the simulator has been my number one request since I joined SL. I expect there will be some changes and some scripts and or systems we have come to use might be borked for some of the user base. But even for the majority of them it will probably just be a learning curve. Detach the 200 script hair and multi-gadgets and turn off the bling scripts and whole sim radars and people should be able to play your game just fine. Attach or run what you need but only when you need it.

The era of one person being able to screw everyone else in the neighborhood is passing and I for one am not sorry to see it go. We will finally have accountability in what we are creating and selling to the public and there will be new opportunities for the best scripters. You Heewee, of all people should be able to create a texture organizer for example that would work with the new limitations. EDIT: This will finally shine the spotlight on the smart/good scripters that do care about resources and can script better then the majority here. It's about time the garbage scripts disappeared. This is opportunity for the best not the end.

It would not surprise me if at some point in the foreseeable future, LL also decides to enact some kind of texture limit. Would be a nice change if that was enacted and they allowed the return of 1024x1024 textures for when they are absolutely necessary. The way it is now, there is no stimulus for anyone to use less then 512x512 textures, even in cases where a 64x64 would work just fine.

seems they're looking at absolute memory requirements only, and not script time used... which means even with the limits in place it's still a possible scenario for a set of scripts to saturate the cpu with calls and lower performance in general.

I'd also be interested in exactly how they plan to implement hard ceilings on a per avatar basis considering the variability of the number of av's on a sim... by parcel is easy, as the total sq/m never changes.. but av's come and go.

ETA: I'm guessing they'll tie it to the sim av limit, and possible the parcel occupied, but I see that being a huge problem for the portability they want to achieve (as scripts request memory at run [by babagges example], you'd go to a big empty parcel, and load up, then enter the small crowded one... do they stay running, do they turn off, what?) and if it is set based on the hard ceiling of a maximum capacity sim, what of all that extra that's available in consistently low populous sims?

That's not supposed to be possible since they started throttling scripts.

It's not an "only" thing, it's just that memory is first on the hit list. After they can get sim hosts to stop dipping into their swapfiles (especially nasty for the openspace/homestead sims that have the same total RAM as full-SIM servers AFAIK), they can start worrying about other issues.

Wow. How do you know that?

The Class 5 spec was 4 GB, and that's about as good as you get in a 32-bit world :/

A "soft" kind of semi-reference on that:

https://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2008_11_12#chat52

Until they iron the bugs out of the 64 bit world that's all your getting. It's tough to get rid of the bugs though when they have the technology, they really are better, stronger, faster.

Who bought the six million dollar can of bug spray?

It wont' help currently, but if you read the log, you'll see why. Only the memory actually assigned after the execution of a statement is currently counted toward the memory limit. If I'm reading those statements correctly, that is going to change. Which means a temporary list created during a concatenation operation may now hit the limit even when the final assigned memory does not. I'm not sure if the old hack will help that or not. Maybe it will, in which case we at least have some recourse. Maybe it won't, in which case we're worse off than before Mono.

This just in: starting in late 2009, Linden Lab is going to be limiting the number of posts you can make to the Second Life forums based on the amount of land you own in-world. You will be able to make one post per month for each prim your total parcels will hold, and any time another resident replies to a thread you start, they will be using your allotment. Happy posting SLers!

Okay. Not really (at least not that I know of). But that's the kind of computer resource sharing it feels like we're heading into. Just like old CPU cycle accounting, as I mentioned above.

They need to implement some of the JIRA suggestions that will let people reduce total script usage For example llGetLinkPrimitiveParams().

The big server upgrade we recently went to upgraded all the servers to 64-bit Linux. That means they can give the servers more than 4G of RAM, and even if the sim software is 32-bit they can reduce the impact of server memory on other sims on the server.

yeah I caught that to, and it's gonna be hard to avoid hitting that wall unless we get some serious improvements on the free memory tests. not so much because it's hard to hard code a limit, but because mono scripts tend to allow bigger and more complex designs with multiple possibilities for hitting that wall.

it'll be interesting to see how they deal with states too, since it seems like in mono only the current state is in memory (although that may be a partial misconception on my part).

I'd also like to see llSetLinkScriptState or some variation, it'd help with scripts that function better in resident prims (sometimes SetLinkPrimitiveParams is just overkill, or doesn't cover the setting you need. a more complete set of remote functions would help, but I can think of at least one (bad) example that would still be best formed as scripted child prims (expandable, rezzable, linked memory, I did say it was bad)

I was actually thinking of linking newly rezzed 'expansions' and then linking them in to take advantage of link messaging, though I could see your idea working similarly (or being abused similarly). although I see my idea having potentailly more storage. on the plus side your solution avoids smacking into the new script memory limits, whereas mine rushes towards it =) on the downside, mine can be implemented now, just painfully. (technically it was only part my idea from hashing out extensible memory schemes here)

voted

Well it should be no problem for all you rich scriptwriters. Can I have all your stuff?

ya know, if I ever leave SL I'm going to make a huge post about it.... and give someone a coronary by actually giving away all my crap to the first person to ask =P