Judith Flow

I ran into an aircraft now that seems to cross fine so far. Sure, it still occasionally has the old fashioned bugs on sim crossings, but on successful crossings, the physics of the vehicle at least seem persistent instead of going haywire. I'm not sure how the builder (MeganAnn Mills) did this exactly, but she did tell me she scripted some kind of physics reset into her script which triggers on every sim crossing to circumvent the problem. So far it seems to work, I haven't experienced a single physics mess up in her plane so far. But, while I'm glad that she seemed able to built a fix into her script, it does mean a piece of code is triggered on every single crossing, which is undesirable from a resource-efficiency point of view. Crossings should simply work without having to run a redundant bit of code every time.

Since maybe a week, I noticed the physics engine of vehicles regularly go haywire on simcrossings. The effect is very inconsistent regarding both what happens and when it happens. What I've experienced so far: vehicles going into a random spinvehicles completely stop movingairplanes plummeting down to the groundvehicle orientation changes (switching left and right, or forward turns into up, etc.)The vehicles ALWAYS stop responding to any user input, whether it's directional or attempting to turn the engine on or off.These are NOT the usual lag effects we've seen in the past. Instead, these effects seem to change the behaviour of vehicles themselves or their script on simcrossing. I haven't found any pattern for these occurances either. One moment, crossing from sim A into sim B goes perfectly, 3 minutes later, going from that same sim A into that same sim B crashes the vehicle in one of the ways described above. It's completely possible to see someone in front of you pass without trouble, while you get hit with this new "feature" yourself. I've also noticed it happens with vehicles from different creators. Some I know to script their own planes, of others I have no idea whether they script themselves or use standard or 3rd party vehicle scripts. I have spoken to a few other residents who encountered similar problems, I just haven't found anything online about this "new feature" yet.

I did notice baking sometimes gives incomplete and blurry results. I'm not sure if my appearance is the same for other people when that happens though. But it happens most often when I change multiple layers in succession. Like, when I put on a shirt, and just before my character starts replacing the texture, so when the server is probably in the middle of the rebaking process, I add a jacket as well. What seems to happen there, is something like this: put on shirt -> server starts rebake process -> put on jacket -> server starts a second rebake process -> first rebake process finishes -> server stops both rebake processes because the first rebake process finished and (correctly) sends the results of the second rebake process. But, that second process is incomplete, resulting in a blurry texture getting sent to your avatar. This can be fixed by wearing another layer of clothing to that area of your avatar, like an undershirt or a tattoo. But I can't say I find that an ideal situation. Especially not if the incomplete bake was actually for the appearance you were after. I'd almost wonder what happens if multiple people start changing outfit at once on the same sim. Taking off the jacket and then putting it back on doesn't seem to fix it. It seems like the server keeps the resulting texture in cache for a little while, so adding another layer of clothing or a tattoo (even if it just has a transparent texture defined for that area, just as long as there is a texture defined) is the best solution we have for now. Suggestion for a better solution: make the avatar rebake function send a message to the server instead to make the server rebake the character, and have the updated texture sent back to the viewer.

