Server Deployments – Week 17
SLS Main Channel
On Tuesday 23rd April, the SLS Main channel received the update package deployed to the three Release Candidate channels in week 16, primarily comprising the new server-side LSL Animation Override capabilities, complete with a fix for BUG 2164, wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates. This deployment additionally includes the slight region performance improvement when there are no pathfinding characters present. Release notes are available.
Release Candidate Channels
On Wednesday 24th April, the RC channels should receive the following updates:
- BlueSteel and LeTigre: should gain a new project which brings preliminary server-side support for experience permissions – release notes
- Magnum: should gain a new server maintenance project. This update brings some new minor features to LSL, and fixes some crash modes – release notes
So the long-awaited experience tools / advanced content creation tools permissioning system looks to be finally on its way, a little under a year since an exploit caused them to be withdrawn after their initial deployment.
Viewer Updates
Development Viewer Updates
The SL development viewer has been through a rapid series of updates over the last few days of week 16 and the start of week 17, with version 3.5.2.2744 released on Monday April 22nd. While release notes are not available, it is thought it includes (among other things), the fix for music stuttering every few seconds when using FMOD EX, as submitted to LL by Latif Khalifa (see OPEN-173).
Particle Project Viewer Soon (?)
It appears a new particle project viewer may be on the horizon in the near future. If it does appear, it is likely to be primarily aimed at testing a new capability to help deal with griefing attacks which use particle emitters. Speaking at the Simulator User Group meeting, Simon Linden said:
We’re doing some testing and may get a project viewer out, which would allow you to test it and (I believe) let other viewers check out the source code. This is right-click on a particle, and it kills the generator … We’ve tossed around a few ideas about blocking particles in other ways but definitely want to get these first steps out the door.
This sparked further discussion on ways and means to help stop particle griefing, which has been on the increase across the Mainland of late. However, given that particles are a viewer-side effect, “stopping” them is actually easier said than done from a server-side perspective. One idea which gained some interest, if it is feasible, would be a block of any particle emitters belonging to an avatar banned from a region / parcel.
In the meantime there are means of stopping the viewer from rendering all particles – such as CTRL – Alt – Shift – +, or going to Preferences > Graphics > and dropping the Particle Count slider to zero. These again only work in your own world view, and while not always ideal, do present an option.
Asked if such a particle project viewer might include the new LSL particle capabilities already deployed server-side, Simon could only say, “Hopefully yes … I’ve been working on getting that chunk of code solid for the last few days. Unfortunately it’s pretty easy to crash at this point and so it’s not ready for consumption.”
Server-side Baking / Appearance
The viewer-side code for SSB/A is starting to appear in more TPVs:
- Cool Viewer has had SSB/A support in the “Experimental” branch for a while, and this moved to the “Stable” and “Legacy” versions on April 20th – see the Cool VL website and release notes
- Singularity released version 1.8.0 with SSB/A support on April 21st, which I’ve reviewed
- Firestorm released version 4.4.0 with SSB/A support on April 22nd, which I’ve reviewed
- Kukua has had an experimental / development version since the start of April (version 3.5.1) which also incorporates SSB/A.
The status of the SL beta viewer with the SSB/A code will take place around the middle of week 17, when a decision taken as to whether to incorporate the code into the SL release viewer or run a further beta release. The expectation is that the code will move to the release channel unless a last-minute significant issue is found within the code which prompts a further run in beta.
Assuming the code does make it to the release channel, it is likely that a release viewer will appear early in week 18 rather than late week 17, due to the time required to test and QA a build.
SUN-72 – Fix Submitted
One issue which is known to exist within the current beta release of the SSB/A viewer code and which has caused considerable problems is SUN-72 – if you have inventory items with special characters (including the likes of asterisks) in their names, they will fail to load. Similarly the use of accented characters (e.g. such as René) in things like chat log path names, the logs are not saved.
Nicky Dasmijn of the Firestorm team developed a patch for this specific problem which is already incorporated into the recent Firestorm 4.4.0 release, and which has been contributed to, and accepted by, the Lab for integration into the SSB viewer code. Hopefully, it should be appearing in the next SSB viewer release, whether beta of SL release viewer.
Sun-38 – Avatar / z-offset
As noted in my last major update on SSB/A, the ability to offset an avatar’s height on-the-fly to accommodate various animations (e.g. kneeling), or to adjust an avatar’s height when sitting / walking of floors, etc., and which will effectively be “broken” as reported in SUN-38, remains an issue for many.
While the Lab have produced an alternative approach which addresses some issues around avatar height offset using new appearance sliders, and which Nyx Linden and others have been continuing to tweak, there is no solution on the horizon for maintaining any form of on-the-fly adjustment; nor does the proposed solution work with no-mod shapes, as noted when I first reported on the “fix”.
During the Content Creation User Group meeting on Monday, April 22nd, a request was made for the Lab to not shut-down the existing baking service until such time as SUN-28 is “solved”, which prompted Nyx to comment:
SUN-38 is not currently considered a blocking issue for our initial release. It’s on our list to investigate, but we don’t have a patch or update immediately. There is a new hover parameter, which should work for attachments that affect your avatar, but the bug reported is also discussing the need to adjust the offset on the fly without changing wearables. Having both the new and the old system enabled is not an option … We are investigating options, but it is not a hard requirement for the initial release.
So, while the current situation is unlike to change prior to the SSB switch being thrown, again as per my last update, this doesn’t mean the issue is entirely closed from LL’s perspective.
FMOD Ex
A problem has been found in that some high-end audio chips using by OSX dislike having to initialise FMOD Ex at 44kHz (a requirement for FMOD Ex to function on Windows XP systems), which can cause audio corruption after the viewer process has ended. A JIRA on the matter was due to be raised on Monday 22nd April, in order to allow further investigation to take place in the hope that a fix can be provided prior to the code moving to the beta viewer.
Sovereign Engineer, who has reported the above issue, has also provided a script for packaging FMOD Ex (see OPEN-74), which may provide assistance to TPVs in using FMOD Ex in their builds.
Other Bits
Of Viewers and Versions
In my last update, I commented on the problem of communications and the number of different versions of the various viewers in circulation, when it comes to ensuring everyone about the forthcoming SSB changes. During a general discussion about viewers at the Open-source Dev meeting, Oz Linden indirectly underlined this with some interesting snippets of data based on LL’s most recent viewer stats:
- Firestorm is the most popular viewer in terms of number of user minutes – and there are some 329 different versions being used to connect to the grid (which obviously includes older versions, unreleased versions, self-compiled versions, etc.)
- Singularity is now the second most popular viewer in terms of number of user minutes – and there are 165 different versions being used to connect to the grid
- The official viewer is the third most popular viewer in terms of number of user minutes
- Phoenix is the fourth most popular viewer, but with numbers continuing to decline.
Animation Issues
Pamela Galli has reported issues with animations, commenting:
I don’t know where else to report this really, so I will just go on record here as saying that I just had to redo the animations in an oven — animations I have used for several years — because they suddenly became borked, and not just in my store, but in other locations. By borked, I mean that the legs started doing random things each time someone “sat” on the oven — crouching one time, leg out to the side another, legs entwined another.
The matter has been raised as JIRA (BUG-204), however, Pamela’s comment caused Monty Linden to reply:
There is work underway on animations and avatars so if anything anomalous is happening, it’s in your best interest to report a bug via JIRA. Gather up as much supporting information as you can and follow the outline here: http://wiki.secondlife.com/wiki/Bug_Tracker.
So if you do encounter peculiar (and reproducible) animation issues, be sure to raise a report.
Performance and Mesh
Concerns are being raised at the level of performance being experienced at Fantasy Faire 2013 due to the time being taken for textures and objects to render – simply because of the load being placed on viewer / server connections during downloads. Part of the problem here is that with services now being switched over to HTTP, those services are coming under increased stress, as Monty Linden commented on the server forum thread:
I visited the host that’s currently running the ‘Crimson Fields’, ‘Fairelands Junction’, and ‘Magnificat’ regions. It was undergoing the heaviest sustained mesh download I’ve looked at as well as a healthy load of textures. The result is a significant delay getting into some HTTP services, something I’ve seen since working on SVC-6760. Some causes are known to me, some may not be revealed. But good bug reports will help identify them.
That mesh “shotguns” the network badly is actually known to Monty – he’s commented on the situation himself numerous times, and it is on his list of HTTP-related work. Events such as Fantasy Faire appear to be exacerbating the issue not only because of the high use of mesh and textures in-world, but also because of the use of things like mesh avatars and attachments. Part of this issue comes down to social education, in much the same was as it is with discouraging people from attending events with script-heavy avatars. Even so, there is still work to be done on the server end of things, and Monty’s ongoing HTTP work will hopefully assist with matters.
Inara Pey: Living in a Modemworld 
Speaking of social education, scripts and lags, I have to say this: When I first visited Fantasy Faire on Sunday, I personally encountered an idiot who had an astonishing 835 scripts on her, of which 403 were running. She was taking 30112Kb of server RAM and aroud 0.37ms of server time.
When I told her she really shouldn’t have so many scripts on her (interestingly, most of them – according to her – were Meeroo-related, further strengthening my belief that buyers of breedables are complete twerps), she said “but that is the point of being in SL.”
I rest my case. Oh, another friend of mine mentioned to me that some of her friends think that scripts and textures don’t cause lag.
LikeLike
I’ve already speculated that Fantasy Faire has maybe got the balance wrong. The gosh-wow factor of the regions may be getting in the way of people actually going there and buying stuff.
I hope people learn something from that, before SL10B gets hit by similar problems. There was another event, earlier this year, which seemed to suffer from the same sorts of optimism about sim capacities. Back in March, they had something inspired by the Great Pyramid at Giza as part of the Relay for Life event: it didn’t work well.
I try to have low-script AVs for these events. And I hope people are learning. But I suspect sim servers are overloading with fewer AVs present than they were a couple of years ago. Is that excessively-scripted AVs, or the new features such as Mesh? I really did get somebody saying, “We had no problems last year.” at Christmas.
The Tinies do a good job with their events around Raglan Shire. And they make good cookbooks too.
LikeLike
I’d say I agree; while the Fantasy Faire regions are truly magnificent to look at, the overuse of mesh (and sculpts) in their builds, combined with the sheer idiocy of many users who visit them while wearing excessively (and poorly) scripted attachments – seriously, how much trouble would it be for them to remove the excessively scripted stuff before teleporting there? Or how much trouble would it be for them to use low-lag avatars like the ones often provided by the managers of the events?
While these regions were obviously not designed with heavy traffic in mind, the appalling lack of consideration and social education that is demonstrated by the visitors plays a significant role in the problem of lag in Fantasy Faire.
Regarding what causes sims to clog up with fewer avatars on them nowadays than before, I think it’s a combination of all the things you mentioned, coupled with the shortcomings of the current HTTP and UDP protocols.
LikeLike
Fantasy Faire appears to be suffering under an undue load due to the HTTP changes (which might be esed where textures are concerned by diabling HTTP for those viewer which still can, although I’m not sure on this). But it’s not just in-world mesh, etc., within the builds. How many avatars are collectively exploring the sims using high poly count mesh bodies, attachments, etc., which are having an significant impact on the HTTP services running of the associayed simulator & underlying server? Sadly, SL10B could well be the same, as improving the HTTP messaging for mesh appears to be a major task Monty will have on his plate.
LikeLike
I would just make one comment on the changes made to Main Server sims this week. The software that is supposed to stop animation conflicts has other, quite significant effects.
If animations are running there is now a significant (up to 5 second) delay in some animations “kicking in” if they are not Animation Overrider animations.
While this change may have removed one type of conflict, it has introduced several new ones. I believe these are referred to as unforeseen regressions. I raised a Bug report to have it summarily closed a s a duplicate of an existing report, so clearly I am not alone in seeing this issue.
LikeLike
Apropos of Monty Linden’s post about the Faire sims’ performance, I will just add that his post was one of the most useful and informative posts made by a Linden in recent time. Monty Linden must have made many friends by answering a question that was taxing many in a way that clearly stated the problem and showed his understanding of it, and his intention to solve it.
LikeLike
The figure for Firestorm versions may be misleading. Anyone using the Firestorm Support groups will see version numbers being reported, with an alphabetic suffix. So I am down as using version 4.4.0f, I had already noticed that it didn’t change with the Build Number, so I asked. Firestorm is signaling which Skin is is using.
I don’t know whether this comes through in the data that Linden Labs collects. It’s significant for support purposes, since the Skins don’t all have the same set of on-screen controls.
Also, when I was Googling at the weekend, I came across a couple of references to “black” Firestorm versions. Some of those outfits which have been griefing the grid over the last month or so are distributing hacked versions of Firestorm, which report a false version number and have built-in griefing and copyboting tools. That could be really fun, when you consider the reactions of some merchants to past copybot scares.
Also, there’s the OpenSim version of Firestorm, which doesn’t include some code for the Pathfinding system and for Mesh uploads. It looks to be code needed for content creation, and I reckon I could be quite happy in SL without either set of functions. So how many of the apparent Firestorm versions are in that family?
In the end, there’s a lot of different reasons for the different versions. And if I were a programmer who could hack a viewer to do something unscrupulous, the popularity of Firestorm makes it a good choice. I’d just be another face in a very large crowd.
LikeLike
I can only imagine how badly shops like N-Core that employ the Gemini CDS Ban Relay scamware/spyware will be hit after it starts banning people for using Firestorm (which it will falsely identify as a “copybot” viewer, as a result of the copybotters’ activities)…
Looks like Skills is not teh super 1337 h4x0r he claims he is; and it also looks like his clients have the IQ of a doorknob.
LikeLike
Looks like we have an angry techie latex mangina here, lot’s of negative energy and frustration in this one 🙂 Since you seem to have alot of in-depth knowledge *cough*cough*, would you like to explain your theory too.. as to why CDS would SUDDENLY flag firestorm as harmful? considering that the blacklist filtering is not something done automatically, why would it suddenly “falsely identify” viewers? People have ALWAYS been using legit viewers as base for their copybot clients, it’s not exactly something new or unusual…
For newer viewers (so i have been told) Skills, “teh super 1337 haxor” doesn’t go by version numbers or channels at all, as SHE (oh my!) has a lot more info on these clients and their users. For example, according to my source she has access to backdoor logs from several viewers that go back years, which have been confirmed to go into CDS soon.
Sooo who’s the doorknob now? 😉 As for me, i’m a happy Firestorm user and i am pretty confident with CDS, it’s not a super copybat “protection” silver bullet, but that’s not what it’s meant to be.
LikeLike
I see one of Skills’ fans decided to post his/her drivel here. Since it’s unlikely that the flame comment will stay for much longer, I’m going to quote it:
1. Right off the bat, you immediately discredit yourself by assuming that women can’t have any knowledge or opinion such matters – see your “mangina” characterisation. This classifies you as nothing but a troll that came here to defend the Gospel of the Gemini CDS Ban Relay – actually, you are a shill, as I shall explain later on.
2. Skills is the one who has been promoting the Gemini CDS Ban Relay as “super-reliable” with “zero false positives”; it has been reported numerous times (just google it) that (a) it gives numerous false positives, (b) its database is often used arbitrarily and vindictively against people who were not using copybot clients, (c) it is very easy to bypass.
3. Skills has been involved in the Emerald spyware scandal; trusting someone that was involved in such shady actions is stupid – unless, of course, you actually want to spy on your clients (hence your decision to not reveal which store you own, as that would immediately classify you as someone who disrespects their customers’ privacy).
4. FACT: The Gemini CDS Ban Relay violates EU privacy legislation. By surreptitiously collecting (harvesting) data from your store’s visitors (and not notifying them), you are breaking the law – and not only in the EU; even US websites and internet services notify visitors regarding the use of cookies and the collection of certain data, disclose to the visitors what kind of data is collected and they have – as they are obliged to – a privacy policy. Do you conform to any of those requirements?
5. Now, let’s go to the last paragraph of your comment… You claim that you have quite intimate knowledge of Skills’ know-how; this is not stuff that someone keen on protecting their alt and copybotter detection techniques would divulge to anyone, for fear of possible leaks. I know I would not divulge any information of this kind to any of my customers. This immediately proves that you are not really a customer and user of this scamware, but a shill that tries to protect the reputation of a piece of scamware/spyware that has been thoroughly discredited numerous times.
6. And as for “backdoor logs” and all that mumbo jumbo, you do know that copybot viewer developers can very easily have the same kind of information and use it to bypass anything that is done to detect these viewers, right?
But I digress… You are here only to troll.
LikeLike
Enough on both counts. This article is about ongoing SL projects. I’ve removed one comment on the basis of it being an ad hominem attack; I’m not about to see the rest of this thread deteriorate in a circular argument involving viewpoints which are unlikely to be reconciled in civil manner.
LikeLike
/me drops the needle on the broken record:
The “it’s no big deal” attitude of some Lindens toward the Z offset problem is just another example of them not *living in* SL. They prove over and over that they just don’t get it.
/me calms down. You may resume your Second Life.
LikeLike
I agree. I have shoes of different heights – from rather high platforms to flats – and therefore I need to be able to change my Z-offset on the fly, without constantly fiddling with the slow process of appearance editing.
LikeLike
No-one is actually saying it’s “no big deal” in fairness. Rather, the issue has been acknowledged and is still be looked into by the Lab – but it is not seen as a blocker to the arrival of SSB/A.
Nor is LL alone in regarding it in this way; when the suggestion was made at the Content Creator’s User Group meeting that SSB/A should not be turned on until the matter has been fixed, several of the attendees asked why and also asked how people managed prior to the on-the-fly capability arrived in TPVs – so opinions are somewhat divided within the community (and I speak as one who has in the past made good use of the z-offset option).
Whether a more suitable solution emerges in the future is anyone’s guess. And while I’m certainly not holding my breath in anticipation that it will, at least Nyx is not saying the matter is closed, he’s saying he and the Lab are still looking at matters and trying to determine what can be done.
LikeLike
I’d like to share some thoughts on the “hover” adjustment option and compare it to the z-offset attachment that is found in some viewers (most notably on Phototools-enhanced Firestorm).
The “solution” provided by LL uses the appearance floater, which has the following disadvantages: (i) It uses the “legs spread, arms half spread” pose, which does not allow the user to accurately assess the effect of the adjustment on-the-fly; (ii) Usage of this option can result to the creation of many different shapes for different outfits with different shoe styles, which, of course, can result to an inventory bloat.
I consider the matter anything but resolved and I think Nyx would do well to invest more time into finding a way to introducing the functionality that Firestorm’s Phototools added a few months ago into the upstream SSB/A viewer code.
I understand that LL don’t see this as a showstopper; it is not. But it’s a flaw that we, the users have been living with – the fact that we tolerated it and (grudgingly) put up with it doesn’t make it right. Of course, I understand that, when LL first designed the shoe base creation system for their avatar, they didn’t have anyone on board that could tell them “look guys, shoes can have any platform and/or heel height, from low to extremely – or ridiculously – high; let’s make it so that our shoe base’s height-related parameters can have a wider range of values.”
One might certainly – and easily – attribute this problem to bad product design. I beg to differ here. Back in the pre-sculpty days, the only way to make a high-heel sandal was to, well, build it right on the shoe base and then use (the dreadful) invisiprims to hide the bits you wanted hidden. If you wanted to make a shoe with a very high heel or a very high platform, you ran the risk of having the shoe sinking into the floor; in fact, even today I know of a certain shoe (a hiking boot design) that, despite its low heel, can need a z-offset of up to 35cm (!!!) to look “right”.
What should a footwear designer do? Resort to scripts for height adjustment? Adding to an avatar’s script count can increase the avatar’s “contribution” to a region’s lag – I do not favour this solution at all; what needs to be done must avoid the use of scripts attached to the avatar.
And I’m only addressing shoe designs here. And then, there are the sitting animations and poses that need to be adjustable – especially the ones that are included in AOs, but on this matter I don’t have enough knowledge to express an opinion.
So, a showstopper this problem may not be, but it is still a problem and can distract from the visual impression and the immersion we want to achieve in Second Life.
LikeLike
Here’s an additional thought for the appearance editor, especially seeing that it incorporates the “hover” function now: I think it would be useful for LL to consider adding an option to switch to the “T-pose” while in appearance edit mode. That way, I think the effect of changes in the value of the “hover” slider would be assessed more easily.
LikeLike
In order to have the Flycam Indicator for my SpaceNavigator will I have to stay with a TPV or will it at last return to the new Linden SSB viewer, feature as been missing from LL viewers since V1.
LikeLike
Blame builders for the use of excessive scripts and not giving users the chance to remove them!
And if i do love the onrs that make mod items where you can remove the scripts or the ones that put an option in the huds to delete the scripts, i found amazing how the big brands so promoted by almost all bloggers don’t allow any of that!
So to be honest, i blame as much as fashion bloggers as brands that are promoted by them!
And 1 rule of mine, never buy no mod items unless creator made a option to remove them!
LikeLike