[Opensim-dev] Thoughts on Scripting

Sun Sep 7 15:06:30 UTC 2008

Mike,

great thinking,

and definitively; as I was trying to convey, we at Tribal have, since square one, tried to figure out how to create tomorrows architecture already with what we have today. Nothing conclusive so far, but you might want to check out
http://lbsa71.net/category/tribal-media/tribal-one/

for a series of (rather bad quality) youtube vids of some concepts we implemented some time ago - including a web api that would not only externalize interactivity, but also delegate the very creation of the in-world content to web services. Especially note the web pane that is used to interact 'around' objects.

Diva just showed us a couple of screen shots where she's doing the very thing you propose, but from an app point, not from an generic object point.

I don't believe these things are as far into the future as you might believe. There's a lot of really far-out things that can be done already with the current platform. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 

Date: Sun, 7 Sep 2008 07:52:40 -0700From: mike at maimedleech.comTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] Thoughts on Scripting

I've also been thinking about things like global scripts and external script servers. External script servers would solve some of the script state serialization issues. Instead of moving a running script from one region to another, it just keeps running on it's server.

But what got me excited recently was the realization that we may not need new client functionality to add in world building features. Would something like the following work?

Most clients have an embedded web browser. The server can request that the client open the browser on a specific URL, right? that means the server can provide it's own UI for things, it isn't limited to just the UI the client has implemented.

For example, the server could show a tree of hierarchically linked prims and other objects. When you select one, you can see and change properties on that object that the client doesn't know about.

The server can also use tricks like locking and unlocking prims and generating "bounding box" prims around grouped objects, allowing them to be scaled, rotated, etc. 

Granted it isn't perfect. Keeping the browser state and the viewer state in sync will be a challenge. But it is a starting point.

If done right, the extended backend functionally would be expected as services that a client could call. That way you can start without any new client features, but the clients can add better features over time.

  == Mike ==

On Sat, Sep 6, 2008 at 11:51 PM, Stefan Andersson <stefan at tribalmedia.se> wrote:

At the moment, it seems we have two main strands of developers; the 'scripters' and the 'appers' - those using the in-world (SL-based) programming model and the ones using the module API's to create region-wide and integrations behaviours.Of course, there's several ideas of where to take OpenSim behaviour customization, but so far, we haven't discussed it much. Although, the scripting engine model allows us to use an array of languages for scripting, and several of them probably gives you the option to do those things you list.I guess the big revolution comes the day we drop our SL-client-centric view of building and scripting, and begin to see external tools to compose behaviours and content, where you can add contextual points that simply aren't there in the SL viewer today. As, for example, region-wide global scripts and libraries - there simply aren't anywhere to place those in th SL-centric model. We at Tribal have been toying with a multitude of ways to get round this (like having region nodes in the inventory, with objects that are local to the region) so there's definitively room for invention and experimentation. One thing I would like to see somebody do, is to have prim scripts being compiled into a c# assembly; ie, something along the line that all scripts that are referenced from within a prim becomes a compiled whole, which would let scripts reference resources in other scripts - and as mentioned, in library nodes. If the actual Prim would be compiled into a referencable (probably marshalled) entity too, that would open truly amazing opportunities. Another interesting Tedd concept that's unfortunately haven't been worked on is the scriptserver, where behaviours are collected and externalized to a central process that could govern several objects in several region processes. Just some cents,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 

Date: Sat, 6 Sep 2008 21:56:08 -0700From: mike at maimedleech.comTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] Thoughts on Scripting 

Thanks Crista. 

I think there are two separate application models at work here. 

What you describe is the API for extending the OpenSim itself. I'm sure I'll have fun experimenting with it in the coming weeks.

However, what I'm trying to understand are the kinds of features that make creating large and complex things in world easier. Usually you don't think of building and scripting in world as creating an application, but isn't that pretty much what it is? At least I find that thinking of it in those terms helps me start think about how to make the task of building complex things easier.

For example, it should be possible to link a set of prims, duplicate that set many times, and then make a change to a prim in the set and have that change replicated, automatically, to all the duplicates. Similarly, it should be possible to create a library of script functions that can be used by many scripts, without manually duplicating the script code over and over. You can think of these things as part of an app model that supports reusable components, something analogous to an assembly. Now you can start thinking about how you would "reference" such a component for your build or how you would distribute an updated version of the component.

I wanted to know how others thought about the current "in world" application model and how it might be evolved. Is any work going on in that area?

  == Mike ==

On Sat, Sep 6, 2008 at 7:19 PM, Diva Canto <diva at metaverseink.com> wrote:

Hi Mike,OpenSim has a rudimentary application model, or even two: the one I'm most familiar with are the region modules, and I think there's another module system. They allow you to develop applications for the OpenSim API. Developing for this API achieves everything you talk about -- or, ahem, it will, once a few rough edges are taken care of. There's practically no documentation about this API, and about application development with OpenSim, so at this point almost no one knows about it. This is because both the API and the module systems are still changing. You have to download the code and bravely browse through it. In any case, the module system(s) in OpenSim is still not as sophisticated as, say, a Tomcat webapp (there are no resources, for example), but it is the beginning of what you are looking for.CristaMike Deem wrote: 

I've got a few thoughts about scripting and I would like your feedback.But first, a bit of an introduction. I'm a professional software developer with years of experience working on all kinds of distributed applications. I became a SL resident, scripter, and builder in early 2006. I'm just beginning to get involved with OpenSim. This is a hobby for me, it is unrelated to my work.For a while I've been thinking about "application models" for virtual worlds. By "application model" I mean something that involves more than simply scripting.A traditional application is a package of application code, shared libraries, resources like images, etc. A platform's application model defines the structure of these packages as well as things like the security model, installation services, etc. To the user, an application represents a consistent self-contained "user experience," usually with a specific purpose.Of particular interest to me is the model for applications built inside a virtual world.

A build of any level of complexity could be thought of as an application. For example: a building with door and window scripts, an attachment with configuration scripts, a vehicle, a stage with programed special effects for a product presentation, etc.SL offers a very rudimentary application model. You can put copies of scripts in prims and you can link a limited number of prims together. The platform also provides a security model and a number of other services.However, the SL application model is missing a bunch of things. For example we need a hierarchical prim model that supports any number of prims and at region scale, a way to share and reuse script libraries, a way to update things after they have been sold, given, or copied, etc.As the complexity of builds increase, the missing features become quite restrictive. This limits the ability of content creators to produce compelling user experiences. That limits the adoption of the platform for commercial purposes.In addition, the SL script execution model is complex to implement and requires a lot of computing resources. Specifically, treating global script execution state as a persistent data store is very problematic.I think we need something better. But I also think that making something that is really better could require moving away from the SL model in some fundamental ways.
What do you think?

  == Mike ==
_______________________________________________
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 listOpensim-dev at lists.berlios.dehttps://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080907/b4efd793/attachment-0001.html>