<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.secondlife.com/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Periapse+Linden</id>
	<title>Second Life Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.secondlife.com/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Periapse+Linden"/>
	<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/wiki/Special:Contributions/Periapse_Linden"/>
	<updated>2026-07-02T03:21:13Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.42.1</generator>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=488092</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=488092"/>
		<updated>2009-09-11T15:53:51Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* FAQs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&lt;br /&gt;
{| align=&amp;quot;right&amp;quot; style=&amp;quot;text-align: center&amp;quot; width=&amp;quot;375&amp;quot;&lt;br /&gt;
| &amp;lt;videoflash&amp;gt;cGoM9p7q1jk&amp;lt;/videoflash&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 DOWNLOAD this video in high-quality!]&#039;&#039;&#039; and&amp;lt;br /&amp;gt; &#039;&#039;&#039;[[Mono_demos|watch more videos of Mono in action]]&#039;&#039;&#039;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) has not changed in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is now live on the main grid with server version 1.24.3&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
== How LSL scripts work ==&lt;br /&gt;
&lt;br /&gt;
Linden Lab server programs, known as &#039;&#039;simulators&#039;&#039; or &#039;&#039;sims&#039;&#039;, run all LSL scripts.  When you teleport, or region cross, your new region&#039;s sim takes on the task of running all your scripted attachments. But a sim cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called &#039;&#039;compilation&#039;&#039;, and the resulting machine-readable version of the script is called &#039;&#039;bytecode&#039;&#039;. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, rsulting in server-side lag. Thus, anything that can speed up the execution of scripts can push out the point where server lag starts to occur.&lt;br /&gt;
&lt;br /&gt;
=== Enter Mono ===&lt;br /&gt;
Mono is an open-source scripting engine with a proven record of speed and versatility.  But switching engines requires a compiler that can turn LSL scripts into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave exactly like scripts running under the original engine. This desire for  backward compatibility required an extraordinary amount of testing.&lt;br /&gt;
&lt;br /&gt;
== Mono on the main grid ==&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono was deployed to the main grid in [[Release_Notes/Second_Life_Server/1.24#Release_Notes_for_Second_Life_Server_1.24.3_.28August_29th.2C_2008.29:| server version 1.24]] on 29 August 2008.  &lt;br /&gt;
&lt;br /&gt;
The Mono Viewer changes were first available in the 1.21 client, and are now present in all allowed SL viewers. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months Linden Lab may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. However, the servers will also maintain the original scripting engine to enable old scripts to run as before, but run as Mono as soon as they are edited.&lt;br /&gt;
&lt;br /&gt;
== Mono benefits ==&lt;br /&gt;
Performance benchmark tests show that Mono is up to 220 times faster than LSL2. The benchmarks were math-intensive scripts typically used to evaluate performance. For ordinary scripts, the performance gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation.  LSL2 allocates a full 16KB for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones.  Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
== How to use Mono ==&lt;br /&gt;
&lt;br /&gt;
Mono is now fully deployed to the main grid with server 1.24.3. All allowed SL viewers have the interface to create Mono scripts. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Log in to Second Life with a Release or Release Candidate viewer&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script and compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Create an object and add a new script to it&lt;br /&gt;
** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* Public JIRA [https://jira.secondlife.com/secure/CreateIssue!default.jspa create issue]&lt;br /&gt;
* If an issue already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
== Testing ==&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
== FAQs ==&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on Resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
:* Dividing by zero - LSL2 errors on divide by zero, Mono uses value &amp;quot;Infinity&amp;quot; and does not error. &lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the Resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
== Mono Memory Myths ==&lt;br /&gt;
&#039;&#039;&#039;NOTE:&#039;&#039;&#039; The following has been commented on since by the OpenSim wiki - Miguel was testing an idle region without any background activity or users. It is not a representitive test. See more at [http://opensimulator.org/wiki/Mono]&lt;br /&gt;
&lt;br /&gt;
Experience with Mono in Opensim has led to the widespread belief that Mono on Linux is an extreme memory hog compared to .NET on MS Windows.  This belief has been countered by the creator of Mono, [http://en.wikipedia.org/wiki/Miguel_de_Icaza Miguel de Icaza], after he performed direct tests on 14th June 2009 in Vista 32, Linux 32, and Linux 64.  His results and advice were posted on [http://pastebin.ca/1460383 pastebin], and are repeated here since that site is not intended for persistent publication:&lt;br /&gt;
&lt;br /&gt;
 A third follow up.&lt;br /&gt;
 &lt;br /&gt;
 With the help from the guys on #opensim on irc.freenode.org I got myself a sample virtual world from:&lt;br /&gt;
 &lt;br /&gt;
 http://opensimworlds.com/index.php?part=worlds&lt;br /&gt;
 &lt;br /&gt;
 I used &amp;quot;Nu Athens&amp;quot; a free download and loaded it up on 3 configurations:&lt;br /&gt;
 &lt;br /&gt;
 Vista, running 32 bit OpenSim&lt;br /&gt;
 Linux, running 64 bit OpenSim&lt;br /&gt;
 Linux, running 32 bit OpenSim&lt;br /&gt;
 &lt;br /&gt;
 And then I loaded all the four files provided in the zip file using the command:&lt;br /&gt;
 &lt;br /&gt;
 load oar FILE.tar.gz&lt;br /&gt;
 &lt;br /&gt;
 The results are as follows:&lt;br /&gt;
 &lt;br /&gt;
 Vista/32: 115 megs + 5 meg helper process (OpenSim.vhost.exe)&lt;br /&gt;
 &lt;br /&gt;
 Mono/32: 92 megs, after a few minutes of inactivity, it goes down to 87 megs.&lt;br /&gt;
 &lt;br /&gt;
 Mono/64: 122 megs, after a few minutes of inactivity, it goes down to 89 megs.   &lt;br /&gt;
 &lt;br /&gt;
 The garbage collector is responsible for the difference in memory usage between the load finished&lt;br /&gt;
 and waiting (I ran into this problem because I came to measure again after a few seconds and the&lt;br /&gt;
 size had been reduced).&lt;br /&gt;
 &lt;br /&gt;
 The Vista system remains at 120 megs total for the same world.&lt;br /&gt;
 &lt;br /&gt;
 So Mono on Linux on both 32 and 64 bit configurations is consuming less memory than Vista, some&lt;br /&gt;
 40 megs out of 120, or one third less memory.&lt;br /&gt;
 &lt;br /&gt;
 Perhaps the difference is in the version of Mono that we are running.  I am running with Mono 2.4,&lt;br /&gt;
 and the OpenSim documentation implies that OpenSim can work with systems like Mono 1.2.6 which is&lt;br /&gt;
 primitive by our standards (that was released more than two years ago).&lt;br /&gt;
 &lt;br /&gt;
 In Mono 2.0, Mono 2.2 and Mono 2.4 we introduced many memory reduction features.   From using&lt;br /&gt;
 precise collection for the HEAP, to reducing the size of generics-heavy code to reduction in code&lt;br /&gt;
 size generated and runtime metadata tables.&lt;br /&gt;
 &lt;br /&gt;
 I would appreciate if you could post a correction to your data in the main article, as it seems to&lt;br /&gt;
 have spread and this could negatively impact the perception of the Mono&#039;s community work towards&lt;br /&gt;
 making a great .NET implementation for Unix.&lt;br /&gt;
 &lt;br /&gt;
 Miguel&lt;br /&gt;
&lt;br /&gt;
* PS. Miguel is measuring RSS (not VSIZE), for reasons explained [http://opensimulator.org/wiki/Talk:Mono in an earlier post].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono/Beta_FAQ&amp;diff=388793</id>
		<title>Mono/Beta FAQ</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono/Beta_FAQ&amp;diff=388793"/>
		<updated>2009-06-10T22:23:23Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;This page is now deprecated. Mono is no longer in beta, having gone live on the Main Grid in August, 2008.&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Here you will find information on the [[Mono]] beta program. If you have questions on the Mono beta that are not answered here, please ask them on the discussion tab for this page. Please limit your questions to the Mono beta. If your questions concern the Second Life Mono implementation or the future plans for Mono, please ask them on the general [[Mono]] page. You can also attend the beta office hour sessions: Wednesday 8am, Friday 3pm, SLT, on the preview grid (Sandbox Goguen MONO). &lt;br /&gt;
&lt;br /&gt;
= Basic Information =&lt;br /&gt;
The Mono beta runs on Aditi, Linden Lab&#039;s preview grid. This grid is not part of the Main Grid, and you will use a special viewer to connect to it. This viewer also has the necessary user interface elements to start using Mono for your LSL scripts.  Inventory and Linden$ transactions will not affect your Main Grid account. Items created on the preview grid will not appear in your main grid inventory.&lt;br /&gt;
* Beta start date: 29 January 2008&lt;br /&gt;
* Location: Preview grid (Aditi)&lt;br /&gt;
* Regions: &lt;br /&gt;
** Sandbox Cordova MONO&lt;br /&gt;
** Sandbox Goguen MONO&lt;br /&gt;
** Sandbox Newcomb MONO&lt;br /&gt;
** Sandbox Wanderton MONO&lt;br /&gt;
** Note: all other regions on the preview grid (most of the grid, in fact) are running simulators for the Havok4 physics beta, occurring at the same time as the Mono beta. &lt;br /&gt;
** Make sure you go to one of these Mono-enabled regions to test Mono. &lt;br /&gt;
* Download viewers: [http://secondlife.com/community/preview.php beta viewers]&lt;br /&gt;
* The Mono UI is really simple, a single checkbox on the script edit window will select compilation to Mono. &lt;br /&gt;
** Note: the checkbox is a compile target switch, so it is only available when you can compile. This means that the script must be in the contents of a rezzed object. A script window opened from inventory does not allow compilation, and hence lacks the Mono checkbox.&lt;br /&gt;
** You can also select several inworld objects at once, and use the Tools menu, Recompile Scripts in Selection, Mono to recompile all the scripts in many objects at once.&lt;br /&gt;
* JIRA meta issue: [https://jira.secondlife.com/browse/SVC-1276 SVC-1276]&lt;br /&gt;
** If you find a bug, first check the issues in the meta issue to see if it&#039;s already been reported&lt;br /&gt;
** If not, create a new issue, make sure &amp;quot;Mono beta&amp;quot; is in the subject line, and link it to the meta issue. &lt;br /&gt;
** Try to give a &#039;&#039;minimal&#039;&#039; repro for your bug. A code snippet which the bug breaks is best.&lt;br /&gt;
* We have now set up a group, Mono Beta. It is free to join, so if you have a free group slot please consider joining. We will use the group to message our status, let you know what we&#039;re working on, announce office hours, etc. We will still use the main Linden blog for major announcements such as when we update the beta simulators.&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
If you have a question about the Mono beta, and it is not answered here, please add it to the discussion tab.&lt;br /&gt;
&lt;br /&gt;
; What is this &amp;quot;Mono&amp;quot; I&#039;ve heard about? : Mono is a technology for making LSL scripts run much faster. You can read more about it on the [[Mono | Mono wiki page]].&lt;br /&gt;
&lt;br /&gt;
; What is the purpose of this Mono beta? : Simply put, we want to find bugs. Before Mono is ready to go out on the Main Grid we want confidence that LSL scripts run the same under Mono as they do now (they&#039;ll just run much faster). Mono has been in QA at Linden Lab for several months, but even that isn&#039;t enough to give us the assurance we need. &lt;br /&gt;
&lt;br /&gt;
; How do I sign up for the beta? : You don&#039;t! Just come on over. You will need to download a special viewer to connect to the preview grid. The link is above, in the Basic Information section. For step by step instructions try the [[Mono#Mono_How-to | Mono Beta How To]] page.&lt;br /&gt;
&lt;br /&gt;
; What happens if I compile one of my scripts to Mono, and then take it to a non-Mono region on the preview grid? : Since we are sharing the preview grid with the Havok4 team this is a likely possibility. Scripts compiled to Mono will not run in the Havok4 regions. You will get an &amp;quot;Unrecognized bytecode&amp;quot; error when you rez the object and the sim determines it cannot run the script. You can either take the object back into inventory and go to a Mono region, or you can recompile the script(s) in the object back to LSL2 (uncheck the &amp;quot;compile to Mono&amp;quot; option).&lt;br /&gt;
&lt;br /&gt;
; I got on the preview grid, but there is no &amp;quot;Mono checkbox&amp;quot; which allows me to compile a script to Mono. : The checkbox is on the LSL script editor dialog. You should see it at the bottom of the window. If there is no checkbox, then you likely aren&#039;t using the Mono viewer. Download the Mono viewer from the links section at the top of this page. Also remember that you can only compile scripts that are contained in objects rezzed inworld. You cannot compile scripts from inventory.&lt;br /&gt;
&lt;br /&gt;
; Ok, I downloaded the Mono viewer, and I see the checkbox, but I can&#039;t select it to compile to Mono. : Most likely you aren&#039;t in a Mono region -- we are sharing the preview grid with Havok4. Teleport to a Mono-enabled region (list at the top of this page).&lt;br /&gt;
&lt;br /&gt;
; These sandboxes are ok, but I need to test scripts under special parcel rules like damage enabled? : We have added a few special parcels, specified below. Note that because this is a beta we have to restore simstates rather frequently. These parcels may at times not be available, or need to be recreated. &lt;br /&gt;
* Water region for testing water vehicles (would like to test water region crossing).&lt;br /&gt;
** Pond at eastern edge of Cordova&lt;br /&gt;
** Water parcel spanning Goguen-Cordova border&lt;br /&gt;
* Damage/push enabled for testing weapons&lt;br /&gt;
** Plateau at northern end of Newcomb&lt;br /&gt;
* No-script area for testing attachments while crossing parcel line into no-script&lt;br /&gt;
** Northwest part of Newcomb has an elevated parcel that is no scripts. &lt;br /&gt;
* Teen Grid Region&lt;br /&gt;
** Once havok4 is done with the preview grid we will add a host for tg regions. &lt;br /&gt;
* No autoreturn parcel for testing long-lived scripts&lt;br /&gt;
** All of Cordova is no autoreturn. &lt;br /&gt;
* Parcel for testing LSL media calls&lt;br /&gt;
** The &amp;quot;No Scripts&amp;quot; parcel at the Northwestern part of Newcomb is assigned to the Mono beta group. If you join that group you will have rights on this land and should be able to set the media stream.&lt;br /&gt;
&lt;br /&gt;
= Office hour transcripts =&lt;br /&gt;
* [[Mono/2008-01-30 | 30 January 2008]]&lt;br /&gt;
* [[Mono/2008-02-08 | 8 February 2008]]&lt;br /&gt;
* [[Mono/2008-02-14 | 14 February 2008]]&lt;br /&gt;
* [[Mono/2008-02-20 | 20 February 2008]]&lt;br /&gt;
* [[Mono/2008-02-22 | 22 February 2008]]&lt;br /&gt;
* [[Mono/2008-02-27 | 27 February 2008]]&lt;br /&gt;
* [[Mono/2008-02-29 | 29 February 2008]]&lt;br /&gt;
* [[Mono/2008-03-05 | 5 March 2008]]&lt;br /&gt;
* [[Mono/2008-03-07 | 7 March 2008]]&lt;br /&gt;
* [[Mono/2008-03-14 | 14 March 2008]]&lt;br /&gt;
* [[Mono/2008-03-19 | 19 March 2008]]&lt;br /&gt;
* [[Mono/2008-03-28 | 28 March 2008]]&lt;br /&gt;
* [[Mono/2008-04-04 | 04 April 2008]]&lt;br /&gt;
* [[Mono/2008-30-04 | 30 April 2008]]&lt;br /&gt;
* [[Mono/2008-05-07 | 7 May 2008]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=388773</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=388773"/>
		<updated>2009-06-10T22:20:08Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* FAQs */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&lt;br /&gt;
{| align=&amp;quot;right&amp;quot; style=&amp;quot;text-align: center&amp;quot; width=&amp;quot;375&amp;quot;&lt;br /&gt;
| &amp;lt;videoflash&amp;gt;cGoM9p7q1jk&amp;lt;/videoflash&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 DOWNLOAD this video in high-quality!]&#039;&#039;&#039; and&amp;lt;br /&amp;gt; &#039;&#039;&#039;[[Mono_demos|watch more videos of Mono in action]]&#039;&#039;&#039;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) has not changed in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is now live on the main grid with server version 1.24.3&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
== How LSL scripts work ==&lt;br /&gt;
&lt;br /&gt;
Linden Lab server programs, known as &#039;&#039;simulators&#039;&#039; or &#039;&#039;sims&#039;&#039;, run all LSL scripts.  When you teleport, or region cross, your new region&#039;s sim takes on the task of running all your scripted attachments. But a sim cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called &#039;&#039;compilation&#039;&#039;, and the resulting machine-readable version of the script is called &#039;&#039;bytecode&#039;&#039;. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, rsulting in server-side lag. Thus, anything that can speed up the execution of scripts can push out the point where server lag starts to occur.&lt;br /&gt;
&lt;br /&gt;
=== Enter Mono ===&lt;br /&gt;
Mono is an open-source scripting engine with a proven record of speed and versatility.  But switching engines requires a compiler that can turn LSL scripts into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave exactly like scripts running under the original engine. This desire for  backward compatibility required an extraordinary amount of testing.&lt;br /&gt;
&lt;br /&gt;
== Mono on the main grid ==&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono was deployed to the main grid in [[Release_Notes/Second_Life_Server/1.24#Release_Notes_for_Second_Life_Server_1.24.3_.28August_29th.2C_2008.29:| server version 1.24]] on 29 August 2008.  &lt;br /&gt;
&lt;br /&gt;
The Mono Viewer changes were first available in the 1.21 client, and are now present in all allowed SL viewers. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months Linden Lab may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. However, the servers will also maintain the original scripting engine to enable old scripts to run as before, but run as Mono as soon as they are edited.&lt;br /&gt;
&lt;br /&gt;
== Mono benefits ==&lt;br /&gt;
Performance benchmark tests show that Mono is up to 220 times faster than LSL2. The benchmarks were math-intensive scripts typically used to evaluate performance. For ordinary scripts, the performance gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation.  LSL2 allocates a full 16KB for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones.  Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
== How to use Mono ==&lt;br /&gt;
&lt;br /&gt;
Mono is now fully deployed to the main grid with server 1.24.3. All allowed SL viewers have the interface to create Mono scripts. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Log in to Second Life with a Release or Release Candidate viewer&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script and compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Create an object and add a new script to it&lt;br /&gt;
** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* Public JIRA [https://jira.secondlife.com/secure/CreateIssue!default.jspa create issue]&lt;br /&gt;
* If an issue already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
== Testing ==&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
== FAQs ==&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=388763</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=388763"/>
		<updated>2009-06-10T22:18:33Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* How to use Mono */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&lt;br /&gt;
{| align=&amp;quot;right&amp;quot; style=&amp;quot;text-align: center&amp;quot; width=&amp;quot;375&amp;quot;&lt;br /&gt;
| &amp;lt;videoflash&amp;gt;cGoM9p7q1jk&amp;lt;/videoflash&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 DOWNLOAD this video in high-quality!]&#039;&#039;&#039; and&amp;lt;br /&amp;gt; &#039;&#039;&#039;[[Mono_demos|watch more videos of Mono in action]]&#039;&#039;&#039;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) has not changed in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is now live on the main grid with server version 1.24.3&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
== How LSL scripts work ==&lt;br /&gt;
&lt;br /&gt;
Linden Lab server programs, known as &#039;&#039;simulators&#039;&#039; or &#039;&#039;sims&#039;&#039;, run all LSL scripts.  When you teleport, or region cross, your new region&#039;s sim takes on the task of running all your scripted attachments. But a sim cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called &#039;&#039;compilation&#039;&#039;, and the resulting machine-readable version of the script is called &#039;&#039;bytecode&#039;&#039;. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, rsulting in server-side lag. Thus, anything that can speed up the execution of scripts can push out the point where server lag starts to occur.&lt;br /&gt;
&lt;br /&gt;
=== Enter Mono ===&lt;br /&gt;
Mono is an open-source scripting engine with a proven record of speed and versatility.  But switching engines requires a compiler that can turn LSL scripts into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave exactly like scripts running under the original engine. This desire for  backward compatibility required an extraordinary amount of testing.&lt;br /&gt;
&lt;br /&gt;
== Mono on the main grid ==&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono was deployed to the main grid in [[Release_Notes/Second_Life_Server/1.24#Release_Notes_for_Second_Life_Server_1.24.3_.28August_29th.2C_2008.29:| server version 1.24]] on 29 August 2008.  &lt;br /&gt;
&lt;br /&gt;
The Mono Viewer changes were first available in the 1.21 client, and are now present in all allowed SL viewers. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months Linden Lab may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. However, the servers will also maintain the original scripting engine to enable old scripts to run as before, but run as Mono as soon as they are edited.&lt;br /&gt;
&lt;br /&gt;
== Mono benefits ==&lt;br /&gt;
Performance benchmark tests show that Mono is up to 220 times faster than LSL2. The benchmarks were math-intensive scripts typically used to evaluate performance. For ordinary scripts, the performance gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation.  LSL2 allocates a full 16KB for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones.  Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
== How to use Mono ==&lt;br /&gt;
&lt;br /&gt;
Mono is now fully deployed to the main grid with server 1.24.3. All allowed SL viewers have the interface to create Mono scripts. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Log in to Second Life with a Release or Release Candidate viewer&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script and compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Create an object and add a new script to it&lt;br /&gt;
** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* Public JIRA [https://jira.secondlife.com/secure/CreateIssue!default.jspa create issue]&lt;br /&gt;
* If an issue already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
== Testing ==&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
== FAQs ==&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=388723</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=388723"/>
		<updated>2009-06-10T22:01:01Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Mono on the main grid */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&lt;br /&gt;
{| align=&amp;quot;right&amp;quot; style=&amp;quot;text-align: center&amp;quot; width=&amp;quot;375&amp;quot;&lt;br /&gt;
| &amp;lt;videoflash&amp;gt;cGoM9p7q1jk&amp;lt;/videoflash&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| &#039;&#039;&#039;[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 DOWNLOAD this video in high-quality!]&#039;&#039;&#039; and&amp;lt;br /&amp;gt; &#039;&#039;&#039;[[Mono_demos|watch more videos of Mono in action]]&#039;&#039;&#039;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) has not changed in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is now live on the main grid with server version 1.24.3&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br/&amp;gt;&lt;br /&gt;
== How LSL scripts work ==&lt;br /&gt;
&lt;br /&gt;
Linden Lab server programs, known as &#039;&#039;simulators&#039;&#039; or &#039;&#039;sims&#039;&#039;, run all LSL scripts.  When you teleport, or region cross, your new region&#039;s sim takes on the task of running all your scripted attachments. But a sim cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called &#039;&#039;compilation&#039;&#039;, and the resulting machine-readable version of the script is called &#039;&#039;bytecode&#039;&#039;. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, rsulting in server-side lag. Thus, anything that can speed up the execution of scripts can push out the point where server lag starts to occur.&lt;br /&gt;
&lt;br /&gt;
=== Enter Mono ===&lt;br /&gt;
Mono is an open-source scripting engine with a proven record of speed and versatility.  But switching engines requires a compiler that can turn LSL scripts into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave exactly like scripts running under the original engine. This desire for  backward compatibility required an extraordinary amount of testing.&lt;br /&gt;
&lt;br /&gt;
== Mono on the main grid ==&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono was deployed to the main grid in [[Release_Notes/Second_Life_Server/1.24#Release_Notes_for_Second_Life_Server_1.24.3_.28August_29th.2C_2008.29:| server version 1.24]] on 29 August 2008.  &lt;br /&gt;
&lt;br /&gt;
The Mono Viewer changes were first available in the 1.21 client, and are now present in all allowed SL viewers. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months Linden Lab may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. However, the servers will also maintain the original scripting engine to enable old scripts to run as before, but run as Mono as soon as they are edited.&lt;br /&gt;
&lt;br /&gt;
== Mono benefits ==&lt;br /&gt;
Performance benchmark tests show that Mono is up to 220 times faster than LSL2. The benchmarks were math-intensive scripts typically used to evaluate performance. For ordinary scripts, the performance gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation.  LSL2 allocates a full 16KB for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones.  Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
== How to use Mono ==&lt;br /&gt;
&lt;br /&gt;
Mono is now fully deployed to the main grid with server 1.24.3. All regions can now run scripts compiled to Mono. You need a viewer versioned 1.21 or later to compile scripts to Mono, however no special viewer is needed to run previously compiled Mono scripts. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** The 1.21 viewer is available in release candidate. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** All regions are Mono-enabled as of 29 August 2008&lt;br /&gt;
** Blog: http://blog.secondlife.com/2008/08/20/mono-launch/&lt;br /&gt;
** Release notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24&lt;br /&gt;
** Forum thread, for comments: http://forums.secondlife.com/showthread.php?p=2115465&lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script and compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Create an object and add a new script to it&lt;br /&gt;
** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
== Testing ==&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
== FAQs ==&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=340822</id>
		<title>LSL HTTP server/beta</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=340822"/>
		<updated>2009-04-30T17:24:13Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[Update, 30 April 09] The HTTP-in code is in trunk and slated for release with Server 1.27. The http-in sandbox regions will remain on aditi until the first 1.27 server is branched from trunk and deployed to all of aditi for testing. This will likely happen in May, with 1.27 deployed to agni in June. &lt;br /&gt;
&lt;br /&gt;
[Update, 6 Feb 09] We still haven&#039;t acquired the merge lock, but Kelly did a new branch off of trunk anyway and Prospero has graciously redeployed http-in to select aditi regions. The http-in sandboxes mentioned below are back online.&lt;br /&gt;
&lt;br /&gt;
[Update, 23 Jan 09] I&#039;d like to thank everyone who participated in this beta. Thanks to your help with testing all the edges and corners of the http-in functionality we passed QA&#039;s integration testing. Http-in is now awaiting the lock to merge into trunk, hopefully for the 1.26 server version. The http-in beta sandbox regions are likely to go down for several days until we actually acquire the lock. At that time we&#039;ll redeploy the merged version for final testing.&lt;br /&gt;
&lt;br /&gt;
;  Where?&lt;br /&gt;
:Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; where n is 1,2, or 3.&lt;br /&gt;
;  What viewer should I use?&lt;br /&gt;
: Use a mono-compatible main grid viewer (version 1.21 or later), and have it log you into aditi. Shift-control-g at the login screen brings up the grid select dropdown. Aditi = preview grid, Agni = main grid.&lt;br /&gt;
; But the viewer won&#039;t know about the new functions&lt;br /&gt;
: When using a Mono-enabled viewer, all compilation is done server side. So make sure you are using a mono-enabled viewer and you will be able to compile a script with the new functions as long as you are in one of the http-in sandboxes. You do not need to have &amp;quot;Mono&amp;quot; checked (see [http://forums.secondlife.com/showthread.php?t=287764 this forum thread]).&lt;br /&gt;
; How do I report bugs?&lt;br /&gt;
: Check this meta JIRA - {{Jira|SVC-3238}}. Existing issues for http-in are linked. Check the open issues to see if your bug is already listed. If so, consider commenting on that issue to add any insights you have. If not, create a new issue. Make sure you:&lt;br /&gt;
* JIRA should be SVC&lt;br /&gt;
* Title should start &amp;quot;http-in:&amp;quot;&lt;br /&gt;
* Component &amp;quot;Scripts&amp;quot;&lt;br /&gt;
* Affects version is unimportant&lt;br /&gt;
* Please include a minimal repro of the bug. Pare down the code to the minimum necessary to exhibit the issue.&lt;br /&gt;
* Link your issue &amp;quot;Relates to&amp;quot; SVC-3238&lt;br /&gt;
; What if I have questions?&lt;br /&gt;
: Several resources are available&lt;br /&gt;
* Use the discussion tab for this page to ask questions about the beta&lt;br /&gt;
* If you are a member of secondlifescripters@lists.secondlife.com you can post a question.&lt;br /&gt;
* Or try asking on the second life lsl forum. &lt;br /&gt;
* I (Periapse Linden) hold an office hour on Fridays at 3pm. Location is Beaumont, eastern edge, under the hill with the observatory dome.&lt;br /&gt;
; What about Teen Grid residents?&lt;br /&gt;
: Teen grid residents are welcome to participate in this beta. Log in to aditi with the appropriate viewer (see above). Teleport to &amp;quot;Http In Sandbox Teen&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Resources ==&lt;br /&gt;
* New functions and their arguments: [[LSL http server]]&lt;br /&gt;
* Meta JIRA with all known issues: {{Jira|SVC-3238}}&lt;br /&gt;
* [[LSL_http_server/examples | Code samples]]&lt;br /&gt;
* Design JIRA: {{Jira|SVC-1086}}&lt;br /&gt;
* Design docs: [[LSL_http_server/design]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono_Scheduler_testing&amp;diff=312322</id>
		<title>Mono Scheduler testing</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono_Scheduler_testing&amp;diff=312322"/>
		<updated>2009-04-10T19:08:06Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A [[simulator]] which incorporates a revised [[Mono]] Scheduler was deployed to [[Aditi]], the preview grid, on 19 March 2009. For the next two weeks [[Resident]]s will be able to go to these [[region]]s and test their [[script]]s on this scheduler. Please return any feedback you have to the [[Issue Tracker|JIRA]] listed below. We&#039;ll use that feedback to fine tune the scheduler performance before we merge it into trunk for release with an upcoming server version.&lt;br /&gt;
&lt;br /&gt;
Please provide any feedback as a comment to {{Jira|SVC-3997}}. If you find any outright bugs, please create a separate JIRA and link it to this one.&lt;br /&gt;
&lt;br /&gt;
Update: &#039;&#039;10April09&#039;&#039;&lt;br /&gt;
&#039;&#039;Based on the wealth of resident testing and analysis presented in {{Jira|SVC-3997}} we&#039;ve decided to hold off on the deploy of the new Mono Scheduler. Instead we will await the next Mono-related project, the effort to transition to 64-bit, and fold the Mono scheduler into that project. Additionally we&#039;ll figure out how best to optimize the simple library functions to mitigate the observed slowdowns. The Scheduler Test regions on aditi will be around over the weekend, but will likely be taken down before the 17th of April.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== The Mono Scheduler ==&lt;br /&gt;
The Scheduler is responsible for managing time and memory resources for all the scripts running in a simulator. As a busy sim might have thousands of active scripts, keeping them all happy and keeping overall simulator performance up is non-trivial. Changes to the scheduler can affect existing scripts: some might run out of memory and break, others might experience performance differences. Because of these possible behavior changes we want to give Residents the chance to test their scripts and give us feedback. We can fine tune the Scheduler so that content is minimally affected.&lt;br /&gt;
&lt;br /&gt;
== Motivation for the reworking ==&lt;br /&gt;
The original Mono Scheduler shipped with [[Release_Notes/Second_Life_Server/1.24|server 1.24]] -- the version that introduced Mono. Its non-deterministic behavior had two deleterious side effects:&lt;br /&gt;
* Some &amp;quot;lucky&amp;quot; scripts were able to acquire more than the 64K memory limit, decreasing available memory for other scripts.&lt;br /&gt;
* Other scripts were able to monopolize time resources, increasing their performance at the expense of other scripts and region performance.&lt;br /&gt;
&lt;br /&gt;
A fix for this was included in an early version of [[Release_Notes/Second_Life_Server/1.25|server 1.25]], however this fix was reverted because it broke considerable content. Babbage Linden and Studio Blighty then reworked the Mono Scheduler so as to make it deterministic, but also to allow us to tune its performance. We now have a version which passes our benchmarks, and we&#039;d like to share that version with the SL scripting community for feedback.&lt;br /&gt;
&lt;br /&gt;
== Goal for this revision == &lt;br /&gt;
Since simulator resources (cpu, memory) are limited the Scheduler&#039;s job is essentially making tradeoffs. Too tight a control and scripts run out of memory more frequently, and script performance is unacceptable. Too loose control allows scripts to hog cpu and RAM at the expense of the simulator&#039;s other duties (physics, communication) and so region performance becomes unacceptable. &lt;br /&gt;
&lt;br /&gt;
We added some benchmark tests to our internal QA for the scheduler in an attempt to find a sweet spot which delivers optimal script and region performance. The scheduler deployed for testing passes those benchmarks, so now we need Resident feedback. &lt;br /&gt;
&lt;br /&gt;
== Who should test ==&lt;br /&gt;
If you&#039;re a scripter who uses Mono for LSL and you write scripts which have either or both:&lt;br /&gt;
* high memory consumption &lt;br /&gt;
* a lot of calculation/processing&lt;br /&gt;
then you should consider testing your scripts in the provided sandbox. Scripts which operate on large lists are particularly prone to be in both of those categories and should be tested. &lt;br /&gt;
&lt;br /&gt;
== How to test == &lt;br /&gt;
# Use any recent Viewer to go to Aditi, the preview grid.&lt;br /&gt;
#* from the login screen hit {{KeyCombo|shift=*|ctrl=*|G}} to bring up the grid dropdown menu&lt;br /&gt;
#* select &amp;quot;Aditi&amp;quot; from the menu&lt;br /&gt;
#* Note: if {{KeyCombo|shift=*|ctrl=*|G}} doesn&#039;t work, try clicking on the Name or Password boxes to move focus to the dialog panel, then do {{KeyCombo|shift=*|ctrl=*|G}} again.&lt;br /&gt;
#* Note: when you&#039;re done testing you can select &amp;quot;Agni&amp;quot; from the grid list to return to Second Life, and again hit {{KeyCombo|shift=*|ctrl=*|G}} to hide the grid select box&lt;br /&gt;
# Teleport to Scheduler Test 2 or Scheduler Test 3 (teen scripters: Scheduler Test TG)&lt;br /&gt;
# You should compare performance between Agni and these test regions. Please let us know if there are significant differences.&lt;br /&gt;
# We want to minimize the amount of content that will break with this new scheduler. Please let us know if you have a script which runs on the main grid but fails (out of memory) on the test regions&lt;br /&gt;
# Add all your feedback to {{Jira|SVC-3997}}.&lt;br /&gt;
# The Scheduler test regions should remain up through the first week of April&lt;br /&gt;
&lt;br /&gt;
== Notes ==&lt;br /&gt;
* A further complication has arisen with script memory. Early builds of the 1.26 server were deployed to large swaths of Aditi for normal beta testing. Residents discovered many scripts which no longer had enough memory to run. These scripts ran fine on Agni (1.25) but broke on Aditi (1.26). This resulted because the 1.26 server was originally built with 64 bit Etch, our first simulator release in 64 bit. The larger word size for references bloated script memory usage, and caused these failures. We have since reverted back to 32 bit builds while we assess the issue. Both the current 1.26 test server, deployed to most of Aditi, and the Scheduler Test sandboxes on select regions now use 32 bit etch.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Preview_Grid&amp;diff=311122</id>
		<title>Preview Grid</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Preview_Grid&amp;diff=311122"/>
		<updated>2009-04-09T20:43:07Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* What is on the Preview Grid */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help|Viewer=*|Misc=*}}&lt;br /&gt;
=Aditi, the Preview Grid=&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In addition to Second Life, the main service that many thousands of residents log into each day, there is a second [[Land#Grid|grid]] open to the public. This grid is known as the Preview Grid, or &amp;quot;Aditi&amp;quot; (in comparison with &amp;quot;[[Land#Agni|Agni]]&amp;quot;, the name we give the production Second Life environment). Aditi is where we test server software that is under development, or that will be coming to Second Life soon. After being dedicated to pre-release testing of the Havok4 physics code for many months, we are again beginning to use it for true server beta tests. It will give all of you a chance to test at the server software we&#039;re planning to deploy to Agni in the near future.&lt;br /&gt;
&lt;br /&gt;
==What We Do with the Preview Grid==&lt;br /&gt;
&lt;br /&gt;
The Preview Grid is used for a number of different things. This means that there, much more frequently than in Second Life, you will find that as you move from one region to another, you will be moving to regions that are running a different version of the server software. To get the most of the Preview Grid, you need to know where you are.&lt;br /&gt;
&lt;br /&gt;
===How do I know what version is running on the region I&#039;m in?===&lt;br /&gt;
&lt;br /&gt;
Some regions have a &amp;quot;channel name&amp;quot; imprinted into the ground over and over again. If the ground texture doesn&#039;t make it obvious, look at &amp;quot;About Second Life&amp;quot; in the help menu. There, you will see a wealth of information about your own system, as well as about the server software that the region you are in is running. The image below shows you where in the help dialog to find the channel the region you&#039;re in is running. (Just to the right of that is the version.)&lt;br /&gt;
&lt;br /&gt;
[[Image:Helpversion.jpg]]&lt;br /&gt;
&lt;br /&gt;
The most important information in the image here is &amp;quot;Second Life Server&amp;quot;; that&#039;s the channel that you&#039;re on. The version number is also important, but the biggest changes you will see are between different channels.&lt;br /&gt;
&lt;br /&gt;
==Reporting Bugs or Problems==&lt;br /&gt;
&lt;br /&gt;
This will vary depending on the channel of the region, and on the state of the release. If you find problems in the &amp;quot;Second Life Beta Server&amp;quot; channel before that version has been deployed to the main Second Life service, please use our Issue Tracker to check to see if that problem has already been reported, and to report it if not. When reporting a problem, please give as much information as possible: what region you were in, exactly what you did and what behavior you saw, when it happened, and the version of both your viewer software and of the server software running in the region where you saw the problem.&lt;br /&gt;
&lt;br /&gt;
In general, you will use the same procedure for problems found on regions in other channels, but sometimes those channels are being used for a focused test by other developers.&lt;br /&gt;
&lt;br /&gt;
==What is on the Preview Grid==&lt;br /&gt;
&lt;br /&gt;
We will be using Aditi for beta testing of the next server version, but we will also be using it for early previews of software that isn&#039;t going to be on Second Life right away, and for some specific public testing of bug-fixes being worked on by some teams of developers.&lt;br /&gt;
&lt;br /&gt;
The regions on Aditi are divided into different channels. There will always be two core channels:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Second Life Production Server&#039;&#039;&#039; : this has the same version of the software as is running on the main Second Life hosts. This exists for purposes of comparison. Sometimes, it will have the *previous* release, right after a new server has been deployed to Second Life.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Second Life Beta Server&#039;&#039;&#039; : this channel is designated for the version of the server we&#039;re planning on next deploying to Second Life in a rolling restart. Generally, after a new server version is deployed to Second Life, it will be at least a few days before the next beta version goes out to Aditi.&lt;br /&gt;
&lt;br /&gt;
In addition, there will sometimes be other channels for specific tests and/or early betas of upcoming features.  Right now, there is:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Http In&#039;&#039;&#039; : Early beta testing of the HTTP-In feature. [[LSL_http_server/beta | Info here]].&lt;br /&gt;
* &#039;&#039;&#039;Mono Scheduler&#039;&#039;&#039; : Scripters can check performance with new scheduler. [[Mono_Scheduler_testing | Info here]].&lt;br /&gt;
&lt;br /&gt;
==How do I log in to Aditi?==&lt;br /&gt;
&lt;br /&gt;
You can use the same Second Life viewer you already use to log into Second Life! At the login screen, hit {{KeyCombo|ctrl=*|shift=*|G}}. At the bottom of the screen to the right of the &amp;quot;Quit&amp;quot; button, you will see a dropdown widget that allows you to select the grid that you want to log in to:&lt;br /&gt;
*[[Image:Whichgrid.jpg]]&lt;br /&gt;
*Select &amp;quot;Agni&amp;quot; to log into Second Life. Select &amp;quot;Aditi&amp;quot; to log into the Preview Grid. (A number of other grids are listed in this dropdown. These are internal development grids which are not available for public access.)&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Snapshot Date:&#039;&#039;&#039; Aditi uses a copy of the database from Agni. We refresh this database typically every few months. If your account is very new, you may not be able to log into Aditi. Once you do log into Aditi, you will have all of the inventory that you have at the time when you first log in. However, new items acquired in Second Life will not be available to your account in Aditi. In no event will you be able to transfer money or objects back from the Preview Grid for use in the production Second Life environment.&lt;br /&gt;
&lt;br /&gt;
== Regions on Aditi ==&lt;br /&gt;
&lt;br /&gt;
This is not an exhaustive list, but it does list the regions that are on Aditi and that we expect to stay on Aditi.  Other regions may come and go.  A &amp;quot;&amp;amp;beta;&amp;quot; next to the region name indicates that this region is running in the Second Life Beta Server channel; other regions are in the Second Life Production Server channel.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Aviation&#039;&#039;&#039;&lt;br /&gt;
** Abbotts &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Core Mainland Area (down to the Named Sandboxen)&#039;&#039;&#039;&lt;br /&gt;
** Ahern&lt;br /&gt;
** Bonifacio &amp;amp;beta;&lt;br /&gt;
** Dore&lt;br /&gt;
** Morris &amp;amp;beta;&lt;br /&gt;
** Balance &amp;amp;beta;&lt;br /&gt;
** Bethel &amp;amp;beta;&lt;br /&gt;
** Brilliant&lt;br /&gt;
** Fame&lt;br /&gt;
** Fortuna&lt;br /&gt;
** Kapor &amp;amp;beta;&lt;br /&gt;
** Lusk &amp;amp;beta;&lt;br /&gt;
** Oak Grove &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Mainland Adjacent Regions&#039;&#039;&#039;&lt;br /&gt;
** Blue&lt;br /&gt;
** Mauve&lt;br /&gt;
** Lime &amp;amp;beta;&lt;br /&gt;
** Mocha &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Help Regions&#039;&#039;&#039;&lt;br /&gt;
** Help Island &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;TSL Core&#039;&#039;&#039;&lt;br /&gt;
** TSL Volunteer Island&lt;br /&gt;
** Card &amp;amp;beta;&lt;br /&gt;
** Pullman&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Combat Regions&#039;&#039;&#039;&lt;br /&gt;
** Combat (sandbox) - Red Team&#039;s HQ &amp;amp;beta;&lt;br /&gt;
** Combat (sandbox) Rausch &amp;amp;beta;&lt;br /&gt;
** Combat (sandbox) - Blue Team&#039;s HQ&lt;br /&gt;
** Sandbox - Weapons testing (no damag &amp;amp;beta;&lt;br /&gt;
** TSL Weapons Testing Sandbox &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Vehicle Regions&#039;&#039;&#039;&lt;br /&gt;
** Periwinkle&lt;br /&gt;
** Purple &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;General Sandbox Regions&#039;&#039;&#039;&lt;br /&gt;
** Sandbox Island&lt;br /&gt;
** Sandbox Island Extension &amp;amp;beta;&lt;br /&gt;
** Sandbox Island (TG) &amp;amp;beta;&lt;br /&gt;
** Sandbox Island 2 (TG)&lt;br /&gt;
** Sandbox Island 3 (TG) &amp;amp;beta;&lt;br /&gt;
** Sandbox Island 4 (TG)&lt;br /&gt;
** Sandbox Newcomb &amp;amp;beta;&lt;br /&gt;
** Sandbox Goguen &amp;amp;beta;&lt;br /&gt;
** Sandbox Cordova &amp;amp;beta;&lt;br /&gt;
** Sandbox Wanderton &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Openspace Sims, mainland, contiguous&#039;&#039;&#039;&lt;br /&gt;
** Adriatic &amp;amp;beta;&lt;br /&gt;
** Aegean&lt;br /&gt;
** Arafura&lt;br /&gt;
** Azov&lt;br /&gt;
** Baltic &amp;amp;beta;&lt;br /&gt;
** Banda&lt;br /&gt;
** Beibu &amp;amp;beta;&lt;br /&gt;
** Bering &amp;amp;beta;&lt;br /&gt;
** Bohai&lt;br /&gt;
** Bohol &amp;amp;beta;&lt;br /&gt;
** Bothnia &amp;amp;beta;&lt;br /&gt;
** Carpentaria&lt;br /&gt;
** Celebes &amp;amp;beta;&lt;br /&gt;
** Cortez &amp;amp;beta;&lt;br /&gt;
** Flores&lt;br /&gt;
** Hudson&lt;br /&gt;
** Ionian&lt;br /&gt;
** Ligurian&lt;br /&gt;
** Marmara&lt;br /&gt;
** Mirtoon&lt;br /&gt;
** Okhotsk &amp;amp;beta;&lt;br /&gt;
** Sargasso &amp;amp;beta;&lt;br /&gt;
** Seto &amp;amp;beta;&lt;br /&gt;
** Sidra&lt;br /&gt;
** Sulu &amp;amp;beta;&lt;br /&gt;
** Tasman&lt;br /&gt;
** Tyrrhenian &amp;amp;beta;&lt;br /&gt;
** Baffin (not openspace, in the middle of the rest)&lt;br /&gt;
&lt;br /&gt;
= See Also =&lt;br /&gt;
* [[Preview Grid Common Questions]]&lt;br /&gt;
* [http://blog.secondlife.com/2008/10/23/help-us-beta-test-second-life-server-releases/ Blog Post about Beta Testing]&lt;br /&gt;
** Server Release Beta Testing office hours are Tue @ 2PM (with Prospero Linden) and Thu at 3PM (with Vektor Linden); they are held &#039;&#039;on the preview grid&#039;&#039; at Morris (192, 251, 35).  These are to discuss beta testing of the next upcoming release of Second Life; when there is not a release pending, we will discuss general SVC issues listed in the JIRA.&lt;br /&gt;
* The [http://forums.secondlife.com/forumdisplay.php?f=348 Server Deploy Forums] have forum discussions about rolling restarts, server release beta testing in general, and specific versions of the server that are about to be released.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono_Scheduler_testing&amp;diff=286072</id>
		<title>Mono Scheduler testing</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono_Scheduler_testing&amp;diff=286072"/>
		<updated>2009-03-20T17:33:31Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A [[simulator]] which incorporates a revised [[Mono]] Scheduler was deployed to [[Aditi]], the preview grid, on 19 March 2009. For the next two weeks [[Resident]]s will be able to go to these [[region]]s and test their [[script]]s on this scheduler. Please return any feedback you have to the [[Issue Tracker|JIRA]] listed below. We&#039;ll use that feedback to fine tune the scheduler performance before we merge it into trunk for release with an upcoming server version.&lt;br /&gt;
&lt;br /&gt;
Please provide any feedback as a comment to {{Jira|SVC-3997}}. If you find any outright bugs, please create a separate JIRA and link it to this one.&lt;br /&gt;
&lt;br /&gt;
== The Mono Scheduler ==&lt;br /&gt;
The Scheduler is responsible for managing time and memory resources for all the scripts running in a simulator. As a busy sim might have thousands of active scripts, keeping them all happy and keeping overall simulator performance up is non-trivial. Changes to the scheduler can affect existing scripts: some might run out of memory and break, others might experience performance differences. Because of these possible behavior changes we want to give residents the chance to test their scripts and give us feedback. We can fine tune the Scheduler so that content is minimally affected.&lt;br /&gt;
&lt;br /&gt;
== Motivation for the reworking ==&lt;br /&gt;
The original Mono Scheduler shipped with server 1.24 -- the version that introduced Mono. Its non-deterministic behavior had two deleterious side effects:&lt;br /&gt;
* Some &amp;quot;lucky&amp;quot; scripts were able to acquire more than the 64K memory limit, decreasing available memory for other scripts.&lt;br /&gt;
* Other scripts were able to monopolize time resources, increasing their performance at the expense of other scripts and region performance.&lt;br /&gt;
&lt;br /&gt;
A fix for this was included in an early version of server 1.25, however this fix was reverted because it broke considerable content. Babbage Linden and Studio Blighty then reworked the Mono Scheduler so as to make it deterministic, but also to allow us to tune its performance. We now have a version which passes our benchmarks, and we&#039;d like to share that version with the SL scripting community for feedback.&lt;br /&gt;
&lt;br /&gt;
== Goal for this revision == &lt;br /&gt;
Since simulator resources (cpu, memory) are limited the Scheduler&#039;s job is essentially making tradeoffs. Too tight a control and scripts run out of memory more frequently, and script performance is unacceptable. Too loose control allows scripts to hog cpu and RAM at the expense of the simulator&#039;s other duties (physics, communication) and so region performance becomes unacceptable. &lt;br /&gt;
&lt;br /&gt;
We added some benchmark tests to our internal QA for the scheduler in an attempt to find a sweet spot which delivers optimal script and region performance. The scheduler deployed for testing passes those benchmarks, so now we need resident feedback. &lt;br /&gt;
&lt;br /&gt;
== Who should test ==&lt;br /&gt;
If you&#039;re a scripter who uses Mono for LSL and you write scripts which have either or both:&lt;br /&gt;
* high memory consumption &lt;br /&gt;
* a lot of calculation/processing&lt;br /&gt;
then you should consider testing your scripts in the provided sandbox. Scripts which operate on large lists are particularly prone to be in both of those categories and should be tested. &lt;br /&gt;
&lt;br /&gt;
== How to test == &lt;br /&gt;
# Use any recent Viewer to go to aditi, the preview grid.&lt;br /&gt;
#* from the login screen hit shift-ctrl-g to bring up the grid dropdown menu&lt;br /&gt;
#* select &amp;quot;aditi&amp;quot; from the menu&lt;br /&gt;
#* Note: if shift-ctrl-g doesn&#039;t work, try clicking on the Name or Password boxes to move focus to the dialog panel, then do shift-ctrl-g again.&lt;br /&gt;
#* Note: when you&#039;re done testing you can select &amp;quot;agni&amp;quot; from the grid list to return to Second Life, and again hit shift-ctrl-g to hide the grid select box&lt;br /&gt;
# Teleport to Scheduler Test 2 or Scheduler Test 3 (teen scripters: Scheduler Test TG)&lt;br /&gt;
# You should compare performance between agni and these test regions. Please let us know if there are significant differences.&lt;br /&gt;
# We want to minimize the amount of content that will break with this new scheduler. Please let us know if you have a script which runs on the main grid but fails (out of memory) on the test regions&lt;br /&gt;
# Add all your feedback to SVC-3997 (https://jira.secondlife.com/browse/SVC-3997).&lt;br /&gt;
# The Scheduler test regions should remain up through the first week of April&lt;br /&gt;
&lt;br /&gt;
== Notes ==&lt;br /&gt;
* A further complication has arisen with script memory. Early builds of the 1.26 server were deployed to large swaths of aditi for normal beta testing. Residents discovered many scripts which no longer had enough memory to run. These scripts ran fine on agni (1.25) but broke on aditi (1.26). This resulted because the 1.26 server was originally built with 64 bit Etch, our first simulator release in 64 bit. The larger word size for references bloated script memory usage, and caused these failures. We have since reverted back to 32 bit builds while we assess the issue. Both the current 1.26 test server, deployed to most of aditi, and the Scheduler Test sandboxes on select regions now use 32 bit etch.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono_Scheduler_testing&amp;diff=285972</id>
		<title>Mono Scheduler testing</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono_Scheduler_testing&amp;diff=285972"/>
		<updated>2009-03-20T16:20:17Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: New page: A simulator which incorporates a revised Mono Scheduler was deployed to aditi, the preview grid, on 19 March 2009. For the next two weeks residents will be able to go to these regions and ...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;A simulator which incorporates a revised Mono Scheduler was deployed to aditi, the preview grid, on 19 March 2009. For the next two weeks residents will be able to go to these regions and test their scripts on this scheduler. Please return any feedback you have to the JIRA listed below. We&#039;ll use that feedback to fine tune the scheduler performance before we merge it into trunk for release with an upcoming server version.&lt;br /&gt;
&lt;br /&gt;
== The Mono Scheduler ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Motivation for the reworking ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Goal for this revision == &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Who should test ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== How to test == &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Notes ==&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=226923</id>
		<title>LSL HTTP server/beta</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=226923"/>
		<updated>2009-02-06T19:42:53Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[Update, 6 Feb 09] We still haven&#039;t acquired the merge lock, but Kelly did a new branch off of trunk anyway and Prospero has graciously redeployed http-in to select aditi regions. The http-in sandboxes mentioned below are back online.&lt;br /&gt;
&lt;br /&gt;
[Update, 23 Jan 09] I&#039;d like to thank everyone who participated in this beta. Thanks to your help with testing all the edges and corners of the http-in functionality we passed QA&#039;s integration testing. Http-in is now awaiting the lock to merge into trunk, hopefully for the 1.26 server version. The http-in beta sandbox regions are likely to go down for several days until we actually acquire the lock. At that time we&#039;ll redeploy the merged version for final testing.&lt;br /&gt;
&lt;br /&gt;
;  Where?&lt;br /&gt;
:Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; where n is 1,2, or 3.&lt;br /&gt;
;  What viewer should I use?&lt;br /&gt;
: Use a mono-compatible main grid viewer (version 1.21 or later), and have it log you into aditi. Shift-control-g at the login screen brings up the grid select dropdown. Aditi = preview grid, Agni = main grid.&lt;br /&gt;
; But the viewer won&#039;t know about the new functions&lt;br /&gt;
: When using a Mono-enabled viewer, all compilation is done server side. So make sure you are using a mono-enabled viewer and you will be able to compile a script with the new functions as long as you are in one of the http-in sandboxes. You do not need to have &amp;quot;Mono&amp;quot; checked (see [http://forums.secondlife.com/showthread.php?t=287764 this forum thread]).&lt;br /&gt;
; How do I report bugs?&lt;br /&gt;
: Check this meta JIRA - {{Jira|SVC-3238}}. Existing issues for http-in are linked. Check the open issues to see if your bug is already listed. If so, consider commenting on that issue to add any insights you have. If not, create a new issue. Make sure you:&lt;br /&gt;
* JIRA should be SVC&lt;br /&gt;
* Title should start &amp;quot;http-in:&amp;quot;&lt;br /&gt;
* Component &amp;quot;Scripts&amp;quot;&lt;br /&gt;
* Affects version is unimportant&lt;br /&gt;
* Please include a minimal repro of the bug. Pare down the code to the minimum necessary to exhibit the issue.&lt;br /&gt;
* Link your issue &amp;quot;Relates to&amp;quot; SVC-3238&lt;br /&gt;
; What if I have questions?&lt;br /&gt;
: Several resources are available&lt;br /&gt;
* Use the discussion tab for this page to ask questions about the beta&lt;br /&gt;
* If you are a member of secondlifescripters@lists.secondlife.com you can post a question.&lt;br /&gt;
* Or try asking on the second life lsl forum. &lt;br /&gt;
* I (Periapse Linden) hold an office hour on Fridays at 3pm. Location is Beaumont, eastern edge, under the hill with the observatory dome.&lt;br /&gt;
; What about Teen Grid residents?&lt;br /&gt;
: Teen grid residents are welcome to participate in this beta. Log in to aditi with the appropriate viewer (see above). Teleport to &amp;quot;Http In Sandbox Teen&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Resources ==&lt;br /&gt;
* New functions and their arguments: [[LSL http server]]&lt;br /&gt;
* Meta JIRA with all known issues: {{Jira|SVC-3238}}&lt;br /&gt;
* [[LSL_http_server/examples | Code samples]]&lt;br /&gt;
* Design JIRA: {{Jira|SVC-1086}}&lt;br /&gt;
* Design docs: [[LSL_http_server/design]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=226913</id>
		<title>LSL HTTP server/beta</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=226913"/>
		<updated>2009-02-06T19:42:31Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[Update, 6 Feb 09] We still haven&#039;t acquired the merge lock, but Kelly did a new branch off of trunk anyway and Prospero has graciously redeployed http-in to select aditi regions. The http-in sandboxes mentioned below are back online.&lt;br /&gt;
[Update, 23 Jan 09] I&#039;d like to thank everyone who participated in this beta. Thanks to your help with testing all the edges and corners of the http-in functionality we passed QA&#039;s integration testing. Http-in is now awaiting the lock to merge into trunk, hopefully for the 1.26 server version. The http-in beta sandbox regions are likely to go down for several days until we actually acquire the lock. At that time we&#039;ll redeploy the merged version for final testing.&lt;br /&gt;
&lt;br /&gt;
;  Where?&lt;br /&gt;
:Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; where n is 1,2, or 3.&lt;br /&gt;
;  What viewer should I use?&lt;br /&gt;
: Use a mono-compatible main grid viewer (version 1.21 or later), and have it log you into aditi. Shift-control-g at the login screen brings up the grid select dropdown. Aditi = preview grid, Agni = main grid.&lt;br /&gt;
; But the viewer won&#039;t know about the new functions&lt;br /&gt;
: When using a Mono-enabled viewer, all compilation is done server side. So make sure you are using a mono-enabled viewer and you will be able to compile a script with the new functions as long as you are in one of the http-in sandboxes. You do not need to have &amp;quot;Mono&amp;quot; checked (see [http://forums.secondlife.com/showthread.php?t=287764 this forum thread]).&lt;br /&gt;
; How do I report bugs?&lt;br /&gt;
: Check this meta JIRA - {{Jira|SVC-3238}}. Existing issues for http-in are linked. Check the open issues to see if your bug is already listed. If so, consider commenting on that issue to add any insights you have. If not, create a new issue. Make sure you:&lt;br /&gt;
* JIRA should be SVC&lt;br /&gt;
* Title should start &amp;quot;http-in:&amp;quot;&lt;br /&gt;
* Component &amp;quot;Scripts&amp;quot;&lt;br /&gt;
* Affects version is unimportant&lt;br /&gt;
* Please include a minimal repro of the bug. Pare down the code to the minimum necessary to exhibit the issue.&lt;br /&gt;
* Link your issue &amp;quot;Relates to&amp;quot; SVC-3238&lt;br /&gt;
; What if I have questions?&lt;br /&gt;
: Several resources are available&lt;br /&gt;
* Use the discussion tab for this page to ask questions about the beta&lt;br /&gt;
* If you are a member of secondlifescripters@lists.secondlife.com you can post a question.&lt;br /&gt;
* Or try asking on the second life lsl forum. &lt;br /&gt;
* I (Periapse Linden) hold an office hour on Fridays at 3pm. Location is Beaumont, eastern edge, under the hill with the observatory dome.&lt;br /&gt;
; What about Teen Grid residents?&lt;br /&gt;
: Teen grid residents are welcome to participate in this beta. Log in to aditi with the appropriate viewer (see above). Teleport to &amp;quot;Http In Sandbox Teen&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Resources ==&lt;br /&gt;
* New functions and their arguments: [[LSL http server]]&lt;br /&gt;
* Meta JIRA with all known issues: {{Jira|SVC-3238}}&lt;br /&gt;
* [[LSL_http_server/examples | Code samples]]&lt;br /&gt;
* Design JIRA: {{Jira|SVC-1086}}&lt;br /&gt;
* Design docs: [[LSL_http_server/design]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=206963</id>
		<title>LSL HTTP server/beta</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=206963"/>
		<updated>2009-01-23T16:46:06Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[Update, 23 Jan 09] I&#039;d like to thank everyone who participated in this beta. Thanks to your help with testing all the edges and corners of the http-in functionality we passed QA&#039;s integration testing. Http-in is now awaiting the lock to merge into trunk, hopefully for the 1.26 server version. The http-in beta sandbox regions are likely to go down for several days until we actually acquire the lock. At that time we&#039;ll redeploy the merged version for final testing.&lt;br /&gt;
&lt;br /&gt;
;  Where?&lt;br /&gt;
:Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; where n is 1,2, or 3.&lt;br /&gt;
;  What viewer should I use?&lt;br /&gt;
: Use a mono-compatible main grid viewer (version 1.21 or later), and have it log you into aditi. Shift-control-g at the login screen brings up the grid select dropdown. Aditi = preview grid, Agni = main grid.&lt;br /&gt;
; But the viewer won&#039;t know about the new functions&lt;br /&gt;
: When using a Mono-enabled viewer, all compilation is done server side. So make sure you are using a mono-enabled viewer and you will be able to compile a script with the new functions as long as you are in one of the http-in sandboxes. You do not need to have &amp;quot;Mono&amp;quot; checked (see [http://forums.secondlife.com/showthread.php?t=287764 this forum thread]).&lt;br /&gt;
; How do I report bugs?&lt;br /&gt;
: Check this meta JIRA - {{Jira|SVC-3238}}. Existing issues for http-in are linked. Check the open issues to see if your bug is already listed. If so, consider commenting on that issue to add any insights you have. If not, create a new issue. Make sure you:&lt;br /&gt;
* JIRA should be SVC&lt;br /&gt;
* Title should start &amp;quot;http-in:&amp;quot;&lt;br /&gt;
* Component &amp;quot;Scripts&amp;quot;&lt;br /&gt;
* Affects version is unimportant&lt;br /&gt;
* Please include a minimal repro of the bug. Pare down the code to the minimum necessary to exhibit the issue.&lt;br /&gt;
* Link your issue &amp;quot;Relates to&amp;quot; SVC-3238&lt;br /&gt;
; What if I have questions?&lt;br /&gt;
: Several resources are available&lt;br /&gt;
* Use the discussion tab for this page to ask questions about the beta&lt;br /&gt;
* If you are a member of secondlifescripters@lists.secondlife.com you can post a question.&lt;br /&gt;
* Or try asking on the second life lsl forum. &lt;br /&gt;
* I (Periapse Linden) hold an office hour on Fridays at 3pm. Location is Beaumont, eastern edge, under the hill with the observatory dome.&lt;br /&gt;
; What about Teen Grid residents?&lt;br /&gt;
: Teen grid residents are welcome to participate in this beta. Log in to aditi with the appropriate viewer (see above). Teleport to &amp;quot;Http In Sandbox Teen&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Resources ==&lt;br /&gt;
* New functions and their arguments: [[LSL http server]]&lt;br /&gt;
* Meta JIRA with all known issues: {{Jira|SVC-3238}}&lt;br /&gt;
* [[LSL_http_server/examples | Code samples]]&lt;br /&gt;
* Design JIRA: {{Jira|SVC-1086}}&lt;br /&gt;
* Design docs: [[LSL_http_server/design]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LlGiveInventoryList&amp;diff=188853</id>
		<title>LlGiveInventoryList</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LlGiveInventoryList&amp;diff=188853"/>
		<updated>2008-12-30T17:16:58Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{LSL_Function/inventory|inventory|uuid=false|insert=list of items}}{{LSL_Function&lt;br /&gt;
|func_id=231|func_sleep=3.0|func_energy=10.0&lt;br /&gt;
|func=llGiveInventoryList&lt;br /&gt;
|p1_type=key|p1_name=avatar&lt;br /&gt;
|p2_type=string|p2_name=folder&lt;br /&gt;
|p3_type=list|p3_name=inventory&lt;br /&gt;
|func_footnote&lt;br /&gt;
|return_text&lt;br /&gt;
|func_desc=Gives &#039;&#039;&#039;inventory&#039;&#039;&#039; items to &#039;&#039;&#039;avatar&#039;&#039;&#039; in a &#039;&#039;&#039;folder&#039;&#039;&#039;&lt;br /&gt;
|spec&lt;br /&gt;
|caveats=* &#039;&#039;&#039;Avatar&#039;&#039;&#039; must be, or have recently been, within the same Region as sending object.&lt;br /&gt;
** See, and/or vote for https://jira.secondlife.com/browse/SVC-868 requesting gridwide functionality&lt;br /&gt;
*Does not create a folder when &#039;&#039;&#039;avatar&#039;&#039;&#039; is a prim [[UUID]].&lt;br /&gt;
**The prim must be in the same region.&lt;br /&gt;
|examples=&amp;lt;lsl&amp;gt;// When any user clicks this object, this script will give a folder containing everything in the objects inventory&lt;br /&gt;
// This could be used to give away multiple freebies at once.&lt;br /&gt;
&lt;br /&gt;
default&lt;br /&gt;
{&lt;br /&gt;
    touch_start(integer total_number)&lt;br /&gt;
    {&lt;br /&gt;
        list        inventory;&lt;br /&gt;
        integer     num = llGetInventoryNumber(INVENTORY_ALL);&lt;br /&gt;
        string      script = llGetScriptName();&lt;br /&gt;
        integer     i = 0;&lt;br /&gt;
 &lt;br /&gt;
        for (; i &amp;lt; num; ++i) {&lt;br /&gt;
            string name = llGetInventoryName(INVENTORY_ALL, i);&lt;br /&gt;
            //Don&#039;t give them the selling script.&lt;br /&gt;
            if(name != script)&lt;br /&gt;
            {&lt;br /&gt;
                if(llGetInventoryPermMask(name, MASK_OWNER) &amp;amp; PERM_COPY)&lt;br /&gt;
                {&lt;br /&gt;
                    inventory += name;&lt;br /&gt;
                }&lt;br /&gt;
                else&lt;br /&gt;
                {&lt;br /&gt;
                    llSay(0, &amp;quot;Don&#039;t have permissions to give you \&amp;quot;&amp;quot;+name+&amp;quot;\&amp;quot;.&amp;quot;);&lt;br /&gt;
                }&lt;br /&gt;
            }&lt;br /&gt;
        }&lt;br /&gt;
 &lt;br /&gt;
        if (llGetListLength(inventory) &amp;lt; 1)&lt;br /&gt;
        {&lt;br /&gt;
            llSay(0, &amp;quot;No items to offer.&amp;quot;); &lt;br /&gt;
        }&lt;br /&gt;
        else&lt;br /&gt;
        {&lt;br /&gt;
            // give folder to agent, use name of object as name of folder we are giving&lt;br /&gt;
            llGiveInventoryList(llDetectedKey(0), llGetObjectName(), inventory);&lt;br /&gt;
        }&lt;br /&gt;
    }&lt;br /&gt;
}&amp;lt;/lsl&amp;gt;&lt;br /&gt;
|helpers&lt;br /&gt;
|also_functions=*{{LSLG|llGiveInventory}}&lt;br /&gt;
|also_events=*{{LSLG|changed}}&lt;br /&gt;
|also_tests&lt;br /&gt;
|also_articles&lt;br /&gt;
|notes|cat1=Inventory&lt;br /&gt;
|cat2&lt;br /&gt;
|cat3&lt;br /&gt;
|cat4&lt;br /&gt;
}}&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Preview_Grid&amp;diff=146873</id>
		<title>Preview Grid</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Preview_Grid&amp;diff=146873"/>
		<updated>2008-11-18T22:56:17Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* What is on the Preview Grid */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Aditi, the Preview Grid=&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In addition to Second Life, the main service that many thousands of residents log into each day, there is a second grid open to the public. This grid is known as the Preview Grid, or &amp;quot;Aditi&amp;quot; (in comparison with &amp;quot;Agni&amp;quot;, the name we give the production Second Life environment). Aditi is where we test server software that is under development, or that will be coming to Second Life soon. After being dedicated to pre-release testing of the Havok4 physics code for many months, we are again beginning to use it for true server beta tests. It will give all of you a chance to test at the server software we&#039;re planning to deploy to Agni in the near future.&lt;br /&gt;
&lt;br /&gt;
==What We Do with the Preview Grid==&lt;br /&gt;
&lt;br /&gt;
The Preview Grid is used for a number of different things. This means that there, much more frequently than in Second Life, you will find that as you move from one region to another, you will be moving to regions that are running a different version of the server software. To get the most of the Preview Grid, you need to know where you are.&lt;br /&gt;
&lt;br /&gt;
===How do I know what version is running on the region I&#039;m in?===&lt;br /&gt;
&lt;br /&gt;
Some regions have a &amp;quot;channel name&amp;quot; imprinted into the ground over and over again. If the ground texture doesn&#039;t make it obvious, look at &amp;quot;About Second Life&amp;quot; in the help menu. There, you will see a wealth of information about your own system, as well as about the server software that the region you are in is running. The image below shows you where in the help dialog to find the channel the region you&#039;re in is running. (Just to the right of that is the version.)&lt;br /&gt;
&lt;br /&gt;
[[Image:Helpversion.jpg]]&lt;br /&gt;
&lt;br /&gt;
The most important information in the image here is &amp;quot;Second Life Server&amp;quot;; that&#039;s the channel that you&#039;re on. The version number is also important, but the biggest changes you will see are between different channels.&lt;br /&gt;
&lt;br /&gt;
==Reporting Bugs or Problems==&lt;br /&gt;
&lt;br /&gt;
This will vary depending on the channel of the region, and on the state of the release. If you find problems in the &amp;quot;Second Life Beta Server&amp;quot; channel before that version has been deployed to the main Second Life service, please use our Issue Tracker to check to see if that problem has already been reported, and to report it if not. When reporting a problem, please give as much information as possible: what region you were in, exactly what you did and what behavior you saw, when it happened, and the version of both your viewer software and of the server software running in the region where you saw the problem.&lt;br /&gt;
&lt;br /&gt;
In general, you will use the same procedure for problems found on regions in other channels, but sometimes those channels are being used for a focused test by other developers.&lt;br /&gt;
&lt;br /&gt;
==What is on the Preview Grid==&lt;br /&gt;
&lt;br /&gt;
We will be using Aditi for beta testing of the next server version, but we will also be using it for early previews of software that isn&#039;t going to be on Second Life right away, and for some specific public testing of bug-fixes being worked on by some teams of developers.&lt;br /&gt;
&lt;br /&gt;
The regions on Aditi are divided into different channels. There will always be two core channels:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Second Life Production Server&#039;&#039;&#039; : this has the same version of the software as is running on the main Second Life hosts. This exists for purposes of comparison. Sometimes, it will have the *previous* release, right after a new server has been deployed to Second Life.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Second Life Beta Server&#039;&#039;&#039; : this channel is designated for the version of the server we&#039;re planning on next deploying to Second Life in a rolling restart. Generally, after a new server version is deployed to Second Life, it will be at least a few days before the next beta version goes out to Aditi.&lt;br /&gt;
&lt;br /&gt;
In addition, there will sometimes be other channels for specific tests and/or early betas of upcoming features.  Right now, there is:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Http In&#039;&#039;&#039; : Early beta testing of the HTTP-In feature. [[LSL_http_server/beta | Info here]].&lt;br /&gt;
&lt;br /&gt;
==How do I log in to Aditi?==&lt;br /&gt;
&lt;br /&gt;
You usually have two options for viewers:&lt;br /&gt;
* You can use the same Second Life viewer you already use to log into Second Life! At the login screen, hit CTRL-SHIFT-G. At the bottom of the screen to the right of the &amp;quot;Quit&amp;quot; button, you will see a dropdown widget that allows you to select the grid that you want to log in to:&lt;br /&gt;
**[[Image:Whichgrid.jpg]]&lt;br /&gt;
**Select &amp;quot;Agni&amp;quot; to log into Second Life. Select &amp;quot;Aditi&amp;quot; to log into the Preview Grid. (A number of other grids are listed in this dropdown. These are internal development grids which are not available for public access.)&lt;br /&gt;
&lt;br /&gt;
* When using the main viewer be aware, however, that with the standard Second Life Viewer, you will not be able to compile scripts in the Mono region. If you want to test your scripts under Mono, you will need to download a special viewer for the Preview Grid. You can find this special version under the heading &amp;quot;Preview Grid Viewers&amp;quot; on the &amp;quot;Test Viewers&amp;quot; section of our [http://secondlife.com/downloads downloads page].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Snapshot Date:&#039;&#039;&#039; Aditi uses a copy of the database from Agni. We refresh this database typically every few months. If your account is very new, you may not be able to log into Aditi. Once you do log into Aditi, you will have all of the inventory that you have at the time when you first log in. However, new items acquired in Second Life will not be available to your account in Aditi. In no event will you be able to transfer money or objects back from the Preview Grid for use in the production Second Life environment.&lt;br /&gt;
&lt;br /&gt;
== Regions on Aditi ==&lt;br /&gt;
&lt;br /&gt;
This is not an exhaustive list, but it does list the regions that are on Aditi and that we expect to stay on Aditi.  Other regions may come and go.  A &amp;quot;&amp;amp;beta;&amp;quot; next to the region name indicates that this region is running in the Second Life Beta Server channel; other regions are in the Second Life Production Server channel.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Aviation&#039;&#039;&#039;&lt;br /&gt;
** Abbotts &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Core Mainland Area (down to the Named Sandboxen)&#039;&#039;&#039;&lt;br /&gt;
** Ahern&lt;br /&gt;
** Bonifacio &amp;amp;beta;&lt;br /&gt;
** Dore&lt;br /&gt;
** Morris &amp;amp;beta;&lt;br /&gt;
** Balance &amp;amp;beta;&lt;br /&gt;
** Bethel &amp;amp;beta;&lt;br /&gt;
** Brilliant&lt;br /&gt;
** Fame&lt;br /&gt;
** Fortuna&lt;br /&gt;
** Kapor &amp;amp;beta;&lt;br /&gt;
** Lusk &amp;amp;beta;&lt;br /&gt;
** Oak Grove &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Mainland Adjacent Regions&#039;&#039;&#039;&lt;br /&gt;
** Blue&lt;br /&gt;
** Mauve&lt;br /&gt;
** Lime &amp;amp;beta;&lt;br /&gt;
** Mocha &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Help Regions&#039;&#039;&#039;&lt;br /&gt;
** Help Island &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;TSL Core&#039;&#039;&#039;&lt;br /&gt;
** TSL Volunteer Island&lt;br /&gt;
** Card &amp;amp;beta;&lt;br /&gt;
** Pullman&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Combat Regions&#039;&#039;&#039;&lt;br /&gt;
** Combat (sandbox) - Red Team&#039;s HQ &amp;amp;beta;&lt;br /&gt;
** Combat (sandbox) Rausch &amp;amp;beta;&lt;br /&gt;
** Combat (sandbox) - Blue Team&#039;s HQ&lt;br /&gt;
** Sandbox - Weapons testing (no damag &amp;amp;beta;&lt;br /&gt;
** TSL Weapons Testing Sandbox &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Vehicle Regions&#039;&#039;&#039;&lt;br /&gt;
** Periwinkle&lt;br /&gt;
** Purple &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;General Sandbox Regions&#039;&#039;&#039;&lt;br /&gt;
** Sandbox Island&lt;br /&gt;
** Sandbox Island Extension &amp;amp;beta;&lt;br /&gt;
** Sandbox Island (TG) &amp;amp;beta;&lt;br /&gt;
** Sandbox Island 2 (TG)&lt;br /&gt;
** Sandbox Island 3 (TG) &amp;amp;beta;&lt;br /&gt;
** Sandbox Island 4 (TG)&lt;br /&gt;
** Sandbox Newcomb &amp;amp;beta;&lt;br /&gt;
** Sandbox Goguen &amp;amp;beta;&lt;br /&gt;
** Sandbox Cordova &amp;amp;beta;&lt;br /&gt;
** Sandbox Wanderton &amp;amp;beta;&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Openspace Sims, mainland, contiguous&#039;&#039;&#039;&lt;br /&gt;
** Adriatic &amp;amp;beta;&lt;br /&gt;
** Aegean&lt;br /&gt;
** Arafura&lt;br /&gt;
** Azov&lt;br /&gt;
** Baltic &amp;amp;beta;&lt;br /&gt;
** Banda&lt;br /&gt;
** Beibu &amp;amp;beta;&lt;br /&gt;
** Bering &amp;amp;beta;&lt;br /&gt;
** Bohai&lt;br /&gt;
** Bohol &amp;amp;beta;&lt;br /&gt;
** Bothnia &amp;amp;beta;&lt;br /&gt;
** Carpentaria&lt;br /&gt;
** Celebes &amp;amp;beta;&lt;br /&gt;
** Cortez &amp;amp;beta;&lt;br /&gt;
** Flores&lt;br /&gt;
** Hudson&lt;br /&gt;
** Ionian&lt;br /&gt;
** Ligurian&lt;br /&gt;
** Marmara&lt;br /&gt;
** Mirtoon&lt;br /&gt;
** Okhotsk &amp;amp;beta;&lt;br /&gt;
** Sargasso &amp;amp;beta;&lt;br /&gt;
** Seto &amp;amp;beta;&lt;br /&gt;
** Sidra&lt;br /&gt;
** Sulu &amp;amp;beta;&lt;br /&gt;
** Tasman&lt;br /&gt;
** Tyrrhenian &amp;amp;beta;&lt;br /&gt;
** Baffin (not openspace, in the middle of the rest)&lt;br /&gt;
&lt;br /&gt;
= See Also =&lt;br /&gt;
* [[Preview Grid Common Questions]]&lt;br /&gt;
* [http://blog.secondlife.com/2008/10/23/help-us-beta-test-second-life-server-releases/ Blog Post about Beta Testing]&lt;br /&gt;
** Server Release Beta Testing office hours are Tue @ 2PM (with Prospero Linden) and Thu at 3PM (with Vektor Linden); they are held &#039;&#039;on the preview grid&#039;&#039; at Morris (192, 251, 35).  These are to discuss beta testing of the next upcoming release of Second Life; when there is not a release pending, we will discuss general SVC issues listed in the JIRA.&lt;br /&gt;
* The [http://forums.secondlife.com/forumdisplay.php?f=348 Server Deploy Forums] have forum discussions about rolling restarts, server release beta testing in general, and specific versions of the server that are about to be released.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=106932</id>
		<title>LSL HTTP server/beta</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=106932"/>
		<updated>2008-10-21T22:06:15Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The new http-in functions described on [[LSL http server]] are available on the preview grid for beta testing. &lt;br /&gt;
&lt;br /&gt;
;  Where?&lt;br /&gt;
:Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; where n is 1,2, or 3.&lt;br /&gt;
;  What viewer should I use?&lt;br /&gt;
: Use a mono-compatible main grid viewer (version 1.21 or later), and have it log you into aditi. Shift-control-g at the login screen brings up the grid select dropdown. Aditi = preview grid, Agni = main grid.&lt;br /&gt;
; But the viewer won&#039;t know about the new functions&lt;br /&gt;
: When using a Mono-enabled viewer, all compilation is done server side. So make sure you are using a mono-enabled viewer and you will be able to compile a script with the new functions as long as you are in one of the http-in sandboxes. You do not need to have &amp;quot;Mono&amp;quot; checked (see [http://forums.secondlife.com/showthread.php?t=287764 this forum thread]).&lt;br /&gt;
; How do I report bugs?&lt;br /&gt;
: Check this meta JIRA - [http://jira.secondlife.com/browse/SVC-3238 SVC-3238]. Existing issues for http-in are linked. Check the open issues to see if your bug is already listed. If so, consider commenting on that issue to add any insights you have. If not, create a new issue. Make sure you:&lt;br /&gt;
* JIRA should be SVC&lt;br /&gt;
* Title should start &amp;quot;http-in:&amp;quot;&lt;br /&gt;
* Component &amp;quot;Scripts&amp;quot;&lt;br /&gt;
* Affects version is unimportant&lt;br /&gt;
* Please include a minimal repro of the bug. Pare down the code to the minimum necessary to exhibit the issue.&lt;br /&gt;
* Link your issue &amp;quot;Relates to&amp;quot; SVC-3238&lt;br /&gt;
; What if I have questions?&lt;br /&gt;
: Several resources are available&lt;br /&gt;
* Use the discussion tab for this page to ask questions about the beta&lt;br /&gt;
* If you are a member of secondlifescripters@lists.secondlife.com you can post a question.&lt;br /&gt;
* Or try asking on the second life lsl forum. &lt;br /&gt;
* I (Periapse Linden) hold an office hour on Fridays at 3pm. Location is Beaumont, eastern edge, under the hill with the observatory dome.&lt;br /&gt;
; What about Teen Grid residents?&lt;br /&gt;
: Teen grid residents are welcome to participate in this beta. Log in to aditi with the appropriate viewer (see above). Teleport to &amp;quot;Http In Sandbox Teen&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Resources ==&lt;br /&gt;
* New functions and their arguments: [[LSL http server]]&lt;br /&gt;
* Meta JIRA with all known issues: [http://jira.secondlife.com/browse/SVC-3238 SVC-3238]&lt;br /&gt;
* [[LSL_http_server/examples | Code samples]]&lt;br /&gt;
* Design JIRA: [https://jira.secondlife.com/browse/SVC-1086 SVC-1086]&lt;br /&gt;
* Design docs: [[LSL_http_server/design]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=106772</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=106772"/>
		<updated>2008-10-21T19:31:24Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Magellan&amp;#039;s flash drive */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* gridded the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship. There&#039;s a picture of his airship inside the Bay City mooring mast.&lt;br /&gt;
* [[Magellan and Gaeta]] Some pictures from Magellan&#039;s voyage of discover to Gaeta.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his primitar suit and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct.&lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;br /&gt;
&lt;br /&gt;
== Rez Zones == &lt;br /&gt;
I’ve established four Rez Zones for boaters around the Nautilus island; they each have a blue mooring bouy in them. One at the eastern end of the canal, one at the smaller island off the south shore, one in the outer harbor area, and one on the northern side, in the “notch” below the citadel wall. I guess the ancient Nautilonians … Nautiloids? … Residents didn’t need Rez Zones. Anyhow, the bouys aren&#039;t particularly ancient! -- Michael Linden&lt;br /&gt;
&lt;br /&gt;
== Mole Tank ==&lt;br /&gt;
One of the LDPW Moles (name withheld) shared the following photos with me. These are two views of the Mole Tank, the special vehicle built for Magellan Linden by the Moles. I include them here to help identify any tracks, tunnels, or wreckage that may be found. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 001.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The above shot shows the Mole Tank stowed on a barge and apparently ready for deploy. Location is unspecified. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 002.jpg | 650px ]]  &lt;br /&gt;
&lt;br /&gt;
This shows an interior view of the Mole Tank as it underwent pre-launch testing.&lt;br /&gt;
&lt;br /&gt;
== Elcano ==&lt;br /&gt;
Magellan has still not surfaced, though evidence of his presence has been discovered in the new Nautilus City. &lt;br /&gt;
&lt;br /&gt;
As alluded to earlier, I was approached by a resident who was manifesting as an obvious alt (account created yesterday). The resident, Elcano Swashbuckler, offered information on the appearance of the new lands below the Nautilean continent and the connection to Magellan Linden. Elcano seemed exceedingly paranoid, and had several requirements for our meeting. Both of us would show up in alts, no Lindens allowed anywhere on the region (so no god powers?), and he said that he would run all his chat messages through a translator twice, so as to hide any telltale phrasing which might give away his identity (?!). Here is our chat log:&lt;br /&gt;
&lt;br /&gt;
You: Nice to meet you, Elcano. You said you have evidence about Magellan&#039;s activities in the new Nautilus island?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Yes, I am in the semi-Magellan. I&#039;ve been there, when the island is called NOCHIRASUSHITI was discovered.&lt;br /&gt;
&lt;br /&gt;
You: Uh, um, did Magellan discover Nautilus City?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Of course, you fool! That&#039;s what I said is. I found it here in the city of the MAZERANNOCHIRASU.&lt;br /&gt;
 &lt;br /&gt;
You: Mazer-what?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I do not know - the only annoying to the translator. I &amp;quot;&amp;quot; meaning the city of Nautilus. Anyway, I have the pictures.&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I believe that these new areas of Magellan Linden discovered the true picture is called NOCHIRASUSHITI prove.&lt;br /&gt;
&lt;br /&gt;
You: huh? You have pictures? May I see them?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler:  Sure, I will send them through. Here you go. So I thought, Magellan is in trouble gridding for the lost city?&lt;br /&gt;
&lt;br /&gt;
You: Magellan is in danger?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: No, damn it, it is Magellan will face charges when you find it?&lt;br /&gt;
&lt;br /&gt;
You: Face charges? What for?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: To disable the invisible shield, you jerk! Eighty to cause new areas suddenly appear.&lt;br /&gt;
&lt;br /&gt;
You: Invisible shield...?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Nautilus City on the island, protected by a transparent shield said.  Since ancient times. Magellan&#039;s shield to figure out the secret, these areas now, all that you can take it down, using his legendary skills.&lt;br /&gt;
&lt;br /&gt;
You: Protected? The city was protected by a transpar--- by an invisibility shield? That&#039;s why we thought it was still ungridded Void?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Yes. No one did not have idea, with the exception of the great Magellan. He came to the place where the lost city of three hundred years old maps.&lt;br /&gt;
&lt;br /&gt;
You: Maps.. yeah, I found an old map on Magellan&#039;s desk.&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: You rummaged through Magellan table! You are the evil pig! You steal one of his cigars? If you have you shall have it.&lt;br /&gt;
&lt;br /&gt;
You: Easy, now. I&#039;m just trying to understand what occurred. Do you know the fate of the original inhabitants of Nautilus City?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I have no idea. Maybe they left, perhaps some strange disease, perhaps they are all still there. In any case, whatever happened there happened centuries ago. The crystals kept in place and ready to drive.&lt;br /&gt;
&lt;br /&gt;
I was unable to get further useful information out of Elcano. I present the photos he showed me below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Mag Remote 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
[[Image:Mag Remote 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
[[Image:Mag Remote 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
[[Image:Magellan In Nautilus 001.jpg | 650px]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=106752</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=106752"/>
		<updated>2008-10-21T19:14:07Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Elcano */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* gridded the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship. There&#039;s a picture of his airship inside the Bay City mooring mast.&lt;br /&gt;
* [[Magellan and Gaeta]] Some pictures from Magellan&#039;s voyage of discover to Gaeta.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct.&lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;br /&gt;
&lt;br /&gt;
== Rez Zones == &lt;br /&gt;
I’ve established four Rez Zones for boaters around the Nautilus island; they each have a blue mooring bouy in them. One at the eastern end of the canal, one at the smaller island off the south shore, one in the outer harbor area, and one on the northern side, in the “notch” below the citadel wall. I guess the ancient Nautilonians … Nautiloids? … Residents didn’t need Rez Zones. Anyhow, the bouys aren&#039;t particularly ancient! -- Michael Linden&lt;br /&gt;
&lt;br /&gt;
== Mole Tank ==&lt;br /&gt;
One of the LDPW Moles (name withheld) shared the following photos with me. These are two views of the Mole Tank, the special vehicle built for Magellan Linden by the Moles. I include them here to help identify any tracks, tunnels, or wreckage that may be found. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 001.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The above shot shows the Mole Tank stowed on a barge and apparently ready for deploy. Location is unspecified. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 002.jpg | 650px ]]  &lt;br /&gt;
&lt;br /&gt;
This shows an interior view of the Mole Tank as it underwent pre-launch testing.&lt;br /&gt;
&lt;br /&gt;
== Elcano ==&lt;br /&gt;
Magellan has still not surfaced, though evidence of his presence has been discovered in the new Nautilus City. &lt;br /&gt;
&lt;br /&gt;
As alluded to earlier, I was approached by a resident who was manifesting as an obvious alt (account created yesterday). The resident, Elcano Swashbuckler, offered information on the appearance of the new lands below the Nautilean continent and the connection to Magellan Linden. Elcano seemed exceedingly paranoid, and had several requirements for our meeting. Both of us would show up in alts, no Lindens allowed anywhere on the region (so no god powers?), and he said that he would run all his chat messages through a translator twice, so as to hide any telltale phrasing which might give away his identity (?!). Here is our chat log:&lt;br /&gt;
&lt;br /&gt;
You: Nice to meet you, Elcano. You said you have evidence about Magellan&#039;s activities in the new Nautilus island?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Yes, I am in the semi-Magellan. I&#039;ve been there, when the island is called NOCHIRASUSHITI was discovered.&lt;br /&gt;
&lt;br /&gt;
You: Uh, um, did Magellan discover Nautilus City?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Of course, you fool! That&#039;s what I said is. I found it here in the city of the MAZERANNOCHIRASU.&lt;br /&gt;
 &lt;br /&gt;
You: Mazer-what?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I do not know - the only annoying to the translator. I &amp;quot;&amp;quot; meaning the city of Nautilus. Anyway, I have the pictures.&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I believe that these new areas of Magellan Linden discovered the true picture is called NOCHIRASUSHITI prove.&lt;br /&gt;
&lt;br /&gt;
You: huh? You have pictures? May I see them?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler:  Sure, I will send them through. Here you go. So I thought, Magellan is in trouble gridding for the lost city?&lt;br /&gt;
&lt;br /&gt;
You: Magellan is in danger?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: No, damn it, it is Magellan will face charges when you find it?&lt;br /&gt;
&lt;br /&gt;
You: Face charges? What for?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: To disable the invisible shield, you jerk! Eighty to cause new areas suddenly appear.&lt;br /&gt;
&lt;br /&gt;
You: Invisible shield...?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Nautilus City on the island, protected by a transparent shield said.  Since ancient times. Magellan&#039;s shield to figure out the secret, these areas now, all that you can take it down, using his legendary skills.&lt;br /&gt;
&lt;br /&gt;
You: Protected? The city was protected by a transpar--- by an invisibility shield? That&#039;s why we thought it was still ungridded Void?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Yes. No one did not have idea, with the exception of the great Magellan. He came to the place where the lost city of three hundred years old maps.&lt;br /&gt;
&lt;br /&gt;
You: Maps.. yeah, I found an old map on Magellan&#039;s desk.&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: You rummaged through Magellan table! You are the evil pig! You steal one of his cigars? If you have you shall have it.&lt;br /&gt;
&lt;br /&gt;
You: Easy, now. I&#039;m just trying to understand what occurred. Do you know the fate of the original inhabitants of Nautilus City?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I have no idea. Maybe they left, perhaps some strange disease, perhaps they are all still there. In any case, whatever happened there happened centuries ago. The crystals kept in place and ready to drive.&lt;br /&gt;
&lt;br /&gt;
I was unable to get further useful information out of Elcano. I present the photos he showed me below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Mag Remote 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
[[Image:Mag Remote 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
[[Image:Mag Remote 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
[[Image:Magellan In Nautilus 001.jpg | 650px]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Magellan_In_Nautilus_001.jpg&amp;diff=106742</id>
		<title>File:Magellan In Nautilus 001.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Magellan_In_Nautilus_001.jpg&amp;diff=106742"/>
		<updated>2008-10-21T19:13:30Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Mag_Remote_3.jpg&amp;diff=106732</id>
		<title>File:Mag Remote 3.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Mag_Remote_3.jpg&amp;diff=106732"/>
		<updated>2008-10-21T19:12:41Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Mag_Remote_2.jpg&amp;diff=106722</id>
		<title>File:Mag Remote 2.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Mag_Remote_2.jpg&amp;diff=106722"/>
		<updated>2008-10-21T19:11:51Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Mag_Remote_1.jpg&amp;diff=106712</id>
		<title>File:Mag Remote 1.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Mag_Remote_1.jpg&amp;diff=106712"/>
		<updated>2008-10-21T19:10:42Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=106662</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=106662"/>
		<updated>2008-10-21T18:30:41Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Mole Tank */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* gridded the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship. There&#039;s a picture of his airship inside the Bay City mooring mast.&lt;br /&gt;
* [[Magellan and Gaeta]] Some pictures from Magellan&#039;s voyage of discover to Gaeta.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct.&lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;br /&gt;
&lt;br /&gt;
== Rez Zones == &lt;br /&gt;
I’ve established four Rez Zones for boaters around the Nautilus island; they each have a blue mooring bouy in them. One at the eastern end of the canal, one at the smaller island off the south shore, one in the outer harbor area, and one on the northern side, in the “notch” below the citadel wall. I guess the ancient Nautilonians … Nautiloids? … Residents didn’t need Rez Zones. Anyhow, the bouys aren&#039;t particularly ancient! -- Michael Linden&lt;br /&gt;
&lt;br /&gt;
== Mole Tank ==&lt;br /&gt;
One of the LDPW Moles (name withheld) shared the following photos with me. These are two views of the Mole Tank, the special vehicle built for Magellan Linden by the Moles. I include them here to help identify any tracks, tunnels, or wreckage that may be found. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 001.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The above shot shows the Mole Tank stowed on a barge and apparently ready for deploy. Location is unspecified. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 002.jpg | 650px ]]  &lt;br /&gt;
&lt;br /&gt;
This shows an interior view of the Mole Tank as it underwent pre-launch testing.&lt;br /&gt;
&lt;br /&gt;
== Elcano ==&lt;br /&gt;
Magellan has still not surfaced, though evidence of his presence has been discovered in the new Nautilus City. &lt;br /&gt;
&lt;br /&gt;
As alluded to earlier, I was approached by a resident who was manifesting as an obvious alt (account created yesterday). The resident, Elcano Swashbuckler, offered information on the appearance of the new lands below the Nautilean continent and the connection to Magellan Linden. Elcano seemed exceedingly paranoid, and had several requirements for our meeting. Both of us would show up in alts, no Lindens allowed anywhere on the region (so no god powers?), and he said that he would run all his chat messages through a translator twice, so as to hide any telltale phrasing which might give away his identity (?!). Here is our chat log:&lt;br /&gt;
&lt;br /&gt;
You: Nice to meet you, Elcano. You said you have evidence about Magellan&#039;s activities in the new Nautilus island?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Yes, I am in the semi-Magellan. I&#039;ve been there, when the island is called NOCHIRASUSHITI was discovered.&lt;br /&gt;
&lt;br /&gt;
You: Uh, um, did Magellan discover Nautilus City?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Of course, you fool! That&#039;s what I said is. I found it here in the city of the MAZERANNOCHIRASU.&lt;br /&gt;
 &lt;br /&gt;
You: Mazer-what?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I do not know - the only annoying to the translator. I &amp;quot;&amp;quot; meaning the city of Nautilus. Anyway, I have the pictures.&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: I believe that these new areas of Magellan Linden discovered the true picture is called NOCHIRASUSHITI prove.&lt;br /&gt;
&lt;br /&gt;
You: huh? You have pictures? May I see them?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler:  Sure, I will send them through. Here you go. So I thought, Magellan is in trouble gridding for the lost city?&lt;br /&gt;
&lt;br /&gt;
You: Magellan is in danger?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: No, damn it, it is Magellan will face charges when you find it?&lt;br /&gt;
&lt;br /&gt;
You: Face charges? What for?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: To disable the invisible shield, you jerk! Eighty to cause new areas suddenly appear.&lt;br /&gt;
&lt;br /&gt;
You: Invisible shield...?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Nautilus City on the island, protected by a transparent shield said.  Since ancient times. Magellan&#039;s shield to figure out the secret, these areas now, all that you can take it down, using his legendary skills.&lt;br /&gt;
&lt;br /&gt;
You: Protected? The city was protected by a transpar--- by an invisibility shield? That&#039;s why we thought it was still ungridded Void?&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: Yes. No one did not have idea, with the exception of the great Magellan. He came to the place where the lost city of three hundred years old maps.&lt;br /&gt;
&lt;br /&gt;
You: Maps.. yeah, I found an old map on Magellan&#039;s desk.&lt;br /&gt;
&lt;br /&gt;
Elcano Swashbuckler: You rummaged through Magellan table! You are the evil pig! You steal one of his cigars? If you have you shall have it.&lt;br /&gt;
&lt;br /&gt;
You: Easy, now. I&#039;m just trying to understand what occurred. Do you know the fate of the original inhabitants of Nautilus City?&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105973</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105973"/>
		<updated>2008-10-20T22:27:38Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Rez Zones */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* gridded the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship. There&#039;s a picture of his airship inside the Bay City mooring mast.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct.&lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;br /&gt;
&lt;br /&gt;
== Rez Zones == &lt;br /&gt;
I’ve established four Rez Zones for boaters around the Nautilus island; they each have a blue mooring bouy in them. One at the eastern end of the canal, one at the smaller island off the south shore, one in the outer harbor area, and one on the northern side, in the “notch” below the citadel wall. I guess the ancient Nautilonians … Nautiloids? … Residents didn’t need Rez Zones. Anyhow, the bouys aren&#039;t particularly ancient! -- Michael Linden&lt;br /&gt;
&lt;br /&gt;
== Mole Tank ==&lt;br /&gt;
One of the LDPW Moles (name withheld) shared the following photos with me. These are two views of the Mole Tank, the special vehicle built for Magellan Linden by the Moles. I include them here to help identify any tracks, tunnels, or wreckage that may be found. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 001.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The above shot shows the Mole Tank stowed on a barge and apparently ready for deploy. Location is unspecified. &lt;br /&gt;
&lt;br /&gt;
[[Image:Borer Preparations 002.jpg | 650px ]]  &lt;br /&gt;
&lt;br /&gt;
This shows an interior view of the Mole Tank as it underwent pre-launch testing.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Borer_Preparations_002.jpg&amp;diff=105963</id>
		<title>File:Borer Preparations 002.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Borer_Preparations_002.jpg&amp;diff=105963"/>
		<updated>2008-10-20T22:26:22Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Borer_Preparations_001.jpg&amp;diff=105933</id>
		<title>File:Borer Preparations 001.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Borer_Preparations_001.jpg&amp;diff=105933"/>
		<updated>2008-10-20T22:19:29Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105693</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105693"/>
		<updated>2008-10-20T17:33:24Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* The Nautilus Lacuna */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* gridded the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship. There&#039;s a picture of his airship inside the Bay City mooring mast.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct.&lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;br /&gt;
&lt;br /&gt;
== Rez Zones == &lt;br /&gt;
&lt;br /&gt;
I’ve established four Rez Zones for boaters around the Nautilus island; they each have a blue mooring bouy in them. One at the eastern end of the canal, one at the smaller island off the south shore, one in the outer harbor area, and one on the northern side, in the “notch” below the citadel wall. I guess the ancient Nautilonians … Nautiloids? … Residents didn’t need Rez Zones. Anyhow, the bouys aren&#039;t particularly ancient! -- Michael Linden&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105363</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105363"/>
		<updated>2008-10-20T15:44:51Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Magellan&amp;#039;s flash drive */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* rezzed the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct.&lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105353</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105353"/>
		<updated>2008-10-20T15:43:18Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Magellan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* rezzed the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Jack spoke of Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life. Magellan discovered Nova Albion, Heterocera, Gaeta, and he first explored all the other continents. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta and the crash of his airship.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit at his computer and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct. &lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105343</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105343"/>
		<updated>2008-10-20T15:38:56Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. This island is now called Nautilus City.&lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* rezzed the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life, is he of whom Jack spoke. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit at his computer and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct. &lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105333</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105333"/>
		<updated>2008-10-20T15:36:33Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. &lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* rezzed the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life, is he of whom Jack spoke. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit at his computer and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct. &lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105323</id>
		<title>Nautilus City investigation</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Nautilus_City_investigation&amp;diff=105323"/>
		<updated>2008-10-20T15:35:48Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: New page: Move this page to the public wiki when Nautilus City is opened.  Call the page: &amp;quot;Nautilus City Investigation&amp;quot;  Editors Note:  On Friday, 17 October, at 7 pm SLT, about eighty new regions s...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Move this page to the public wiki when Nautilus City is opened. &lt;br /&gt;
Call the page: &amp;quot;Nautilus City Investigation&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Editors Note: &lt;br /&gt;
On Friday, 17 October, at 7 pm SLT, about eighty new regions suddenly erupted from the Void in the area formerly known as the Nautilus Lacuna. This unplanned manifestation mystified residents of South Nautilus and land management Lindens alike. I was asked to investigate, and this represents my hasty collage of evidence. I will stress that there does not appear to be any danger to either Nautilus residents or the Grid itself. The new lands, though full of wonders and apparently well maintained, are unpopulated. &lt;br /&gt;
&lt;br /&gt;
== The Nautilus Lacuna ==&lt;br /&gt;
Land management Lindens have long acknowledged the odd gap in South Nautilus. The Nautilus and Satori continents link on the west with water regions. For rest of the border, everywhere east of Pan Suong and Giranzo, there was only the Uncrossable. The Void separating the two continents is only two sims thick for most of the length, raising questions as to why the intervening Ocean regions were not rezzed. Jack Linden replied &amp;quot;Well that&#039;s just it -- we believed that we *had* rezzed the open spaces between Nautilus and Satori. All our instruments showed that the Nautilus Lacuna was filled, but we could never teleport there, and nothing ever showed on the map.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
I asked how this could be, and Jack admitted it was beyond him, but he pointed me toward the one Linden who might have the answers.&lt;br /&gt;
&lt;br /&gt;
== Magellan ==&lt;br /&gt;
Magellan Linden, the famed explorer whose footprints were the first to grace most of the known continents of Second Life, is he of whom Jack spoke. For those unfamiliar with Magellan&#039;s legacy you might want to check out:&lt;br /&gt;
* [http://secondlife.blogs.com/magellan/ His blog posts] on the discovery of Heterocera and the original Moth people culture&lt;br /&gt;
* [http://secondlife.wikia.com/wiki/Magellan_Linden A short bio].&lt;br /&gt;
* [http://web.mac.com/salazarjack/Site/Magellan_Linden.html Another bio]. &lt;br /&gt;
* [http://headburroantfarm.wordpress.com/2008/04/07/the-search-for-magellan-linden-starts-now/ Recent activity] over the discovery of Gaeta.&lt;br /&gt;
&lt;br /&gt;
Magellan Linden&#039;s desk was unoccupied, of course -- he&#039;s never spent much time there, nor indeed made any effort to be reachable by his fellow Lindens. On the desk lay a weathered map. Opposite corners of the map&#039;s curling edges had been weighted down on one side with a bottle of single malt scotch, and on the other a box of thickly-rolled Havanas. The map shows an island whose shape matches the landmass revealed in the heart of the Nautilus Lacuna. The map appears to be several centuries old, though several food stains attest to more recent use. A scanned and &#039;shopped image of the map appears below.&lt;br /&gt;
&lt;br /&gt;
[[Image:Old Nautilus Map Weathered.jpg | 700px]]&lt;br /&gt;
&lt;br /&gt;
Magellan was unreachable though any means, inworld or out. Podmate Michael Linden noted that &amp;quot;Mag hasn&#039;t been around much in the last few months. He&#039;s been hanging out with the Moles, as far as I know. I&#039;m sure he&#039;s behind all this. I&#039;d check with the Moles.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
== &amp;quot;You built him a *what*?&amp;quot; ==&lt;br /&gt;
I went inworld and IM&#039;ed the LDPW group. A couple of moles were on, and responded cryptically to my questions about Magellan Linden&#039;s whereabouts or activities. &amp;quot;We don&#039;t know where he took the Mole Tank,&amp;quot; one little furry said before being shushed (yes, &amp;quot;shushed&amp;quot; in group chat). &amp;quot;Mole Tank?&amp;quot; I asked. &lt;br /&gt;
&lt;br /&gt;
Eventually the Moles informed me that they had constructed an odd vehicle, made to Magellan&#039;s specs. This &amp;quot;Mole Tank&amp;quot; is some kind of armored, boring, submarine -- or so I gathered. They didn&#039;t know (or wouldn&#039;t say) what Magellan intended for this vehicle. They did note, however, that they gave the vehicle trans-Void capability. Like Magellan&#039;s famous suit itself, this vehicle could exist in both Second Life and the Void.&lt;br /&gt;
&lt;br /&gt;
== Magellan&#039;s flash drive == &lt;br /&gt;
Michael then provided the next clue. He brought me back to his pod of desks and pointed to Magellan&#039;s Mac. There, sticking out of the side of the laptop, was a USB flash stick hand labeled &amp;quot;Helmet Cam&amp;quot;. Sadly, only one salient video file remained. The rest had been recorded over with something more recent: Magellan at home, wearing his Void suit at his computer and drunk IM&#039;ing various Linden alts with deprecations and curses. &lt;br /&gt;
&lt;br /&gt;
Below you can see several stills from the one remaining segment. I offer these to you with only the most modest of explanation, so that you may form your own opinions. Where appropriate I detail what I can make out of the audio track. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 1.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The segment starts with the suit apparently prone on the floor of an unknown interior space. Audio indicates that Magellan is inside as he can be heard breathing and making other, um, biological noises. He gradually stands, offering up confused and unintelligible mutterings on the audio. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 2.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The interior space has some kind of door, which opens to reveal the outside. The cant of the land seems to indicate that the floor of the interior space is pitched at an odd angle. Magellan rights himself, moves to the door and steps outside. &lt;br /&gt;
&lt;br /&gt;
[[Image:MagCam 3.jpg | 650px]]&lt;br /&gt;
&lt;br /&gt;
The view outside shows a wide canal, stone lined, flowing through a land with some low buildings on the far bank. I cannot confirm the location, though the map view of Nautilus City does show a long canal leading to a central circular bay. I leave it to the reader to determine if this is correct. &lt;br /&gt;
&lt;br /&gt;
== Chat log == &lt;br /&gt;
A final bit of evidence came from the GTeam. A resident (name withheld) filed an Abuse Report against Magellan a while ago, and included a chat log. &lt;br /&gt;
&lt;br /&gt;
Resident: Excuse me, but could I ask you please to move?&lt;br /&gt;
&lt;br /&gt;
Resident: I mean, with that huge suit you&#039;re wearing, it&#039;s hard for people to walk around you in here.&lt;br /&gt;
&lt;br /&gt;
Resident: Please?&lt;br /&gt;
&lt;br /&gt;
Magellan: Hush, woman! I&#039;m in three different IMs and they&#039;re all more important than you.&lt;br /&gt;
&lt;br /&gt;
Resident: But this is my art gallery. People are here for the opening party.&lt;br /&gt;
&lt;br /&gt;
Magellan: Just tow it out to Weiland or Shenning. I&#039;ll board it there, head south.&lt;br /&gt;
 &lt;br /&gt;
Resident: What?&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it!&lt;br /&gt;
&lt;br /&gt;
Resident: What did I do? Tow what?&lt;br /&gt;
&lt;br /&gt;
Magellan: No, some arty-farty cow is making noise and confusing me.&lt;br /&gt;
&lt;br /&gt;
Magellan: Damn it again!&lt;br /&gt;
&lt;br /&gt;
Resident: Hey, wait, are you talking about me?&lt;br /&gt;
&lt;br /&gt;
== Further investigation ==&lt;br /&gt;
Lastly, I was just contacted by a resident who claims to have &amp;quot;evidence&amp;quot; relating to both Magellan Linden and the appearance of Nautilus City. He says he won&#039;t meet with me directly. Instead I have to create a new alt and go to a certain meeting place tonight. He says, &amp;quot;The deals off if my sensor script smells a Linden anywhere on the sim.&amp;quot; I&#039;m not sure what he means, as he hadn&#039;t previously mentioned any &amp;quot;deal&amp;quot;, but I&#039;ll go anyway. Hopefully I&#039;ll have more to report after the meeting.&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=102693</id>
		<title>LSL HTTP server/beta</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server/beta&amp;diff=102693"/>
		<updated>2008-10-17T20:39:06Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: New page: The new http-in functions described on LSL http server are available on the preview grid for beta testing.   ;  Where? :Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; w...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The new http-in functions described on [[LSL http server]] are available on the preview grid for beta testing. &lt;br /&gt;
&lt;br /&gt;
;  Where?&lt;br /&gt;
:Aditi, the preview grid. Regions are named &amp;quot;Http In Sandbox n&amp;quot; where n is 1,2, or 3.&lt;br /&gt;
;  What viewer should I use?&lt;br /&gt;
: Use a mono-compatible main grid viewer (version 1.20 or later), and have it log you into aditi. Shift-control-g at the login screen brings up the grid select dropdown. Aditi = preview grid, Agni = main grid.&lt;br /&gt;
; But the viewer won&#039;t know about the new functions&lt;br /&gt;
: With Mono, compilation is done server side. So make sure you select the Mono checkbox and you will be able to compile a script with the new functions as long as you are in one of the http-in sandboxes.&lt;br /&gt;
; How do I report bugs?&lt;br /&gt;
: Check this meta JIRA - [http://jira.secondlife.com/browse/SVC-3238 SVC-3238]. Existing issues for http-in are linked. Check the open issues to see if your bug is already listed. If so, consider commenting on that issue to add any insights you have. If not, create a new issue. Make sure you:&lt;br /&gt;
* JIRA should be SVC&lt;br /&gt;
* Title should start &amp;quot;http-in:&amp;quot;&lt;br /&gt;
* Component &amp;quot;Scripts&amp;quot;&lt;br /&gt;
* Affects version is unimportant&lt;br /&gt;
* Please include a minimal repro of the bug. Pare down the code to the minimum necessary to exhibit the issue.&lt;br /&gt;
* Link your issue &amp;quot;Relates to&amp;quot; SVC-3238&lt;br /&gt;
; What if I have questions?&lt;br /&gt;
: Several resources are available&lt;br /&gt;
* Use the discussion tab for this page to ask questions about the beta&lt;br /&gt;
* If you are a member of secondlifescripters@lists.secondlife.com you can post a question.&lt;br /&gt;
* Or try asking on the second life lsl forum. &lt;br /&gt;
* I (Periapse Linden) hold an office hour on Fridays at 3pm. Location is Beaumont, eastern edge, under the hill with the observatory dome.&lt;br /&gt;
; What about Teen Grid residents?&lt;br /&gt;
: Teen grid residents are welcome to participate in this beta. Log in to aditi with the appropriate viewer (see above). Teleport to &amp;quot;Http In Sandbox Teen&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Resources ==&lt;br /&gt;
* New functions and their arguments: [[LSL http server]]&lt;br /&gt;
* Meta JIRA with all known issues: [http://jira.secondlife.com/browse/SVC-3238 SVC-3238]&lt;br /&gt;
* [[LSL_http_server/examples | Code samples]]&lt;br /&gt;
* Design JIRA: [https://jira.secondlife.com/browse/SVC-1086 SVC-1086]&lt;br /&gt;
* Design docs: [[LSL_http_server/design]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server&amp;diff=102613</id>
		<title>LSL HTTP server</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=LSL_HTTP_server&amp;diff=102613"/>
		<updated>2008-10-17T18:30:01Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Intro ==&lt;br /&gt;
This is the counter part to llHTTPRequest.  While llHTTPRequest lets scripts in Second Life request data from http accessible sources, this &amp;quot;http-in&amp;quot; project allows outside sources to request data from scripts in Second Life.  The key difference is that llHTTPRequest exchanges data when the script in SL wants; http-in allows outside sources to determine when they need to communicate with scripts in SL.  Prior to http-in similar functionality could be achieved by polling with llHTTPRequest, llEmail and XML-RPC.  All three are cumbersome and the latter two have serious scalability bottlenecks.&lt;br /&gt;
 &lt;br /&gt;
== Uses ==&lt;br /&gt;
* Easily get data from LSL scripts to outside viewers, scripts or servers.&lt;br /&gt;
** Web front end for a visitor counter or other statistics accumulator.&lt;br /&gt;
* Easily get data into LSL scripts from outside viewers, scripts or servers.&lt;br /&gt;
** A store with a web front end that communicates to an in-world object to exchange L$ and inventory items.&lt;br /&gt;
** A game in-world where the primary game logic is handled by an external program which needs to manipulate in world items.&lt;br /&gt;
&lt;br /&gt;
Gory Technical Details follow.  Or jump straight to the [[LSL_http_server/examples | Script Examples]].&lt;br /&gt;
&lt;br /&gt;
== Script API ==&lt;br /&gt;
* &#039;&#039;&#039;key llRequestURL()&#039;&#039;&#039;&lt;br /&gt;
: Request a new LSL Server public URL. &lt;br /&gt;
: An http_request event will be triggered with success or failure and include the returned key&lt;br /&gt;
 lsl: request_id = llRequestURL(); &lt;br /&gt;
* &#039;&#039;&#039;key llRequestSecureURL()&#039;&#039;&#039;&lt;br /&gt;
: Similar to &#039;&#039;llRequestURL&#039;&#039; except requests an HTTPS / SSL URL.&lt;br /&gt;
: An http_request event will be triggered with success or failure and include the returned key&lt;br /&gt;
 lsl: request_id = llRequestSecureURL(); &lt;br /&gt;
* &#039;&#039;&#039;llReleaseURL(string url)&#039;&#039;&#039;&lt;br /&gt;
: Clear the specific URL, used for both secure and non-secure URLs.&lt;br /&gt;
 lsl: llReleaseURL(&amp;quot;http://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221&amp;quot;);&lt;br /&gt;
* &#039;&#039;&#039;http_request(key id, string method, string body)&#039;&#039;&#039;&lt;br /&gt;
: Event triggered when an URL is hit:&lt;br /&gt;
:* id is unique to this request&lt;br /&gt;
:* Supported methods are GET/POST/PUT/DELETE&lt;br /&gt;
:* body: The body of the request.&lt;br /&gt;
: Event also triggered with response to &#039;&#039;llRequestURL&#039;&#039; and &#039;&#039;llRequestSecureURL&#039;&#039;&lt;br /&gt;
:* id matches the key returned by &#039;&#039;llRequestURL&#039;&#039; or &#039;&#039;llRequestSecureURL&#039;&#039;&lt;br /&gt;
:* method == URL_REQUEST_GRANTED for success, URL_REQUEST_DENIED for failure to get an URL&lt;br /&gt;
:* body is the public URL.  If unable to get a public URL body will be empty.&lt;br /&gt;
* &#039;&#039;&#039;llHTTPResponse(key id, integer status, string body)&#039;&#039;&#039;&lt;br /&gt;
: Send &#039;&#039;body&#039;&#039; to the requester with status code &#039;&#039;status&#039;&#039;&lt;br /&gt;
:* id is the id from http_request that maps to the specific request&lt;br /&gt;
* &#039;&#039;&#039;string llHTTPHeader(key id, string header)&#039;&#039;&#039;&lt;br /&gt;
: Returns the string for the specified header in the specified request&lt;br /&gt;
:* Supported headers are:&lt;br /&gt;
::* &amp;quot;x-script-url&amp;quot;: The base url, as originally recieved from llRequestPublicURL&lt;br /&gt;
::* &amp;quot;x-path-info&amp;quot;: Any trailing path information from the requested url&lt;br /&gt;
::* &amp;quot;x-query-string&amp;quot;: Any query arguments, the text past a ? in the url&lt;br /&gt;
::* &amp;quot;x-forwarded-for&amp;quot;: The host that made the request&lt;br /&gt;
::* &amp;quot;user-agent&amp;quot;: The user-agent header as reported by the requester &lt;br /&gt;
 requested url: &#039;&#039;https://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221/foo/bar?arg=gra&#039;&#039;&lt;br /&gt;
 x-script-url: &#039;&#039;https://sim123.agni/cap/f23b4b94-012d-44f2-bd0c-16c328321221&#039;&#039;&lt;br /&gt;
 x-path-info: &#039;&#039;/foo/bar&#039;&#039;&lt;br /&gt;
 x-query-string: &#039;&#039;arg=gra&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;changed(integer change)&#039;&#039;&#039;&lt;br /&gt;
:* CHANGED_REGION_RESTART: New changed() event triggered on region startup.&lt;br /&gt;
* &#039;&#039;&#039;integer llGetFreeURLs()&#039;&#039;&#039;&lt;br /&gt;
: Returns the number of URLs available to this script.&lt;br /&gt;
&lt;br /&gt;
== URL Lifetime Limitations ==&lt;br /&gt;
* URLs are &#039;&#039;&#039;temporary&#039;&#039;&#039;!&lt;br /&gt;
* URLs will be lost in the following cases, all detectable by the script events listed with them.&lt;br /&gt;
** On object derez/rez: &#039;&#039;on_rez&#039;&#039;&lt;br /&gt;
** On script save/reset: &#039;&#039;default state_entry()&#039;&#039; (trickier in multi-state scripts)&lt;br /&gt;
** On region cross or TP(attachments): &#039;&#039;&#039;changed() event, CHANGED_REGION and CHANGED_TELEPORT&#039;&#039;&lt;br /&gt;
** On region restart: &#039;&#039;changed() event, new flag CHANGED_REGION_RESTART&#039;&#039;&lt;br /&gt;
* When urls are &#039;lost&#039; it means that all public urls for that script are gone, new ones will need to be requested and the new urls will &#039;&#039;&#039;&#039;&#039;not&#039;&#039;&#039;&#039;&#039; resemble the old ones.&lt;br /&gt;
* Maintaining persistent URLs will require building or using an external service similar to how [http://en.wikipedia.org/wiki/Dynamic_DNS Dynamic DNS] services work for tying domain names to dynamic IP addresses.&lt;br /&gt;
&lt;br /&gt;
== Resource Limitations ==&lt;br /&gt;
* There are a limited number of URLs available in each region, split by land ownership exactly like prim limits.&lt;br /&gt;
** Use llGetFreeURLs to get the exact number of available URLs for the script.&lt;br /&gt;
** The number of available URLs is the same as the number of available prims on the parcel the object is over.&lt;br /&gt;
**: &#039;&#039;Object owner does not matter, all objects over a parcel will use the resource pool for that parcel.&#039;&#039;&lt;br /&gt;
**: &#039;&#039;Like prims, all the parcels owned by the same owner and in the same region share the same pool of resources.&#039;&#039;&lt;br /&gt;
**: &#039;&#039;If you have two parcels in a region that each support 100 URLs, then you could use all 200 in objects on a single parcel.&#039;&#039;&lt;br /&gt;
** The region&#039;s object bonus factor does not apply to available URLs.&lt;br /&gt;
**: &#039;&#039;If a parcel has a max of 300 prims in a region with a 2x bonus factor there will only be 150 urls available.&#039;&#039;&lt;br /&gt;
* Each resident has their own unique pool of available URLs with a max of 38 URLs per resident.&lt;br /&gt;
** This is 1 per attachment point, but all 38 could be used by a single attachment for example.&lt;br /&gt;
* Vehicles are special and lazily moved to resident pools by the following logic:&lt;br /&gt;
** Any object that has a resident sitting on it is a &#039;vehicle&#039;&lt;br /&gt;
** Vehicles will use the url resources from the parcel they are over until the cross a parcel border.&lt;br /&gt;
**: &#039;&#039;Specifically this prevents anyone from breaking your vending machine by sitting on it and making it a &#039;vehicle&#039;.&#039;&#039;&lt;br /&gt;
** When any object using URL resources with a resident sitting on it crosses a parcel boundary the resources will switch to the first sitting resident with enough resources.  If no sitting agents have enough resources then the resources from the parcel being moved onto will be used.  If even then there are not enough resources to use then the vehicle will be blocked from moving.&lt;br /&gt;
**: &#039;&#039;In short we do everything we can to find a pool to host the resources needed by the vehicle, but will block movement if we can&#039;t.&#039;&#039;&lt;br /&gt;
* Parcel Sale: When a parcel is sold such that it changes the total available URLs in the region for either resident (seller or buyer) such that more URLs are being used than are available some objects will be returned.  &lt;br /&gt;
** The objects returned will be from youngest object to oldest object of those using URLs in each category in order of object category: Temporary, Other, Group, Owner, Selected/Sat upon.&lt;br /&gt;
**: &#039;&#039;The &#039;&#039;&#039;only&#039;&#039;&#039; time objects are possibly returned is when parcels change owner, and only if more resources are being used than allowed.&#039;&#039;&lt;br /&gt;
**: &#039;&#039;We return youngest temporary objects before older temporary objects before younger &#039;other&#039; (owned by non-group, non-parcel-owner) objects etc.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Other Limitations ==&lt;br /&gt;
* Size of the body of the requests will be limited to 2k bytes.&lt;br /&gt;
* Size of headers of requests will be limited to 255 bytes.&lt;br /&gt;
* The size of responses to requests is not currently limited, but this is subject to review during testing.&lt;br /&gt;
* The content type of the returned data is always &#039;text/plain; utf-8&#039;&lt;br /&gt;
*: &#039;&#039;Allowing more content type options is a possibility for the future, but not guaranteed.&#039;&#039;&lt;br /&gt;
* There is a cap of 64 in flight requests per script. This is based on the maximum number of pending events in LSL.&lt;br /&gt;
* &#039;&#039;We may throttle the rate we accept hits at the CAP server level as well.  This is possible, but has not yet been decided.&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
== Links ==&lt;br /&gt;
* [[LSL_http_server/examples | Script Examples]]&lt;br /&gt;
* [[LSL_http_server/design | Design Document]]&lt;br /&gt;
* Design Jira:{{jira|SVC-1086}}&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:MagCam_3.jpg&amp;diff=102603</id>
		<title>File:MagCam 3.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:MagCam_3.jpg&amp;diff=102603"/>
		<updated>2008-10-17T18:15:32Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:MagCam_2.jpg&amp;diff=102593</id>
		<title>File:MagCam 2.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:MagCam_2.jpg&amp;diff=102593"/>
		<updated>2008-10-17T18:15:11Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:MagCam_1.jpg&amp;diff=102583</id>
		<title>File:MagCam 1.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:MagCam_1.jpg&amp;diff=102583"/>
		<updated>2008-10-17T18:14:48Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=File:Old_Nautilus_Map_Weathered.jpg&amp;diff=102573</id>
		<title>File:Old Nautilus Map Weathered.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=File:Old_Nautilus_Map_Weathered.jpg&amp;diff=102573"/>
		<updated>2008-10-17T18:14:03Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=User:Periapse_Linden/Office_Hours&amp;diff=94694</id>
		<title>User:Periapse Linden/Office Hours</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=User:Periapse_Linden/Office_Hours&amp;diff=94694"/>
		<updated>2008-10-07T16:12:11Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: New page: {{Office Hours |Resident=Periapse Linden |location=[http://slurl.com/secondlife/Beaumont/247/184/24?title=Beaumont Per&amp;#039;s Place] |topics=&amp;#039;&amp;#039;Topics:&amp;#039;&amp;#039; * Mono for LSL * Metaverse interoperabil...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Office Hours&lt;br /&gt;
|Resident=Periapse Linden&lt;br /&gt;
|location=[http://slurl.com/secondlife/Beaumont/247/184/24?title=Beaumont Per&#039;s Place]&lt;br /&gt;
|topics=&#039;&#039;Topics:&#039;&#039;&lt;br /&gt;
* Mono for LSL&lt;br /&gt;
* Metaverse interoperability&lt;br /&gt;
* Agent and Region Domains&lt;br /&gt;
* Favorite chili ingredients&lt;br /&gt;
** Habenero peppers&lt;br /&gt;
** Gold leaf&lt;br /&gt;
** Culinary grade plutonium&lt;br /&gt;
** Dark energy&lt;br /&gt;
&lt;br /&gt;
|times= &#039;&#039;&#039;Fridays @ 3:00pm SLTime&#039;&#039;&#039;&lt;br /&gt;
|}}&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=89400</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=89400"/>
		<updated>2008-09-02T21:25:49Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) has not changed in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is now live on the main grid with server version 1.24.3&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
You can also check out a &#039;&#039;&#039;[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 Torley video turorial]&#039;&#039;&#039; or view other &#039;&#039;&#039;[[Mono_demos| videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The 1.24 server version is Mono enabled, and fully deployed to the main grid as of 29 August 2008.&lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are contained in the 1.21 client, now available as a [http://secondlife.com/support/downloads.php release candidate]. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. Mono requires the 1.21 viewer to create Mono scripts. Note that no special viewer is required to &#039;&#039;&#039;run&#039;&#039;&#039; Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is now fully deployed to the main grid with server 1.24.3. All regions can now run scripts compiled to Mono. You need a viewer versioned 1.21 or later to compile scripts to Mono, however no special viewer is needed to run previously compiled Mono scripts. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** The 1.21 viewer is available in release candidate. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** All regions are Mono-enabled as of 29 August 2008&lt;br /&gt;
** Blog: http://blog.secondlife.com/2008/08/20/mono-launch/&lt;br /&gt;
** Release notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24&lt;br /&gt;
** Forum thread, for comments: http://forums.secondlife.com/showthread.php?p=2115465&lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script and compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Create an object and add a new script to it&lt;br /&gt;
** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=88834</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=88834"/>
		<updated>2008-08-29T19:45:57Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is now live on the main grid with server version 1.24.3&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The 1.24 server version is Mono enabled, and fully deployed to the main grid as of 29 August 2008.&lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are contained in the 1.21 client, now available as a [http://secondlife.com/support/downloads.php release candidate]. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. Mono requires the 1.21 viewer to create Mono scripts. Note that no special viewer is required to &#039;&#039;&#039;run&#039;&#039;&#039; Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is now fully deployed to the main grid with server 1.24.3. All regions can now run scripts compiled to Mono. You need a viewer versioned 1.21 or later to compile scripts to Mono, however no special viewer is needed to run previously compiled Mono scripts. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** The 1.21 viewer is available in release candidate. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** All regions are Mono-enabled as of 29 August 2008&lt;br /&gt;
** Blog: http://blog.secondlife.com/2008/08/20/mono-launch/&lt;br /&gt;
** Release notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24&lt;br /&gt;
** Forum thread, for comments: http://forums.secondlife.com/showthread.php?p=2115465&lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script and compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Create an object and add a new script to it&lt;br /&gt;
** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=88776</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=88776"/>
		<updated>2008-08-29T15:48:03Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* The Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with [http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24 server version 1.24]. As of 28 August, simulator version 1.24.3 is deployed to 1/4 of the grid (selected randomly).&#039;&#039;&#039; Prior to the full deploy you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The 1.24 server version is Mono enabled, and will complete its deploy to the main grid on 29 August 2008.&lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are contained in the 1.21 client, now available as a [http://secondlife.com/support/downloads.php release candidate]. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second. Mono requires the 1.21 viewer to create Mono scripts. Note that no special viewer is required to &#039;&#039;&#039;run&#039;&#039;&#039; Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 20th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on week of 25 August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. Update (28 August): Mono deploy in progress. &lt;br /&gt;
*** Mono is now out on 1/4 of the main grid. Use Help/About Second Life to see if the region you are in is running Second Life Server 1.24&lt;br /&gt;
*** Blog: http://blog.secondlife.com/2008/08/20/mono-launch/&lt;br /&gt;
*** Release notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24&lt;br /&gt;
*** Forum thread, for comments: http://forums.secondlife.com/showthread.php?p=2115465&lt;br /&gt;
** If you wish to test Mono before it rolls out completely on the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=88591</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=88591"/>
		<updated>2008-08-28T17:39:27Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with [http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24 server version 1.24]. As of 28 August, simulator version 1.24.3 is deployed to 1/4 of the grid (selected randomly).&#039;&#039;&#039; Prior to the full deploy you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The viewer and server changes will deploy separately in August. &lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate after the server rolls out, during the week of 25 August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.&lt;br /&gt;
&lt;br /&gt;
The Mono server changes are checked in for the 1.24 server. This server is currently deployed to nearly all regions of the Preview Grid. Simulator version 1.24.3 is now deployed to 1/4 of the grid, and full deploy will follow if no problems are discovered. Most sandbox regions are currently running 1.24 (Goguen, Wanderton, Newcomb, for example). &lt;br /&gt;
The 1.24 simulator is also available on the preview grid. You can download the preview grid viewer from the [http://secondlife.com/support/downloads.php downloads page] and test Mono on the various preview grid regions.&lt;br /&gt;
&lt;br /&gt;
Mono requires the 1.21 viewer to create Mono scripts. Note that no special viewer is required to &#039;&#039;&#039;run&#039;&#039;&#039; Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Another viewer dependency concerns the &amp;quot;Script perf&amp;quot; line in the statistics bar (ctrl-shft-1). In older viewers (1.20 and lower) this line will no longer contain useful data. In 1.21 and later viewers this line becomes &amp;quot;Script events&amp;quot; and gives the number of events handled per second.  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 20th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on week of 25 August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. Update (28 August): Mono deploy in progress. &lt;br /&gt;
*** Mono is now out on 1/4 of the main grid. Use Help/About Second Life to see if the region you are in is running Second Life Server 1.24&lt;br /&gt;
*** Blog: http://blog.secondlife.com/2008/08/20/mono-launch/&lt;br /&gt;
*** Release notes: https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24&lt;br /&gt;
*** Forum thread, for comments: http://forums.secondlife.com/showthread.php?p=2115465&lt;br /&gt;
** If you wish to test Mono before it rolls out completely on the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Release_Notes/Second_Life_Server/1.24&amp;diff=88585</id>
		<title>Release Notes/Second Life Server/1.24</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Release_Notes/Second_Life_Server/1.24&amp;diff=88585"/>
		<updated>2008-08-28T17:18:51Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Release Notes for Second Life Server 1.24 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Release Notes for Second Life Server 1.24 ==&lt;br /&gt;
&lt;br /&gt;
Changes: &lt;br /&gt;
* Mono is an alternate way to run ordinary LSL scripts. It has advantages of speed and memory management over the current script engine. For more information about Mono see the wiki article: https://wiki.secondlife.com/wiki/Mono.&lt;br /&gt;
** Note: Although no special viewer is needed to run Mono scripts, to create them you will need a viewer version of 1.21 or later. &lt;br /&gt;
**The 1.21 Release Candidate Viewer is expected to be available the week of August 25th.&lt;br /&gt;
&lt;br /&gt;
* Enabled group moderation features for voice chat.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Changes that require both 1.24 Server *and* 1.21 Viewer (not yet released):&lt;br /&gt;
* New LSL calls for touch &amp;quot;position&amp;quot; in the touch_start(), touch(), and touch_end() events. Each touch() event provides the current surface point data (allowing grabbing, sliders, levers, and all sorts of pseudo GUI builds!):&lt;br /&gt;
** [[llDetectedTouchUV]]() - returns the UV coordinates of the point touched.&lt;br /&gt;
** [[llDetectedTouchFace]]() - returns the face of the point touched.&lt;br /&gt;
** [[llDetectedTouchPos]]() - returns the world coordinates of the point touched.&lt;br /&gt;
** [[llDetectedTouchNormal]]() - returns the surface normal of the point touched.&lt;br /&gt;
** [[llDetectedTouchBinormal]]() - returns the surface bi-normal of the point touched.&lt;br /&gt;
** [[llDetectedTouchST]]() - call to query surface coordinates.&lt;br /&gt;
&lt;br /&gt;
* Script performance now measured in &amp;quot;events per second&amp;quot; (eps) instead of &amp;quot;instructions per second&amp;quot; (ips)&lt;br /&gt;
** 1.21 viewers will show &amp;quot;Script events&amp;quot; in the statistics window (ctrl-sht-1), but the metric will only have useful data for regions running 1.24.&lt;br /&gt;
** Earlier viewers will show the legacy &amp;quot;Script perf&amp;quot; in the stat window, but its value will only be useful for regions running 1.23. &lt;br /&gt;
** Once 1.24 is deployed gridwide, the only way to obtain useful script performance info will be with a 1.21 or later viewer&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* New feature to return all objects on an estate&lt;br /&gt;
** [https://jira.secondlife.com/browse/MISC-713 MISC-713]: Add &amp;quot;Return All Objects&amp;quot; as an estate-wide feature for a specified resident&lt;br /&gt;
&lt;br /&gt;
* New info added:&lt;br /&gt;
** Add Time Stamp to Parcel Object List &lt;br /&gt;
** Add Time Stamp to Top Scripts Colliders List&lt;br /&gt;
** Add more categories to Help -&amp;gt; Report Abuse..&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Fixes:&lt;br /&gt;
* Three security fixes&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Release_Notes/Second_Life_Server/1.24&amp;diff=88584</id>
		<title>Release Notes/Second Life Server/1.24</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Release_Notes/Second_Life_Server/1.24&amp;diff=88584"/>
		<updated>2008-08-28T17:18:06Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Release Notes for Second Life Server 1.24 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Release Notes for Second Life Server 1.24 ==&lt;br /&gt;
&lt;br /&gt;
Changes: &lt;br /&gt;
* Mono is an alternate way to run ordinary LSL scripts. It has advantages of speed and memory management over the current script engine. For more information about Mono see the wiki article: https://wiki.secondlife.com/wiki/Mono.&lt;br /&gt;
** Note: Although no special viewer is needed to run Mono scripts, to create them you will need a viewer version of 1.21 or later. &lt;br /&gt;
**The 1.21 Release Candidate Viewer is expected to be available the week of August 25th.&lt;br /&gt;
&lt;br /&gt;
* Enabled group moderation features for voice chat.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Changes that require both 1.24 Server *and* 1.21 Viewer (not yet released):&lt;br /&gt;
* New LSL calls for touch &amp;quot;position&amp;quot; in the touch_start(), touch(), and touch_end() events. Each touch() event provides the current surface point data (allowing grabbing, sliders, levers, and all sorts of pseudo GUI builds!):&lt;br /&gt;
** [[llDetectedTouchUV]]() - returns the UV coordinates of the point touched.&lt;br /&gt;
** [[llDetectedTouchFace]]() - returns the face of the point touched.&lt;br /&gt;
** [[llDetectedTouchPos]]() - returns the world coordinates of the point touched.&lt;br /&gt;
** [[llDetectedTouchNormal]]() - returns the surface normal of the point touched.&lt;br /&gt;
** [[llDetectedTouchBinormal]]() - returns the surface bi-normal of the point touched.&lt;br /&gt;
** [[llDetectedTouchST]]() - call to query surface coordinates.&lt;br /&gt;
&lt;br /&gt;
* Script performance now measured in &amp;quot;events per second&amp;quot; (eps) instead of &amp;quot;instructions per second&amp;quot; (ips)&lt;br /&gt;
** 1.21 viewers will show &amp;quot;Script events&amp;quot; in the statistics window (ctrl-sht-1), but the metric will only have useful data for regions running 1.24.&lt;br /&gt;
** Earlier viewers will show the legacy &amp;quot;Script perf&amp;quot; in the stat window, but its value will only be useful for regions running 1.23. &lt;br /&gt;
** Once 1.24 is deployed gridwide, the only way to obtain useful script performance info will be with at 1.21 or later viewer&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* New feature to return all objects on an estate&lt;br /&gt;
** [https://jira.secondlife.com/browse/MISC-713 MISC-713]: Add &amp;quot;Return All Objects&amp;quot; as an estate-wide feature for a specified resident&lt;br /&gt;
&lt;br /&gt;
* New info added:&lt;br /&gt;
** Add Time Stamp to Parcel Object List &lt;br /&gt;
** Add Time Stamp to Top Scripts Colliders List&lt;br /&gt;
** Add more categories to Help -&amp;gt; Report Abuse..&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Fixes:&lt;br /&gt;
* Three security fixes&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87216</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87216"/>
		<updated>2008-08-20T21:39:56Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* FAQ */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with server version 1.24, which should deploy during the week of 17th August.&#039;&#039;&#039; Prior to that you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The viewer and server changes will deploy separately in August. &lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate after the server rolls out, during the week of 25 August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.&lt;br /&gt;
&lt;br /&gt;
The Mono server changes are checked in for the 1.24 server. This server is currently deployed to nearly all regions of the Preview Grid. The plan is for the Mono server to roll out to the main grid the week of 17th August. &lt;br /&gt;
&lt;br /&gt;
Those who would like to try out Mono before it goes to the main grid can download the preview grid viewer from the [http://secondlife.com/support/downloads.php downloads page] and test Mono on the various preview grid regions.&lt;br /&gt;
&lt;br /&gt;
According to this plan the Mono server will deploy before the 1.21 viewer is available as a release candidate. Thus, although the main grid will be Mono enabled, no one using the regular or release candidate viewer will actually be able to create Mono scripts. During this time before the viewer release enterprising scripters can use the preview grid viewer and force it to connect to the main grid. Note that no special viewer is required to run Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 20th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on week of 25 August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. It will deploy over three days starting 19th August (see the [http://blog.secondlife.com/ SL blog] for a post when it happens). After the deploy all main grid regions will be Mono enabled.&lt;br /&gt;
** If you wish to test Mono before it rolls out to the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87215</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87215"/>
		<updated>2008-08-20T21:19:46Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* FAQ */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with server version 1.24, which should deploy during the week of 17th August.&#039;&#039;&#039; Prior to that you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The viewer and server changes will deploy separately in August. &lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate after the server rolls out, during the week of 25 August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.&lt;br /&gt;
&lt;br /&gt;
The Mono server changes are checked in for the 1.24 server. This server is currently deployed to nearly all regions of the Preview Grid. The plan is for the Mono server to roll out to the main grid the week of 17th August. &lt;br /&gt;
&lt;br /&gt;
Those who would like to try out Mono before it goes to the main grid can download the preview grid viewer from the [http://secondlife.com/support/downloads.php downloads page] and test Mono on the various preview grid regions.&lt;br /&gt;
&lt;br /&gt;
According to this plan the Mono server will deploy before the 1.21 viewer is available as a release candidate. Thus, although the main grid will be Mono enabled, no one using the regular or release candidate viewer will actually be able to create Mono scripts. During this time before the viewer release enterprising scripters can use the preview grid viewer and force it to connect to the main grid. Note that no special viewer is required to run Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 20th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on week of 25 August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. It will deploy over three days starting 19th August (see the [http://blog.secondlife.com/ SL blog] for a post when it happens). After the deploy all main grid regions will be Mono enabled.&lt;br /&gt;
** If you wish to test Mono before it rolls out to the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Are there other ways to make my scripts even more memory efficient when using Mono? ;  : Indeed, Mono can do what&#039;s called bytecode sharing. Suppose you have a region which uses many instances of the same script, like XYText or Puppeteer, for example. As long as all the instances share the same asset id, the bytecode will only be added to memory once, and shared by all the copies. Key to making this work is ensuring that you simply copy the scripts (or the objects the scripts are within) after they have been saved for the final time. If you have purchased a script that is used many times, ask the creator for a Mono version, and then copy that version into the objects. It&#039;s important that you copy the scripts, so that the asset id is the same. If you recompile each instance separately, they will get different asset ids and the engine won&#039;t be able to share the bytecode. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
;Why didn&#039;t you use &amp;lt;favorite_language&amp;gt; instead of Mono? (ie lisp, python, lua, javascript) : TBA&lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87201</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87201"/>
		<updated>2008-08-20T21:01:45Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* Mono How-to */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with server version 1.24, which should deploy during the week of 17th August.&#039;&#039;&#039; Prior to that you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The viewer and server changes will deploy separately in August. &lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate after the server rolls out, during the week of 25 August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.&lt;br /&gt;
&lt;br /&gt;
The Mono server changes are checked in for the 1.24 server. This server is currently deployed to nearly all regions of the Preview Grid. The plan is for the Mono server to roll out to the main grid the week of 17th August. &lt;br /&gt;
&lt;br /&gt;
Those who would like to try out Mono before it goes to the main grid can download the preview grid viewer from the [http://secondlife.com/support/downloads.php downloads page] and test Mono on the various preview grid regions.&lt;br /&gt;
&lt;br /&gt;
According to this plan the Mono server will deploy before the 1.21 viewer is available as a release candidate. Thus, although the main grid will be Mono enabled, no one using the regular or release candidate viewer will actually be able to create Mono scripts. During this time before the viewer release enterprising scripters can use the preview grid viewer and force it to connect to the main grid. Note that no special viewer is required to run Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 20th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on week of 25 August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. It will deploy over three days starting 19th August (see the [http://blog.secondlife.com/ SL blog] for a post when it happens). After the deploy all main grid regions will be Mono enabled.&lt;br /&gt;
** If you wish to test Mono before it rolls out to the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
;Why didn&#039;t you use &amp;lt;favorite_language&amp;gt; instead of Mono? (ie lisp, python, lua, javascript) : TBA&lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87199</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=87199"/>
		<updated>2008-08-20T21:00:34Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: /* The Plan */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with server version 1.24, which should deploy during the week of 17th August.&#039;&#039;&#039; Prior to that you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The viewer and server changes will deploy separately in August. &lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate after the server rolls out, during the week of 25 August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.&lt;br /&gt;
&lt;br /&gt;
The Mono server changes are checked in for the 1.24 server. This server is currently deployed to nearly all regions of the Preview Grid. The plan is for the Mono server to roll out to the main grid the week of 17th August. &lt;br /&gt;
&lt;br /&gt;
Those who would like to try out Mono before it goes to the main grid can download the preview grid viewer from the [http://secondlife.com/support/downloads.php downloads page] and test Mono on the various preview grid regions.&lt;br /&gt;
&lt;br /&gt;
According to this plan the Mono server will deploy before the 1.21 viewer is available as a release candidate. Thus, although the main grid will be Mono enabled, no one using the regular or release candidate viewer will actually be able to create Mono scripts. During this time before the viewer release enterprising scripters can use the preview grid viewer and force it to connect to the main grid. Note that no special viewer is required to run Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 17th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on 20th August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. It will deploy over three days starting 19th August (see the [http://blog.secondlife.com/ SL blog] for a post when it happens). After the deploy all main grid regions will be Mono enabled.&lt;br /&gt;
** If you wish to test Mono before it rolls out to the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
;Why didn&#039;t you use &amp;lt;favorite_language&amp;gt; instead of Mono? (ie lisp, python, lua, javascript) : TBA&lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
	<entry>
		<id>https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=86935</id>
		<title>Mono</title>
		<link rel="alternate" type="text/html" href="https://wiki.secondlife.com/w/index.php?title=Mono&amp;diff=86935"/>
		<updated>2008-08-19T17:50:17Z</updated>

		<summary type="html">&lt;p&gt;Periapse Linden: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Help |Glossary=*}}&lt;br /&gt;
&#039;&#039;&#039;&amp;quot;Mono for Second Life&amp;quot; refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.&#039;&#039;&#039; The Linden Scripting Language ( [[LSL Portal | LSL]] ) will not change in any way&amp;lt;span class=&amp;quot;TablePager_nav&amp;quot;&amp;gt;[[#FAQ-Differences|*]]&amp;lt;/span&amp;gt;, so all of your existing scripted objects and attachments continue to function as before, only now they will have the opportunity to run faster. The key to this improvement is an open-sourced scripting engine called [http://www.mono-project.com/Main_Page Mono]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mono is slated for the Main Grid with server version 1.24, which should deploy during the week of 17th August.&#039;&#039;&#039; Prior to that you can still give Mono a spin on the preview grid (see below).&lt;br /&gt;
&lt;br /&gt;
You can also &#039;&#039;&#039;[[Mono_demos|see videos of Mono in action]]&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
= How LSL scripts work =&lt;br /&gt;
All your LSL scripts are run by the simulator (Linden Lab server program) that also runs the region you are in. When you teleport, or region cross, your new region&#039;s simulator takes on the duty of running all your scripted attachments. But the simulators cannot understand LSL directly -- the language was designed for human readability, not machine. So before the script can be executed, it must be turned into a machine readable format. This process is called compilation, and the resulting machine readable version of the script is called bytecode. LSL scripts are compiled when they are created by resident-programmers. The bytecode itself is stored on the Linden Lab asset servers and never needs to be referred to directly by residents. Instead, when you rez a scripted object, the simulator for the region you are in notes the script(s) in the object, and requests the appropriate bytecode from the asset database. The simulator program has several parts, and the part which runs the script bytecode is called the LSL scripting engine or virtual machine. &lt;br /&gt;
&lt;br /&gt;
In today&#039;s Second Life, scripts are everywhere in regions: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to your chat commands. For many regions the scripting engine is kept busy trying to execute hundreds of scripts all at once. As the number and complexity of scripts in a region rises, so do the demands upon the simulator. After a certain point the scripting engine starts taking up so much processing time that the rest of the simulator (particularly the physics engine) bogs down, and server-side lag results. Thus anything that can speed up the execution of scripts can push out the point where server lag starts to occur.  &lt;br /&gt;
&lt;br /&gt;
= Enter Mono =&lt;br /&gt;
Mono is another kind of scripting engine. It is fully open-sourced and has a proven record of speed and versatility. For over a year now Mono has been considered by Linden Lab as an alternative to the original scripting engine (sometimes called the LSL2 VM). But there are difficulties with switching engines. The most fundamental problem is that all bytecodes are different. So the LSL bytecode is just gibberish to Mono, and vice versa. Before we could start using a Mono scripting engine, we need to develop a compiler which can take LSL scripts and turn them into Mono bytecode. This is tricky, because the goal is to make scripts running under Mono behave &#039;exactly&#039; like scripts running under the original engine. It&#039;s painstaking work, and requires an extraordinary amount of testing. The final sprint of coding was completed in the third quarter of 2007, and since November Linden Lab QA has been rigorously pounding on the new scripting engine with an assortment of tests both automated and manual. &lt;br /&gt;
&lt;br /&gt;
= The Plan =&lt;br /&gt;
Thanks to the efforts of the beta test residents, and the Linden development and QA teams, Mono is now ready for the main grid. The viewer and server changes will deploy separately in August. &lt;br /&gt;
&lt;br /&gt;
The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate on 20th August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection, and a change to simulator statistics to show events per second instead of instructions per second.&lt;br /&gt;
&lt;br /&gt;
The Mono server changes are checked in for the 1.24 server. This server is currently deployed to nearly all regions of the Preview Grid. The plan is for the Mono server to roll out to the main grid the week of 17th August. &lt;br /&gt;
&lt;br /&gt;
Those who would like to try out Mono before it goes to the main grid can download the preview grid viewer from the [http://secondlife.com/support/downloads.php downloads page] and test Mono on the various preview grid regions.&lt;br /&gt;
&lt;br /&gt;
According to this plan the Mono server will deploy before the 1.21 viewer is available as a release candidate. Thus, although the main grid will be Mono enabled, no one using the regular or release candidate viewer will actually be able to create Mono scripts. During this time before the viewer release enterprising scripters can use the preview grid viewer and force it to connect to the main grid. Note that no special viewer is required to run Mono scripts -- that is automatic and handled by the server. A Mono viewer is only required in order to change the compile target of a script (from LSL2 to Mono, or vice versa).  &lt;br /&gt;
&lt;br /&gt;
Once Mono has been live on the main grid for several months we may turn off compilation to the original scripting engine. At that point all new and edited scripts will be Mono. We will, however, keep the original scripting engine running. This means that old scripts will continue to run as before, but as soon as they are edited they will become Mono scripts.&lt;br /&gt;
&lt;br /&gt;
= Mono benefits =&lt;br /&gt;
We&#039;ve run some benchmarks to compare the performance of the original scripting engine and the Mono VM. When we run the tests side by side we found that Mono is up to 220x faster than LSL2. These benchmarks were math intensive scripts usually used to evaluate performance. It should be noted that for ordinary scripts the gains are much more humble. &lt;br /&gt;
&lt;br /&gt;
Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. With LSL2, a full 16K is allocated for all scripts, even simple &amp;quot;Hello, Avatar&amp;quot; ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, is about a wash as far as overall memory footprint goes. &lt;br /&gt;
&lt;br /&gt;
In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K.&lt;br /&gt;
&lt;br /&gt;
Mono tip:&lt;br /&gt;
Mono can do bytecode sharing. Thus multiple copies of scripts with the same asset id will only take up as much room as one instance. Imagine some script that you use a dozen times on your land. If each of the objects containing the script is separately compiled from text source, you will use up a dozen times the script&#039;s size of memory. But if instead you simply drag a copy of the single, already compiled script into each of the dozen objects, then no matter how many copies exist they only take up the size of one script (plus data) in memory.&lt;br /&gt;
&lt;br /&gt;
= Mono How-to =&lt;br /&gt;
&lt;br /&gt;
Mono is scheduled for deployment to the main grid with the 1.24 server, starting 17th August. After that deployment all regions will be able to run LSL scripts compiled to Mono. The 1.21 viewer, scheduled for first release candidate on 20th August, has the user interface needed to compile scripts to Mono (any viewer will run a previously created Mono script). The following information should help developers start working with Mono during this transition period, until both server and viewer are fully deployed. &lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Download a viewer with the Mono UI if you want to create Mono scripts&#039;&#039;&#039;&lt;br /&gt;
** When the 1.21 viewer is available in release candidate, use it. See the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
** Before the 1.21 viewer is available, you can still compile to Mono using the preview grid viewer, available from the Test Viewers section of the [http://secondlife.com/support/downloads.php downloads page].&lt;br /&gt;
* &#039;&#039;&#039;Log in to SL and go to a Mono-enabled region&#039;&#039;&#039;&lt;br /&gt;
** Mono will deploy to the main grid with the 1.24 server. It will deploy over three days starting 19th August (see the [http://blog.secondlife.com/ SL blog] for a post when it happens). After the deploy all main grid regions will be Mono enabled.&lt;br /&gt;
** If you wish to test Mono before it rolls out to the main grid, you can go to the preview grid. Nearly all regions on the preview grid are now running Mono. Check the server version by doing Help / About Second Life.&lt;br /&gt;
** If you want to use the preview grid viewer to compile mono scripts on the main grid (necessary until the 1.21 viewer is available in release candidate), you will need to force that viewer to log you in to the main grid instead of the preview grid.&lt;br /&gt;
*** Open the preview grid viewer&lt;br /&gt;
*** At the login page hit Ctrl-Shift-G. This will bring up the grid select drop down menu. (If Ctrl-Shift-G isn&#039;t available on your system, you can set ForceShowGrid to TRUE under [[Debug Settings]].)&lt;br /&gt;
*** Select &amp;quot;agni&amp;quot; (the main grid) from the drop-down menu, and log in normally&lt;br /&gt;
*** Note: if, later, you want to use that viewer for the preview grid again, select the preview grid (aditi) from the drop-down. &lt;br /&gt;
* &#039;&#039;&#039;Create/edit a script an compile it to Mono&#039;&#039;&#039;&lt;br /&gt;
** Rez your script in an object.&lt;br /&gt;
*** Edit the script from the object&#039;s contents tab.&lt;br /&gt;
*** On the script editing dialog you will see a new checkbox at the bottom &amp;quot;Mono&amp;quot;. Check it.&lt;br /&gt;
*** Hit Save to recompile this script to Mono.&lt;br /&gt;
** You may now treat this script like any other. It will automatically run in the Mono runtime, regardless of ownership transfers or viewer version.&lt;br /&gt;
** If you fail to see the checkbox, you are not running a Mono viewer.&lt;br /&gt;
** If the checkbox is grayed out for Mono, you are not in a Mono enabled region.&lt;br /&gt;
** To convert a Mono script back to ordinary LSL2, uncheck the checkbox.&lt;br /&gt;
* &#039;&#039;&#039;To convert a number of scripted objects all to Mono at once&#039;&#039;&#039;&lt;br /&gt;
** Rez all the scripted objects&lt;br /&gt;
** Use the select tool to select them all.&lt;br /&gt;
** From the Tools menu select Recompile Selection / Mono.&lt;br /&gt;
&lt;br /&gt;
After you have converted a scripted object to Mono you will need to do a full QA run. Though Mono is compatible with old LSL2, there are timing differences which may cause object behavioral changes. Test your objects thoroughly before releasing Mono versions. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;To report Mono issues, use JIRA&#039;&#039;&#039;&lt;br /&gt;
* First check [https://jira.secondlife.com/browse/SVC-1276 this meta JIRA] to see if anyone has reported the issue already&lt;br /&gt;
** This may not be doable unless you&#039;ve drilled down into your script to locate what is breaking.&lt;br /&gt;
* If a JIRA already exists, and it appears to be the same failure, then simply add your information as a comment and attachment to that issue.&lt;br /&gt;
* If not, open a new SVC ticket for each bug you find. In the ticket summary please use the word &amp;quot;Mono&amp;quot; so that we can filter for them. &lt;br /&gt;
* In addition to your description of the problem please attach your script itself, or (ideally) a smaller script which illustrates the difference in behavior between the two scripting engines.&lt;br /&gt;
* Link your JIRA to the meta JIRA.&lt;br /&gt;
&lt;br /&gt;
= Testing =&lt;br /&gt;
During the integration of Mono we have used tests to ensure there are no regressions. For the current version of the regression test see [[LSL Language Test]]. This effectively serves as the specification of LSL.&lt;br /&gt;
&lt;br /&gt;
There are tests for library call bindings in [[LSL Library Call Test 1]] and [[LSL Library Call Test 2]]. This is split to overcome the memory limitations.&lt;br /&gt;
&lt;br /&gt;
[[Event test script]]&lt;br /&gt;
&lt;br /&gt;
There are several benchmarks to test the performance. They are available here:&lt;br /&gt;
*[[LSL Recursion Benchmark]]&lt;br /&gt;
*[[LSL Mandelbrot Benchmark]]&lt;br /&gt;
*[[LSL Partial Sums Benchmark]]&lt;br /&gt;
*[[LSL NSieve Benchmark]]&lt;br /&gt;
*[[LSL NSieve Bits Benchmark]]&lt;br /&gt;
&lt;br /&gt;
= FAQ =&lt;br /&gt;
Section for questions.&lt;br /&gt;
; Can you give a few examples scripts where Mono&#039;s speed increase is readily apparent? : These calculation intensive scripts run considerably faster under Mono: [[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]].&lt;br /&gt;
; As far as previously purchased LSL scripts, why do I have to wait for the scripter to convert the script to run on Mono, why can’t I just do this myself? : The increase in speed provided by Mono can cause problems with objects using communication between multiple scripts and there are a few cases where we have had to make Mono behave slightly differently to LSL. It&#039;s much safer to have the original scripter convert and &#039;&#039;&#039;test&#039;&#039;&#039; the scripts.&lt;br /&gt;
; Will scripts compiled to Mono work on an older version of the viewer? : Yes. You only need a viewer version 1.21 or later if you want to make Mono scripts. You can run Mono scripts from any viewer since Mono actually runs on the server.&lt;br /&gt;
; How long until scripts can be compiled to Mono? : The 1.21 viewer release candidate should be available on Wednesday, 20 August. &lt;br /&gt;
; Is there an indicator of some kind to tell me that a script is running on Mono? How can I tell? : No. It&#039;s very difficult to work out whether objects and all the objects they contain use Mono scripts, so we haven&#039;t attempted to display it. &lt;br /&gt;
; Given that OpenSim runs on Mono, will LL implementing Mono expedite interoperability between the two worlds? : We are talking to OpenSim developers about script interoperability based on Mono.&lt;br /&gt;
; Has the available memory for scripts changed? (Currently 16k in LSL2 VM) : For the same LSL script the Mono bytecode and original (LSL2) bytecode will be of different size. In order to be compatible with all known scripts, we have expanded the size ceiling for Mono to be 64k. This is ok to do for Mono because unlike LSL2, Mono allocates memory dynamically, whereas all LSL2 scripts occupy 16K. Mono scripts only allocate the memory that they need.&lt;br /&gt;
; 64K? Wow, isn&#039;t that going to encourage inefficient scripting? : We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary. &lt;br /&gt;
; Will I have to manually convert all my objects to using Mono, or is there an automated tool? : Yes, you must manually invoke compilation to Mono. Though you can make use of the Tools Menu to recompile all scripts in selection to Mono. &lt;br /&gt;
; Can I keep my scripts running on the original scripting engine forever? : We have no plans to eliminate the original engine. This will be re-examined after Mono has been live on the Main Grid for a while. But right now it is easier to continue to support the original scripting engine than to migrate all scripts. &lt;br /&gt;
; Will I be able to write scripts in languages besides LSL since Mono supports lots of languages? : Eventually. Right now our goal is to make Mono completely compatible with the original scripting engine for LSL scripts.  &lt;br /&gt;
;Why didn&#039;t you use &amp;lt;favorite_language&amp;gt; instead of Mono? (ie lisp, python, lua, javascript) : TBA&lt;br /&gt;
; Will LSL be getting real language features with this change? (ie arrays, references/pointers, includes/imports)&lt;br /&gt;
: No.  The LSL language is not changing with this update.&lt;br /&gt;
; In the original scripting engine scripts are compiled on the viewer then uploaded, will that change with Mono? : Yes, Mono compilation is done in a distributed fashion on the sim hosts. &lt;br /&gt;
; Related to the above, I use a &amp;quot;clever trick&amp;quot; to upload my compiled bytecode in LSL2 with out the correct script text. What will happen to scripts I uploaded in this way when converted to Mono? Will I be able to continue to use my &amp;quot;clever trick&amp;quot; for Mono scripts? : The Mono compiler looks only at the script text. The Mono engine will only run bytecode which has been compiled by our Mono compiler. You will not be able to run any uploaded Mono bytecode.&lt;br /&gt;
; What about scripts whose LSL code has been lost, ie scripts that still run, but result in &amp;quot;Script missing from database.&amp;quot; when you try to edit them?  Is there any possibility of bytecode translation, or are these scripts stuck in the original scripting engine forever?&lt;br /&gt;
: There are currently no plans to allow byte code translation of LSL scripts, only compiling from source. This may be considered depending on resident demand.&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Differences&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;What are the known differences between the LSL2 and Mono compilers and runtimes?&lt;br /&gt;
: We have not tried to make Mono 100% compatible with the original engine. At least not to the point of duplicating any of the tricks or hacks that LSL2 allowed. Below are listed some known behavioral differences. Add to the list as more are discovered.&lt;br /&gt;
:* Unicode support. From Strife Onizuka &amp;quot;In LSO LSL, the entire Unicode range was supported by complying to RFC 2279 (about 2 billion possible characters). Mono supports RFC 3629 which supplants RFC 2279 and limits the Unicode range to the first 1,114,112 character codes. This directly effects these functions: [[llBase64ToString]], [[llUnescapeURL]]. Strings being passed from LSO scripts to Mono scripts will become corrupted (in a reliable way) if they contain characters outside the limited Unicode range.&amp;quot; -- {{Jira|SVC-1960}}&lt;br /&gt;
; &amp;lt;span id=&amp;quot;FAQ-Recompile&amp;quot;&amp;gt;&amp;lt;/span&amp;gt;After Mono launches why not recompile *all* scripts everywhere on the Grid to Mono?&lt;br /&gt;
: While it is certainly appealing to have only one compiler and runtime to support, practical concerns make this not feasible. Here&#039;s a list of the difficulties that give us pause:&lt;br /&gt;
:* We do not have the text asset (the LSL code) for all running scripts. These &amp;quot;bytecode only&amp;quot; scripts would stop working.&lt;br /&gt;
:* The automatic recompile would restart all scripts. Many scripts are meant to run continuously without restarting.&lt;br /&gt;
:* Mono scripts have a different timing profile than the original (usually faster). This will introduce behavior differences which will lead to some scripts breaking, often in subtle ways.&lt;br /&gt;
:* Some scripts take advantage of undocumented &amp;quot;features&amp;quot; of LSL2. We did not strive for 100% compatibility in such situations, but rather made Mono behave as sensibly and predictably as possible.&lt;br /&gt;
:* As a result of both reasons above, scripts need QA work after they have been recompiled. Residents who code and sell LSL scripts will have to test and possibly adjust the behavior of Mono versions of their scripts. If conversion were automatic they would not be reimbursed for their QA effort. With manual recompilation the resident scripters can sell Mono versions of their scripts as an upgrade, after they have tested and modified them. &lt;br /&gt;
:* Recompiling all scripts would play rather heavy-handedly with the permissions system. If someone has made and sold a script as &amp;quot;no-modify&amp;quot;, an automatic recompilation would violate their policy. While some scripters would be ok with this, many would not.  &lt;br /&gt;
; Is Mono still available on the preview grid? : Yes, see [[Mono/Beta FAQ]].&lt;br /&gt;
&lt;br /&gt;
[[Category:Features]]&lt;/div&gt;</summary>
		<author><name>Periapse Linden</name></author>
	</entry>
</feed>