A Few Random Observations
It's been a while, hasn't it? Nothing much to report about SL lately, at least from my end. Just another month of tinkering and such. I have, however, noticed a few things about working at high altitudes that might be useful to someone.

While working on the SkyLounge (first mentioned here, about 2/3 of the way down) and on my modest attempts at the SL altitude record, I ran across a couple of interesting things about high altitude operations in SL.

As I mentioned before, it is quite possible to build long-lasting structures above the non-physical movement limit (768m). The trick is to avoid moving them once they're in place, so that they don't spontaneously jump to the non-physical ceiling. Rezzing them in the proper place (via script) is the easiest way to do this.

However, I've noticed a couple of wrinkles with high altitude builds in the past few weeks. First, there appears to be some form of cleanup operation that runs when the grid is rebooted after scheduled upgrades (and possibly after sim crashes and resets, too, although I cannot confirm this). After a reboot, any non-physical object above the non-physical ceiling has a chance of being returned to the owner. Or, if it was rezzed by script, it has a chance of disappearing altogether. (The latter may depend on your STATUS_DIE_AT_EDGE and STATUS_RETURN_AT_EDGE settings.) This behavior isn't consistent (I've had the SkyLounge stay around after some upgrades, and disappear after others), but it happens often enough to be a real problem.

This problem, however, was fairly easy to solve. As mentioned above, we're already rezzing the high altitude builds by script. In my case, I was also already using a scripted object (a physics-enabled elevator located at ground level, see the Garden of Mo link on the right) to transport avatars to the SkyLounge. It was a simple enough matter to build in a sensor that scans for objects named "SkyLounge" when it was in range, and rez a new copy of the Lounge if necessary. One could do something similar with an automated system (a sensor-equipped rocket launched every N minutes?) to accomplish the same result. It's a bit of a pain to pack everything up in a rezzable bundle, but otherwise it's not a huge issue.

While working on the SkyLounge, I discovered another nifty trick. The non-physical movement ceiling can be used to your advantage to speed up the return trip. The return platforms are simple non-physical movers. As such, when they attempt to move during normal use, they jump from their current elevation of 4000m to the non-physical ceiling at 768m. Voila! Instant three kilometer teleport! I thought that was kind of nifty, anyway.

While working on my abortive attempt at the SL elevation record, I found out something interesting about the behavior of objects rezzed above the object ceiling. As you may know, any non-attachment object that moves above 4096m is returned to its owner. However, I discovered that this de-rez is not instantaneous. An object can exist for a fraction of a second before disappearing. This small window of time can be used to run scripts triggered with the on_rez event. I haven't performed many experiments, but I did find that the scripts have time to speak two or three lines of text (using llSay), apply one or two physical impulses to an agent, or perhaps perform other quick operations before disappearing.

It's hard to imagine too many uses for this little bit of trivia, but I was able to perform one somewhat interesting experiment with it. In an attempt to build a faster vertical thruster, I attempted to use external scripted objects to push my avatar upward several times a second. I made a scripted attachment that rezzed a booster prim once every tenth of a second. The booster prim, in turn, attempted to push me upward as many times as possible before disappearing. It was kind of a small scale version of Project Orion, but without the nuclear fallout.

The experiment was a mixed success. It worked as planned, but could only achieve constant speeds of around 26m/s. I can see methods for improvement, however. Many people have built highly effective (as in millions of meters in a fraction of a second) avatar launchers composed of hundreds of prims pushing together in concert. My booster was only a single prim. Perhaps my next attempt will use multi-prim boosters.

My other concern was the distance between the booster object and my avatar. My initial experiments simply rezzed the boosters as fast as possible. As such, if my avatar was already moving at a substantial speed, it could be a considerable distance beyond the booster before the first push lands. Future experiments may involve slowing my avatar to a full stop prior to rezzing the next booster. This would slow the process, of course, but it would assure that the booster was right on top of the avatar when it fired. This could be especially helpful with the multi-prim booster idea. But finding the optimal timing for maximum net speed could be tricky.

I may have to come back to this someday, when I'm especially bored.
Posted by Moriash Moreau at 6:26 PM