Cerise Sorbet

Yes there have been some changes. Draw distance is only a part of the system. In addition, the server decides what it will and will not tell your viewer. This part, that LL calls the interest list, received some major rewirk this year. The set of objects and avatars you can see with a given draw distance setting did go through some significant changes. There is another quirk, and that is in the "show look at" camera hints. These can be pointed at anything, but they are not an indication that a viewer can actually display what the crosshairs are pointed at. (They also don't really tell you if that is what a person is really looking at.)

Search for "crash mode" in server release notes, there were at least a dozen this year already. Most other security fixes won't be listed at all. On the occasions when they are listed, they are described in a way that avoids calling them security fixes. Viewer patches work about the same way. Even when you can see in the repositories what's going on, the release notes will step around that in the descriptions, or simply not mention them.

Crashers are fixed all the time, then somebody finds new ones. They could prevent most of this very simply, by turning off user generated content. Oh, wait.

Bounces from snapshots will go to www-data@lindenlab.com It's possible they keep them a short time in case they need to dig into big delivery problems, but it's quite possible they go straight to /dev/null.

I just tried a few aircraft on crossings, with RC-RC, main-main, main-RC, RC-main crossings on each, and they are working fine for me. This suggests that the problem may not be with the vehicles, since you say that both your and other people's aircraft are not crossing for you. Other possibilities are network issues that are affecting you, or something about your avatar, maybe "heavy" attachments. Are you seeing this trouble with vehicles that have no avatars sitting on?

I wouldn't worry about it too much yet. The materials repository still has patches flowing in to deal with problems with incorrect interactions between the new materials and legacy bump maps. So, it's quite possible that editor bugs stuck attributes on your object that you didn't intend to put there.

Tini Jewell wrote: can you point me to where something official states that system clothes will no longer be visible? we are all going to be subjected to wearing only mesh??? i haven't seen that written anywhere as yet and would love to know more. thanks! On old viewers that don't support server side appearance, avatar textures won't load, because those old viewers won't know how to fetch them. That includes skins, alpha wearables, and system clothes. I think shapes may be stuck as Ruth too, but it hardly matters at that point. Attachments will appear OK, though. Clothes will work about the same as always for people on up to date viewers.

You aren't going to like this. If you can't update to a current viewer, it's probably time to stop buying system clothes. In a few weeks, once the bugs are flushed out of the server side appearance setup, you won't be able to see those, or avatars in general, either.

Luna Hula is the name you're looking for. For inworld shopping try http://maps.secondlife.com/secondlife/Abbey%20Island/64/43/33 Also on marketplace at https://marketplace.secondlife.com/stores/5457 but the belts don't seem to be available on MP.

Mircea Lobo wrote: Apparently this is meant to solve gray avatars by processing some textures server-side. Although I don't know the SL code, I always thought the issue is textures and shapes taking too long to network over, not the viewer having little resources to process them (since any modern CPU / GPU prolly handles that quickly). Being a developer myself, this makes little sense as to how it's helpful... so I was wondering if someone can offer a better technical description. When LL put in the old baking setup, they were thinking as you are, that this compositing should be an easy enough job for any PC that can handle SL in the first place. In reality, the world is fully of buggy hardware, buggy drivers that aren't or can't be updated, and networks that are a lot less reliable than they should be. Server side appearance is really about eliminating all those variables.

The limits on if statements applied back when scripts were compiled on the viewer. The Windows version of the compiler, in particular, had some tight restraints on nested if statements. At the time when Mono was introduced, all script compilation (both Mono and LSO) was moved to the server side, and this problem went away for practical purposes. There are probably lots of old copies of lslint and similar tools around, that will still complain about this. If you see that, it's time for updated tools.

One other possibility is a buggy or insecure scripted security object. Now that these can change estate level access, broken ones are more annoying than ever.

It would be a feature request, I think. Viewers have been configured to work this way forever. Under each viewer's app_settings folder there will be a keys.ini or keys.xml, depending on the viewer version. The SHIFT + up/down/w/s are omitted from the sitting section. You can add them yourself, if you like. Hopefully there will be someone at LL who remembers why it is done this way, and won't be afraid to change it.

It was probably this thing. Fun shop, that one.

BigThickNick wrote: make it so that I'm able to put my parcel back into my name after it is group owned? No one is left in the group except me. When I set it for sale back to myself it'll jump me up into the next land tier. How would I buy my parcel back without going into the next land tier? Your easiest option may be to create an alt and join it up to the group.

Sort of. It has intel HD 4000 for graphics, so it's not really a great performer for SL. See also http://answers.microsoft.com/en-us/surface/forum/surfpro-surfupdate/surface-pro-5142013-firmware-update-breaks-second/cd973538-2218-4cca-a53d-6125b01bf2cb - a recent Surface Pro update broke SL, but you can fix it by using Intel's driver.

This happens occasionally, the update servers get out of sync when they edit the versions. When I've seenthis in the past, it stopped nagging after a couple hours.

Kenbro Utu wrote: Group liabilities are turned on by default, and if a group owner does not specifically check, then members share in liabilities as well as profits. There have been group owners on the other side of the fence, having sold group land and the proceeds divided among the group members. It cuts both ways. I still have no clue why the default has not been changed after all these years. It did change, in July 2012. It now defaults to off for newly created groups, so the accidental cases should gradually fade away.

This was never really a server bug. It has been in the viewers for a long time. The interest list changes (which have been on all server channels for few weeks now) made this viewer bug much more obvious. The old interest list code sent more updates than needed, and hid the bug most of, but not all, the time. Agan, please see if you can reproduce this problem when running Second Life viewer version 3.5.2. I can't. I can still make if happen at will on older viewers that have not been patched yet.

What viewer are you using? The problem should be fixed in SL Viewer 3.5.2, are you seeing it on that? Other viewers will add patches on their own schedules, of course.

The "agent not found" error is old. It is more common to see it since more threading was added to region crossings some months ago, but the problem predates that by quite a while too. This error happens because vehicles and their riders do not really cross over simultaneously. They are moved individually, then the receiving sim puts the avatars back in their seats. To work around it, use an agent presence check like llGetAgentSize, and skip function calls that operate on avatars unless that returns a nonzero vector. This old office hour transcript explains what will need to be done to solve this for good. Search in there for Carmilla Linden's discussion of differential crossings and atomic handoff. That would be a future addition to the earlier threaded region crossing changes.

If you are using custom offsets, make sure not to duplicate them in more than one linked part, or the viewer will do that jitter thing.

A new SL beta viewer, 3.5.2 (275653) , was released today. It has a patch for the missing objects problem. I have been playing with this build since Friday, and not seen the trouble at all on this viewer. (It is still happening on unpatched viewers.) A read-only objectcache folder is ugly and leaves in some situations when invisible objects can still happen, so I wouldn't recommend it as a regular workaround for unpatched viewers. It was mainly interesting as a test.

Group ban lists are already being worked on, so yay for that. The limited group notices idea would be interesting, LL can figure out if it's practical to make it happen. (groups are full of surprises, the parts that looks simple are sometimes the most complicated under the hood, and vice versa). The best way to get the idea under the Linden's nose will be to send in a bug report through jira.secondlife.com. The BUG project is the right place to drop a request for this, even though it's a feature request.

If you were on a private estate and the region is no longer on the map, you can send in a support ticket to LL, and they can restart the region temporarily so you can get your stuff. Beyond that, they can't help you get your unused rent back. Renting from other residents is a risky proposition, even long term operations with seemingly good reputations sometimes vanish without notice. Keep your eyes open and your rental periods brief.