Deploys for the week of 2012-07-09

[WolfBaginski Bearsfoot]

Havok version changes do odd things to anything depending on physics, and i am afraid that some content creators have never bothered to update code to ceorrect the bahaviour. I've done a few tests, and there is nothing obvious about the code in the Magnum RC, but I haven't been fiddling with ground vehicles.

I am not impressed by the Linden Lab attitude. Can't they at least document the changes? One critical change, and it was a lont time back, affected how water vehicles floated. A constant needed a slight change, or a boat would sink.

This sort of thing goes beyond bas communication with customers: if they cannot keep track of what is supposed to happen, how can they be sure whether anything is breaking? 

[MB Robonaught]

Hi, please note that LL spent about an hour on my sim  and totally  tested everything under the sun in order to trace the cause of this issue. We had excellent communication while the sim was being tested. Now they'll need to go through thousands of lines of code to find those lines that match the information they acquired today. If one has ever seen a large programming code one will see what a daunting task it will be. Trust me they are taking this seriously.

[Ayesha Askham]

Triple

I don't mean to be rude, and I am certain that you know a lot more about Internet programmes than I, but...I just cleaned out my browser's cache of all files and cookies.  The next attempt at getting in here still dumped me back at the help page of Secondlife.com and when I navigated back to this forum, It told me that I was NOT logged in!

So to you and Cincia, who do not have these issues, I say "Good for you", but I still DO have issues with this Lithium software and I have done from the day it was introduced.

I have no problems with the SL JIRA nor the Grid, nor any other websites, so I have to insist that there is something different about SL's Forum software, and not in a good way!

[Vladi Hazelnut]

Ok, so after my rant last night its time to eat a little crow. I like mine medium rare with lots of butter thank you.

Today while MB and I were in a pathfinding sanbox trying to figure out a work around to this issue Falcon Linden suddenly shows up bearing gifts. He (possibly others) bascially fixed our car for us. Not completey, it still needs some tweaking, but he did point us in the right direction. He said he wanted to make as few script changes as possible but he did give us some suggestions. It still breaks when we hit return but other wise when you rez it out it works just fine so far.

As for what he changed I honeslty couldn't tell you, I am not that smart lol. All I heard was blah, blah, blayh physics state, blah blah llsetparameters, blah blah blah. MB seemed to understand it though. Must be some special nerd language lol. So if you want to know what he said you would have to ask MB.

We really need to give a huge thanks to Falcon Linden and anyone else who helped him. Within a few hours of us reporting the problem he was on our sim testing the car and running debug tests on the sim. And within less than 24 hours he comes back with a viable solution to the problem. Yes we will proabably have to change our scripts a bit and the way we put the cars together. And update a ton of them. However at least we are not standing in a sandbox scratching our heads wondering where to start. For somene to take the time to do that really impresses me and shows me not all the lindens have given up. The lindens in this forum and Falcon seem to honestly care about the issues so my hat is off to them.

But like I stated before, don't expect them to scrap months worth of work because of a few issues. From the sounds of it they think its ready to release. I guess we will have to solve issues as they come up and move on with the times

[Darian Rau]

I too, would like to publicly thank Falcon, Maestro and Oskar Linden for their attention and all of their efforts thus far. It is not every day that you see people in their positions go as far out of their way as these three have done to help what amounts to a small fraction of their subscriber base. Their generosity is most sincerely appreciated and if I could I would buy them all a drink. Thank you.

[Ayesha Askham]

@Darian

We are all grateful to Falcon, Maestro and as ever, Oskar for their contact and willingness to meet with and help SL residents.

However....

There is a serious flaw in this whole business.  The Havok7 software needed to make Pathfinding work is simply not compatible with most existing SL physics.  Indeed the interaction of ANY object with the Sim ground is going to be changed radically by its introduction.

This will affect a lot more that drag racers.  It will affect materially a good portion of SL residents, though they may not notice it immediately.

The prime reason that Falcon was inworld trying to give some of the worst affected sim owners in this pilot roll is because Linden Lab realise the sheer scale of impact that the introduction of Pathfinding will have.

