YEngine is a more modern script engine than XEngine. Its main advantage is that it recovers memory from scripts, which XEngine does not do, according to the OpenSim documentation. Its syntax and error reporting is also supposed to be better (and is supposed to be closer to the standard syntax of the SL script engine). It is the default script engine from OpenSim and this means that we will needed to switch to it for a forthcoming upgrade if we are to follow standard developments in OpenSim (although XEngine will still be available). It makes made sense to perform a phased switchover (functionally an upgrade) to YEngine before doing a full upgrade in order to check to see whether anything breaks broke (and fix it). Consequently, we are starting started by moving empty regions like sea areas and little-used islands over to YEngine first and then we will moved the three most developed islands one by one. The hope is that the need to restart simulators will be less frequent once memory is recovered automatically by the script engine.

This experience has been so good that we wholeheartedly recommend that all grids switch to YEngine unless there is a very good reason not to do so. The only one that I can think of is those people who are writing scripts in C#, which YEngine does not support but XEngine does. This can't be very many people. Do NOT try to run both script engines at once. The performance problems are huge.

[Final edit at 2021-12-21 15:36]

All complete at 2021-12-21 15:29 GMT: all sea areas with 5122 island region Manaw, the 12802 large island region Rheged, the 2562 island regions Aeron, Gododdin, Celyddon & Annwfn: scripts fixed. See below for stats for minor script errors fixed.

Stats on compile errors at 2021-12-21 15:29 GMT:

  • Rheged: 1 (of 19 = ~5.3%. This script was probably already broken but this was experimental/test code.)
  • Manaw: 0 (of only 2 scripts here anyway! 0%)
  • Sea areas (6): 0 (of only 2 scripts each here anyway! 0%)
  • Gododdin: 11 (of 1072 = ~1.0%)
  • Celyddon: 9 (of 1075 = ~0.8%)
  • Annwfn: 8 (of 896 = ~0.9%)


  • YEngine also has some improvements and additions that can simplify scripting, as documented on the OpenSim YEngine page.
  • The biggest challenge is concern was the three 2562 island regions Annwfn (home region), Celyddon & Gododdin. These are where all the major sights are and consequently lots of scripts that might possibly break here and there where YEngine syntax is stricter. We shall see how good our scripting standards are! Apparently our scripting standards are on the whole pretty good with some minor errors only!
  • The errors in the logs conveniently give prim name:script name and the vector coordinates of the prim, so it's quite easy to track down and fix these scripts. Perhaps some of them were already broken?
  • It does seem from these fixes that XEngine allowed many type errors to pass, possibly breaking expected behaviour in some cases (see points below on touch_* events).
  • The slow region start/restart caused by XEngine having to tediously convert all of the scripts into C# is avoided, meaning that regions come up much faster!
  • In fact, shutting down threads also seems faster, so the slow shutdown problem is also considerably improved!
  • Performance is noticeably improved: no doubt through much better thread management for scripts.
  • Initial monitoring (using top in Linux/Debian) shows a dramatically reduced memory imprint. If this is sustained then performance will be increased, which will be very high given that we have 32GB RAM on the server, and region restarts will no longer have to be performed once or twice daily! This could potentially open the door to running additional simulators, although there are no plans to do so at present after the recent addition of 6 new regions of various sizes on an additional simulator (1 new island and 5 sea areas).
  • Mostly these were very silly mistakes in scripting that XEngine ignored. None had significant security errors: e.g. all prevented use by groups where it should have been allowed is more restrictive rather than less). All examples so far have been touch_* events using llDetected* functions including a very few integers compared with TRUE where the word was mistakenly put in brackets as a string (which would have failed).
  • We are not including multiple similar errors in one script in these stats.
  • We ignored warnings about script-defined type declarations, which are numerous but do not prevent scripts running. On a further restart, these did not reoccur.