Pandorah Ashdene

I have been following the discussion here on the forum, and on various other sites, but there seems to be an aspect, that hasnt cropped up anywhere, so, let me play the devil's advocate here for a moment, and let me point out a consequence of the 'official' postion held by Linden Lab; just to make that clear, it is nothing I 'suggest', but it is merely a logical result of how Peter Gray (Linden Lab spokesman) 'explained' the Lab's position regarding the TOS changes; I quote Peter Gray from http://nwn.blogs.com/nwn/2013/09/linden-lab-tos-textures.html: "Linden Lab often acts as an intermediary between Second Life residents (for instance, in its capacity as the operator of the Second Life Marketplace) which necessitates that Linden Lab have certain rights (such as the right to re-sell) in order to effectuate such exchanges or transactions." So, let's think that through, shall we? Agreement to the TOS is necessary for the Lab to be able to deliver items on the market place. So. What will happen now to all the content, that is on the MP belonging to accounts that havent logged in since the TOS change? Because strictly speaking those merchants havent agreed to the TOS change, from which follows their products can not be delivered by the Lab, since agreement to the TOS is necessary for that service. Will all those products be removed and/or set inactive? When is this purge going to happen? Or can we decuce by argument of contradiction, that since the removal is not happening, that the 'justification' is not valid, ie. the position that the TOS change is necessary for the MP delivery just not true? Linden Lab, your move. ((Not that I expect a reply, to be honest - the Lab is as usual 'sitting it out' and hopes for the whole thing to 'blow over', - soon to be replaced by another decision we can all get excited about))

HisaDrug wrote: (...) Also I found another bug today that the confirmed payments on MP only show up on my trasnaction, but on MP. I'm not even sure what they bought because they are untrackable (...) Hisa, I had the same issue and was puzzled for a while, but it seems that the ones that show up in the transaction without an entry in the MP book keeping are the 'latecommers', ie. these are the payments you 'missed out' on; you probably have to go way back in your MP book keeping to find the original purchase entry;

The "customer charged, item delivered but creator not paid" bug is still up and running. Just had one instance myself:

Well, considering the fact that the MP is still not 'uptodate' regarding that merchants still have to specify an object's land impact in the slot 'prims', the Lab seems to have some consistency problems on their own, but can you be a little more specific and clear (not that your post was not fun to read)? Regrads, Pan.

Oskar Linden wrote: (...) The SVC-8124 issue is one which we are working on fixing in the Magnum channel. __Oskar Thank you Oskar, I realy appreciate that 'feedback - even if it's not much more than "we are aware of it"' - as Hitomi pointed out, a lot of the 'anger' and frustration on our side has to with the lack of communication, and being left 'in the dark'; - sorry to say so, but the 'acknowledged' flag on the Jira and the assignement to WorkingOnIt Linden has lost its value over time, where Jiras stayed unfinished in that state for ages; I realy can't emphasize enough the killer-dimension this bug has for people like me with a datacap; without me noticing that hole in the bucket used up this month's data alocation in a few days, before I became aware of the issue and could locate it (- no malware or virus, but logging into SL at the wrong spot); and for the rest of it I am forced to pay each MB I use the net extra; I realy wonder, if you (not especialy you personal) are underestimating the impact this has and the urgencey - it realy is more than "people have to deal with a little more lag than usual"; So, at least it's recognised as an issue and I realy hope you get that fixed sooner than later; - for me personal SL is off-limits for the rest of the month.

You're not serious, are you? My jaw just dropped to the floor. - I am seeing https://jira.secondlife.com/browse/SVC-8124 mentioned nowhere. We are bleeding datatransfer-wise to death, and you are planning "no intentional changes to existing behaviour"? Sorry, I am so angry that I better refrain from posting one more word.

WolfBaginski Bearsfoot wrote: ... At times SL systems are trying to send very large amounts of data, using significantly more bandwidth than I have set as a limit in-viewer. This is maxing out my connection and showing high rates of dropped packets. ... There is a major network bug spaming the pipeline: https://jira.secondlife.com/browse/SVC-8124