The reason that this project will go ahead is not that its impact can be mitigated...in a great many instances it cannot!  It will go ahead because it is on the SL roadmap upon which the CEO has made his make or break decision.

The failure of Pathfinding would badly impact on the CEO's standing with the board and shareholders of Linden Lab.  That he will do his utmost to avoid...those below him are feeling the pressure.

[Vladi Hazelnut]

Here is the problem the way I see it.

"There is a serious flaw in this whole business.  The Havok7 software needed to make Pathfinding work is simply not compatible with most existing SL physics.  Indeed the interaction of ANY object with the Sim ground is going to be changed radically by its introduction."

That is easy for people to say, but unfortunately no one is proving it. Hell our Jira on this issue only has like 6 votes. The way it was explained to me at the meeting is there really have not been alot of complaints with issues. And they could not find many during testing. If people all over are having issues no one is speaking up. The issues they have seen come up can either be dealt with, or in their opinion ignored. I was the only person at this meeting that had anything bad to say, everyone else is itching to have it deployed and start messing with it. So based on this LL and the developmnt team are not going to scrap months and months worth of work for something that is effectign a small percentage of residents. And not every vehicle in sl is effected by this. Many still work just fine, it all depends on how they were built. Drag cars a bit different then most SL vehicles because of the way we want them to perform. And all of the other sims I have been to with this code seem to run fine, I think our two sims must be messed up somehow. We were having problems before this happened, and changing the server code just made it worse.

This is progress, and sometimes progress is a **bleep**. This surely wouldn't be the first time new code or LSL changes have broken stuff. I remember buiding a DJ booth and paying to have a script written for it only to have new code break some of the features before I even got it released. And this surely isn't the first time we have had to adapt our cars to a new physics engine. I can think of three times it has had major effects on our cars and I have only been in sl 3 and a half years.

You are most likely correct though, this is no different than any other company or factory I have worked for. The people that do want to make a quality product and do the right thing normally get overidden by upper management and have their hands tied.

[Darien Caldwell]

---

Ayesha Askham wrote:

Triple

I don't mean to be rude, and I am certain that you know a lot more about Internet programmes than I, but...I just cleaned out my browser's cache of all files and cookies.  The next attempt at getting in here still dumped me back at the help page of Secondlife.com and when I navigated back to this forum, It told me that I was NOT logged in!

So to you and Cincia, who do not have these issues, I say "Good for you", but I still DO have issues with this Lithium software and I have done from the day it was introduced.

I have no problems with the SL JIRA nor the Grid, nor any other websites, so I have to insist that there is something different about SL's Forum software, and not in a good way!

---

You're not the only one. I have to log in two times every time I visit the forums. It's the forums, not you or I.

I don't really mind much. I rarely come here. And I know it took LL about 2 years to get logging into the SL website *overall* to persist past a day.

I gather either it's intentional, or something at the bottom of a very, very long list of things to do some day.

[Darien Caldwell]

---

Vladi Hazelnut wrote:

As for what he changed I honeslty couldn't tell you, I am not that smart lol. All I heard was blah, blah, blayh physics state, blah blah llsetparameters, blah blah blah. MB seemed to understand it though. Must be some special nerd language lol. So if you want to know what he said you would have to ask MB.

 

---

 

It would be good if MB could come and share that information with the rest of us.

[Perrie Juran]

---

Darien Caldwell wrote:

---

Ayesha Askham wrote:

Triple

I don't mean to be rude, and I am certain that you know a lot more about Internet programmes than I, but...I just cleaned out my browser's cache of all files and cookies.  The next attempt at getting in here still dumped me back at the help page of Secondlife.com and when I navigated back to this forum, It told me that I was NOT logged in!

So to you and Cincia, who do not have these issues, I say "Good for you", but I still DO have issues with this Lithium software and I have done from the day it was introduced.

I have no problems with the SL JIRA nor the Grid, nor any other websites, so I have to insist that there is something different about SL's Forum software, and not in a good way!

---

You're not the only one. I have to log in two times every time I visit the forums. It's the forums, not you or I.

