WolfBaginski Bearsfoot

Vehicle use is generally good. Some of the old problems are still there, but we're back at the quality level that followed the intr#oduction of the threaded code, Still glitches apparent at the moment of region crossing, but few total failures, On the missing prim problem, while I usually hear people warning against cache clearing, I chose to clear cache, going by the possibility that there might be bad data which explains why particular prims always seem to be invisible. And, so far, that does seem to have made a difference. I'm not sure this is a good idea, but if you're seeing the same prim go missing every time, it may be worth doing. Clearing Cache is not a panacea, and your bandwidth consumption and general lag will go up for quite a while.

How many people out there have their own Spitfire in Second Life? Isn't it about time we got together over the Blake Sea and tried a mass flight? The technical term is a "Balbo", named for the Italian aviator who led a large formation of flying boats from Rome to Chicago. No need for precise formation flying. No dayes or times fixed yet, but if you're interested, post here with a possible time. Then all we need is a sucker volunteer with a Dornier

And yet on the tests I have done so far, the missing prims I have seen have been parts of linksets, present 9in the physics model but invisible. It was all fitting in a pattern, and then your edit popped up. I use Firestorm, and it hasn'r had a release since December, so I was willing to write it off as a Viewer problem. I know of a couple of glitches glitches that are gone in more recent viewers. Thanks for keeping us informed. Vehicles are much better. There is a pirate battle underway. There has been a rush to get back into the skies over Second Life. The last time I saw this much activity at an airfield they were scrambling nuclear bombers.

This missing prim problem does seem to have become worse after that latest roll-out. It is unpredictable. in general, though some prims have been very consistently afflicted. Using Alts, from the same machine, with the same cashe, and the same Viewer, one will see the prim most of the time, while the other has to go through the right-click process most of the time. It doesn't seem to make any different which of the two Alts logs in first, after this computer has been restarted. I should note that this problem, if it is a Viewer bug, may be obvious in Firestorm because there are not freqeunt updates. If it's been fixed in the Linden Viewer since December, we'll be stuck with it in Firestorm for a while yet. And the combination of CHUI and Server-Side Baking may have messed with all Viewer development. It's a big change that has to be ported to a TPV and tested. Maestro, if this missing prim problem is a Viewer bug, and already fixed in the Linden Viewer, please let us know, so we can stop pestering you. But, if it is such a bug, it feels a little odd that it gets worse after a change to the sim code. If you're changing the signalling between sim and viewer, I hope you remembered to tell the viewer team. Sorry, Maestro, but I have become accustumed to LL appearing to be generally lousy at communications, both internally and with customers. It may not be the problem this time but, as with the race not always being to the swift, it still appears to be the way to bet.

How To Contact Support does have at least a veneer of continuing usefulness. It has an apparent purpose. Whether Support is worth contacting, I sometimes wonder.

have my doubts as to whether that outfits works well when the wearer is dancing. Pants and short skirts seem to work much better. Whether that counts as tacky or not, I'm not sure.

The reported problems with display names and groups may be nothing to do with the specific sim server. I saw that happen a couple of times during the weekend, which was weird in a lot of ways.

So the vehicle-crossing fix didn't make it to main channel. %&?%$@%*&! William Tare Fox and similar expressions used by dismayed aviators.

I'm getting a bit worried. The Grid seems to have been unsually lag-ridden over the weekend, and it doesn't seen to be the in-world griefing that can be blamed. Severe lag spikes, that sort of thing. Weekends usually have more people connected. It can show up problems. I really hope that this isn't down to some server bug that will block the code being tested in Magnum. Next weekend is Easter (and Pesach), and if we don't get that particular fix, I am not going to be happy. With the griefing I am already somewhat grumpy.

One thing you should try, with any viewer, is reducing the bandwidth setting. It doesn't matter what your internet connection can provide; a setting of 500 is high enough for most purposes, and more reliable. There are four components which every avatar has to have: hair, skin, shape, and eyes. Changing one of these usually the hair, can kickstart things and get you out of the cloud state. Check with the in-world support group. If you have a problem with Firestorm, you can actually get support, which is one-up on Linden Labs. Hopefully, this particular problem will become a thing of the past when Server Side Baking rolls out. There's a new Firestorm release lurking in the wings preparing for that event.

OK, it's a Canadian University, in Hamilton ON, with a long history. Being in Canada, it looks as though the legal protection for your privacy, quite apart from any academic rules on research ethics, is rather better than that any leagl protection that exists in the USA. And this notice is a lot more professional than some of the students who pop in-world saying they are writing a paper. It's a personal choice whether to take part, of course, but let's not mock the people who do make an effort to do such things right.

