DotNetEngine and xengine

The realization
Before my hands went bad I started the process of introducing a new common way of implementing script engines. This came from the realization of two things. First of all that many had difficulties understanding how to implement their own engine variations based on current engine, and second that not all developers are willing to conform to one structure.

Developers are (often) skilled people and often have a clear understanding of what is right. Structure and rules on how to do things are key elements to write good code. And with the complexity of modular programming languages there is more than one way to get things done ‘right’.

The idea behind DotNetEngine was simple. We implement an engine consisting of a set of modules and a couple of classes to bind it all (main ScriptEngine and in-world ScriptLoader). Any new script engine could then inherit what it liked and ignore what it didn’t like.

DotNetEngine was made from the assumption that users are hostile (or stupid). They will run too many scripts, script may be harmful to system, etc. It works with a set of queues that ensures equal priority for all scripts and will drop loading/execution if system resources is exhausted (if you don’t have a fast enough CPU). It allows things like regions themselves and physics to go in front of script execution.

I felt this approach was correct for a generic engine as it would guarantee a smooth region execution.

xengine is for the most part the effort of Melanie. It is targeted towards gaming in the sense that scripts essentially will have dominance over resources.

With the introduction of xengine the DotNetEngine modular inheritance model was bypassed and most of DotNetEngine simply copied into xengine and made modifications to. This means that any patch needs to be applied to two places, which of course meant double work and ended in it not being done. This was especially bad for LSL implementation where steady progress has been over a long period of time and suddenly there were demands that new functions should be implemented only in xengine.

DotNetEngine vs xengine
There has been an ongoing conflict between the developers on how to solve this problem. On one side we have the newly formed xengine mob which feels that DotNetEngine is inferior, and on the other side we have those who cheer for DotNetEngine and a revamp.

I’ve personally chosen not to take part in this debate as I agree with Einstein (with a modification) – Politics lasts for about a month, code lasts forever. I have however seen a lot of false assumptions been spoken both about DotNetEngine and about my self and my intentions, as well as a few true ones. But I believe this is totally irrelevant. We have the power to fix anything, and frankly most of the ones pointed out in DotNetEngine are not that big. However I feel some sides in this case may have be pushing too strongly on the political side and not doing too enough the code side to solve the problem – and that is a WOMBAT. (Waste Of Money, Brains And Time)

Now back to this common structure I mentioned at the start of this post.
— to be continued in next post —

1 thought on “DotNetEngine and xengine”

  1. I think you are right, they should push together to make 1 engine better. Not two new or more, because in the end, there is only 1 running on most of the sim.Lets not create conflict and wombat, work together.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.