I don't really mind much. I rarely come here. And I know it took LL about 2 years to get logging into the SL website *overall* to persist past a day.

I gather either it's intentional, or something at the bottom of a very, very long list of things to do some day.

---

The issue is that they need to decide how they want the cookies and log-ins to work.

What we have is essentially several different services being provided.

Your 'Dashboard' is one service provided by LL.

The 'Forums' are another separate service.

Their is also the Marketplace, The JIRA's, The Lindex, etc.

Each was established independent of the other and the way they are interconnected is not very streamlined or secure.

For instance, I signed into the Dashboard and then opened the Market place in a separate tab.  I found myself automatically logged in to the Marketplace.  I then closed the  Marketplace tab and logged out of the dashboard.  To get back to my Dashboard I would have needed to re-enter my password.  However, going back to the Marketplace I find I am still logged in there! 

For more detailed discussion, see this thread:

http://community.secondlife.com/t5/General-Discussion-Forum/Security-Flaw-In-The-Second-Life-Web-Site/m-p/1279015/highlight/true#M41407

[Pandorah Ashdene]

Maybe somebody can help me out here (I assume I am 'missing' something) regarding the following 'feature' on the Magnum Server:

All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0). This provides the benefit of not penalizing prim-based creators for optimizing their content by opting into the new system and will make the streaming cost more reflective of the true network cost of the objects.

I made the following test: a pipe built out of 4 legacy prims (four hollow cylinders and a quarter hollow torus) and two sculpts (bolts), which shows up with a land impact of 6 with 'legacy' accounting; when I switch the sculpts to 'physics shape' "none" the land impact jumps to 113 (!);

Shouldnt the 'capping' have the effect that it is limited to a land impact of 8?

[MB Robonaught]

Hi Darien, I'd be happy to do that. To fix cars hanging at low speed use the following steps:

1.If not already move the cars root approximately .5m up from the ground

2.(for high prim no attachment cars)Set the root to prim for physics type, set the wheels to convex hull(a mesh wheel using a spherical physics shape is preferred)and set everything else to none.

I'm still working on why the return to last position feature fails for some cars and not other and will pass that information along as I find it. I suggest following the JIRA's for any issue as that is where the real work goes on. In this case it's

SVC-8048

[Ayesha Askham]

@Vladi

I sincerely hope you are right in that it is merely your sims that are wonky.  However given the trouble I have in loging onto this forum, it is unlikely that many would have the patience to keep entering their username until the system finally allows me in.

The incompatibility issue is not my wording but Falcon Linden's.  There has been a change in the way SL land is mapped, from being a "height field" in the current physics set up to being a mesh in Havok7.  This, as I understand it, basically means that any object with physical interaction with SL ground will be impacted by this change.

As to the numbers complaining, for every one posting there must be one hundred disgruntled users that either cannot post or cannot be bothered to post.  Linden Lab may well have tested things prior to the roll but for such a fundamental change a great deal more preparation was needed and this clearly was NOT done.  Problems with physical objects should have been known about prior to even Beta Grid tests.  This is not the sort of issue that we can just "suck up".

@MB: 

Thanks for the explanation, and indeed that might be a partial fix for drag racers running on a prim surface, but that is nowhere near a fix for the other issues created by the use of Havok7 physics.

This is going to take more than a few weeks to rationalize.  Oh, and I maintain my point about "pressure from above".

[Darien Caldwell]

---

MB Robonaught wrote:

Hi Darien, I'd be happy to do that. To fix cars hanging at low speed use the following steps:

1.If not already move the cars root approximately .5m up from the ground

2.(for high prim no attachment cars)Set the root to prim for physics type, set the wheels to convex hull(a mesh wheel using a spherical physics shape is preferred)and set everything else to none.

I'm still working on why the return to last position feature fails for some cars and not other and will pass that information along as I find it. I suggest following the JIRA's for any issue as that is where the real work goes on. In this case it's

SVC-8048

---

Thanks

[Maestro Linden]

