[Opensim-dev] weird idea #2: inworld applications - access to client's widget set?

Wed Jan 28 05:13:33 UTC 2009

There are two "ground up" viewer projects that I'm aware of, Idealist and
Openviewer. Here is a site which discusses them from a technical
perspective: http://playsign.fi/engine/rex/viewerarchs
Idealist can be found at:
http://forge.opensimulator.org/gf/project/idealistviewer/
Openviewer can be found at: http://openviewer.org/

Then there is the Xenki viewer which aims to be a browser plug-in rather
than a standalone viewer. Find it here:
http://forge.opensimulator.org/gf/project/xenki/

On Tue, Jan 27, 2009 at 6:58 PM, John Sheridan <john at pseudospace.net> wrote:

>  Well, I'm glad someone's at least taking a swipe at the client from a
> usability standpoint although it would be nice if they like a few of the
> other client projects I've seen would consider starting with a ground up
> rebuild of the code base.  At least not only to solve the gpl vs bsd vs
> <insert favorite license here> problem but as well to make it so one can
> actually read and understand the code without loosing all grip on reality
> (virtual or not) then curling up into a fetal position under their desk
> while the world around them crumbles into some sort of bad rendering bug ala
> The Matrix.  And yes, for those who actually can read and understand the
> Linden's coding style I am that much of a wimp.  :)
>
> Thanks for the info Dahlia, :)
>
>  - John / Orion Pseudo
>
>
> Dahlia Trimble wrote:
>
> That would most likely require modifications to the sl viewer. I think the
> Imprudence project is looking at providing a viewer with similar
> capabilities: http://imprudenceviewer.org/
>
>
> On Tue, Jan 27, 2009 at 12:18 PM, John Sheridan <john at pseudospace.net>wrote:
>
>> While on the topic of weird ideas and in world apps...  I posted this
>> idea to the Lindens about a year ago back when I was first trying to
>> figure out LSL, but it likely went off to the noobie duh bin as at the
>> time I pretty much asked them to include a copy of Visual Basic in world
>> :P  Anywho, as it is we already have the LSL language with our own
>> additions via the os functions.  What I'm thinking would likely require
>> client modifications which merely makes it something to think about for
>> the future, but why not cobble together something that gives lsl access
>> to the client's widget set? Optimally something like a Mono Winforms
>> type of addition to lsl that would let a scripter actually use a real
>> gui as an interface for their scripts instead of hacking one out with
>> prims or a dialog box?
>>
>> Thanks, :)
>>
>> John / Orion Pseudo
>>
>> Dirk Krause wrote:
>> > Hi,
>> >
>> > this thing came up when I was thinking about what to do for OpenSims 2nd
>> birthday.
>> >
>> > I thought it would be really funny to reconstruct the Sony Home Arcades
>> in OpenSim, basically for giggles. I unfortunately don't have access to Sony
>> Home for now so I don't know exactly what effort it means to model this,
>> being not a good builder myself (for reference -
>> http://tinyurl.com/def8fn )
>> >
>> > The interesting point would be the ability to play either MAME or C64
>> games on the machines in these 'OpenSim Home (tm) Arcades'. So I looked up a
>> C# c64 emulator on the web ( http://tinyurl.com/bobw9y ) but then came to
>> think where such an emulator would run.
>> >
>> > (the following holds probably true for all kinds of applications running
>> in the OpenSim context, namely:
>> > - graphic-heavy c# or c++ applications
>> > - flash/silverlight/moonlight applications
>> > - 'co-browsing', works in Rex with this nice trick:
>> http://therexfiles.cybertechnews.org/?p=183 )
>> >
>> > So, to stick with the arcade example, the good question is - where does
>> the process run?
>> > I think there are these possibilities in general
>> > 1) SERVER - the application totally runs on the server side. One av
>> takes over the game machine and his key strokes are transmitted to the
>> server (via HUD?) and the emulator creates the graphic output. This would be
>> a series of textures (not really good) or a video stream of sorts.
>> > 2) CLIENT - the applications totally runs on the client. This is
>> possibly the easiest way to implement it (and out of scope for opensim-dev)
>> since it needs hacking the client. But just for the record: as soon as the
>> client detects arcade.jp2 as the texture, it fires up ye old space invaders
>> and renders2texture the graphic output to the client.  Other people would
>> see either
>> > a) nothing but the standard texture as long as they are not playing it
>> or
>> > b) a screenshot every 5 secs or so,  since the client sends every 5 secs
>> or so a screenshot to the server, updating the view for the cheering
>> bystanders
>> > c) the real game, since their clients also fire up the emulator, receive
>> the key strokes from the current player (while they are near him) which must
>> be sent from the server of course.
>> > 3) BOTH- the application runs on both server and client with
>> synchronicity calls every N secs with some prediction by the client side
>> when the calls don't get through fast enough (basically like networked
>> physics in professional games works)
>> >
>> > All in all you are in synchronicity hell the more 'real' the output for
>> everyone gets because there can be no real simultaneousness.
>> >
>> > So sorted by applications:
>> > - Physics:
>> > either only server sided (like it is now) which is sufficient for most
>> use cases, or both when the physics is fast and heavy like in games.
>> > - Video:
>> > Number 2c is used to play video in SL right now - one av activates the
>> script that start the media playing on all clients in the vicinity. if they
>> didn't activate media support then they see nothing. If they did the video
>> starts on all clients, probably 1 to N secs off each, depending on their
>> network, also slowly drifting into asynchronicity the longer the video runs.
>> If it should be more synchronous then a streaming server is mandatory.
>> >
>> > - Turn based games
>> > could be implemented completely on server side. So a simple text
>> adventure (Zork, anyone) or even a MUD could be implemented even on a
>> different server with a gateway of sort. Come to think of it this could even
>> be a tty terminal.
>> >   Same goes for
>> > - co-browsing web pages, powerpoint projectors
>> > Could be either server sided (like it is now via the php render trick)
>> or client sided (via the Rex trick)
>> >
>> > So the interesting part stays where to implement, say, a moonlight
>> application? Let's say people want to create micro/casual games or small
>> apps,then it would be interesting to see whether there would be an
>> infrastructure to hook these things into?
>> >
>> > I would even go so far that there could be a mechanism that handles LL
>> or OS scripts in a way that it either runs on the client (libomv Test.exe
>> with some script) or on the server side (the existing scripting
>> architecture).
>> >
>> > Best regards,
>> >   Dirk/Barth
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>  ------------------------------
> _______________________________________________
> Opensim-dev mailing listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090127/8575d920/attachment-0001.html>