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

Sat Sep 6 03:49:28 UTC 2008

Alright, having read all this, I propose that we don't either deprecate 
DotNetEngine or stop it being the default at this time.

Kurt, it would be good if you could go ahead with the refactoring to 
eliminate the existing code duplication. Is there any way at all to 
split the changes into smaller patches so that we can look to get 
something in within the week and possibly so that other hands can 
complete the job?

Thanks.

--
justincc

Melanie wrote:
> Charles, please don't muddy the waters on the facts. In SL, a script 
> _never_ restarts unless the user restarts it. If scripte would 
> restart and lose state, then no rental system and no vending system 
> could ever work.
>
> The DotNetEngine is not compliant in that respect. It never was. 
> Using broken behavior as a reference is not correct procedure. The 
> DotNetEngine behavior is broken in that respect, and limits OpenSim 
> scripting, compared with SL scripting.
>
> In SL, scripts retain state even when in user inventory. I can 
> create a script, store some data ina global variable within the 
> script,then take the script out of the prim into inventory. I can 
> then pass the script to you, and you can rez it into a prim. If you 
> then query it;s data, it will still be there.
>
> SL never resets a script's global variables, and never re-runs 
> state_entry in default, unless it is specifically requested by 
> either the user,the script, or another script in the same prim, or 
> the script is edited.
>
> XEngine emulates that behavior as closely as the current state of 
> the supporting code in OpenSim permits.
>
> I am purposely not voting on this, because I would be accused of 
> having a vested interest. But when it comes to facts, I have to clarify.
>
> And, by the way, the X never meant experimental. I just couldn't 
> think of a name.
>
> Melanie
>
>
> 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> 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
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>   