Pandorah: what caused the land impact to be 113? Was it physics weight? Both tori and hollow cylinders are very expensive to the physics engine, and thus have a very high physics cost.  Setting them to physics shape type 'prim' should be avoided whenever possible.  This guide has some more information: https://wiki.secondlife.com/wiki/Physics_Optimization

[Innula Zenovka]

I think what's confusing Pandorah (and if it's not, I apologise, but it's certainly confusing me) is what Nyx was saying about changes to the LI accounting system at the Mesh User Group meeting of March 30,  (12:18 and following) and what Falcon was saying at the Simulator User Group meeting of March 27 (about 5pm) .

The idea was to stop people using the llVolumeDetect hack to phantom child prims (particularly sculpties), because that and pathfinding don't play nicely,  and have them do it properly by setting them to PRIM_PHYSICS_SHAPE_NONE, wihout breaking large amounts of content by forcing them to use the LI accounting system and become horribly expensive.

Maybe I misunderstood, but the impression I got from reading those, and various other transcripts at the time was that, while nothing was finalised, the aim was to change the LI accounting system so that changing non-mesh objects to the LI accounting system didn't appreciably increase their cost.    

Did I and others get that wrong?  Or is it going to happen but it's not yet been turned on, or what?

 

[Talia Davidov]

@ Innula

Its actually in the release notes from this deploy

(copied from original post)

Changed prim accounting for legacy prims which use the new accounting system

• All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0). This provides the benefit of not penalizing prim-based creators for optimizing their content by opting into the new system and will make the streaming cost more reflective of the true network cost of the objects.
• Server cost will be adjusted to MIN{ (0.5*num_prims) + (0.25 * num_scripts), num_prims }. This preserves the current value for unscripted linksets and reduce the cost for linksets containing fewer than 2*num_prims scripts. It provides the benefit of rewarding creators for reducing the number of scripts in their objects.

 

[Innula Zenovka]

@Talia -- thanks, and this is what's puzzling me.   The KB article on Calculating Land Impact (a topic I don't really understand, which is maybe why I'm having problems) says that  

---

For each object in the Second Life world, Second Life compares three important performance factors: download weight, physics weight, and server weight. It then chooses the highest of these weights and assigns it to the object as that object's land impact rating.

---

and Maestro seems to be suggesting the reason the LI of Pandorah's object is so high is that its physics cost is the highest of its three weights in this case, so that's the value being used to calculate its Land Impact.  

That makes sense to me, but at first sight it seems to subvert what I'd thought was the intention behind these changes to the prim accounting system, since any benefits gained by changes to the way the object's streaming cost is calculated are apparently purely academic once the streaming cost falls below the physics weight.

Is it  that, if I've got an object currently composed of complex prims and sculpties that uses the Volume Detect hack, and I want to ensure that setting the "phantom" child prims to PRIM_PHYSICS_SHAPE_NONE doesn't increase my object's LI to an uneconomic figure, I simply  need to set the non-phantom components to PRIM_PHYSICS_SHAPE_CONVEX at the same time I set the components I want to be phantom to PRIM_PHYSICS_SHAPE_NONE  in order to enjoy the benefits of these changes?

[Pandorah Ashdene]

---

Maestro Linden wrote:

Pandorah: what caused the land impact to be 113? Was it physics weight? Both tori and hollow cylinders are very expensive to the physics engine, and thus have a very high physics cost.  Setting them to physics shape type 'prim' should be avoided whenever possible.  This guide has some more information: 

https://wiki.secondlife.com/wiki/Physics_Optimization

---

Hello Maestro,

thank you for replying to my post.

Maybe I should explain the general problem I have with the way you have implemented the landimpact accounting in the 'mesh context', which I was hoping would finaly be fixed by the pathfindng rollout.

Take this simple scenario: I build something out of legacy prims, say I rezz a cylinder and hollow it; the way the prim gets 'born' is with physics shape 'prim'; and not a problem, the land impact is 1; now I rezz a second cylinder, say again a cylinder, hollow it and use it as ring around the first; I link both prims; landimpact becomes 2; fair enough; - and please note: BOTH prims default to physics 'prim' in this situtation;

