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

Mon Sep 8 12:54:56 UTC 2008

Thanks for the replies Charles (and everyone).

I threw this out there because I believe that DotNetEngine possibly is 
falling behind in terms of functionality and stability.  In my 
estimation, 8 out of 10 script engine patches in the last 3 weeks or so 
have been for XEngine/Shared only.  When ever I resync my code to head 
its a very painful process that really has illuminated this for me.

But the biggest underlying issue is, when I am done re-writing all the 
code necessary to make the new DotNetEngine, the 2 engines are going to 
be actually much more similar than they are now. This effort is much 
bigger than refactoring a few lines of code and retaining what we know 
today as DotNetEngine. It really will be a completely new entity when it 
is done. Because of this, it begs the question - was this trip really 
necessary?

What if we just fixed any potential migration issues with XEngine?

Kurt

Charles Krinke wrote:
> 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 <mailto: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 
> <mailto: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 <mailto: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 <mailto:Opensim-dev at lists.berlios.de>
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto: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
>   

-- 
Kurt R Taylor (Kurt Stringer)

Open Virtual Worlds Development
http://opensimulator.org   http://opensim.ibm.com
International Business Machines, Corp.
(512) 838-2496    T/L:  678