Bike Status
As mentioned last week, I've been taking another stab at wiring up my old stationary exercise bicycle. This morning, I more or less finished.


Not too much to look at here, really. A momentary connect lever switch is mounted on the frame of the bike (attached to that bit of plywood there at center), right above the bearing for the pedal sprocket. (I'm making up terminology on the fly here, but it's not that hard to figure out!) A bisected scrap of wooden dowel is appended on the sprocket itself. As the sprocket turns, the dowel passes over the switch and depresses the lever. The switch is wired to the Page Up key, and the associated scripts in SL know what to do with the keypresses (currently measuring time between presses and deducing speed). Simple enough.

This morning's addition involved steering. Over the past few days, I've kicked around all sorts of custom switching schemes to allow me to move in world. Finally, late last night, it occurred to me that modern joysticks might already have solved the problem for me. I haven't used a joystick for a decade or more, and apparently they've come a long way in the interim.

The joystick pictured above is a Logitech Attack 3. Nothing terribly special about it, although it does seem to work fairly well. Mostly, though, it was the cheapest one available at the local Best Buy. The important thing is it allows the user to assign all of the controls, including the axis controls. This was a bit of a surprise, and was exactly what I needed! Currently, it's configured to act as fancy keyboard arrow keys. Push it left, it presses the left arrow key for me. Pull it back, it presses the down arrow. And it has a variety of other assignable buttons, which I've configured to activate various utility gestures in-world. The trigger hits CTRL-F2 for me, which turns my flight control script on and off. The buttons at the base control various fine-tuning aspects of the script. And so on. Pretty slick!

So, this one turned out to be quite a bit simpler than the treadmill project (you can see the umbilical feeding the control interface, monitor, keyboard, and mouse for that running offscreen at right). Once I had the joystick, and figured out how to configure it, I just needed to come up with a place to put it. Thus the little shelf hanging off of the handlebars. It's not pretty, but it seems to work. It's nice to have a sufficient accumulation of scrap and spare parts lying around to be able to knock something like that together in half an hour, without having to make a specific trip to the hardware store first.

I should send out a nod to qDot's previous work with bicycle interfaces. His is no doubt more technically sophisticated than mine. In particular, it pre-processes (by hardware and non-LSL software) the signals from the bike, and uses a scheme to more efficiently pass the resulting data to SL. As for me, I simply monitor the keypresses and do all of the interpretation work in LSL. (Fortunately, this does not seem to be a particularly resource-intensive process.) While dDot's approach has its advantages, this seems to work just fine for my purposes. The main difference is mine is susceptible to loss of focus if, say, an IM window is opened. Mildly vexing, but I don't often engage in long typed conversations while biking, in any case. (Might be fun when voice comes along, assuming the equipment isn't too noisy.) If you get a Busy response, well, there's a chance that I'm out riding my bike. Leave a message, and I'll get back to you later.

