Cerise Sorbet

AOL already shut down some of their shoutcast hosting a couple weeks ago, maybe all. Independent shoutcast hosts ought to be fine, just the yp listings might not be available any more.

Perrie Juran wrote: Cerise Sorbet wrote: The trouble is that many region owners have paid LL to have their regions moved to specific spots on the grid. Even if the effects would be insignificant, there would be screaming. IT would have been a different story if LL didn't charge for region moves in the first place, or at least didn't charge US$150 for the service. Isn't that for attachment to specific other regions? I don't think moving would disturb that. Those clusters would be moved together. I doubt any one asks to have a stand alone region place in a specific area. No, it is for any move. Some of these arrangements were just to get a region near another, even though they aren't connected, and even though there isn't any technical benefit to that. People paid to have their regions put where they are, whether you think the reasion is worthy or not, and they should get what they paid for.

The trouble is that many region owners have paid LL to have their regions moved to specific spots on the grid. Even if the effects would be insignificant, there would be screaming. IT would have been a different story if LL didn't charge for region moves in the first place, or at least didn't charge US$150 for the service.

There would be no loss of waterfront if the continents were moved, just look at how Sansara and the atoll were connected. Moving the estates in between would still be needed to avoid making a connection incredibly tedious and dull, there is a lot of territory in between, and it's really extra wacky if Zindra is taken into account. It's guaranteed that estate owners will scream if their regions are moved en masse, because it's a change and they didn't request it and there would be some down time.

They would have to move mainland continents to make it practical. Landmarks would survive this, but the hundreds of estate regions that have been placed in between over the years, and would also have to move, might not like this at all. There were supposed to be more changes related to region crossings that would (at least in theory) make a Portal style of region cross possible, but the work that would make it possible seems to have been on hold for a couple of years. So I wouldn't hold my breath on that one.

Eh, it's been an ongoing problem, wrong names, images, feed entries have appeared throughout the site. Most of it was recently cleaned up, conincidentally after the rodvik.linden profile got corrupted. (his feed is still messed up, atributing his comments to nessiah mint, and his profile picture is missing)

No, it did not work correctly, it was only able to work right in limited circumstances, after all objects were loaded. That would be fine for a static environment, but it was utterly broken for a dynamic virtual world. The problem is that the viewer would be rendering those 5 million polys much of the time, when it should have only been rendering half of them. That's an extremely common case where the software was utterly failing.

arton Rotaru wrote: Nah, it always rendered what is on your screen. What is not on your screen isn't rendered. This viewer only loads things in another order. If your scene is fully loaded, and you have 5 million polys in view, you have still five million polys in view. That doesn't even make sense. What is on the screen is determined by what is rendered, not the other way around. That is how it gets on the screen in the first place. The big problem was that the viewer lacked enough information to know what NOT to render in a timely fashion. Object occlusion couldn't do its job properly, so objects that should have been out of view, were in view, and got rendered when they should not be rendered. Now it has that information, and object occlusion can do its job right away.

arton Rotaru wrote: It still will render the same content as always. It won't do that, and that's the whole point of the exercise. The old system left the viewer to render stuff it didn't need to, and these changes reduce that greatly.

Ceka Cianci wrote: So i'm curious..will it be in my benefit to get this new viewer or does it matter? You'll get the same features sooner or later anyway, after other viewers merge it in. This particular viewer is out there for testing and bug hunting. It is definitely worth a few moments to download and try, for anyone who has slow rezzing issues and wants to see if there is a light at the end of the tunnel.

It can even be simpler, just a bit of llMoveToTarget to drag the avatar to the last known spot without collisions. It looks wonderfully silly, and I've always thought that leash scripts should spin particle birds or stars around the wearer's head. Sometimes the most fun comes from letting SL act like SL.

Avatars can be moved with several of the physics functions, and in many cases the autopilot feature will kick in and make if look, well not awesome, but not so bad.

That is probably as good as you will get, if your aim is an "eyeryday" avatar that feels somewhat realistic to its wearer. If the giant was part of some kind of game environment, a plan B might be some kind of transparent sit-on vehicle thing, but that's a serious letdown for general use in a world with so much no-rez land.

The server derives the height directly from the shape wearable at bake time. Animation and mesh deformations are not counted, those are separate from baking. The depth and width are fixed.

arton Rotaru wrote: KarenMichelle Lane wrote: Did I miss anything? About 2) The viewer determines what is of your greatest "interest" by your "Field of View". There are no preferences settings you could set. These can be tweaked with SceneLoadMinRadius, SceneLoadFrontPixelThreshold, SceneLoadRearMaxRadiusFraction, SceneLoadRearPixelThreshold

Madelaine McMasters wrote: If understand the flow of ripped content correctly, isn't most of it coming into SL? That was the initial direction, but the tide is turning as more decent content that isn't available elsewhere comes online. Much of the activity is similar to the old copybot, with models re-uploaded to remove permission flags. Given the limitations built in with SL, exports to wholly different commercial environments won't be too appealing many times, but the SL clone grids are of course good matches.

Because rigging (but that's not in the part of the cache Prok is worried about.)

Prokofy Neva wrote: But as I noted, I'm not talking about the viewer cache. I'm talking about downloading to the hard drive. Unless the mechanics of viewer-caching in fact involve downloading files to the hard drive. Even so, making the file cache significantly larger opens up larger issues. You are talking about the viewer cache. That's what all those files in your SL objectcache folder are. They are binary blobs, but not encrypted or especially hard to read. The viewer source would provide complete instructions on decoding anyway, so there is no point in scrambling them.

The viewer has had this same object cache for years and years. The only real difference with this new viewer, is that it makes those cache files larger, otherwise it's the same old same old. There really aren't any new implications for security (or lack thereof) of inworld objects.

Those people just didn't get caught. It's not OK to use that material. For all the hype in past years, SL is still kind of a niche place, so lots of unlicensed content sneaks under the radar or doesn't seem important enough for some companies to act. Other companies do notice and do act, especially if the content gets wider exposure on the marketplace, write-ups on the web, etc. You'll get better sleep if you don't wander into that game.

Radeon 4800 is from 2008, it was added to the GPU tables years ago. Note also that the viewer ran before the Windows 8.1 update.

Do you have any public rezzing parcels with short autoreturn on the region (the sort that's often provided for unpacking etc.)? If you could arrange it so that the test items are rezzed on that land, and it's not in the same group, then the region can take care of cleaning up for you.

The item is handed back and forth. You gave it to the sploder winner, and it is transferrable, and you are having them give it back to you by dropping it in this second chance box. You want you second chance box to rez objects it received, without knowing what they are. So, you rez one of these unknown objects (which now belongs to you), and it's been scripted by someone to rez something nasty of its own in its on_rez event. And you are hoping that you can find it in your object_rez, grab its details, and return it before it rezzes its payload. And that's on land owned by the object owner, so autoreturn won't be cleaning up. This really calls for an alt account with only a minimal rights to keep the device rezzed, and once you have that you can stick it on a parcel with regular 1 minute autoreturn.

You probably don't want to be rezzing scripted objects from random people anyway. Maybe, instead of handing the item back and forth, you could do this like the game shows, and just ask. "You won half a stale pretzel! Want to keep it, or take your chances and see what's behind door number two?"

NealCrz wrote: while it feels faster thre are other issues Im finding that crash it like paying for land. (Crash) They already committed fixes for the buy land crash and a problem with keyboard controls, so next week's build should have them.