Update on Simulator Lag
Friday, December 15th, 2006 at 11:24 AM by: donlindenI wanted to let everyone know that we are actively looking into simulator performance issues. I have been digging into the code and looking at statistics over the past couple months, and I assure you that we are taking sim performance problems seriously.
Last week we released a change to the simulators which reduced the number of crashes and, indirectly, some simulator performance problems. This change still did not address the increase in lag over time problem.
Today, we will be rolling out another change which we hope to increase simulator performance for hosts with simulators running for long periods of time. It looks as though we had a memory leak, which would cause performance issues over time. We will be monitoring the effects of this change over the next few weeks.
There are still other changes I plan to make to improve performance over the next couple of months. Specifically, we may need to rethink how we handle temp on rez objects, and near-unlimited number of scripts on objects. We will of course hold further discussions about this before we implement any changes.
December 15th, 2006 at 11:34 AM
I know you are trying very hard / keep up the good work / happy holidays
December 15th, 2006 at 11:45 AM
There are 2 major reasons in my experience for lots of scripts in objects:
1. 16K memory limit, exacerbated by the extremely inefficient implementation of lists.
2. Script delays on llSetPos, etc. Chaining rules on llSetPrimitiveParams is good, but doesn’t help for things like physical animations.
These also clearly don’t limit sim load since they are so easy to code around, but are a major PITA. The solutions are obvious.
Beyond that, the inability to change script states in linked objects and remote objects is a major issue. I turn scripts on and off as needed in a single prim, but can’t on linked, much less remote prims. Lots of scripts are only run occasionally, but need to be there to add behaviour to objects. The 3 sec delay on llRemoteLoadScriptPin makes that completely impractical for many purposes.
Finally, the pretty much complete lack of any tools to measure sim load caused by individual objects and scripts makes good coding practices a matter of folklore. Many scripters would like to write efficient code, but it’s tough to do when it can’t be readily measured.
I know the temptation is to just remove functionality, but SL is based on rich content creation IMHO.
December 15th, 2006 at 12:01 PM
“Finally, the pretty much complete lack of any tools to measure sim load caused by individual objects and scripts makes good coding practices a matter of folklore. Many scripters would like to write efficient code, but it’s tough to do when it can’t be readily measured.”
Amen to that!
December 15th, 2006 at 12:13 PM
I understand that it’s useful for things like bullets, fireworks, etc. However the temp on rez feature, as abused to load a 512m parcel with a couple thousand prims worth of deluxe lifestyle, caused a lot of lag near me. Some neighbors were running a HUGE freebie warehouse/porn shop, with temp on rez devices constantly refreshing their site at way over the paltry limits a 512m plot has.
Is there a way to detect and DELETE any prim that is running a temp on rez script continuously?
December 15th, 2006 at 12:16 PM
Thanks! This is great to hear. As a new (but already committed to the tune of $25 land tier!) resident, I don’t have any history to compare performance to, but I’m still glad you’re looking into sim capacity, in light of the other 999,999 people who signed up along with me in the last two months.
December 15th, 2006 at 12:27 PM
Keep your chin up Don. Working with sim code must be like controlling space around a busy interstellar port. My orchard trees drop temp on rez fruit in Slate. Feel free to experiment with settings there. Just please blue us a dialog when you’re gonna IPL.
December 15th, 2006 at 12:39 PM
“Finally, the pretty much complete lack of any tools to measure sim load caused by individual objects and scripts makes good coding practices a matter of folklore. Many scripters would like to write efficient code, but it’s tough to do when it can’t be readily measured.”
YES!
A way to pinpoint problems would go a huge way toward letting us regulate our resource usage.
December 15th, 2006 at 12:41 PM
The overall performance of SL is just great at the moment, aside from database delay issues. Please, pretty please DON’T change anything else in an attempt to further increase performance, it will likely ruin other important functions. I can live with a little lag now and then, but I can’t live with a reduction of features and graphics quality.
The overall texture display is borked; I can’t walk around in a mall and quickly scan all displays around me for the product I’m looking for, since most textures stay blurry now and only load when I “zoom” onto the object. After the last two updates, the avatar mesh seems to have changed too; avatars at a (closer) distance look very low-polygon now, making it hard to take photos / screenshots in an acceptable quality at high resolutions. Rez delays, sometimes causing an object to vanish from the user’s inventory but never turning up inworld. Reduced search functionality. All caused by the attempts to increase performance and reduce database load.
I don’t care if I get 18 or only 14 fps. I don’t mind walking on a spot for a minute, in a crowded place. I also don’t mind having to relog 1 or 2 times each day. What I do care about though is a decreased optical quality on a platform that never had contemporary 3D graphics to start with. A mainland sim with an overcrowded club will be slow and laggy; if the only solution for this problem is to reduce features and display quality for everyone, please just don’t change things. Mainland sims aren’t designed for large crowds, period. If people use the mainland as cheap housing space and pay for islands if they need a high performance and lots of traffic, everything works just fine. Why not implement a traffic restriction based on parcel size instead?
December 15th, 2006 at 12:43 PM
“I don’t care if I get 18 or only 14 fps.”
Consider yourself lucky if you are seeing those. As for overall performance of SL being great…. uh… No.
December 15th, 2006 at 12:47 PM
For many purposes, temp-on-rez is really used for visuals, they don’t need to interact with the world, but particles aren’t complex enough.
How about forcing temp-on-rez objects to be phantom? I would think that would greatly limit sim lag caused by these objects, but would allow complex objects to be displayed in things like vendors.
However, there is another use for temp-on-rez, object collision boundary detection. If volume detect were fixed so it could detect non-physical objects, or scanners were changed to detect object collision boundaries, not just centers, that would eliminate this need.
December 15th, 2006 at 12:49 PM
Why not dynamicly change the texture/prim detail level based on server loading? That way a havilly used server will self-optimize to a low-prim/blurry texture to reduce it’s load ONLY when there are a lot of people or scripts around. Places that have only one rezi in the entire sim will look visually stunning.
December 15th, 2006 at 1:13 PM
I too would like to have statistics available to me that shows *my* impact on sim performance. If one of my scripts is causing excessive I certainly want to know about it. If I accidentally use a bunch of large textures within an object of linked prims I’d like to know that too. Same for attachments and animation overrides if these are impacting others it’d be useful information. At events the host is always saying we should disable these features to help other’s enjoy their experience but sometimes even the most innocent looking items could be causing the most lag.
Would it be possible to have mini-sims that developers/builders could temporarily rent from the Linden’s that contain nothing (to get a baseline), then we place our build/script/avatar into it and see what the statistics are showing with our items in that mini-sim in order to measure impact?
December 15th, 2006 at 1:38 PM
‘performance issues over time’ Don?
I think not - try ‘performance issues against number of accounts logged on’. That might be more fruitful - unless of course looking into that is an offical no-no?
December 15th, 2006 at 1:44 PM
>> I don’t care if I get 18 or only 14 fps.
>Consider yourself lucky if you are seeing those. As for overall performance of SL being great…. uh… No.
Sorry, speak for yourself. I have 30+ fps with a fair graphics card. SL uses up to 750MB of RAM which I think is great (this means if you have RAM like that, less disk swapping is done). Overall performance is fair to good. I must agree with Ishtara Rothschild: “since most textures stay blurry now and only load when I ‘zoom’ onto the object”. I have these experiences too. I have a prim-rich parcel with hi-res textures where me and my group have our peaceful homes. When I login, I need to look around for at least 2-3 minutes before all textures have loaded. Since I have a 20mbps/s connection, I must assume the delays are either server- or bandwidth-related. I cannot seem to get more than 600-700 kbps… Perhaps more streams would be preferable (downloading the client on the webpage is done by one stream (200KB/s); while using a dl accelerator (8 streams) I get 1.5MB/s).
The overall joy/experience I get is increasingly positive. Higher framerates, less lag (some sims are ‘laggier’ than others) and less crashes. Lindens: keep up the good work; you’re getting there!
Roger Gaspara
December 15th, 2006 at 2:11 PM
Hasn’t there already been some work on limiting temp-on-rez so that someone could make use of it but not be able to create the couple thousand temp prims that people are commenting about? There was an equation a while back, something like a 512 could go 512 over their prim limit with temp-on-rez prims but the rest would expire immediately or something?
December 15th, 2006 at 2:18 PM
One of the reasons that so many scripts is bad is that each idle script takes up 0.003ms of script time. It may not sound like much, but that means 6666 scripts is 20ms, even if all of them are Hello, Avatar sitting idle.
I know some combat systems have several hundred scripts in them. It adds up fast.
If there is any way the script scheduler could be improved to use less time for idle scripts, that would be a big help for reducing script load and overall scheduler contention.
December 15th, 2006 at 2:18 PM
FYI - While the previous update did break a lot of stuff, some still not back, for me anyway, the dropped packets issue and low fps seemed to get fixed. I currently see 20+fps with it never dropping below about 18 expect for very brief periods. Pie for all who worked on that.
December 15th, 2006 at 2:43 PM
Seems that the island owners have a way to seeing what Scripts or Objects are creating the largest amount of lag on their SIM. Would be nice to have this feature on the Mainland and in smaller parcels as well. Could help owners track down the LAGGIEST scripts in their objects and tighten the code.
Keep up the good work this update has gone much smoother than others in the past.
December 15th, 2006 at 2:47 PM
i am very impressed with the “hands on the switch” coding practises of you and/or your team. your extraordinary ability and adherence in developing this delicious medium for self expression. sex. (ooops)
any and all faults i hear being expressed here seem petty. from a users point of view, i appreciate your watching over our happy homes.
we are your children
December 15th, 2006 at 3:02 PM
I reside on a new island and there are times when lag hits us too, the problem seems to be the bandwidth and also the connection. I run SL on a 3.5GHZ processor with only 128 VidRam and 512 Ram. There are times when I move fluidly through the world and things res perfectly with no delays.
But I have noticed lately when the logins reach about 10-15 thousand users the bandwith is reduced greatly and lag ensues. I know it takes money to ingrease the bandwidth and also to push data. But in time I think we will be fine.
I’m not leaving SL because of lag, this is my home and I will deal with it for the moment. I have an island now that at times is perfect. Even the new islands experience lag but it is not simulator lag I am afraid. I too agree that the improvements are great but the bandwidth issues need to looked at harder. Phillip has even spoken of these issues but related them back to financial needs as well.
I have been running a wireless connection at 54Mbs and no problems, till something gets fixed. I think we have to understand the complexity of the code and realize that when one thing is fixed it can affect another in a way not realized by the programer till it happens. Its our reporting that really makes the diff. Thanks on a great job and I personally await any further fixes.
.
December 15th, 2006 at 3:08 PM
A simple improvement would be if llSetPrimitiveParams can change other prims than only the one the script is in. Now you often see delegates talking to scripts only responsible to change the color or transparency or other simple property.
Other solutions would be limit the number of scripts owned by the same person can run in one sim (of course this limit should be higher for sim/plot owner). Side effect would be that it gets a lot harder to make grey goo.
Of course better would be increase the efficiency of script handling, a few thousand scripts most of them being idle or listening shouldn’t be a burden at al for a modern server.
- Zhe
December 15th, 2006 at 3:11 PM
I really want to know about when you raised SIM Prices….where has that money gone? The lag is so bad, it appaals me. When I logged on last night, it was about 10,000 less than today.. 10k new members in 24 is NOTHING to be proud of. This lag is being caused because so many “one timers” come in. Ever thought of spending that extra 100$ you get from SIMs on something useful, like servers or more Liasons? Seems to me all this lag is being caused by greed. Remember the saying…Qualtity NOT quanity
December 15th, 2006 at 3:13 PM
Zhe, there is setlinkalpha and setlinkcolor already, though it would be nice to be able to change their texture and such from primativeparams.
More people need to learn how to use the existing commands to modify prims other than the root prim (gun holsters etc).
December 15th, 2006 at 3:13 PM
Ahzzmandius Werribee: textures have little to no impact on sim load, the only thing the sim knows about a texture is its UUID.
December 15th, 2006 at 3:50 PM
Thanks a ton for the update! I’ve noticed the time dilation / sim fps is still there, but not as bad as it’s been for the past few weeks. It seems we’re headed back in the right direction; thanks for the hard work.
December 15th, 2006 at 4:00 PM
I would be more interested in knowing why in the last few weeks the sim stats have gone from being relatively stable to a pretty constant state of flux. ie…the sim fps and time dilation used to hold pretty steady at 45fps and 0.99 respectively in almost all the sims I visited,(yes, even those with a lot of avi’s in them), whereas now they both fluctuate wildly…often going into the teens in fps…with the corresponding dip in time dilation. This is when I see the lag that is not cleary being caused by the database load and bandwidth. Those I understand…it’s the fact that the sims now seem to have a floating fps as opposed to the old 45fps apiece that I can’t seem to find any information about. (And yes, I do understand the difference between my pc’s fps and the sim fps stats, and no, this is not just related to my home sim, but virtually every sim I visit. Take a look for yourself…pull up the stats and watch them for a minute or two.)
December 15th, 2006 at 4:03 PM
….and I agree with FlipperPA..they have improved a bit in the last week or so, and if this is what you have been working on, great….keep it up…^_^
December 15th, 2006 at 4:12 PM
Sim performance is a global responsibility. Not only for the Lindens, but Residents & Creators of content. (and yes, that goes for me too.) While I applaud the efforts of the Dev team, it’s half the picture. Many residents (even ones like me, just starting to learn this voodoo) do not yet understand how they impact the performance of the world with thier creations–and that’s not completely our fault.
Currently, we have no benchmark tools to tell us that our script is laggy on an individual script/object level, or what the individual client/server taxing is. We have few trustworthy voices telling us what the best/better practices are, and even hostility & noise when we ask other residents.
Often, the advice we get (if we get any at all) is not to have the object/script (yeah, right…) or advice that conflicts with what we’ve been told before.
THere are some systemic bottlenecks in lsl, but imho those pale in comparison to a sim-full of not-so-well constructed code by us residents as we learn to get better. And we WANT to be better–it’s just damn hard when we have to make a semi-uneducated guess in the Stats window’s fluctuating numbers.
Having a tool to tell us how our script is performing would help this frustrating issue greatly, but my sense of it is that without education in “Lag 101, Lag 105 & Clent/Server Load Negotiation 201″, even this will not make the dent in lag Worldwide it might otherwise.
Textures are another thing: How much ACTUAL mem space am I inflicting upon others when I build? I cant really tell with the window right now.
Lindens, 4 things:
1) a Script Speedometer Tool of some fashion. The real Coders in here have a better
idea on specifics for this than I. I just want to be able to understand it later.
2) a Texture Meter that I can read without being a computer myself.
3) an updated wiki containing “best practices” and more code examples for non-ubercoders.
Right now the wiki is a little coder-centric, and that’s fine…but I’m not a coder–yet.
4) a list of places that I can go and learn from the best and brightest in SL instead of
relying more on the myths and legends of the residents.
With these things I can make better content creation decisions to reduce lag (or dispell the myths surrounding it).
I’m going In-World to once again try and find a scripting school… one where the students wont ripoff my product ideas seems hard to find. (been there, done that) …But that’s another post… heh.
Cheers,
Trajan
Sidenote: I really appreciate it in the scripting wiki when folks post what the delays are in a script operation/function and the WORKAROUNDS for it, if any. It helps me learn the right ways to think about something from the get-go.
December 15th, 2006 at 4:12 PM
Well my simulator FPS is getting worse and worse. I restarted it twice today for low FPS… the second time it was at 0 or 1 FPS for about 5 minutes. I told it to restart and couldn’t even TP out in the 2 minutes for the restart. There was about 8000ms spent in net time. and 5000ms in scripts and about 500ms in images time. The first time it was fluctuating wildly and most of the time was spent in images time. Now I am just waiting for my sim to come back up after the restart… I wonder if this means it is something else wrong with the sim this time? It has been about 10 minutes now.
December 15th, 2006 at 4:23 PM
Do campers have any effect on simulator lag?
I do know that in our region one casino is often filled with campers preventing “live” folks from even entering! I visited several other “popular” casinos and the vast majority of them were filled with campers, not active gamers.
December 15th, 2006 at 4:26 PM
All the technical speak aside (Even after 7 months in SL I can’t understand half of it) I know that with a brand new computer with nothing but I.E. and SL and a couple graphics programs on it…Huge RAM and a 1 gig graphics cards, I am still only seeing MAYBE 8fps and crashing at least 5 times a day. I have all of my settings turned as low as they will go and hardly what you call a sim jumper. Plus the fact that I lost over 15K Linden worth of stuff and still havent got any of it back, even though I followed the advice of a liason and bug reported it and left my name……SL is a great game, but when you cant do what you want what’s the point of playing….Or more yet, Paying to Play….
December 15th, 2006 at 4:41 PM
A lot of the “best” coders in SL use things like “x / 10″ instead of “x * .1″ and “My Program; More of my program; I need a new variable, so I declare it here {in the middle of my program}; More of my program; Oh! I need another variable, so I’ll declare this new one here!;” and the like.
Other tricks: If, in a function, you call another function more than once, assign the output of that function to a variable. It’s faster to call a function once and assign it’s output to a variable, then get the value of that variable, then it is to call a function even twice, or worse, five or six times.
Make sure you’re using only the variable type you need to get the job done. Using an vector where you can use an integer is very inefficient, for example.
Finally, KISS. For those of you Super Major Geeks From Mars, this means “Keep It Simple, Stupid!” The best programmers don’t use fancy tricks or gimmicks, because when a fancy trick or gimmick breaks, well, it’s hard to figure out why, and to come back later and fix it.
Lynn Kukulcan
December 15th, 2006 at 4:43 PM
I was wondering why for a 24 hour period, I could not TP off of a particular map. Thanks for the update.
December 15th, 2006 at 4:44 PM
For an example of what we’ve been putting up with for the last 8 (yes, that is the number EIGHT) months, click on the link in my name. Note that not all of thos entries are crashes; about 5% of them are restarts, and another 5-10% are lag severe enough to make the watcher scripts think the sim has crashed, but the rest are crashes to the point of booting all people in the sim at the time out of SL, regardless of what the LL simulator logs say.
We’ve been patient, reminding the Lindens only every so often, and trying our hardest to be understanding. I GUARANTEE that if I had that kind of downtime on my webservers (which I get two WHOLE dedicated webservers for the cost of one quarter of a SL simulator server), I’d be out of business, and so would my upstream.
December 15th, 2006 at 4:45 PM
Oh! Instead of declaring variables haphazardly in scripts or functions, all variables used by a script or a function should be declared at the head of the script or function. This does two things.
One, it increases program / script performance. No idea how it does it, but I’ve coded in BASIC, and believe me, it actually works.
Two, if makes the code MUCH easier to read, because we know, when we look at the script or function, what the variables are it’s going to play with and can even get an idea of what they’re for. ^.^
Lynn Kukulcan
December 15th, 2006 at 4:49 PM
I don’t mind some growing pains and i appreciate SL trying hard to make the experience worthwhile, but in light of all the problems lately, I would suggest (if it hasn’t happened) that a few people at SL get their walking papers, NOW~!
December 15th, 2006 at 4:53 PM
And I also mentioned the x / 10 thingie. Well …
All computers multiply faster than divide. And, while I’m discussing script math …
Sure you can make your program super short with that (((((()()())((((()))))(()()))))))((()))(())))))((())))))()))))))) formula, but …
Before the computer can touch that formula, it has to parse it, first, then figure out which parts have to be done first, then do each part in sequence.
A small pointer I learned in BASIC to optimize script coding? Parse that monster formula for the PC!
That’s righ! It’s faster for the computer to do a bunch of basic operations on a bunch of different variables than it is to scrap the variables and have it process the equasion directly!
So instead like answer = ( x + y ) * z;, you go a = x * y; answer = a * z;.
Lynn Kukulcan
December 15th, 2006 at 5:10 PM
THe earlier suggestion of detecting and deleting any prims which are continuously running temp on rez scripts would kill Cubey Terra Mark IV teleporters, which at the moment I use for getting around in my house. It’s not practical.
December 15th, 2006 at 5:15 PM
I’m not a coder or a scripter. I’m just a new user who cannot believe how slow things load and how laggy everything is. I play 3d graphics intensive games, like Battlefield, Doom 3, Tribes, etc. and there’s no lag. However, everything in this game is choppy. I’m getting around 3-4 frames per second (with graphic options set at ~30%) if there’s no other people around. Add some people and I’m lucky to get a frame every other second. I’d be happy with 15fps but something tells me that’s not likely.
December 15th, 2006 at 5:22 PM
[...] As mentioned on the blog by Don Linden, we have identified a fix of some simulator lag and are rolling out an update with a patch. The patch also addresses these issues: [...]
December 15th, 2006 at 5:22 PM
@ Lynn
i am no math genius but shouldn’t it sound like that:
instead of answer = ( x + y ) * z;, you go a = x * y; answer = a * z;?
December 15th, 2006 at 5:23 PM
@ Lynn
sorry i typed the same like you but i mean
i am no math genius but shouldn’t it sound like that:
instead of answer = ( x + y ) * z;, you go a = x + y; answer = a * z;?
December 15th, 2006 at 10:29 PM
Actually the reason that x/10 is likely to be faster than x*.1 is to do with integer versus floating point math. Integer math is fatser. There is no difference between a left shift and a right shift in terms of speed which is how a multiple and dived respectively are implemented.
As for the difference between assigning and partial equation and running it as a complete formula, I strongly doubt there would be any net effect - but that does depend a little on the quality of the parser’s handling of infix notation conversion to postfix notation for stack operations, however the more expensive operation is the assignment - the push and pop involved in stack operations used when the math library executes the bracketed operations is extremely fast compared to assignment to an indirect mememory address as is generally the case with variable assignments.
Of greater impact o code performance are the comments made in the first response to this blog - and i would add to that list the method used for notecard reading and inter-object comms. Note card reading is simply cumbersome to code and (probably) ineficent to execute because the reading method involves many more lines than should be necessary. Conversely, the lack of writing to a notecard induces in ram storage in lists for long running scripts which means more ram (though i guess that all depends on the tradeoff against the extra time taken for the asset server if notecard writing involved a write back to the asset server).
Inter object comms is just silly at the moment. All of the methods are inefficient, and the use of llEmail is nuts. When it becomes faster for me to do inter-object comms over long distances by polling an external webserver - as it is now - than simply talking directly to an object in an event driven model we must be inducing network heavy code….unless the external web server comms is done from the client - then the network load is passed to the client - but i don’t believe that is the case as scripts execute on the servers - right?
A love the finite state machine, but i think a little redesign on the language with a couple of extra functions might make a big difference to the quality of code experienced coders would produce - and hence the weight of scripts on the servers.
December 16th, 2006 at 7:16 AM
The time dilation and sim fps problem seems to have vastly improved in the past two days. Whatever those patches were, they seem to be helping! For those of you asking about improving the scheduler for running scripts - and overall performance - check out the video here:
http://download.microsoft.com/download/9/4/1/94138e2a-d9dc-435a-9240-bcd985bf5bd7/Jim-Cory-SecondLife.wmv
It’s a demo by Cory and Babbage Linden of the upcoming mono engine. The first half is Cory giving a Second Life 101; Babbage’s specifics on mono start about halfway through. The final 10 minutes or so is Babbage showing the mono engine running on a test grid, and the speed increase we’ll all see. He uses the Fibonacci sequence for the demonstration, to show how the mono engines runs LSL scripts 50 to 150 times as fast as the current virtual machine.
Regards,
-Flip
December 16th, 2006 at 11:09 AM
FlipperPA - If only.
My understanding is that Mono and Havoc > 2 is a very long way off in the future. I would LOVE to be incorrect about that and would greatly appreciate any Linden comments on it.
BTW - some of the previous comments in this thread I believe exactly illustrate my earlier comments about how good LSL coding practice is a matter of folklore, and is often questionable.
If there were real ways to measure object and scripting actual overhead, this could be another product differentiator. People could advertise their products’ lag overhead as part of their competitive advantages the way number of prims is currently used.
December 16th, 2006 at 7:36 PM
[...] Update - Complete Rolling Update - Complete: “As mentioned on the blog by Don Linden, we have identified a fix of some simulator lag andare rolling out an update with a patch. The patch also addresses these issues: [...]
December 17th, 2006 at 5:20 PM
I THOUGHT FPS and DilS where better. UNTIL 60 mins ago. Its is a nightmare in high traffic sims! And I not talking about money chairs casinos either! Looks like its going to be a really bad day with this current client!
December 18th, 2006 at 12:06 PM
Myself and my friends have known for sometime that staying on a busy sim would eventually crash SL running the PC out of memory. I have little knowledge of software but I did suspect this was a memory leak as re-logging releases the memory and clears the problem.
It would be nice if a log off and back on were possible without completely re-loading the client.
December 18th, 2006 at 3:19 PM
I hope by ‘near unlimited’ you’re refering to objects that contain 500+ scripts (usually to enhance some push effect or other).
If you’re talking of objects with 50-100 scripts, we’re all in big trouble. *Most* objects with
December 18th, 2006 at 3:20 PM
(repost)
I hope by ‘near unlimited’ you’re refering to objects that contain 500+ scripts (usually to enhance some push effect or other).
If you’re talking of objects with 50-100 scripts, we’re all in big trouble. *Most* objects with
December 18th, 2006 at 3:21 PM
(since my post seems to get truncated, feel free to just remove it)
… *Most* objects with
December 18th, 2006 at 3:21 PM
I hope by ‘near unlimited’ you’re refering to objects that contain 500+ scripts (usually to enhance some push effect or other).
If you’re talking of objects with 50-100 scripts, we’re all in big trouble. *Most* objects with less than 30 scripts are just toys, though I doubt LL realises that since they’ve never had experience actually scripting any major infrastructure inworld (a consequence of their policy of keeping out of the content creation business I’d guess).
One simple way to dramatically reduce the number of scripts in-world (excluding the 500+ identical scripts type case), would be to increase the script memory limit and/or create an inter-script function call mechanism.
I find personally, that 60-75% of the code in my objects is spent on managing distributed state and inter-script communication. Also, in moddable objects, encrypting inter-script link messages for security puts a lot of unnecessary, but unavoidable, load on the sim’s CPU.
I’d be all for restricting objects to 64 scripts if we could have 64K in each and/or inter-script function calls.
)
(perhaps an llExtendMemory() call?
My 2c. Slightly OT.
-Cenji.
December 18th, 2006 at 3:22 PM
(BLOG COMMENT BUG: including < causes truncation)
December 20th, 2006 at 12:47 PM
i would like to see restrictions on scripts/particals/even avatar count in the same way we have prim limits - ‘X’ amount per sq mtr.
EG:
I am so tired of people putting up sim killing casinos/clubs/whorehouses in 1024, 2048 or 4096’s and killing entire sims with sheer amount of people visiting/scripts running.
Why should these people be allowed to hold the rest of a sim hostage when quite often they are paying less tier than other residents on that sim.
December 20th, 2006 at 6:33 PM
Wandarich………better word is ZONING.Yes and I do agree.
September 16th, 2007 at 1:18 AM
[...] でもこの仕組みってどうなってるんだろう。きっと『TemporaryOnRez』とか、一年前のだけどこの記事も気になる・・・え〜〜と何々？？・・・ふむふむ・・・・うんうん・・・・・こらこらそこのあんた張飛にお酒を呑ますな〜！！はっ！誰？私の側に『三国志５巻』を置いたヒトは？？(あんたしかいないよ・・・) [...]
May 11th, 2008 at 9:31 PM
eb9d0039053f…
eb9d0039053fbff2b152…