Now I try to be a considerate builder and decide to set the physics of the second hollow cylinder to 'none', because, well the bigger cylinder as collision shape should sufficent; and POOF! - the landimpact jumps to 13 (!!)

Seriously. This makes no sense - the two cylinders - both with physics 'prim' - count as LI=2; switching one of the prims to physics 'none' results with a LI=13 (more than six times the value!) for the linkset; this is totaly reverse to what it should be! - dont I reduce the server physics calculation by switching off one the prims in the linkset?

Originaly my 'problem' actualy surfaced in the context of using mesh in combination with legacy prims (again hollow cylinders and the like), because linking a mesh object with legacy prims has exactly the above described effect; and let me be frank here, I stopped making new mesh stuff because I find it realy hard to 'explain' or justify this effect to people who potentialy buy my stuff;

The way legacy prims and mesh interact regarding the landimpact make it in my opinion unusable; sorry to say so; I was helping you guys testing when mesh was still on Aditi and was realy looking forwar to it being on the main grid, but to be honest, the way you implemented it, you realy ruined it for 'us' builders;

Basicaly I have to label the mesh items I make with a WARNING! sign and an explanation as long as my arm, to prevent people from linking their own builds with them; how much sense makes a mesh building element (say a corrugated metal sheet) if people can not link into their builds with the landimpact exploding?

The comments in the Pathfinding context, that legacy prims will be capped to a LI=1 and sculpts to LI=2, made me hope that there is finaly light at the end of the tunnel, but it doesnt seem so;

I rezz a mesh I-Beam (physics 'prim': download 0.1, physics 0.3, server 0.5) with LI=1 and link it to a hollow cylinder (physics 'prim': download 0.6, physics 13.0, server 0.5) with LI=1 and the result is LI=13 (!!)

