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 <j...@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@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
