<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;">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.<br><br>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.<br><br>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. <br><br>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.<br><br>Charles<br><br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;">----- Original Message ----<br>From: Melanie <melanie@t-data.com><br>To: opensim-dev@lists.berlios.de<br>Sent: Saturday, September 6, 2008 2:39:53 AM<br>Subject: Re: [Opensim-dev] Script engine base functional merge - Dot Net Engine<br><br>
I really need to chime in here now. XEngine is _more_ compatible <br>with SL.<br>DotNetEngine loses script state at every sim restart. Therefore, <br>each time a sim restarts, the default state's state_entry event is run.<br>XEngine preserves state. Therefore, it does not restart scripts from <br>the beginning. Rather, it reloads the global variables and state <br>information and continues delivering messages to the script right <br>where it left off. This exactly duplicates the SL behavior.<br><br>The reason for the issues that were mentioned derive from the "eye <br>candy" functionality, e.g. texture animation, rotation, sound, <br>hovertext and particles, which are supposed to be a property of the <br>prim and not the script.<br><br>These are meant to survive a region restart without the script <br>having to start them again. Because they are a property of the prim.<br><br>However, for a long time, that was not implemented at all. Instead, <br>as a
stopgap measure, I provided a changed(CHANGED_REGION_RESTART) <br>event to the script, which scripts could use to explicitly restart <br>their eye candy.<br><br>Since preservation of state was a main goal and one of the things <br>that make XEngine more complete then DotNetEngine, simply disabling <br>state persistence didn't appear as a viable option, as that would <br>have negated the main design goal behind the XEngine.<br><br>Since then, I have added the fields for the eye candy and created a <br>path from the database to the prim. The only thing left to add is to <br>create some glue code that, in the creation of a prim from storage, <br>goes over the eye (and ear) candy settings and sends the approriate <br>messages to viewers to let them know that that prim is indeed <br>texture animated / has omega / has particles, etc...<br><br>The fields for the particle systems are yet missing, an omission I <br>didn't notice until I was all done with that
patch. With most of the <br>framework in place, that could be trivially added.<br><br>This still won't cover the XML representation of the prim. That is, <br>however, not currently an issue, as the script state is also not <br>preserved in that case. That means the script will restart from the <br>beginning on rez, and restore the eye candy that way. This is <br>slightly incompatible with SL, but emulates the current DotNetEngine <br>condition to 100%. Therefore we can disregard that case.<br><br>So, what really needs to be done os to examine the prim data as it <br>comes from the database, and add the calls to the relevant methods <br>to make the returned eye candy values actually perform.<br><br>Melanie<br><br><br>Nebadon Izumi wrote:<br>> +1 on achieving compatibility before anything is shed.. one of the reasons<br>> i myself have been hesitant to test xengine, is the requirement of extra<br>> code.<br>> <br>> Neb<br>>
<br>> On Fri, Sep 5, 2008 at 6:42 PM, James Stallings II <<br>> <a ymailto="mailto:james.stallings@gmail.com" href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>> wrote:<br>> <br>>> Just a quick note:<br>>><br>>> The problem is that XEngine doesn't automatically start up the scripts on a<br>>> region restart. They have to either be manually restarted OR have the<br>>> comaptibility breaking code in place (detection and service of a particular<br>>> 'change' event).<br>>><br>>> This is definitely problematic for the plazas (or any other place where<br>>> there are scripots owned by diverse avs), but to say that 'we have not been<br>>> able to use xengine effectively on OSGrid' is a bit misleading in terms of<br>>> the severity of the problem.<br>>><br>>> I have found XEngine to be fairly stable and feature-complete than DNE, and<br>>> use
it exclusively on my regions on OSGrid with considerable success.<br>>><br>>> I want to say that last time I spoke to Mel about this (a few months back),<br>>> that she told me the underlying cause is buried somewhere in (inner) scene.<br>>> My hope is that the proper work is undertaken to address the underlying<br>>> issues that require this special treatment of scripts under XEngine, and<br>>> then procede to move forward from there.<br>>><br>>> Just mah 0.02$L :D<br>>><br>>> Cheers!<br>>> James<br>>><br>>><br>>> On Fri, Sep 5, 2008 at 7:57 PM, Charles Krinke <<a ymailto="mailto:cfk@pacbell.net" href="mailto:cfk@pacbell.net">cfk@pacbell.net</a>> wrote:<br>>><br>>>> I have spoken with Nebadon about the issue with xengine and we have not<br>>>> been able to use xengine effectively on OSGrid.<br>>>><br>>>> I am told
that scripts are not running properly on xengine without<br>>>> modification.<br>>>><br>>>> It is particularly concerning to consider changing the default away from<br>>>> our dotnetengine and it also concerning in that it will probably make our<br>>>> support go up in the #opensim irc. If some of the key folks that test and<br>>>> support our users cannot use xengine, then I would suggest we should tread<br>>>> carefully here.<br>>>><br>>>> Charles<br>>>><br>>>><br>>>> <<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>><br>>>><br>>>> _______________________________________________<br>>>> Opensim-dev mailing list<br>>>> <a ymailto="mailto:Opensim-dev@lists.berlios.de"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>>><br>>>><br>>><br>>><br>>> --<br>>> ===================================<br>>> The wind<br>>> scours the earth for prayers<br>>> The night obscures them<br>>><br>>> <a href="http://osgrid.org" target="_blank">http://osgrid.org</a><br>>> <a href="http://del.icio.us/SPQR" target="_blank">http://del.icio.us/SPQR</a><br>>> <a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br>>> <a href="http://www.linkedin.com/pub/5/770/a49" target="_blank">http://www.linkedin.com/pub/5/770/a49</a><br>>><br>>> _______________________________________________<br>>> Opensim-dev mailing
list<br>>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>><br>>><br>> <br>> <br>> ------------------------------------------------------------------------<br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>_______________________________________________<br>Opensim-dev mailing list<br><a ymailto="mailto:Opensim-dev@lists.berlios.de"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></div></div></div></body></html>