Ash Qin
-
Posts
129 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Ash Qin
-
-
Hello!
I'm one of the Exodus Viewer developers, so call me biased for my answer if you wish. However I wish to point out a few things.
First of all, all viewers that connect to the Second life grid must comply to Second life's third party viewer policy. This policy is on http://secondlife.com/corporate/tpv.php - If we (developers), do not comply to this policy, Linden lab would be quick to block the viewer from logging in. If we circumvented the blocks, our Second life accounts would end up banned.
Secondly, listing on the Second Life TPV list is optional. Believing you are any safer with a viewer on the TPV is a false sense of security. TPV developers self certify their viewer's compliance (regardless of being listed) to the TPV, Linden Lab are not known to normally certify viewer releases on the TPV list. You should question all viewers regardless of being on the TPV.
You have to apply to be on the list, you can see LL's terms for applying here http://wiki.secondlife.com/wiki/Downloads#For_developers:_how_to_apply_to_list_a_viewer_in_this_directory
Thirdly, at this time, we aren't seeking out to be on the TPV list, we're still in beta after all. We are however listed on Second life's wiki on, http://wiki.secondlife.com/wiki/Downloads#Exodus_Viewer - which makes listing on the TPV somewhat pointless if we're listed anyway.
As one of the developers of Exodus Viewer, I would like to say that I stand by everything that is written in http://exodusviewer.com/faq.html - Which pretty much references the fact we don't have cheaty, password stealing or any of that other stuff.
-
3
-
-
Bavid Dailey wrote:Thanks for the information, Both libomv and JVA look interesting, pity I don't run windows though :-(
My libomv bot is running on Linux under Mono.
-
Bavid Dailey wrote:Ash,I'm astonished to find you have a tool that can collect this data; what is its provenance?
I have two bots for monitoring statistics in Deshima. One of them is called "Deshima", which collects a lot of data and dumps it to CSV files (it also does a lot of other things), where I can open it up later in Microsoft Excel and make pretty graphs on just about anything. I wrote said bot using libomv.
Second one is ran by a friend of mine (lex.mars), which runs under the username "Seeker". I believe it's running on some bot software called "JVA" to collect the data and then later uses MRTG to draw the graphs you see and then uploaded to a website. I find myself relying more on the latter just because it's easy to just open a webpage and look as opposed to downloading the .csv files, importing it with Excel and then setting up the graphs I want to draw.
-
Yep, as mentioned in my post I was doing some heavy testing, which is why you see those spikes. What is interesting is when you look at the other stats and don't see them as adversely effected as sims are normally known to be when physics is heavily abused.
Sorry, I guess I should have clarified that further in my post.
-
So today I have been heavily testing my region running Second Life RC Magnum 11.05.23.230743 (Mesh prep).
Before I get into specifics, I need to summarize a few things about my region. There have been significant changes to a lot of things that the content my region (Deshima) relies on. To give a bit of background information, my sim has a rather large space station build and relies heavily on physics, trickery and things that make Falcon cringe like a volume detect megaprim. There are also a few bots that do weird things on the region that I sometimes suspect may sometimes harm region performance, one example is Subnova Hax which sits and downloads the Second life map data and stores the map texture UUIDs in a database for others to access via the Subnova map API (example script using it).
The region has a lot of physical elements to it. The primary way to get up and down the station is elevators that travel through tubes, there are roughly about 600 scripted asteroids which dynamicly generate their shape, size, sculpt map, can be knocked around, blown up, form from dust etc. Vehicles that transverse the outside of the space station. There is a single large volume detect megaprim that is used to pick up vehicles, avatars and display them on a 3d representation and act on events depending where these are on the station. There are megaprim walls surrounding the station to prevent objects from flying off world as well as preventing people from accidentally flying their vehicles out of the region unless they intended to (there is a hole in one of the megaprim walls where a sort of vortex gateway sits for people who want to leave).
Going ahead with my findings. I am pleasantly surprised to say that the amount of issues I have encountered is minimal, I have thrown everything I could at both region physics, volume detect. The new physics engine appears to be handling very heavy loads well, which is great news for those of you in the SL combat scene.
Here are some pretty graphs to show how much the sim was overloaded and the continued performance. The white bits are due to sim restarts and testing different settings in the sim console. First white bit is due to the rolling restart.
Things that were not broken which concern the Second life Military Community (combat sims using LL damage) was 'armor' systems, where by someone sitting on a volume detect object cannot be killed by Linden damage (it's considered a feature by many, since they can build tanks and such where the avatar doesn't die, the tank needing it's hit points taken out and then scripted to explode or such). I admit that if I had been on the beta grid more often, I would have been able to confirm this sooner, however, I've had a lot of real life work to deal with thus preventing me from spending much time on things.
Issues I did find. Steep terrain, particularly newly created terrain can cause an avatar to jump continuously when standing on the side or even suddenly shoot them up into the sky. This does not seem to be the case when accurate terrain is enabled. Over time, the violent reaction of jumping or tossing goes away or reduces it self (like after an hour). This could be a big concern for sims that rely heavily on land mass for walking and such.
The next issue I found was when the sim physics was getting abused, the edges of prims had a very powerful rebounding effect, enough so that while there is heavy physics usage, my elevators are unable to transverse their tubes as they keep bouncing off the corners of prims that didn't cause an issue before the update. In this case, a 95% hollow cylinder sized at 4.300x4.300x2.875 would cause issues for a 3.500x3.500x0.090 cyliner traveling inside it. I was able to reduce the issue by flipping these mysterious collision_tolerance value in the sim console to 0.01 - I'd love to know exactly what this does.
When changing collision_tolerance between 0.1 and 0.01, I did some testing to see if volume detect prims, both thin and thick had any particular issues detecting prims I was firing at them. To my surprise, neither settings made any significant difference in results, even when overloading the sims physics while testing this. I did however notice that prims tended to do less bouncing off things at 0.01 and dying on contact like they're scripted to do. I feel that for these sim console functions that deal with physics, it would be a good idea to have more values for llGetEnv to return information on including collision_tolerance and accurate_terrain. Particularly in accurate_terrain, there are instances where vehicle creators can use some alternative prim configuration that handles better in that mode. It's entirely possible though that the sim host at the time may have been the cause for either reaction mentioned, as you have to restart the region to flip these values.
The sim is extremely fast at recovering after heavy physics usage has stopped, it's almost instantaneous, something I have not observed on previous server versions. I have not observed any noticeable negative effects in either way when the volume detect megaprim is rezzed or not. I did not find any issues with accuracy of the megaprim's detection either. I also have not noticed any major increase in events being fired either - Such changes would require changes to how certain functionality is throttled to work optimally.
I was disappointed to find that llCastRay is still disabled, which would definitely be of use for one of my recent projects involving turret systems that have predictive logic to determine where a target is going to be and fire off projectiles to hit them. llCastRay would have been super useful to determine if there was something obscuring the trajectory of the projectiles. I really look forward to the day it's enabled.
I have truly had minimal problems with this framework update, my fears of things breaking horribly didn't come true. I did notice the new sim console value 'max_prim_scale', which sets the maximum prim scale, sadly read only. I guess I'll get my 64meter prims later on. :3
I'll be comparing the sim performance over time and comparing it against past data too, I don't expect to see a major difference with what I've experienced so far. If others wish to do so as well, some of the statistics for Deshima are publicly accessible on:
http://www.subnova.com/secondlife/deshima/html/week.htm
In all,
Great work on the server!
Facebook
Instagram
Twitter
YouTube
Flickr
OSX Mavericks - Anyone tested SL the dev version yet?
in Second Life Viewer
Posted
> As the SL viewer goes through another rocky period of major instability as new features are added, and Firestorm has trouble keeping up to date, i sudden wondered if any Mac SL Users had tried the current viewers on the next big OSX update mavericks.
Yes.
> So has anyone got the OSX MAvericks developer beta and have they tested Sl on it yet?
No, I tested it on the release version instead of using a beta.