Next version of SlIcer deployed

I've been up late a few nights on this, so allow me to go on a bit...This is the next version of SlIcer, which is essentially a utility for hookup up things in Second Life to things in real life. I've seen things like ObjectOverlord that work on the client code, but I wanted to do things that would work within the vanilla client. Good idea? Not sure, but at least it's workable.

What it does now:

• Inventories people and objects within a sim using scripted sensor objects that are placed in strategic locations. This inventory can be for multiple regions, and is kept in a database.
  
• Creates a queue for messages bound for Second Life. These messages are stored in a database, and delivered through scripted hub objects (co-located with the sensors). Essentially, the hubs poll the database for pending messages, which come down in a bundle, and are distributed to target nodes.

The test case is a mapping room, with a map on the floor, and 3D symbols that reflect state and position. Messages can come in from external applications, and the objects on the map change position, reconfigure to reflect state changes, and can also display floating text for other messages.



That's a picture of the map floor. The round object floating in air is the sensor/hub. Against the wall is our people sensor that looks for individuals, sort of virtual RFID. The SlIcer web app, which is still very much a work in progess, can show an inventory of everything discovered by our in-world sensors.


That's a screen shot that shows, for example, a rover_counter on the map. The database contains info like the last sense time, the x,y,z coordinates, etc. The cool thing is, there are simple URL's that an external app can call, targeting a region and object by their known name. This obviates the need to keep up with SL UUID's.


I'm an awful object builder, but this is my pitiful truck object in a 'stowed' state..an external source (such as a mobile GPS unit), could send telemetry by calling a URL, this enqueues a message for delivery to the sim...




And bammo...state/position change...




What's next:

• I've already got a database of objects, and it will be easy to add a table of arbitrary name/value properties per object. This gives a Silo-like capability to maintain object state outside of the sim. Objects could update their own state, or pick up state changes pushed in from the web. What would be cool is that that state can survive object name changes, and also re-rezzing. The drawback is that objects have to have a unique given name, I don't do duplicates.
• Thinking about a pub/sub system for events. For example, do something when an object is rezzed, when an object moves, when a certain person walks into a room, etc. I thought about putting this up in an additional sim, and doing some stupid pet tricks where moving and object in one sim causes a change in an object in another.
  

From there, I'm not quite sure, but it seems to open a lot of possibilities up. I have some cruft in the database for doing some reliable delivery stuff, but that's not a burning issue right now. The whole thing is done using Ruby on Rails, which I am really keen on these days. This has not taken a huge effort, development can go very quickly one you make the mental jump!

Rails, SL, mash-ups, all in one project...how cool is that...