As an aside, InnerLife is not my project; I'm merely one of the folks who's helped to test aspects of it, and helped the actual devs in supplying a quiet area to work from (plus an occasional script assist). I am a member of their SL group however.
The original concept was to create an online, multiplayer interactive variant of 'Journey to Wild Devine,' which happens to be a game that teaches biofeedback techniques for various uses (normally as part of a wellness program). http://www.wilddivine.com/
As someone who's had issues with stress and depression over my life (in particular after 9/11) I'm particularly drawn to helping projects like this when I can.
--TSK
On 7/24/06, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
The LSL script on the 'master' object is opening an XML-RPC channel and reading a real-time stream from a custom application written for PC/Mac. Master object translates as needed and generates the appropriate 'say' messages in relay.
There is a latency issue with the number of XML-RPC packets that SL will allow per second without generating a backlog (probably due to the channel still being funneled via one central server, and is therefore throttled). On average 4/sec has been OK, though a little faster would be nice at times. In most instances 2/sec should be fine however, and should not be an intense burden on the sim.
Yes, though it's more of an adjunct to the keyboard than replacing it. The messages will have upwards of 10 variables sent in them (Skin Conductance, heartrate, and a couple derived items if just the LightStone device. Including a EEG device from another source it'd also include Alpha/Beta wave data and its derived information, plus derived data from both combined).
This is what I suggested on their forum. A purpose-built variant of the SLProxy app will probably end up being the base for this. If done correctly, it could probably also be used generically to implement Prop 203 (Support local devices beyond mouse/kboard); Just hook in and fire away. :)
This was my original idea. However, having extra avatars on the sim defeats the purpose of trying to save resources on the SL side. The interaction from the 'child' scripted objects were a bit busy during testing, and that was with just a couple avatars (I believe its been slimmed down considerably since then). Plus everything should be done with just each avatar participating anyway, so that group BFB interaction is greatly simplified.
Message: 3
Date: Sun, 23 Jul 2006 18:55:31 -0700
From: Ben Byer <[EMAIL PROTECTED]>
Subject: Re: [libsecondlife-dev] Introduction / Using LibSL for
InnerLife BFB Relay
Hi!
So, let me see if I understand this correctly -- you've got object in-
world in SL that are the "recipients" of this BFB data, and you have
BFB devices plugged into a home computer that are input devices. You
want to get data from the BFB device on your PC (or whatever) and
eventually to an object written in LSL running on a sim.
The current way you are doing this (correct me if I'm wrong) using an
LSL script to connect over HTTP to a "server" running on the user PC,
and the HTTP server spits out data from the BFB box using "say" to
other scripts inside SL.
The LSL script on the 'master' object is opening an XML-RPC channel and reading a real-time stream from a custom application written for PC/Mac. Master object translates as needed and generates the appropriate 'say' messages in relay.
It sounds like this works, but you are having problems with latency
(BFB to HTTP server to "master object" to "required object in-word"
to some action in-world back to the user's SecondLife client, or
what)? and also maximum transmission rate?
There is a latency issue with the number of XML-RPC packets that SL will allow per second without generating a backlog (probably due to the channel still being funneled via one central server, and is therefore throttled). On average 4/sec has been OK, though a little faster would be nice at times. In most instances 2/sec should be fine however, and should not be an intense burden on the sim.
Further, it sounds like what you'd really like is to be able to
somehow use that BFB box to directly create messages that your SL
client would "say" -- kind of to replace the keyboard?
Yes, though it's more of an adjunct to the keyboard than replacing it. The messages will have upwards of 10 variables sent in them (Skin Conductance, heartrate, and a couple derived items if just the LightStone device. Including a EEG device from another source it'd also include Alpha/Beta wave data and its derived information, plus derived data from both combined).
If all of that is correct, there are a few different ways you could
go --
<snip>
2. Write some code to inject packets into the output of the
SecondLife client with "say" content -- not ready yet, but Austin
Jennings is working on some code to make that easy
This is what I suggested on their forum. A purpose-built variant of the SLProxy app will probably end up being the base for this. If done correctly, it could probably also be used generically to implement Prop 203 (Support local devices beyond mouse/kboard); Just hook in and fire away. :)
3. Write a new, completely separate client for secondlife using
libSL, that would directly communicate with your BFB and the sim --
this may or may not be appropriate. Do you need / want a full
graphical interface with SecondLife at the same time. If so, you
might still be able to do so, but you'd have to create a second
"dummy" account and have them both logged in at the same time, on the
same sim.
This was my original idea. However, having extra avatars on the sim defeats the purpose of trying to save resources on the SL side. The interaction from the 'child' scripted objects were a bit busy during testing, and that was with just a couple avatars (I believe its been slimmed down considerably since then). Plus everything should be done with just each avatar participating anyway, so that group BFB interaction is greatly simplified.
Hope this helps,
--TSK
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
