Difference between revisions of "Mono information for non-scripters"
Yoz Linden (talk | contribs) m (1 revision) |
Rand Linden (talk | contribs) m (Text replace - 'Category:Content Creation' to 'Category:Content creation') |
||
(14 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
{{ | <noinclude>{{KBmaster}}</noinclude> | ||
==What is Mono?== | ==What is Mono?== | ||
Mono for Second Life® is a new way of running LSL (Linden Scripting Language) scripts inworld. In addition to being considerably faster than the original script engine, Mono offers better memory management and security. It also opens the door for eventual scripting in the Second Life virtual world with other programming languages besides LSL. | Mono for Second Life® is a new way of running LSL (Linden Scripting Language) scripts inworld. In addition to being considerably faster than the original script engine, Mono offers better memory management and security. It also opens the door for eventual scripting in the Second Life virtual world with other programming languages besides LSL. | ||
==How Mono works== | ==How Mono works== | ||
Currently all Second Life scripts are written in a special scripting language, developed for Second Life, called LSL. This script code is compiled into a machine format, called LSL bytecode. Each simulator (sim) that runs the Second Life world has a "virtual machine" that runs LSL bytecode. When you rez an item or attachment containing a script, the sim obtains the bytecode for the script, and the sim's virtual machine runs it. Mono is an open-sourced virtual machine. For this project we have deployed the Mono virtual machine alongside the LSL virtual machine in each simulator. We also made a special compiler that can take LSL code and turn it into the Mono bytecode. For the technical details of how to compile a script to Mono, see [[Mono information for scripters]]. If you're just interested in using Mono scripts that you buy, it's much easier -- in fact, there's absolutely nothing you need to do! When you rez any scripted object now, the simulator will check to see whether the script is ordinary LSL or LSL-for-Mono. It will automatically send the appropriate bytecode to the correct virtual machine. | Currently all Second Life scripts are written in a special scripting language, developed for Second Life, called LSL. This script code is compiled into a machine format, called LSL bytecode. Each simulator (sim) that runs the Second Life world has a "virtual machine" that runs LSL bytecode. When you rez an item or attachment containing a script, the sim obtains the bytecode for the script, and the sim's virtual machine runs it. Mono is an open-sourced virtual machine. For this project we have deployed the Mono virtual machine alongside the LSL virtual machine in each simulator. We also made a special compiler that can take LSL code and turn it into the Mono bytecode. For the technical details of how to compile a script to Mono, see [[Mono information for scripters]]. If you're just interested in using Mono scripts that you buy, it's much easier -- in fact, there's absolutely nothing you need to do! When you rez any scripted object now, the simulator will check to see whether the script is ordinary LSL or LSL-for-Mono. It will automatically send the appropriate bytecode to the correct virtual machine. | ||
==Mono's importance== | ==Mono's importance== | ||
With the option to compile ordinary LSL into Mono bytecode and run it in our simulators, both programmers and other Residents get some immediate benefits in speed, security, and flexibility. | With the option to compile ordinary LSL into Mono bytecode and run it in our simulators, both programmers and other Residents get some immediate benefits in speed, security, and flexibility. | ||
===Speed=== | ===Speed=== | ||
In general, the Mono virtual machine runs scripts much faster than the LSL one does. | In general, the Mono virtual machine runs scripts much faster than the LSL one does. | ||
* For complicated scripts that do a lot of calculation, Mono speeds things up about a hundred times. | * For complicated scripts that do a lot of calculation, Mono speeds things up about a hundred times. | ||
* For simple, small scripts, the speed difference may not be noticeable, but Mono still produces benefits by introducing better memory management. With LSL, even the smallest script takes up the maximum amount of memory on the simulator; with Mono, scripts only use as much memory as they need. | * For simple, small scripts, the speed difference may not be noticeable, but Mono still produces benefits by introducing better memory management. With LSL, even the smallest script takes up the maximum amount of memory on the simulator; with Mono, scripts only use as much memory as they need. | ||
===Security=== | ===Security=== | ||
Mono also increases security. With Mono's server-side compilation, we can ensure that the simulator only runs scripts it has compiled -- bytecode upload hacks are blocked. | Mono also increases security. With Mono's server-side compilation, we can ensure that the simulator only runs scripts it has compiled -- bytecode upload hacks are blocked. | ||
===Flexibility=== | ===Flexibility=== | ||
For the future, Mono is the first step toward enabling scripting in Second Life with languages other than LSL. Mono is a general purpose virtual machine, and open-source compilers exist to turn code in other computer languages like C# and Python into Mono bytecode. This will shorten the learning curve for scripting SL, since programmers likely already know one of these mainstream languages before coming to Second Life. | For the future, Mono is the first step toward enabling scripting in Second Life with languages other than LSL. Mono is a general purpose virtual machine, and open-source compilers exist to turn code in other computer languages like C# and Python into Mono bytecode. This will shorten the learning curve for scripting SL, since programmers likely already know one of these mainstream languages before coming to Second Life. | ||
==How to use Mono== | ==How to use Mono== | ||
Mono scripts are no different from the ones you use today. When you rez or wear an item from your inventory, any scripts it contains (whether Mono or not) are automatically run. So if you purchase an item that has been scripted with Mono, you'll just use it like any other item. Another way to use Mono is to check with the creators of your favorite scripted objects. They may have Mono versions available for the objects you already own. They may offer a free upgrade to Mono, or they may charge extra for Mono versions. | Mono scripts are no different from the ones you use today. When you rez or wear an item from your inventory, any scripts it contains (whether Mono or not) are automatically run. So if you purchase an item that has been scripted with Mono, you'll just use it like any other item. Another way to use Mono is to check with the creators of your favorite scripted objects. They may have Mono versions available for the objects you already own. They may offer a free upgrade to Mono, or they may charge extra for Mono versions. | ||
===Converting your own scripts to Mono=== | ===Converting your own scripts to Mono=== | ||
If you want to convert your own scripts to run under Mono, that's easily done. You can convert any script for which you have modify permission to and from Mono. | If you want to convert your own scripts to run under Mono, that's easily done. You can convert any script for which you have modify permission to and from Mono. | ||
{{KBnote| The script must be put in an object so that it can be edited and compiled.}} | |||
{{KBnote| | |||
}} | |||
# Rez the object that contains the script. | # Rez the object that contains the script. | ||
Line 66: | Line 43: | ||
# Select the '''Mono''' checkbox and click '''Save'''. | # Select the '''Mono''' checkbox and click '''Save'''. | ||
{{KBnote| Although the two compilers are compatible, timing differences between LSL and Mono may lead to different behavior. When you convert a script to Mono, you should test it to ensure that it still works as expected. If you find that the script no longer behaves as desired, you can edit the script, or you can uncheck the '''Mono''' box and click '''Save''' again. This will make the script go back to being standard LSL.}} | |||
{{KBnote| | |||
}} | |||
==Frequently Asked Questions== | ==Frequently Asked Questions== | ||
The following are some frequently asked questions about Mono. | The following are some frequently asked questions about Mono. | ||
===Does Mono help reduce lag, or does it create more?=== | ===Does Mono help reduce lag, or does it create more?=== | ||
Mono executes much faster than LSL, especially for math-intensive scripts. This can translate into more simulator cycles available for other scripts or physics simulation, and that means less server-side lag. Also, Mono's dynamic memory management only allocates the amount of memory needed for the script (LSL used to allocate the maximum allotment of memory even for the smallest script). This benefit is largely offset, however, by the fact that Mono scripts tend to be larger than the corresponding LSL bytecode. Ultimately, any benefits from Mono in speed or memory will only be realized as the scripts in a Region are converted to run Mono. Initially, and perhaps for a while after Mono launches, most scripts in a Region will still be running old-style LSL bytecode, so it's likely no major differences will be seen at first. | Mono executes much faster than LSL, especially for math-intensive scripts. This can translate into more simulator cycles available for other scripts or physics simulation, and that means less server-side lag. Also, Mono's dynamic memory management only allocates the amount of memory needed for the script (LSL used to allocate the maximum allotment of memory even for the smallest script). This benefit is largely offset, however, by the fact that Mono scripts tend to be larger than the corresponding LSL bytecode. Ultimately, any benefits from Mono in speed or memory will only be realized as the scripts in a Region are converted to run Mono. Initially, and perhaps for a while after Mono launches, most scripts in a Region will still be running old-style LSL bytecode, so it's likely no major differences will be seen at first. | ||
===How can I tell if a script I bought is Mono or regular LSL?=== | ===How can I tell if a script I bought is Mono or regular LSL?=== | ||
If you have modify rights to a script you can determine whether it is Mono or regular LSL by doing the following: | If you have modify rights to a script you can determine whether it is Mono or regular LSL by doing the following: | ||
# Rez the object that contains the script. | # Rez the object that contains the script. | ||
Line 97: | Line 61: | ||
# In the '''Contents''' tab, double-click on the script. The Script window opens. At the bottom of the Script window is a checkbox labeled '''Mono'''. | # In the '''Contents''' tab, double-click on the script. The Script window opens. At the bottom of the Script window is a checkbox labeled '''Mono'''. | ||
The '''Mono''' box will be checked if the script is compiled to Mono, unchecked if regular LSL. | |||
{{KBnote| You need modify rights to the script itself to be able to open it in the editor. Having modify rights to the prim in which the script is contained won't be sufficient.}} | |||
{{KBnote| | |||
}} | |||
==='''What if I don't have modify rights to a script I bought? How can I tell if it is Mono or LSL?'''=== | ==='''What if I don't have modify rights to a script I bought? How can I tell if it is Mono or LSL?'''=== | ||
We didn't implement any way to determine the runtime of a no-modify script, because we made an optimistic guess that soon after Mono launched, ''all'' the new scripts everyone bought would run Mono. We figured that there would be little reason for scripters to continue to use regular LSL when with just a click of a checkbox they could get -- completely free -- Mono's advantages in speed and memory management. | We didn't implement any way to determine the runtime of a no-modify script, because we made an optimistic guess that soon after Mono launched, ''all'' the new scripts everyone bought would run Mono. We figured that there would be little reason for scripters to continue to use regular LSL when with just a click of a checkbox they could get -- completely free -- Mono's advantages in speed and memory management. | ||
===Does this mean that you're going to turn off regular LSL at some point?=== | ===Does this mean that you're going to turn off regular LSL at some point?=== | ||
We have no plans to ever turn off the LSL virtual machine itself. It's easy to maintain, and there are good reasons for keeping it running. A few examples: | We have no plans to ever turn off the LSL virtual machine itself. It's easy to maintain, and there are good reasons for keeping it running. A few examples: | ||
* Many old scripts that are currently running all across the grid are no-modify, and the creators of those scripts may not even be in Second Life anymore; no one would be around to ever convert them. | * Many old scripts that are currently running all across the grid are no-modify, and the creators of those scripts may not even be in Second Life anymore; no one would be around to ever convert them. | ||
* There are some scripts running in the Second Life world today for which we no longer have the corresponding actual code (the text asset was somehow lost or deleted), but whose LSL bytecode still exists. In this case, the script will continue to run whenever it is rezzed. | * There are some scripts running in the Second Life world today for which we no longer have the corresponding actual code (the text asset was somehow lost or deleted), but whose LSL bytecode still exists. In this case, the script will continue to run whenever it is rezzed. | ||
These examples can never be converted to Mono, so we will keep running the LSL virtual machine to support them. We may, however, at some point decide to turn off the LSL ''compiler''. This would mean that all new and edited scripts will only compile to Mono bytecode -- insuring that we are only making Mono scripts in the future. | These examples can never be converted to Mono, so we will keep running the LSL virtual machine to support them. We may, however, at some point decide to turn off the LSL ''compiler''. This would mean that all new and edited scripts will only compile to Mono bytecode -- insuring that we are only making Mono scripts in the future. | ||
==Further resources and reading== | ==Further resources and reading== | ||
*[[Mono information for scripters]] | |||
*[[Mono]] | |||
[[Category:Content creation]] | |||
[[Category:Scripting]] | |||
[[Category: | |||
[[Category: |
Latest revision as of 23:43, 2 August 2011
What is Mono?
Mono for Second Life® is a new way of running LSL (Linden Scripting Language) scripts inworld. In addition to being considerably faster than the original script engine, Mono offers better memory management and security. It also opens the door for eventual scripting in the Second Life virtual world with other programming languages besides LSL.
How Mono works
Currently all Second Life scripts are written in a special scripting language, developed for Second Life, called LSL. This script code is compiled into a machine format, called LSL bytecode. Each simulator (sim) that runs the Second Life world has a "virtual machine" that runs LSL bytecode. When you rez an item or attachment containing a script, the sim obtains the bytecode for the script, and the sim's virtual machine runs it. Mono is an open-sourced virtual machine. For this project we have deployed the Mono virtual machine alongside the LSL virtual machine in each simulator. We also made a special compiler that can take LSL code and turn it into the Mono bytecode. For the technical details of how to compile a script to Mono, see Mono information for scripters. If you're just interested in using Mono scripts that you buy, it's much easier -- in fact, there's absolutely nothing you need to do! When you rez any scripted object now, the simulator will check to see whether the script is ordinary LSL or LSL-for-Mono. It will automatically send the appropriate bytecode to the correct virtual machine.
Mono's importance
With the option to compile ordinary LSL into Mono bytecode and run it in our simulators, both programmers and other Residents get some immediate benefits in speed, security, and flexibility.
Speed
In general, the Mono virtual machine runs scripts much faster than the LSL one does.
- For complicated scripts that do a lot of calculation, Mono speeds things up about a hundred times.
- For simple, small scripts, the speed difference may not be noticeable, but Mono still produces benefits by introducing better memory management. With LSL, even the smallest script takes up the maximum amount of memory on the simulator; with Mono, scripts only use as much memory as they need.
Security
Mono also increases security. With Mono's server-side compilation, we can ensure that the simulator only runs scripts it has compiled -- bytecode upload hacks are blocked.
Flexibility
For the future, Mono is the first step toward enabling scripting in Second Life with languages other than LSL. Mono is a general purpose virtual machine, and open-source compilers exist to turn code in other computer languages like C# and Python into Mono bytecode. This will shorten the learning curve for scripting SL, since programmers likely already know one of these mainstream languages before coming to Second Life.
How to use Mono
Mono scripts are no different from the ones you use today. When you rez or wear an item from your inventory, any scripts it contains (whether Mono or not) are automatically run. So if you purchase an item that has been scripted with Mono, you'll just use it like any other item. Another way to use Mono is to check with the creators of your favorite scripted objects. They may have Mono versions available for the objects you already own. They may offer a free upgrade to Mono, or they may charge extra for Mono versions.
Converting your own scripts to Mono
If you want to convert your own scripts to run under Mono, that's easily done. You can convert any script for which you have modify permission to and from Mono.
![]() |
Note: The script must be put in an object so that it can be edited and compiled. |
- Rez the object that contains the script.
- Right-click the object and select Edit. The Tools window opens.
- In the Contents tab, double-click on the script. The Script window opens. At the bottom of the Script window is a checkbox labeled Mono.
- Select the Mono checkbox and click Save.
![]() |
Note: Although the two compilers are compatible, timing differences between LSL and Mono may lead to different behavior. When you convert a script to Mono, you should test it to ensure that it still works as expected. If you find that the script no longer behaves as desired, you can edit the script, or you can uncheck the Mono box and click Save again. This will make the script go back to being standard LSL. |
Frequently Asked Questions
The following are some frequently asked questions about Mono.
Does Mono help reduce lag, or does it create more?
Mono executes much faster than LSL, especially for math-intensive scripts. This can translate into more simulator cycles available for other scripts or physics simulation, and that means less server-side lag. Also, Mono's dynamic memory management only allocates the amount of memory needed for the script (LSL used to allocate the maximum allotment of memory even for the smallest script). This benefit is largely offset, however, by the fact that Mono scripts tend to be larger than the corresponding LSL bytecode. Ultimately, any benefits from Mono in speed or memory will only be realized as the scripts in a Region are converted to run Mono. Initially, and perhaps for a while after Mono launches, most scripts in a Region will still be running old-style LSL bytecode, so it's likely no major differences will be seen at first.
How can I tell if a script I bought is Mono or regular LSL?
If you have modify rights to a script you can determine whether it is Mono or regular LSL by doing the following:
- Rez the object that contains the script.
- Right-click the object and select Edit. The Tools window opens.
- In the Contents tab, double-click on the script. The Script window opens. At the bottom of the Script window is a checkbox labeled Mono.
The Mono box will be checked if the script is compiled to Mono, unchecked if regular LSL.
![]() |
Note: You need modify rights to the script itself to be able to open it in the editor. Having modify rights to the prim in which the script is contained won't be sufficient. |
What if I don't have modify rights to a script I bought? How can I tell if it is Mono or LSL?
We didn't implement any way to determine the runtime of a no-modify script, because we made an optimistic guess that soon after Mono launched, all the new scripts everyone bought would run Mono. We figured that there would be little reason for scripters to continue to use regular LSL when with just a click of a checkbox they could get -- completely free -- Mono's advantages in speed and memory management.
Does this mean that you're going to turn off regular LSL at some point?
We have no plans to ever turn off the LSL virtual machine itself. It's easy to maintain, and there are good reasons for keeping it running. A few examples:
- Many old scripts that are currently running all across the grid are no-modify, and the creators of those scripts may not even be in Second Life anymore; no one would be around to ever convert them.
- There are some scripts running in the Second Life world today for which we no longer have the corresponding actual code (the text asset was somehow lost or deleted), but whose LSL bytecode still exists. In this case, the script will continue to run whenever it is rezzed.
These examples can never be converted to Mono, so we will keep running the LSL virtual machine to support them. We may, however, at some point decide to turn off the LSL compiler. This would mean that all new and edited scripts will only compile to Mono bytecode -- insuring that we are only making Mono scripts in the future.