One thing I notice is the similarities between his time-out scheme and mine. It's been a while since I read his article, so I can't say with certainty if I got the concept from him or developed it independently. In any case, it's the only way this setup will work. The helicopter setup has a timer that resets every time the Page Up key is pressed. If too much time elapses (1.5 seconds, currently), the script in-world assumes that I've stopped pedaling, and the heli-bike plummets from the sky. (The trigger on the joystick turns this script on and off, should I wish to just hang where I am under my avatar's normal flight power.) I like his idea of rigging a bike powered version of SFCave. I'd experimented with a version of that using normal keypresses (press a key, the player is pushed upward, release and he falls). But it proved to require far too much space to operate, and wouldn't fit on my parcel. Perhaps the trick would be to leave the player stationary and move the cavern (in the form of a series of paired prims (roof and floor, with continuously varying spaces between, floating front-to-back under their own power) around him. Food for thought, that.

And I suppose that's all I have to say about this thing. Now, I'm going for a ride!
Posted by Moriash Moreau at 6:45 PM - 1 comments

 
Random Update
Just a few things that have been on my mind lately in SL.

First, ran across this Planet Karen webcomic a bit back. Yes! Exactly! It's surprisingly difficult to work in extended conversations in the limited space available in a comic frame. Quite a few times, I had to go back and re-shoot a frame because I changed the dialogue, and couldn't make the proper left-to-right order work out in the space allotted. And quite a few more times, I didn't but should have.


Second, a quick picture of a new addition to the SkyLounge tower. I've added free-floating faux laser show butterflies to the sculpture garden on level one. (They're somewhat clearer in person. JPGs don't handle pure colors very well, even at low compression.) Kind of an interesting bit of manufactured future-retro tech, that. It would be quite easy to have near-photo-realistic butterflies flitting around up there. In fact, I have several flocks of realistic particle Monarchs flying about at ground level now. ([plug] Available at Mo-Tech Industries for only L$250! And remember, all proceeds go to Relay for Life! [/plug]) The trick was to come up with something obviously not intended to look real, and fit the somewhat futuristic feel of the Lounge. Finally settled on this. The orb at top center is a varying cone of RGB lasers, intended to simulate projectors for the associated RGB outlines of butterflies below. Kind of reminds me of the old laser rock shows down at the local planetarium, before they got shut down for excessive drug use by the patrons. Strangely enough, Laser Pink Floyd attracted potheads. Who knew?

Of course, this kind of free-floating display is technically impossible without additional schemes to block/show the light (screens, smoke, etc). Light doesn't just spontaneously stop in clear air. I briefly considered trying to come up with some kind of head nod toward addressing that (perhaps a light fog of stage smoke in the area of the butterflies), but decided I was being overly pedantic about it. We can all fly and teleport. I don't think it's breaking the illusion overmuch if I assume some minor revolution in free-floating volumetric displays, too. In any case, it's kind of a neat effect, if I do say so myself.


Third, last weekend I decided to pull the old stationary bicycle out of storage and have another go at wiring it up. I decided to scrap the existing scheme and start over from scratch. Instead of using a reed switch (which for some reason never seemed to work reliably), I went with a simple spring-loaded lever switch and a bit of bisected dowel rod on the main sprocket. Every turn of the pedals, the dowel passes by the switch and depresses it. Simple enough. I'm a little concerned about wear issues there, since it requires moving parts in the switch. I'll have to see how it works out over time.

Right now, all I've got is elevation control. To maintain altitude, I have to keep pedaling at a given speed. I settled on a range between about 10 and 15 MPH (according to the speedometer built into the bike). Pedal slower, and the Heli-Bike loses altitude. Pedal faster, and it gains altitude.

From a programming perspective, this wasn't all that difficult to work out. In order to minimize lag effects, I divided the work into two scripts. The first script monitors a key (the Page Up key, in this case) and reports the time between keypresses (in hundredths of a second) via link messages. It also contains a timer to determine if the user has stopped tapping the key altogether. The timer is reset each time a key is pressed. If the timer lapses, keys are being pressed slow enough to be considered a full stop.

The second script takes that time and compares it against various numerical ranges: hover, rise slowly, rise quickly, fall slowly, and fall quickly. This proved to be somewhat complicated. Longer periods between keypresses correspond to higher numbers. If the period is longer (more hundredths of a second have passed), the user must be pedaling slower. This proved to be quite confusing and counter-intuitive (one would expect higher equals faster), especially after banging my head against the wall for a couple of hours. About halfway through, it occurred to me that a simple change of interpretation (such as working in frequency, 1/seconds, instead of period, seconds) would have made things somewhat more intuitive. But by then it was too late, and everything had been sorted out. And working in whole numbers (whole hundredths of a second is sufficiently fine resolution for my purposes) is still more convenient. Still, worth keeping in the back of my mind next time something like this comes up.

Worse, the ranges had to be determined by trial-and-error, actually using the bike in question to find comfortable (yet challenging) speeds. This involved a few hours of climbing on the bike, pedaling for a few minutes, observing the various numerical data being spewed out in debug, climbing off, tweaking code, and repeating. (My legs were so sore this morning, I could barely climb out of bed.) Fortunately, I had the foresight to work out the various ranges as offsets from one "neutral" number. Right now, everything centers around approximately 12.5 MPH, which corresponds to one full pedal revolution per 0.73 seconds. This method allows me to tweak speed ranges simply by changing one number, and having the software adjust all the ranges for me. I may even build in a method to do this on the fly, so I can make the Heli-Bike more or less demanding to keep aloft as needed.

So, I had code to interpret speeds as rates of climb/descent. The next trick was to come up with some kind of simple physical engine to drive it all. I've decided to stick with attachments for this project, mostly to avoid the frustrations of SL vehicles and sim crossings. This leaves me with normal avatar flight, and various forces to enhance or cancel a flying avatars normal buoyancy. Basically, the attachment applies an llSetForce along the avatar's Z axis, with positive forces lifting upward and negative forces pushing downward. Again more confusion there, with the inverted fast/slow/high/low/up/down scheme I'd backed myself into. Very frustrating after the umpteenth change of greater-than to less-than and plus to minus.

Originally, I created a linear equation directly relating pedal speed to force. Pedal faster to apply stronger forces and climb faster. In practice, this worked well enough from a purely physical standpoint, but proved irritating to watch. It's impossible to maintain a perfectly constant speed (even assuming lag effects didn't cause fluctuating time readings). So the pedal periods would vary slightly even when attempting to maintain a constant speed, causing associated minor variations in lifting forces. Normally, a minor (a few percentage points) change in force from second to second wouldn't be noticeable. But the effect became quite pronounced when followed by the normal SL client camera. What would appear to be a reasonably smooth climb to an outsider became a stuttering, jerking, motion-sickness-inducing movement when viewed through the damped, delayed motion of the default follow camera. I suppose I could have come up with some kind of custom camera parameters to minimize (but likely not remove) this effect, but instead I settled on breaking the forces out into the five speed ranges described above. The force only changes magnitude if the speed moves from one broad range to the next. Less realistic, but considerably smoother and easier on the eyes when viewed through my own camera. And, really, that's the important thing here. If I can't stand to watch it in action, it doesn't matter if the movement is realistic or not. It'll quite realistically stay parked on the ground or in my inventory.