This particular attack has happened several times since the weekend. The common factor is the creation of large scripted prims, which fill up any land parcel where building is possible, and spew out thousands of massages which fill your viewer window. While these spamming objects are active, you can get a new burst of spam every time you log in within range. The primary remedy is to Block the creator/owner of the boxes, using the username you will see in the notifications. The process may be impeded by the sheer number of notifications affexting your viewer. Log out, and log-in somewhere else, after making a note of the name If you control land, I would urge you to not allow public building and set an autoreturn time of a few minutes. If you cannot regularly check your land, you may find a heap of these spammer-prims on your land, you're popularity will plummet, and you may receive highly critical IMs as you have extended the effect of this attack. You may even be invited to perform anatomically implausible assaults on yourself. I have given up on expecting useful results from an Abuse Report, but making a report is a right-click option for the Goon Squad prims. Usernames I have most recently seen associated with these attacks are goonsquadarmy and JanetBoomBoom. By naming them I anticipate somebody playing the moderator card on me. Not naming them increases the effect of these attacks and any moderator who is thinking of objecting should consider that such action makes them accomplices to the griefer. Earlier attacks used other disposable accounts, including one which was such a blatant breach of decency rules that I am astonished it could be created by a new user. I expect other names to be used, and you should make yourself familiar with the process to Block another user before you might fall victim to these attacks.

One minor little admin niggle I'm noticing. The Calendar, RHS of the Status page, always gives the start time for the Main Channel rollouts as 5am And they seem to be consistently starting, according to the actual Status Reports, at about 7am. Maestro, if the Calendar start time is the time you and the team have to show up for work, and you do a couple of hours of setting things up, it makes some sense. But it still looks a bit slipshod. It could as easily be an obsolete setting that has never been fixed. With today's inventory maintenace scheduled to start at 5am, the combination could be seen as a little reckless.

I've been led to believe that some of these unspecific bugs are security-related, which would jusftify the reticence. But I agree that a little more info would be helpful. A JIRA reference of the form SEC-1234 would be rather a giveaway, so how to resolve that conflict? Maybe something like Magnum-Wk01 to identify where and when the bugfix went public?

I consider myself an Anarchist. I've studied the philosophy, and Anarchism bvaries a lot. Common successful Anarchistic structures are typified by a bottom-up power structure and by a strong sense of community, both features that can go sadly wrong. In that light, I have to say that SL is not Anarchy. It is, maybe, Libertarianism under the sufferance of an essentially Capiitalist power structure, domninated by a few who manage to have the ear of the real power holders. In SL, all you have to do is pay your money and you have absolute power in a specified part of the Grid. And, whatever you choose to do, it seems that Linden labs will not interfere. Kropotkin, over a century ago, pretty much demolished that approach as a sort of Anarchism. With the apparent sustained lack of governance we might have a small-a anarchy in the ancient sense of chaos and rule by those string and ruthless enough to enforce their will. And that seems to be the anarchy on which so much of modern Libertarian thinking seems to be build. And one particular reason why SL cannot be Anarchy is that were are imprisoned by a set of constraints imposed by Linden Labs. Anarchism gives all a duty to participate in the governing community. It is built on collective social duties: you do not stand by and let a neighbour's house be consumed by fire. You do not wait for your neighbour to give you permission to fight the flames. Inded, it would be a strange society which did not permit such intervention. Substitute "griefer" for fire; see those great tumbling piles of scripted prims, screaming abuse and textured to offend many, which drag a region down into unusability; and you will find that there is nothing you can do without explicit permission from your afflicted neighbour. And, I regret, the Linden Response is inadequate: you can do the equivalent of calling the fire-brigade, but the engine is pulled by spavined nags fit only for the glue factory, and nobody has the matches to light the fire that raises steam for the pumps. All they can say is "Keep the fire going until we get there." No, SL can never be Anarchy. It is something far worse.

It's pretty easy to build a set-up that simulates an extended ping-time for testing effects on a network. You have a dedicated box in the chain from server to client that can introduce a variable delay. Might be a dedicated network test gadget, it might be a cheap Linxu box with the right software, Actually, it doesn't simulate an extended ping-time, It just adds a controllable delay to the network traffice that passes froim one ethernet port to another. And the extra ping time is real. Look, even I can find out about such things with a Google search. It's in Wikipedia. If Linden Labs can't do this sort of test, well on past performance I can't say it astonishs me.

I don't see any of that improving the current mess I see with the Grid. Let's save everyone's time and re-read last weeks Deploy thread.

