John Mela wrote:I've grumbled before about the unfairness of OpenSim terminating events on the basis of elapsed time (and it's worth emphasising that this is part of the vanilla code, not something that Kitely has done). In effect, this means that script A can put heavy load on the script engine and cause script B to fail, even if A and B are in different objects and created by different people. A much more just method would be to limit the number of function calls in an event (or CPU cycles if that's feasible), so that if a script works on a lightly-loaded system it won't fail when there is heavy load.
I agree John. I know this is a function of OpenSim because I've seen the specific setting line in the .ini file (and altered it on my VARs). Interestingly though, like you I've never experienced an event timeout in any of my code before Kitely (and I've been scripting for about 15 years on various grids). I'm not pointing fingers; merely suggesting the setting / issues be reconsidered. To be honest, before this I was never aware of the downside of an event running a lengthy period of time, however I believe your solution to be a better one (though possibly difficult to implement). I heard such has been implemented to an extent, but not sufficient to this need, obviously.
One of the reasons given for a 30 second limit is that "if one event is running another can't be triggered" and the example given of being in a timer event and a touch event not working (fairly similar to an extensive loop). In my opinion that's an issue for the coder to deal with and is irrelevant to the system. Maybe the coder
wants the item to not be touchable while that timer event is in operation. Beginning coders learn by experience and mistakes; experienced coders know to avoid excessive loops to begin with. That's more a scripting issue, less a system-level one. I know that "in extreme situations" one bad script can affect an entire world... but that will always be the case, no matter what. One test I've run in the past which has proved valuable is to rez 50 of an item and see what impact it has on the world. If 50 doesn't impact, the script is likely trustworthy. One can also check Top Scripts for badly-behaving scripts.
It's up to coders to make scripts work as desired, and up to world owners to implement scripts wisely. But to have a script cease to function because something
might be coded badly... seems to be counter-productive.
(For example, what is it about a script writing an internal notecard that causes this to be a "security risk" function in OSSL? Would someone involved in that decision please explain to me their reasoning? Perish forbid a script would write a "deadly notecard".)
There's only so many "safeguards" that can be imposed on a system... and some safeguards are more brick walls than helpful. I believe this event timeout concept is one of those brick walls. But I leave that to those that work with deep system code on a daily basis. I'm a user and don't know all the pros and cons of system functions.