[Opensim-dev] Script engine base functional merge - Dot Net Engine

Sat Sep 6 03:03:21 UTC 2008

I'm sorry, but I disagree Melanie. I believe that it is reasonable that scripts start when a region starts and I suspect this is the way that the linden sims operate. I admit to not being 100% sure, but the impression I get from all of those who have created, copied and run scripts with our default dotnetengine is that this is normal behavior.

This discussion started as a opinion of checkins of dotnetengine versus xengine. As I recall, there are just as many for each. In other words, I have difficulty believing that the dotnetengine is languishing at all. There are hundreds of sims using it and changing the default, will in my opinion, lead to significant support issues while we regain lost ground. Personally, I would not like to do that.

I would like us to solve the issue of a duplicated source code file for the LSL-C# wrappers. That is the original problem we are trying to solve. It really has little to do with engineZ versus engineY. 

Lets solve the problem of a duplicated file and go on. There are many folks quite happy with the dotnetengine and until xengine is compatible, I believe that changing the default has the potential of causing more problems then it solves.

Charles

----- Original Message ----
From: Melanie <melanie at t-data.com>
To: opensim-dev at lists.berlios.de
Sent: Saturday, September 6, 2008 2:39:53 AM
Subject: Re: [Opensim-dev] Script engine base functional merge - Dot Net Engine

I really need to chime in here now. XEngine is _more_ compatible 
with SL.
DotNetEngine loses script state at every sim restart. Therefore, 
each time a sim restarts, the default state's state_entry event is run.
XEngine preserves state. Therefore, it does not restart scripts from 
the beginning. Rather, it reloads the global variables and state 
information and continues delivering messages to the script right 
where it left off. This exactly duplicates the SL behavior.

The reason for the issues that were mentioned derive from the "eye 
candy" functionality, e.g. texture animation, rotation, sound, 
hovertext and particles, which are supposed to be a property of the 
prim and not the script.

These are meant to survive a region restart without the script 
having to start them again. Because they are a property of the prim.

However, for a long time, that was not implemented at all. Instead, 
as a stopgap measure, I provided a changed(CHANGED_REGION_RESTART) 
event to the script, which scripts could use to explicitly restart 
their eye candy.

Since preservation of state was a main goal and one of the things 
that make XEngine more complete then DotNetEngine, simply disabling 
state persistence didn't appear as a viable option, as that would 
have negated the main design goal behind the XEngine.

Since then, I have added the fields for the eye candy and created a 
path from the database to the prim. The only thing left to add is to 
create some glue code that, in the creation of a prim from storage, 
goes over the eye (and ear) candy settings and sends the approriate 
messages to viewers to let them know that that prim is indeed 
texture animated / has omega / has particles, etc...

The fields for the particle systems are yet missing, an omission I 
didn't notice until I was all done with that patch. With most of the 
framework in place, that could be trivially added.

This still won't cover the XML representation of the prim. That is, 
however, not currently an issue, as the script state is also not 
preserved in that case. That means the script will restart from the 
beginning on rez, and restore the eye candy that way. This is 
slightly incompatible with SL, but emulates the current DotNetEngine 
condition to 100%. Therefore we can disregard that case.

So, what really needs to be done os to examine the prim data as it 
comes from the database, and add the calls to the relevant methods 
to make the returned eye candy values actually perform.

Melanie

Nebadon Izumi wrote:
> +1 on achieving compatibility before anything is shed..  one of the reasons
> i myself have been hesitant to test xengine, is the requirement of extra
> code.
> 
> Neb
> 
> On Fri, Sep 5, 2008 at 6:42 PM, James Stallings II <
> james.stallings at gmail.com> wrote:
> 
>> Just a quick note:
>>
>> The problem is that XEngine doesn't automatically start up the scripts on a
>> region restart. They have to either be manually restarted OR have the
>> comaptibility breaking code in place (detection and service of a particular
>> 'change' event).
>>
>> This is definitely problematic for the plazas (or any other place where
>> there are scripots owned by diverse avs), but to say that 'we have not been
>> able to use xengine effectively on OSGrid' is a bit misleading in terms of
>> the severity of the problem.
>>
>> I have found XEngine to be fairly stable and feature-complete than DNE, and
>> use it exclusively on my regions on OSGrid with considerable success.
>>
>> I want to say that last time I spoke to Mel about this (a few months back),
>> that she told me the underlying cause is buried somewhere in (inner) scene.
>> My hope is that the proper work is undertaken to address the underlying
>> issues that require this special treatment of scripts under XEngine, and
>> then procede to move forward from there.
>>
>> Just mah 0.02$L  :D
>>
>> Cheers!
>> James
>>
>>
>> On Fri, Sep 5, 2008 at 7:57 PM, Charles Krinke <cfk at pacbell.net> wrote:
>>
>>> I have spoken with Nebadon about the issue with xengine and we have not
>>> been able to use xengine effectively on OSGrid.
>>>
>>> I am told that scripts are not running properly on xengine without
>>> modification.
>>>
>>> It is particularly concerning to consider changing the default away from
>>> our dotnetengine and it also concerning in that it will probably make our
>>> support go up in the #opensim irc. If some of the key folks that test and
>>> support our users cannot use xengine, then I would suggest we should tread
>>> carefully here.
>>>
>>> Charles
>>>
>>>
>>> <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
>>>
>>>
>>
>>
>> --
>> ===================================
>> The wind
>> scours the earth for prayers
>> The night obscures them
>>
>> http://osgrid.org
>> http://del.icio.us/SPQR
>> http://twitter.com/jstallings2
>> http://www.linkedin.com/pub/5/770/a49
>>
>> _______________________________________________
>> 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 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/20080905/9869491a/attachment-0001.html>