I do get the impression that the Lindens can pretty reliably measure the sever-time involved in the sim-crossing, but I am less confident that they are able to measure the time delays invoilved in actually transmitting the data over a network. Using such things as variations in ping time as a guide, I could be seeing five times as much delay in server to viewer traffic as somebody in Linden Labs might experience. How much the total effect is on sim-crossing, with most of the data transfer happening between Linden servers, I don't know. But it could extend a delay into the realm of human perception. And second life transmits so many different sorts of data, from different servers, that I cannot see how anything can be delivered in a steady stream of regular packets. It's possible that taking the load off the sim servers has eliminated any chance of maintaining a steady flow. The sim server knows to send a position update, but it no longer can know if some large packet of texture data is likely to get in the way. It very much seems as if Second Life might be behaving for everyone as if we were trying to simultaneously run a bit-torrent with no particular attempt to prioritise any particular sort of data packet.

This is pretty much what I am seeing. My last test run involved 16 sim crossings. 4 of them went severely wrong. rubberbanding by at least one sim-width, followed by a prolonged pause before the vehicle went back to somewhere on the offending sim-boundary, with camera and avatar sit displaced from vehicle settings. Every crossing had some rubberbanding, and there was rubberbanding within every sim. I had draw distance set to 32m, which can be a bit short for driving. On three occasions the prim road never appeared before I had passed over it, although the physics engine knew that something was there. In most of the regions, my Avatar was the only one there, suggesting that none of the glitches were incidental to the actions of other avatars. On at least two occasions, distant objects did seem to start rezzing. This test was done with a ground vehicle, and during the extended rubberbanding episodes, the vehicle seemed to stay at about ground level, and terrain became visible. The movement might be attributable to imterpolation by the Viewer, but I don't see how the Viewer knows the local terrain height deep within the next sim. I find myself wondering if a part of the general problem is associated with delivery of Navmesh data. If this behavious were happening on an RC channel, I would consider it reckless to promote the code to the Main Channel

With UK news media reporting that RBS, one of the major banks, has been having computer problems affecting payment, it was worrying when I got one of the usually vague Linden Lab emails telling me that the Premium Payment had failed, and the recommended remedy also failed. I was very careful to be sure that I was logging in to a Linden Labs web page, but I was getting "Unexpected Error" Eventually the problem seemed to sort itself out. Was this a transient problem? I hope so, but I get stuff from other US sources and, taking into account the number of transactions, Linden Labs do not seem to have a reliable system. Don't Panic, and check those web addresses before you log in or submit payment data. A fake web pahe that throws up an error before sending you to the real site to "resubmit" those card details is an old trick. But even real errors are worrying.

This all looks a bit sub-standard in the area of research ethics. OK, I'm not inclined to click on any links to on-line surveys, and I'm not likely to answer this particular sort of question (clue: my AV is not human anyway), but I really don't know if you're who you claim you are, and that's a big obstacle. And "a short survey on Google" doesn't give me any confidence that this is proper academic work.

Ayesha, you flatter me. I am but a bear of very little brain.

It's not directly linked to the new code, I haven't yet done a test, but I can confirm that misplaced sits on sim-crossing have been affecting ground vehicles too. Also, camera displacement and very prolonged sim crossings. It's consistent with the patterns I reported when the threaded code went grid-wide. The process doesn't fail so often, but there can be a prolonged period of controlled displacement and pitch/roll/yaw before the process completes with a jump back to the vicinity of the original crossing point. It occurs to me that one possible cause for all this is lousy network communication between sims. Some of this may be down to interpolation by the Viewer. There is an option to turn Interpolation off (Advanced menu?) which means the vehicle just freezes at the region boundary until the sim-crossing process completes. Some of these sim-crossing problems became worse when Pathfinding was released. I know that it isn't particularly linked to the use of Mesh. From my own experience, I cannot avoid the feeling that I am wasting my time when I report these obvious faults: the Lindens never seem to listen. Mesh still feels like an incomplete project. Pathfinding caused us much grief, and seems largely unused. I'm finding it difficult to have confidence that any new project will be worth the hassle. Threaded region crossing isn't worthless, but even just walking around, it is obvious that there are huge unresolved problems. It might not all be under the control of Linden Labs. Maybe design choices at the core of how SL works just will not work any more on the modern Internet. Viewer 2 did give us a reworking of the Viewer code. Has any rewrite on the same scale ever happened with the sim server?

It may have helped that I eventually submitted a support ticket based on the secondary effects: general region lag associated with a huge number of scripts. My original AR seemed to have been ignored. The Linden who checked on the support ticket apparently escalated that to an AR which was acted on. But I had waited. Original AR: Fri, 1 Mar 2013 12:34:54 Support Ticket: Sun, 03 Mar 2013 00:08:01 Response to Support Ticket: Sun, 03 Mar 2013 09:15:08 (All above dates/times in PST, aka SLT) Of course, the Governance Team never says anything. I was wondering if there even any point in logging in before around 09:00 Monday.

There are some Lindens I would still buy a drink for. But not many.