[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensim-dev
Subject:    [Opensim-dev] ScriptEngine as stand-alone
From:       stefan () tribalmedia ! se (Stefan Andersson)
Date:       2007-09-20 18:58:00
Message-ID: BAY108-W2085A126AD4DE7AD9EC274D5BA0 () phx ! gbl
[Download RAW message or body]

I think that it's a bloody brilliant concept.
 
I do, however feel that following the LL architecture '(LSL) scripts, attached to one \
object' would not be optimal, since LSL is inherently a very environment-intensive \
language (almost all commands do some minor interaction with the environment) and \
that every script can only (or mostly) influence one prim, makes it inefficient if it \
were remoted.  
Compare instead, if the behaviour (aka script or code) was encapsulated with API \
calls and events that would set big sets of data transfers in motion, or only \
                transfers 'on demand'
  * Wait until any Avatar comes within 3 meters of my Bounding Box, then give me All \
                Avatars within 100 metres
  * Run thru all my objects, ask them if they need movement update within my frame, \
try to Move All these object groups to these locations, break on collision and \
                report.
  * Don't send information about objects that nobody has tagged as 'interesting' \
(being subscribed to) - for example, if the object is only interested in avatar \
                interactions, and is in a region with no clients attached.
  * Changes in all 'foreign objects' that are tagged as 'interesting' (subscribed to)
  * Create this object, consisting of these 25 prims, with these properties
 
This would be the whole EXE communicating for ALL its objects, with all regions where \
it currently has objects. If one has something like that (with the API tailored for \
big, sweeping, general updates) I think it could be well as effective an arch as the \
LL arch, minus the transfer hassle. Of course, you wouldn't do that for a piece of \
bling that should blink when another avatar is near, since that piece would do \
trivial work spread out over thousands of regions, but you might well do it for, say, \
a car.I actually believe the communications could be made quite simple, but I'd \
suggest you start with something very specific and work your way from there.  
But hell, DO IT! It's one of the things I've dreamt about. It's third-party \
extensibility in a box.  
Best,
/Stefan


Date: Thu, 20 Sep 2007 09:10:03 +0200From: tedd at konge.netTo: opensim-dev at \
lists.berlios.deSubject: [Opensim-dev] ScriptEngine as stand-alone




Hi
 
I need to gather some views on something I?ve been thinking of for a while now.
I?m considering the benefits and drawbacks of moving the scriptengine to a separate \
.EXE, running as a daemon.  
The advantage is that a script can be running on a different computer than the sim \
itself. This can be used to protect IP (source code) and to offload the actual \
server.  
Protecting IP can be everything from someone wanting to stop untrusted servers from \
getting their code, to a company selling and hosting scripts (like a ?script for \
rent?-company). Offloading the servers is anyway good since they will be quite busy \
with physics and stuff. If you want really complex scripts then you can run a cluster \
of machines.  
Also a running script would not have to be moved between regions, it can just contact \
the next region as the avatar does.  
 
Separating scriptengine from the sim would require a separation of LSL commands.
Any command that does not manipulate or gather information about the region or its \
objects/avs can be executed by the scriptengine. Any command that does so will have \
to communicate using some sort of network protocol, for example remoting.  
I need inputs on how much traffic this would cause. Overhead? Advantages? Drawbacks? \
Showstoppers? What do you think?
 
Sincerely,
 Tedd
No virus found in this outgoing message.Checked by AVG Free Edition.Version: 7.5.487 \
                / Virus Database: 269.13.25/1018 - Release Date: 19.09.2007 15:59
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/opensim-dev/attachments/20070920/759f4108/attachment.html>



[prev in list] [next in list] [prev in thread] [next in thread]