Theresa Tennyson wrote: My understanding of the accounting is that hollow objects like tubes or torii are hateful for physics calculations which is why they're penalized. However, you can set the physics type to "none" for your tube and put simpler invisible shapes inside it for the walking surface, or you can sandwich together two scooped out half-cylinders. Hello Theresa, thank you for suggesting possible workarounds for the issue; the matter still stands that the era of one legacy prim = one landimpact is over;

arton Rotaru wrote: Hi Pan,:cathappy: I asked this last week at the pathfinding meeting. It's just like it's described in the release notes. The keyword here is "streaming cost", which is the "download weight" in the viewer. Only the download weight is capped. The physics weight is unchanged. So if the physics weight of a legacy prim is greater than 1, it's land impact will be greater than 1 as well. Hello Arton, It took me a while to wrap my head around your clarification, but I am seeing the problem clearer now; thank you very much. So it is the physics setting to 'Prim' (which is the default when you rezz them) that is the 'source' of the landimpact explosion, which has to be switched to 'Convex hull' to avoid the effect; which is not practical, in case you want the prim to have an 'inside', say a hollow cylinder, that you want to use as walkable canal pipe; I see a lot of grief in this implementation and not the intended "encouragement" to switch to the 'new' accounting;

Hello Oskar, you keep repeating: 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.But this is NOT how it works! Some of us are still waiting for the answers to the questions we brought up in the thread for the deploy of 2012-07-09 (http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2012-07-09/td-p/1595111 ) Would you please be so kind to clarify?

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.

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.

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.

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?

Medhue Simoni wrote: Pandorah Ashdene wrote: Hello Medhue (/me waves), I am not so sure about your remark "It is all mesh based, so they are never going to see the massive overuse of polygons and textures that plagues SL." - what makes you think that? As far as I could see there are no polylimits or any accounting (like LI) in place as of yet, and the texture size limit is 1024x1024, - same as SL; so it should not be too hard to upload pretty 'heavy' meshs ploywise, with a bunch of materials, each of them overlaoded with a 1024. Hey Pandorah!! Yep, you are totally right. I should have elaborated. See there is a big difference between object made with prims and sculpties and a mesh. Each new sculpty requires a texture, and many have really high poly counts for what they actually are. A mesh of the same sculpty could easily be 1/10th. With prims, you need to use many to get a complicated shape, and the more you twist and distort a prim the more polys you get. A prim can also have 6 different textures on it. Plus, even a mesh box can be less polys than an SL cube, and it will only have 1 texture, even if every side is different. Now, when you compare this to a mesh. There is a much higher learning curve to making it. This means, that generally more people will understand not to go crazy with polygons if you don't need to. When you combine this with the fact that a mesh has an editable UV Map, the total texture data saving can be crazy. I've put whole animal skins on 1 1024 x 1024 texture. People put whole building on 1 texture. Just in total texture data alone, you are talking a massive amount of texture data savings. Thanks for clarifying you point of view. And having had a few discussions with you, when mesh was still on Aditi, I know that you are a conscious builder and take all those aspects into consideration; I know that YOU know how to make effective mesh content. I could even lengthen your list of bad building practice, especialy with sculpts, where I have even seen people use 1024x1024 sculpt maps, lol, - but I did not question whether mesh CAN be used more efficient than legacy prims or sculpts; The issue I have with your statement "It is all mesh based, so they are never going to see the massive overuse of polygons and textures that plagues SL.", is that you imply, that the fact, that all content is only mesh there will be "no overuse of polygons and textures". Right now the biggest question for me as builder is "What will be the 'accounting' of builds/meshs?" - what I mean by that, is right now as far as I could see you can upload pretty much anything and rezz it; in SL the upload costs and to a much higher degree the landimpact 'encourage' you to a certain degree to be effective, at least regarding the polycount (you can still slap eight 1024s on the materials, which is roughly a 32MB download for the object); Mesh content without the implementation of an 'incentive' is NOT going to be necesarily 'effective', not if we talk about "user created content"; not if you think of the users that are beginners or hobbyists, that often arent even aware of the 'problem'; CloudParty will have to put a lid on 'usage' in some way - otherwise you can be sure that people will upload & rezz meshs that bring your computer on its knees - and that 'lid' will enforce 'effectiveness'; mesh per se does not guarantee low-lag content or prevent abuse.