So, anyway, I now have a helicopter that can move up and down. From there, it's simply a matter of hardware. Normal flight can be used for forward motion and steering, without additional software. I just need to come up with an appropriate controls scheme. Considering that I'll need at least three switches (left, right, and forward), possibly more, integrating this all into my handlebars is going to take a little thought.

More to come.

Addendum
Finished this project, more or less. Seems to work pretty well.
Posted by Moriash Moreau at 12:15 PM - 1 comments

 
Building at 100,000 Meters
As you may know (especially if you've heard me yammer on about it on this weblog), the absolute maximum object limit in Second Life is 4,096 meters. Any unattached object that is rezzed above this ceiling, or otherwise moves above it, quickly disappears. This is normally not an issue, unless you're performing some high-flying acrobatics with an SL jet. It can be quite disconcerting to have one's flying machine suddenly evaporate four kilometers above the ground.

However, as I discovered early last year, this effect is not instantaneous. An object that finds itself above the build ceiling will last a fraction of a second before disappearing. Not a terrifically useful distinction, of course, but still interesting.

On the evening of April 6, 2007, I performed a little experiment high above my land in Louise. Using a battery of seven scripted HUD attachments (the seven gold buttons shown in the film below), I attempted to create a solid floor at an altitude 100,000 meters. (The green and white HUD is the flight assist I used to reach the test elevation.) Each HUD is composed of 50 simple rez scripts and a master timing script. Every second, the timing HUD calls each of the 50 rez scripts in turn (one rez every 0.02 seconds, with distributed rez scripts to help circumvent the built-in scripted delays for llRezAtRoot). This is a theoretical maximum of 350 temporary floors per second (50 per HUD, seven HUDs). (The distributed scheme was used in order to avoid the "grey goo" fence.) In reality, the overall rez rate is likely somewhat less than this, due to lag effects and built in delays. If I ever attempt this experiment again, I will likely go with a larger number of rezzer attachments, with a longer delay time for each master timing script.

The rezzed object is a simple, temp-on-rez prim. The floor prim is five meters by five meters by 0.01 meters. This size was a compromise: large enough to easily stand on, but small and light enough to minimize rez delays due to object mass. Following is a film of one experimental run in action.



As you can see, Will Webb and I are able to stand on the rapidly rezzing, rapidly evaporating floors. In earlier experiments, only one rezzing HUD (only 50 floors per second, max) was used. In that case, we were perpetually in the free fall animation, as our avatars continually lost support and fell a couple of millimeters, only to be buoyed by the next floor rezzed inside our bounding boxes. As more rez HUDs were added, we spent less and less time in free fall, until finally we were able to stand more or less normally (give or take the occasional fall and jitter). The experiment filmed above had a small, but noticeable (approximately 0.3 dilation) effect on simulator performance.

It seems likely that, if one were to greatly increase the number of rezzer objects, a stable and largely flicker-free structure could be created. But such a construct would likely be quite costly in terms of simulator resources. One could also optimize the system by controlling the rez timing across all of the rezzer objects. Currently, each of the rezzer HUDs operates independently, and it's likely that the overall periods between rezzed floors is not uniform.

In any case, it seems unlikely that a high altitude construct like this could be made permanent. Even if some form of self-replication could be programmed that was fast enough to rez a duplicate and transfer inventory before the original object dissipated, yet slow enough to miss the grey goo fence, one lag spike would break the chain and cause the whole build to disappear. And, of course, there is little that could be done in such a build, beyond jerkily wandering around and saying "Yep, I'm at 100 kilometers." Chairs and poseballs would disappear before they could be used, and scripts would not have time to execute anything more than the most basic commands.

Alas, it seems that ultra-private skyboxes and the like are still limited to 4,096 meters and below.
Posted by Moriash Moreau at 11:59 AM - 0 comments

 
Ratings
Well, it appears that the Lindens are looking at removing the ratings system. Honestly, I'm not all that concerned about it, as you can probably guess from my mediocre numbers.


Not all that stellar, especially considering I've been here a bit over 27 months now. Still, I appreciate the few I have received over the last couple years.

In spite of my own dismal ratings, I can certainly understand why some people would be a bit miffed and disappointed about losing theirs. For many, this is a tangible representation of peoples appreciation of their efforts. For many residents, the occasional IM and pos-rate are the only rewards for their hard work. And even though they don't have any actual effect on the world, in concrete terms, I can sure see how it'd hurt to lose them. It'd be on par with someone breaking into their homes and confiscating their diplomas, certificates of merit, and bowling trophies. I don't disagree with the reasoning (the system consumes desperately needed server resources, and has been gamed and corrupted from the beginning), but it's a tough thing to see happen, nonetheless.
Posted by Moriash Moreau at 11:35 AM - 0 comments

 
Filth!
Hey, cool! The Garage of DOOM got a mention in the Death issue of Filth magazine. I'm side-by-side with sexy zombie chicks! What's not to like? Go pick up your copy at the Filth Magazine corporate HQ. And thanks go out to Kitty Lalonde for not making me sound too much of a dweeb.
Posted by Moriash Moreau at 9:35 PM - 1 comments

 
Tower
Well, after procuring a little extra prim land (thanks to a land swap with Walker), I've finally taken on a project I've been kicking around since Babel Two in last year's Burning Life. The old SkyLounge has been converted from an arbitrarily hanging skybox to a four kilometer tall tower.


The top of the tower is substantially the same, save for the addition of the dome and aerial at the top. The tip of the needle is at 4,106 meters, or 4,060 above ground. (I equipped the needle with a flashing warning light, for no good reason. Any high-flying plane would evaporate a fraction of a second after exceeding 4096 meters.) I won't say this is the tallest structure on the grid (I know better than to claim the first, biggest, or best anything in SL!), but it's the tallest I've ever seen or heard of, anyway.

By my rough calculations, the tallest possible normally constructed tower would be a couple centimeters shy of 4,133 meters high, assuming it was built on land lowered to nearly zero elevation, and was capped by a linked object (using all the tricks for maximizing link distance) with its root insertion a hair below 4096 meters (the absolute build limit). You might be able to squeeze a few more meters out of it with various prim-twisting tricks on that last prim, as well. I honestly don't feel the need to scramble for that last few meters, and my sim wouldn't allow me to terraform my land that low even if I did. If someone really wants the height record, well, they can have it.

And, of course, one could outright cheat and use a 65,636 meter tall megaprim. I assume that's the max size for such a hack. That's the largest I've ever seen, in any case. (Oh, darn, only 65.6 kilometers across. Why bother?) If it was placed with its root at just below 4096 meters (the build limit is determined by the prim's insertion point), that would allow someone to create an unadorned, single-prim tower up to 36,864 meters tall (assuming zero ground elevation). Said tower would just be a simple solid, with nothing on the top. You can't link to anything greater than 32 meters away, center-to-center, and anything rezzed on top of it would instantly disappear. It would, indeed, be 36-and-change kilometers tall, but it sure wouldn't be all that useful or interesting when all was said and done.