If it's one specific region, then contact the owners of the region (if it's an estate) or Lindenlabs (if it's mainland) and ask for a restart. Lindenlabs rarely does this, but it's always worth a try. Estate owners are generally more focussed on keeping things running. Something else to consider: Lower your drawdistance. I really wish Firestorm hadn't flatout disabled the DD gestures, since the gestures gave the user a lot more control over how to rebuild their drawrate depending on where they teleport to, and it can even improve success on teleports

I found it varies a lot, depending on latency (if the area I'm in rezzed slowly, then my avatar will rebake much slower as well), server lag (if one of the sims on the server is taking a lot of resources, then something else can be affected, like rebaking), and on whether I use http texture retrieval or not. It's generally slower without, but my crashrate goes up a little when I use http, so I often turn it off when I do something that might strain my connection, like flying (constant sim crossings, constant downloading of new objects, models and textures). And that's just some of the things thataffect avatar baking.

1 B/C. It's nice to feel welcome, but it doesn't have to feel like it's someones' job to welcome you, that makes it feel a bit strained, and insincere. 2 A. A personally typed "Hi judith" simply feels more sincere than <insert giggle sounds and wooshes> "~o0 XoXoX Hi Judith XoXoX 0o~" that I *KNOW* is for 90% automated. If you don't want to spend time on giving me some attention, than don't try to fool me into thinking you are. 3 B. They're a necessary evil, but practice restraint in their use. 4 B. 5 C. 6 D. Practice a lot of restraint, and invest into some kind of display for the schedule. Sending a notecard once a week in the group with the next weeks' schedule works too. But "announce" things too often, and it will start to feel like you're begging for attention or customers. Overall, these are things you have to get a feel for as a host I think. I'm glad I'm not a host myself, but some simply annoy me to hell with their constant yells and shouts and group notices (I rarely stay in such groups for long), while I'm happy with others who seem to actually have a feel for their visitors. The former I mentally ignore within a few minutes, the latter I pay attention to every time they say something.

For those who don't know what Petite Mesh Avatars are: they're mesh avatars created by Yabusake Loon which are only about a third the size of a regular Avatar. Because of their size and certain other properties of these avatars, many regular animations actually do NOT play correctly. Specifically, animations involving hip-movement will not play perfectly well on these avatars, though the impact of any distortions can be so small that it's hardly noticable. However, on certain animations, like ground sits, floor- and poledances, the distortion can be very apparent, causing Petite Mesh Avatars to float in mid-air or sink through the ground. This little guide is for manually adjusting your LOCAL animation files, so unless you're a creator, you probably won't have any use for this guide since it involves directly hacking into the .BVH files. Tools needed: Notepad or a similar program, but for this guide I'll assume you use notepad. Okay, the first thing to do is: make your animation as usual, process it and everything as usual as well. Just everything you usually do untill the moment where you'd usually upload your bvh file to Second Life as a regular animation. Now, instead of uploading to Second Life, open the .bvh file in notepad. Notepad++ or certain other editors might work as well, but just good old Notepad works perfectly. Next, TURN OFF WORD WRAP. I know you'll getting some extremely long lines, but don't worry. We need to edit some things, and those things are right at the beginning of the lines involved Scroll down a bit, untill you get to: MOTION Frames: (some number, probably 30) Frame Time: (another number) Right below that, you'll get a long list of all kinds of numbers And we're going to edit some of them: the first, second and third number on each line! These first three numbers are the positions of the avatars HIP, in the order X, Z, Y. Yes, Z and Y have been reversed. Now let's see how exactly we're going to adjust these numbers. For the first and third number on each line, divide the number by 3. That's it, just divide by 3. Why 3? That's because your avatar is only a third the size of a normal avatar, so hip movement needs to be only a third the amount of movement found on regular avatars. The second number on each line except the first needs adjustment too, but this one is a bit trickier! The default vertical offset for the hip is usually something around 43.5, where the X and Y default offsets are 0. That's why those were easier to adjust. The safest method I found, was writing the second number from each line down, so I'd get a list looking like: 43.528519 37.764259 32.000000 24.500401 12.000000 2.000000 2.000000 Behind that, I write down the increments from the previous line, so: 43.528519 0 37.764259 ~-6 32.000000 ~-6 24.500401 ~-9 12.000000 ~-12 2.000000 ~-10 2.000000 0 Next, I divide those new numbers by 3 again, so I'd get: 43.528519 0 0 37.764259 ~-6 -2 32.000000 ~-6 -2 24.500401 ~-9 -3 12.000000 ~-12 -4 2.000000 ~-10 -3.5 2.000000 0 0 And finally, I start from the first line, adding those last numbers I got to get a new list of z-offsets: 43.528519 0 0 43.528519 37.764259 ~-6 -2 41 32.000000 ~-6 -2 39 24.500401 ~-9 -3 36 12.000000 ~-12 -4 32 2.000000 ~-10 -3.5 28.5 2.000000 0 0 28.5 And use those numbers in the list I got Another way would be to use the formula: (new offset - default offset from the first line) / 3 + default offset from the first line. So if a is the Z offset from the first line (43.528519) And b is the Z offset from the line you're working on (for example, 32 from the third line), you'd get: (b-a)/3 + a => (32 - 43.5)/3 + 43.5 => -11.5/3 + 43.5 = > -3.8 + 43.5 = 39.6. So 39 wasn't too far off for a crude estimate ^_^ Now save the file, preferrably change the name to save your old one incase something messes up, and upload the new file to SL. There you have your Petite compatible Animation! Note on all these divisions by 3: the amount is actually *roughly* 3. So you might need more fiddling to get an animation aligned just perfect, but it's close enough already to make distortions hardly noticable. I'm sure someone could write a little external program or poser plug-in to automate updating your .bvh files, and I actually parsed this information to someone and asked him to do so, but untill then, manual has to do. In case someone decides to automate this process: I post this to help the community in general. I'll support you in automating it, but I won't support anyone using this information to establish a monopoly on its use, and will merily unleash legal hell if things like DMCA's are used against other people trying to automate this process. I want to help make SL a better place, not help you get filthy rich over some faulty abuse of permissions. Judith Flow

It might simply be other animations, like the default sit animations etc. interfering with yours. To prevent this, try changing the angle of every single joint by ~1 degree on the THIRD frame, which should be the frame where you actually start your animation. This "locks" the joints in place, and prevents other animations from overriding yours, unless those other animations have a higher priority. Which is, believe it or not, sometimes a GOOD thing, so don't assume right away that your animation should have top priority. It's usually system-animations interfering with your animations, and those generally have lowest priority anyway, while something like animated food SHOULD have higher priority, since those animations should only alter the angles and positions of the hands using the food, to make it look like eating, while not interfering with any other joints.

I have display names turned off by default for several reasons. 1. A display name has no meaning if it can be changed on a whim. Why the hell should I be bothered with keeping track of who's who when people constantly change their names? Who's who on my friendslist? Who's who in that group I'm in? I seriously can't be bothered to find out. If people want to hide behind a new name, then I'll let them hide behind that, but not in my friendslist. 2. The old username system provided unique usernames, display names do not. It's totally possible to find 20 people standing together with the exact same display name. Good luck addressing a specific one of them with that. 3. Usernames are currently a VERY easy way to make threat assessments for griefers. Does the user have a last name? The chances of him/her being a griefer go down noticably. A user with an old name intent on griefing will generally make a throw-away account which does not have a last name, instead of using his/her main account where all his/her items, contacts and lindens are stored. Yes, this may sound harsh, but under circumstances where there's a high griefer threat, I look suspicious at anyone without a lastname. 4. Displaying both a username and a displayname clutters up my screen. I don't like that, so I display only one. 5. The old firstname-lastname system actually encouraged some smart usercustomization. The first name was for customization, the lastname for identifying. Two people could both be named James, but they'd still have different lastnames for identification purposes. I DO think display names are a great addition to second life. But I simply don't feel they warranted the removal of last names.

While I do regularly enjoy flying and ballooning myself, I also have a skybox right below cloudcover that I wish to keep private. So my solution? Rez a phantom hollow megaprim around it, though still within my own bounderies, and texture the outside with "banline tape". The non-flickering kind, and low resolution (128*128 I believe). So it loads pretty fast, is visible with any view setting over 30 meters (and to really enjoy ballooning, you'd want a view range of at least 150 meters), and gives plenty visible warning to anyone coming near it. There's still a 10 second security orb inside, which is set to boot a person home, but it doesn't extend outside the megaprim. Result: fast airplanes can easily fly through in the rare occasion they don't spot it in time (though they risk crashing into the skybox then, but that's their problem for flying faster than their surroundings rez), while ballooners get plenty of visible cue to navigate around it. It might not look too awesome to my neighbours, but go 50 meters up or down, and it shouldn't bother. And yes, you do own all the space above your land. Common practice, is to rez a prim at the corner of your land, and then simply change the z-position to your intended building height. When you go outside that perimeter, you're encrouching your neighbours. When your neighbours come inside, they're encrouching on you. It's up to you how to handle such. But if it breaks your enjoyment, for example because you can't even skydive on your own land, then they HAVE to move out the prim, and if they don't, you CAN AR the object, in which case a Linden may eventually come and just remove it and anything else attached. And your neighbour won't like finding his skybox in his Lost & Found while logging in naked, but that'd be his problem for being stupid.

Well, it seems my alt, who's on another computer experienced the exact same teleporting problems. I switched to Phoenix myself, while I kept my alt on the new LL viewer. Which is rather inconvenient, since teleporting basically means having to log out, and logging back in with the the place you want to go as target destination. Just brilliant.. Completely cleared all caches, uninstalled the viewer and re-installed it as well, but that didn't help either. At some point, my alt for once saw a neighbouring sim on her minimap (those had disappeared from there too). So, I attempted to fly over, and now my alt is ghosted there, waiting for the sim to restart. Sorry, but I think it's just too much of a coincidence, how all this started right after the forced viewer update, while 15 minutes before that everything worked just fine (as far as that's even possible in SL). I guess I'll get an email about the whole thing in about 5 weeks saying the ticket is resolved. Though I'm hoping the usual rolling restarts on wednesday sort her out. For now, I'll just stick to Phoenix and Kirstens'. Even an experimental version of Kirstens' has less issues than a Linden Labs final release!

A forced viewer update.. And suddenly I can't TP anymore.. That's just too much of a coincidence to my liking :-/

If it has volume control, set it to 10-30% at most. It's an okay effect really, except that most who use it have the sound set to 100% so you can hear it all the way on the other side of the sim. At 10%, it's clearly audible within 3 meters, with the sound dying down real fast at larger distances. And to not make you look too silly, turn it off when you're on a beach. It's already odd to walk on sand with stiletto's, but it's simply stupid if it also makes a noisy click-click sound!