Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

I'm writing a (real) joystick interface using libsecondlife.

Huns Valen
Don't PM me here.
Join date: 3 May 2003
Posts: 2,749
08-14-2006 14:30
Hello,

I'm writing a joystick interface that runs over SLProxy (using libsecondlife.) It will support arbitrarily mapping controls (axes, buttons, sliders, hat switches) from multiple joysticks (or steering wheels, or anything else that talks to DirectInput), and I've already got it squirting updates into a simulator. The idea is to provide vehicles (and anything else interesting) with full access to joystick hardware, so you can (for example) have very fine control of the pitch/roll/yaw without having to use mouselook steering. My question is this: Is anyone at LL working on integrating analog joystick support into the client? If so, and if it's going to be available sometime in the near future, maybe I don't need to continue. Let me know.

----

Response:
That sounds fantastic. Should enable us to plug all sorts of things into the simulator, and we wouldn't have to exit the viewer every time we wanted to recompile our apps. Something that would be useful (especially for handling sims with slow script execution) would be an option to choose whether the data was delivered in a FIFO or just overwritten each time it was received. As an example, my physics routine tries to tick four times a second, but that gets to be impossible when (for example) I'm flying through some simulator that's got 3,000 scripts on a Class III machine. My physics are smart enough to measure how much time has elapsed, but if there's a big queue of control information coming in, it could stack up pretty fast.

Maybe this is beyond the scope of what you had in mind, but I'm thinking of something like this -

client: Hello, here's some data: <XAxis>-0.4</XAxis><YAxis>0.1</YAxis>
LSL: (not able to pick it up yet, doing something else)
client: Hello, here's some more data: <XAxis>-0.7</XAxis>
LSL: OK, picking up the data.

There's two ways to give LSL the data:
FIFO - <XAxis>-0.4</XAxis><YAxis>0.1</YAxis><XAxis>-0.7</XAxis>
New data with same name overwrites old - <XAxis>-0.7</XAxis><YAxis>0.1</YAxis>

Obviously there would have to be some sane cap on the amount and persistence of data, so that someone couldn't just send a few megs of stuff and have it hanging around forever, but that's the kind of implementation that would make this system very nearly as responsive as mouselook steering, particularly when the simulator is very busy.

PS: Here is a thread ---> /108/17/130132/1.html#post1230488
Andrew Linden
Linden staff
Join date: 18 Nov 2002
Posts: 692
08-14-2006 16:02
Oh! This is a project I've been wanting to work on for a while, but stuff keeps coming up that fills my schedule. I mentioned the idea to Cube Linden who is excited about getting this done. We both agree that it shouldn't be very hard to do. Give us three weeks to get it done, and a week to push it through QA. If we haven't made any progress withing three weeks you'd better get started on your libsecondlife hack.
Andrew Linden
Linden staff
Join date: 18 Nov 2002
Posts: 692
08-14-2006 17:36
The way I was planning on trying to make this work is as follows...

The simulator already has a simple home-brewed embedded http server that can serve a little bit of XML info for internal purposes. I think the same server has already been added to the client, but if it hasn't been yet I would try to do it. Then I would have the viewer read and write XML from some port on 127.0.0.1. The joystick input and output could then be read/written by some 3rd party script running on the same machine. Of course, the feature would be 'OFF' by default and would have to be turned on in the preferences somewhere.

The advantages of this system is:

(1) simple
(2) OS agnostic
(3) no matter what your favorite scripting language is: perl, python, C#, lisp, etc , there is an http module or library for it

Anyway, that was the plan. We'll see how it goes if I ever manage to find the time to work on it.

Edit for typo.