And it would also wreak utter havoc (or should I say Havok?) with physics, and probably get slapped down by the Lindens. Unless you're on your own private island, megaprims are verboten. I find myself wondering how one would even get to the top of said tower, in any case. No known teleporter or elevator scheme will reach anywhere near that high, and orbiters are too unpredictable for such duty. (You'd have to be darn good at scripting ballistics, and have an exceedingly low-lag sim, to consistently hit a target a few meters across from 30-some-odd kilometers below.) I believe map-based teleportation is limited to a few thousand meters up, as well. I suppose they'd have to hand out flight-assist attachments at the door.

In any case, I'll stick with my humble four kilometer tall monument to bragging rights. There's plenty more to do on this without scrambling for every inch.


Here's the base of the tower. Not much to look at, now, but I'm kicking around schemes for improvement. Given that it's nestled between a giant no-entry'd prim hedge, a wooden privacy fence, and a meters-tall cliff, I don't feel too bad about putting in such a lackluster base structure for the time being. I'll probably expand the entry lobby at some point in the near future. It has a nifty irising automatic door, in any case.

You may have noticed that the base doesn't match the top of the tower. That's because the tower rezzing apparatus does some texturing on the fly. Each segment checks its elevation on rez, and adjusts its shade based on height (higher is lighter). So the tower gradually fades from black to white as elevation increases. It also adjusts the inside diameter, getting narrower as it goes. Then the script deletes itself from the segment's inventory, to save on lag. You have to think of such things when you're building a structure out of 400+ scripted components.

