Second Life Server

[Perrie Juran Member]

---

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-Sit...

[Pandorah Ashdene Honored Resident]

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 Member]

---

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 Recognized Helper]

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 Recognized Helper]

@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 Honored Resident]

---

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.