Jump to content

Deploys for the week of 2011-10-24


Oskar Linden
 Share

You are about to reply to a thread that has been inactive for 4523 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Second Life Server (main channel)
We have had a simultor version hanging around patiently waiting its turn for more than a month now. Last week it was on BlueSteel and LeTIgre. This week it is getting promoted to the main channel. There are some features to help with estate management. There is a new LSL function called llManageEstateAccess(). Estate Owner or Estate Managers can us it to add or remove agents from the estate's agent access or ban lists or groups from the estate's group access list. There are more details in the release notes.
You'll notice that I adjusted the times for the RC channel rolling restarts to more accurately reflect the window in which they are updated. Regions on an RC channel will get their update sometime after 7am but before 11am. We attempt to upgrade all of the regions as fast as possible. Usually this means all upgrades are done before 11am, but sometimes it takes longer.

 

2011-10-25, 5:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/11
 

Second Life RC BlueSteel
Both BlueSteel and LeTigre have a project that has some refactored voice code. We fixed some bugs and cleaned up some code. There were some parcel issues with voice dots not showing up. There is more info in the release notes.

2011-10-26, 7-11:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/11
 

Second Life RC LeTigre
Same as BlueSteel.

2011-10-267-11:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_LeTigre/11
 

Second Life RC Magnum
Magnum will have the same maint-server project with lots of bugs fixes and a few server crash fixes.


2011-10-267-11:00am: Rolling Restart - Release Notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/11
 

We will be monitoring this thread during the next week so please feel free to post issues that you feel have been introduced by the new code. Please file a JIRA for issues you find and post the JIRA link into this thread. It really helps us out. When determining if issues are relevant or not research is key. Tracking down exactly the right situation where an issue is occurring greatly speeds up the development process to get fixes in place.
I appreciate your help. Have a good week!
 
__Oskar
 
p.s. If you are interested in helping test SecondLife in beta please join the group "Second Life Beta" in-world. We also have an email list where we communicate upcoming projects and how you can help. ( https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta ) Once a week we meet on ADITI to discuss new features, new bugs, new fixes, and other fun stuff. You are more than welcome. Information is here: https://wiki.secondlife.com/wiki/Server_Beta_User_Group
Link to comment
Share on other sites

Thanks, llManageEstateAccess works great.  I started working on a tool that will let group members ban griefers without having to be an estate manager.  The only problem is that the only way to get a key from a name is to use a sensor, which requires someone to be within 96 meters.  Sensors are also case-sensitive, unlike the "Choose Resident" name lookup window we have for various things in the viewer.

Is there any progress on having a Name2Key function available to scripts?

Link to comment
Share on other sites

Hey Oskar

Last week you asked me to list things that would help estate mangers better monitor their sims. A friend of mine came up with a real good idea that I hope is possible and should be #1 to be added. He suggested a setting in estate to limit an avatar's script time/memory usage when joining a sim.

For example the other day we had 40 people on the sim for an event and there was very little if any lag. Most guests had script times of around .500ms but then several  script kiddies showed up with one that was well over 7.500ms. It was like hitting  a wall people started crashing and most couldn't walk without rubberbanding. Once they were asked to leave the lag left and everything continued as before. If there was a setting that would not allow access to the sim if the persons script time is above X.XXms

I bet that most claims of server lag would stop or at least ease aggravation on both sides and force those that write crappy scripts to do better

Link to comment
Share on other sites

Ah the script wars :)  First we had the misrepresentative ARC wars with people being told to stop lagging the sim with their "ARC" and now the game has been changed to scripts.

Actually I agree with you despite all the claims that "oh scripts only affect each other, they don't affect the physics engine", evidence suggests that when it all goes bad, that claim just doesn't hold.  Besides, the physics engine isn't the only element that's important, the experience that someone has when interacting with other scripted objects is poor if that object can't respond due to someone else talking all the script time even if they can still walk around happily.

What I would like to see though is accurate memory reporting because right now we have the script nazi's using scanners to auto eject people because that scanner says "You are using xx MB of memory, we only permit zz MB" but a mono script is scanned and reported as 64KB regardless of whether it's 64KB or 1KB.

The result of this is that it still appears to be more advantageous to use LSL and report 16KB even if your actual usage is substantially less but for using less memory but appearing to take at minimum four times more, you get ejected from the region.

This leads to people being forced into dysfunctional behaviour and we can't take advantage of mono memory usage because other 'tards are spanking people for doing so!

Link to comment
Share on other sites

Actually MB was talking about script "time" not script "memory", but abusing either can have a negative impact on how a region performs when you get 30-40 avatars together for an event. When I buy new hair I make a copy for safe keeping and so I can re-adjust it if I need to, then I adjust the copy I wear and delete the scripts. I do the same with scripted shoes and skirts. This dramatically reduces my impact on a region both in script memory and time. I won't buy hair, shoes or skirts that aren't mod/copy (Mesh items being the one exception) or that don't permit the scripts to be deleted.

Link to comment
Share on other sites

Cincia you sure have that right estate script time has been snapshot then average then back to snap shot several times this year I forget where it is right now lol. But more so if you check script counts in estate vs. the status window the count is usually off by a couple thousand  scripts running and script times are different by sometimes 10.0ms... which is accurate? I took a screen shot of my sim when I bought it with nothing on it save a couple friends who were very low scripted and the status window still said there were 700 scripts running,how can that be? My friends  sure weren't wearing that many scripts! Maybe there is a logical answer but we haven't been told so we all have to keep guessing and pestering LL when our sims lag. As I've been pushing for ways for us to watch over things ourselves I agree with Sassy and Cincia that accurate data would sure help. I wish more people were like Sassy and descripted items that don't need them. It's not just hair why are sunglasses scripted? If it's to adjust fine but then take the scripts out to help everyone enjoy SL

Link to comment
Share on other sites

Oskar

I'm curious.

I have noticed over the past week that TPs back into Main Server regions from regions on RC channels LeTigre and Magnum (LeTigre in particular) result in slow texture reloading (longer "rez times") than in TPs between regions running Main Server.

Is there any conceivable reason for this?  I carry a relatively high script-load relative to some, but this effect is script-load independent. (Or certainly seems to be).

Anyone else seeing this?

PS I use HTTP Texture get - I've tried going back to UDP but it's too damn slow to load new textures.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4523 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...