As with all extreme altitude builds, this one is vulnerable to sim restarts. Anything above 2000 meters (or so my experiments show- not 2048 meters- odd!) disappears on a reboot. So I've had to add yet another maintenance robot to the SkyLounge staff. In addition to the rez rocket that periodically checks on the SkyLounge itself, and the device that rezzes the radio tuner (which had to be group owned in order to change the media streams on my group land), I've had to add a widget that wanders the length of the tower checking for missing segments. These three devices alternate, and run at several minutes between cycles. My neighbors may lynch me for erecting a superscalar phallic symbol in my back yard (sometimes a four kilometer tall tower with a big knob on the end is a just a four kilometer tall tower with a big knob on the end), but at least they'll be able to do so in a low lag environment.


I had to do a little remodeling on the first floor to make room for the altered method of entry. Those of you who've visited may remember that the old SkyLounge was entered via a balcony on the third floor. Now, the elevator takes visitors up through the center of the tower, and drops them off on the first floor. This meant removing the giant pine tree from the center of the garden area to make room for entry. This was unfortunate, and I almost scrapped the project for this reason alone. But, finally, I decided that I was sick of the tree disappearing and waiting for me to return. (There's a long-standing bug that prevents trees from being rezzed by script when the owner is absent. Given the other issues in SL at the moment, I don't see that one being given priority any time soon.) The big pile of bare dirt looked pretty odd if a visitor arrived before I could log in and re-rez the trees again. I've left the shrubbery, even though it, too, is volatile due to the tree rez bug. I'll replace the donut-shaped mound of dirt with something else (perhaps a fish pond), eventually. The prim sculpture garden doesn't look too bad without them, in the interim.

Next up, I'll be fitting out the ground level with something a little more appealing. Then I'll expand the third level (the free form "holodeck" space) with a few more programs. The never-used stage area is getting kind of old. I'm looking into a particle-based fireworks system (something like Jopsy Pendragon's fireworks show, although I have little hope of matching her artistry), and maybe a sky diving center. Lots of potential here.

Addendum, 11:43 pm

Revamped the base of the tower this evening. I think this looks quite a bit better. Now I just need to furnish it.
Posted by Moriash Moreau at 11:56 AM - 3 comments

 
Apparently, I'm Legitimate
Ran across this article this morning on GeekPress. On April 16, US Astronaut Sunita Williams will be running the Boston Marathon... From space. She'll be using a treadmill on the International Space Station, and running by proxy. Her sister will be running the 26.2 mile race in person, roughly at the same time (give or take time shifting required by space station operations).

I think this is really quite cool. And it makes me feel a little less silly about my own comparatively paltry efforts in the upcoming SL Relay for Life. No, I won't be doing 26 miles, but at least there's a precedent for this kind of thing now. Kind of nifty.
Posted by Moriash Moreau at 10:36 AM - 0 comments