Wednesday, 14 March 2012
Create a Radar HUD for Phoenix or Firestorm
Most HUD radars in Secondlife use LSL scripts to scan for avatars in a maximum range of 96m.
If you use the third party viewers Phoenix or Firestorm, you can make use of their built-in full sim radar by creating a one prim HUD that will report EVERYONE in the sim and their distance from you.
Because this information is gathered by the viewer from sim data, there are less script delays and lag than having to ping the sim every second as most radars do.
First;
In Phoenix/Firestorm open the menu named Phoenix or Firestorm then open the Avatar List.
In the options tab, enable Update AND Announce keys to HUD.
Next;
Copy the open source script here.
Create a prim and drop this script in to it.
Profit!
That's it.
Attach it to any HUD position or even wear it.
It will display hovertext above the prim with avatar names and relative distance from your position.
You can modify the script to integrate with your own HUD if you are making one and relay messages in other ways (llOwnerSay, llInstantMessage, llRegionSay [if it's communicating with other objects in the same sim]).
For more information check Phoenix/Firestorm Avatar List.
Saturday, 10 March 2012
Secondlife: Reducing Lag
The Secondlife viewer is a system hog!
It eats virtual memory constantly, creates a gazillion heavily fragmented cached textures and objects which in turn creates client-side lag after which you crash.
Sound familiar?!
Besides the obvious options of turning down graphics in preferences, lowering your draw distance, etc, there are a number of things you can do to postpone the inevitable.
Scenario # 1:
You've been in-world for a while, everything's been going ok.
No lag to speak of.
Textures loading fine then all of a sudden movement gets jerky and lag sets in.
Minimise the Secondlife viewer to the task bar.
Wait a few seconds.
Maximise the viewer.
That's a *bit* better.
What you didn't see, unless you had Task Manager open in Windows, was the Memory Usage drop from well over 300,000K to less than 80K.
As soon as you maximise the viewer that number is going to climb again substantially.
I DO keep Task Manager open on a second screen and if the viewer starts getting up into the 500,000K range, I minimise the viewer window for a few seconds and maximise it again.
It's simple but effective.

Scenario # 2:
You're listening to a musician at a club and the stream starts to jump.
Adjust your viewers bandwidth in preferences.
This slider determines how much of your available bandwidth will be hogged by your Secondlife viewer.
The music stream is independent of Secondlife servers so if you have the bandwidth slider turned way up in your viewer you're making it more difficult for that music stream to keep a good connection with your computer.
I usually run my bandwidth at 5000, being the half way point of the maximum 10,000.
Even this is probably too much but I'm not always listening to music and it doesn't seem to be an issue when I do.
That said, most people's download speeds are less than 5000K for their entire home usage.
So in a heavily populated sim with a lot of lag, I find turning the viewers bandwidth down to between 3,200K - 3,600K gives more resources to the audio stream.
In these circumstances, grab a seat or at least don't move your camera around too much to perv at all the people because that lag is client-side!
Sure the sim is struggling too feeding out all those textures, objects and math.
The server has to send all sim textures including your avatars textures to each and every avatar in the sim and there's to you.
But your viewer is furiously squirrelling these cached textures and objects into folders.
It does this quite inefficiently creating a lot of fragmentation.
When you revisit a texture (swing your camera around and gawk at that girl you were checking out 5mins ago!), your viewer has to check through the texture and object cache first to see if it already has those things.
While caching like this saves some bandwidth rather than have to retrieve them again from the Secondlife servers, it's all very labour intensive on your CPU.
Currently I don't have a good solution to the problem of heavily fragmented cached files other than to defrag* my hard drive after every SL session.
*I recommend Defraggler by Piriform as a free alternative to Windows built-in defragmenter. It allows you to defrag only the files that are fragmented rather than the entire drive saving a lot of time.
Scenario # 3:
You like to run Photoshop or some other heavy usage program at the same time as you run Secondlife OR you are running multiple viewers and it's really laggy! OR you are trying to make a movie in Secondlife (machinima) and the viewer window that's not 'in focus' is really jerky.
Open the Advanced Menu.
If you don't know where it is perhaps you shouldn't be playing with it!
Lol. The SL Wiki has those details.
Next open Debug Settings and type in "BackgroundYieldTime".
If you are running Photoshop or multiple viewers, try upping the Background Yield Time to 200 or more.
This will make the viewer window(s) NOT in focus become very jerky but it will reduce lag in the window you have in focus by updating background viewer windows less often.
Reduce the number to 1 in BackgroundYieldTime for the best possible frame rate in all open viewer windows.
The above are just a few of the undocumented viewer features I've discovered and wanted to share.
Reducing the number of worn scripts and complex attachments can help especially if you are having difficulty teleporting.
Turning off chat logging will also reduce client-side lag.
There are no sure fire solutions or cure-all's when it comes to lag in Secondlife.
More often than not the lag will pass or at least get bearable in time.
In the meantime, you can try some of these options to minimise your own lag.
Edit to add:
Network Lag Discovery Tools:
The Internet Traffic Report provides data in real time on the state of global web traffic.
A quick glance at their home page reveals the current Global Traffic Index ("a score from 0 to 100 where 0 is "slow" and 100 is "fast" determined by comparing the current response of a ping echo to all previous responses from the same router over the past 7 days." - from the FAQ), Global Response Time and Global Packet Loss.
This is a handy way to determine if the lag is 'just you' or the network as a whole.
The Internet Traffic Report (ITR) also breaks down each of these indexes into regional data so while your country may have a good average you might see that North America has a lot of traffic and high packet loss.
In this scenario, you'd expect response times to be high as well and as Secondlife is run by Linden Lab out of San Francisco with server farms in Dallas, Tuscon and Reston, this *could* be the source of your lag.
You can grab a code snippet from the Internet Traffic Report website to add a small image to a web page that includes a handy real time graph of Global Response Time.
I made a simple framed page I built as my browsers start page that includes the Secondlife Grid Status Report, My Secondlife Dashboard, application links to launch Secondlife, Phoenix and some other TPV's direct from the web browser, an iframe with Yahoo's Babelfish translator (you never know who you might have a conversation with in Secondlife!), my current local time and Secondlife current time, links to the SL Wiki, SL Scripting Portal, etc AND the ITR's Global Response Time widget so at a glance I can see the state of the world's connectivity or lack thereof.
A similar website with real time network data is Akamai's Real Time Web Monitor. Here you can view a map of the world and the amount of traffic, latency (response time) and network attacks! Yes, they're going on all the time and DDoS (Distributed Denial of Service Attacks) can greatly affect response time depending on which servers they are aimed at.
WinMTR is a brilliant little free download that can trace the route from your computer, via your ISP, through network hops to any website or server.
It will identify each hop in the journey first by its numerical IP address and if it can, it's 'friendly' name.
So I can discover the IP address of a Secondlife region in the viewer's Help/About menu and enter that into WinMTR and it will trace the route measuring response times at all hops.
Now you can determine if that lag is happening between you and your ISP or further down the line.
Perhaps it's one of the USA's gateway routers in Los Angeles that has hiccuped or maybe one of Linden Lab's server farms has sneezed.
After playing with WinMTR for a while, you'll get to know what a good response time is compared to a bad one. Of course everyone has different speeds and distance from their exchange so results may vary but you can get a good average for your own personal situation and when the dreaded lag sets in, check WinMTR to see where it's coming from.
Subscribe to:
Comments (Atom)