Sure, *I* do understand why that happens (looking at the 'More Info' panel, - but look at it the way it looks to the 'average' hobby-builder, that normaly has the 'More info' panel not open: when they link in the mesh part the landimpact explodes!

In this case, it might look 'easy' to find the source of the problem, but imagine a build with say a hundred legacy prims; somebody links in the i-beam and POOF! they get the build returned and probably cant even rezz it anymore because the landimpact went way beyond what they have as resources; and then I get IMs blaming me that my stuff is crap because it ruined their build; what do I tell them? "Go to a sandbox and try to switch the physics of some of the prims in your build to 'none' or 'convex hull'"?

Sorry, but this is a total mess, and I was realy hoping that the Pathfinding cap for legacy prims would finaly 'repair' the situation; obviously it doesnt; which leaves me at a loss.

[Pandorah Ashdene]

---

Innula Zenovka wrote:

I think what's confusing Pandorah (and if it's not, I apologise, but it's certainly confusing me) is what Nyx was saying about changes to the LI accounting system at the

Mesh User Group meeting of March 30

,  (

12:18

and following) and what Falcon was saying at the

Simulator User Group meeting of March 27

 (about 5pm) .

The idea was to stop people using the llVolumeDetect hack to phantom child prims (particularly sculpties), because that and pathfinding don't play nicely,  and have them do it properly by setting them to PRIM_PHYSICS_SHAPE_NONE, wihout breaking large amounts of content by forcing them to use the LI accounting system and become horribly expensive.

Maybe I misunderstood, but the impression I got from reading those, and various other transcripts at the time was that, while nothing was finalised, the aim was to change the LI accounting system so that changing non-mesh objects to the LI accounting system didn't appreciably increase their cost.    

Did I and others get that wrong?  Or is it going to happen but it's not yet been turned on, or what?

 

---

Yes Innula, this is exactly how I understood it too, but obviously that's not how it's meant to work, or at least it's not working on the Magnum test sandboxes.

[Pandorah Ashdene]

---

Innula Zenovka wrote:

@Talia -- thanks, and this is what's puzzling me.   The KB article on

Calculating Land Impact

 (a topic I don't really understand, which is maybe why I'm having problems) says that  

---

For each object in the Second Life world, Second Life compares three important performance factors: download weight, physics weight, and server weight. It then chooses the highest of these weights and assigns it to the object as that object's land impact rating.

---

and Maestro seems to be suggesting the reason the LI of Pandorah's object is so high is that its physics cost is the highest of its three weights in this case, so that's the value being used to calculate its Land Impact.  

That makes sense to me, but at first sight it seems to subvert what I'd thought was the intention behind these changes to the prim accounting system, since any benefits gained by changes to the way the object's streaming cost is calculated are apparently purely academic once the streaming cost falls below the physics weight.

Is it  that, if I've got an object currently composed of complex prims and sculpties that uses the Volume Detect hack, and I want to ensure that setting the "phantom" child prims to PRIM_PHYSICS_SHAPE_NONE doesn't increase my object's LI to an uneconomic figure, I simply  need to set the non-phantom components to PRIM_PHYSICS_SHAPE_CONVEX at the same time I set the components I want to be phantom to PRIM_PHYSICS_SHAPE_NONE  in order to enjoy the benefits of these changes?

---

This seems to be exactly the issue;

Like in the post I made (two up) consider this example: I rezz a mesh I-Beam (physics 'prim': download 0.1, physics 0.3, server 0.5) with LI=1 and link it to a hollow cylinder (physics 'prim': download 0.6, physics 13.0, server 0.5) with LI=1 and the result is LI=13 (!!)

Prior to linking the physics of the cylinder (13.0) is 'hidden' because on rezzing the cylinder uses 'legacy accounting' and it shows a landimpact of 1; the linking to the mesh element changes that and the LI jumps to 13; you could now set the physics of the linked-in cylinder to 'none' (if it's not the root) or 'convex hull' to 'compensate';

But I find this ridiculous; if you're building you have to go through all elements in the linkset and switch all by hand; if you have a scripted situation the script will have to go through all elements in the linkset and make the 'right' choice; sorry, makes no sense to me.

[MB Robonaught]

I ran sim crossing tests at the pathfinder sandboxes on both mesh cars and non mesh cars. 50% of the crossing with non mesh cars(50 crossings total) were flawless while the rest of the crossings would rubber band you across the region and back. This appeared worse the more time the cars would cross without rerezzing. Every crossing(again 50 crossings) with a car either fully mesh or partial resulted in as region wide rubber band effect. Pehaps more tests are needed?

[Talia Davidov]

It is very concerning.  On one of the buildings I make I took out the prims that I had used the volume detect hack on and replaced them with prims using PRIM_PHYSICS_SHAPE_NONE.  When I linked it all back up the PE went from 70ish to well over 300.

[Innula Zenovka]

Yeah,  I'm rather alarmed, too.   However, I've just tried this for myself on Magnum 1.

I made the most horribly contorted torus I  could and linked it, as the root prim, to a sculptie.

Land Impact: 2

I then used edit linked parts to turn my sculptie to PRIM_PHYSICS_SHAPE_NONE, leaving my contorted torus as a prim:

Land Impact 897 (!).

I then set  the contorted torus to PRIM_PHYSICS_SHAPE_CONVEX

Land Impact 2 again.

After that, I'm rather less alarmed than was I before.   It's going to be rather more work to convert objects than I'd expected, but they're not going to be irreparably broken (and, much of the time, if I simply want to phantom sculpties, I can do it by script and change the legacy prims to convex simultaneously).

I am rather concerned about what happens to no-mod objects.   I'd taken the comments at the various office hours to mean that the volume detect hack sculpties (and conventional prims?)  which were rezzed in world when the changes were implements would be changed automatically -- I'm hoping this means the conventional prims will be changed to convex hull, too.

 ETA -- I later rezzed my test object on my home sim, which is on the main server channel.  LI 2 as prims, LI 4 as convex hull + none, and I didn't dare test prim + none because I don't have 897 prims to spare at the moment.

[badguy Boozehound]

ll volume detect is unstable and we can grab ppl driving a car by right clicking them hmmm strange that problem used to be solved . but now we are back to what the phisics were like over a year ago . and worse ll volume detect is used in alot of things and when its unstable it probally effecting half of secondlife