OpenSimulator - User contributions [en]

Money

2011-09-14T23:35:12Z

Karen Palen: /* Protect Yourself */ emphasis

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

'''But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business''' and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Consumer Protections ===

There are all kinds of laws in every jurisdiction concerning protection of "Consumers" from all kinds of legal hazards and scams. The basic idea is to protect the legendary "widows and orphans" from evil criminals who are intent on stealing their meagre pensions.

NONE ('''NONE!''') of the "Consumer Protection" laws apply the '''instant you accept money''' (or "value") in a "business" transaction! You are no longer a "Consumer".

Your "Home-owners" insurance no longer applies, your auto insurance is voided, and in they eyes of many you are now merely a "RICH evil capitalist" (all for selling a US$1 virtual hat online!)

I exaggerate only for emphasis - and not very much!

=== Protect Yourself ===

It should not be a surprise that you are not the first to have this problem :-) and there are ways to "minimise" the risks and hazards. All the same '''NEVER''' forget that it is a different world!

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Mr. Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

'''ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything you would ever own!
'''

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T23:31:23Z

Karen Palen: /* Are you running a "business"? */ add emphasis

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

'''But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business''' and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Consumer Protections ===

There are all kinds of laws in every jurisdiction concerning protection of "Consumers" from all kinds of legal hazards and scams. The basic idea is to protect the legendary "widows and orphans" from evil criminals who are intent on stealing their meagre pensions.

NONE ('''NONE!''') of the "Consumer Protection" laws apply the '''instant you accept money''' (or "value") in a "business" transaction! You are no longer a "Consumer".

Your "Home-owners" insurance no longer applies, your auto insurance is voided, and in they eyes of many you are now merely a "RICH evil capitalist" (all for selling a US$1 virtual hat online!)

I exaggerate only for emphasis - and not very much!

=== Protect Yourself ===

It should not be a surprise that you are not the first to have this problem :-) and there are ways to "minimise" the risks and hazards. All the same '''NEVER''' forget that it is a different world!

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Mr. Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T23:13:47Z

Karen Palen: /* Protect Yourself */ typo (yes I know I can't type so sue me ...)

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Consumer Protections ===

There are all kinds of laws in every jurisdiction concerning protection of "Consumers" from all kinds of legal hazards and scams. The basic idea is to protect the legendary "widows and orphans" from evil criminals who are intent on stealing their meagre pensions.

NONE ('''NONE!''') of the "Consumer Protection" laws apply the '''instant you accept money''' (or "value") in a "business" transaction! You are no longer a "Consumer".

Your "Home-owners" insurance no longer applies, your auto insurance is voided, and in they eyes of many you are now merely a "RICH evil capitalist" (all for selling a US$1 virtual hat online!)

I exaggerate only for emphasis - and not very much!

=== Protect Yourself ===

It should not be a surprise that you are not the first to have this problem :-) and there are ways to "minimise" the risks and hazards. All the same '''NEVER''' forget that it is a different world!

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Mr. Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T23:12:41Z

Karen Palen: /* Consumer Protections */

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Consumer Protections ===

There are all kinds of laws in every jurisdiction concerning protection of "Consumers" from all kinds of legal hazards and scams. The basic idea is to protect the legendary "widows and orphans" from evil criminals who are intent on stealing their meagre pensions.

NONE ('''NONE!''') of the "Consumer Protection" laws apply the '''instant you accept money''' (or "value") in a "business" transaction! You are no longer a "Consumer".

Your "Home-owners" insurance no longer applies, your auto insurance is voided, and in they eyes of many you are now merely a "RICH evil capitalist" (all for selling a US$1 virtual hat online!)

I exaggerate only for emphasis - and not very much!

=== Protect Yourself ===

It should not be a surprise that you are not the first to have this problem :-) and there are ways to "minimise" the risks and hazards. All the same '''NEVER''' forget that it is a different world!

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T23:11:26Z

Karen Palen: /* Consumer Protections */

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Consumer Protections ===

There are all kinds of laws in every jurisdiction concerning protection of "Consumers" from all kinds of legal hazards and scams. The basic idea is to protect the legendary "widows and orphans" from evil criminals who are intent on stealing their meagre pensions. I exaggerate only a little!

NONE ('''NONE!''') of the "Consumer Protection" laws apply the '''instant you accept money''' (or "value") in a "business" transaction! You are no longer a "Consumer".

Your "Home-owners" insurance no longer applies, your auto insurance is voided, and in they eyes of many you are now merely a "RICH evil capitalist" (all for selling a US$1 virtual hat online!)

=== Protect Yourself ===

It should not be a surprise that you are not the first to have this problem :-) and there are ways to "minimise" the risks and hazards. All the same '''NEVER''' forget that it is a different world!

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T23:10:38Z

Karen Palen: /* Are you running a "business"? */ add Consumer Protection comments

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Consumer Protections ===

There are all kinds of laws in every jurisdiction concerning protection of "Consumers" from all kinds of legal hazards and scams. The basic idea is to protect the legendary "widows and orphans" from evil criminals who are intent on stealing their meagre pensions. I exaggerate only a little!

NONE ('''NONE!''') of the "Consumer Protection" laws apply the '''instant you accept money''' (or "value") in a "business" transaction! You are no longer a "Consumer".

Your "Home-owners" insurance no longer applies, and in they eyes of many you are now merely a "RICH evil capitalist" (all for selling a US$1 virtual hat online!)

=== Protect Yourself ===

It should not be a surprise that you are not the first to have this problem :-) and there are ways to "minimise" the risks and hazards. All the same '''NEVER''' forget that it is a different world!

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T17:28:50Z

Karen Palen: /* Are you running a "business"? */ typo

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and your local city/town government offices will have all kinds of information.

=== Protect Yourself ===

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Mr. Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T17:27:47Z

Karen Palen: /* A Different Idea */ fix typo

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and you local city/town government offices will have all kinds of information.

=== Protect Yourself ===

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Dividend'''

The OpenSim project should have a currency that pays a dividend. If users earn a dividend just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a dividend will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a dividend would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a dividend. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

The Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Money

2011-09-14T17:23:24Z

Karen Palen: /* OpenSim, Applications and Money */ add comments on setting up a "business"

__NOTOC__
{{Quicklinks}}
 

{{proposal}}
This page is intended as an open discussion board for ideas regarding an in-world financial system - Ezekiel.

== OpenSim, Applications and Money ==
The OpenSim project does not consider providing any kind of functioning monetary system within its scope. Doing so is entirely up to the service provider, as that provider has to be the source of the trust associated with monetary transactions.

The OpenSim platform will provide whatever protocol hooks necessary to implement a monetary system, and reference implementations for demonstration purposes, but not actual implementations of functioning monetary systems. It is essential to understand this when discussing what OpenSim can do with respect to monetary systems.

== Are you running a "business"? ==

The answer is simple: '''If you accept "real world" money or "something of value" IN ANY WAY for doing something then you are operating a business'''!

The fact that everything is "virtual" and it is all run from a computer in your bedroom makes no difference.

A simple standalone grid which you pay for yourself and run out of your home is likely a "hobby" not a business (but there are exceptions), even if you have hundreds of visitors every day.

Your grid may or may not be a business (depending on local law) if it is run ONLY by donations.

But if you rent "virtual land", charge for uploads, or sell "cute hats" in world then you ARE running a business and a whole new set of rules and laws apply! The details differ everywhere, but that distinction is universal.

In addition there are all kinds of licenses, safety laws, taxes, and often other requirements that apply to ALL businesses.

You need to research this before you start. This is not as hard as it sounds, the local Chamber of Commerce and you local city/town government offices will have all kinds of information.

=== Protect Yourself ===

If you are planning on something that deals in real life transactions IN ANY WAY, then look into setting up a business entity (Corporation, LLC, or whatever) to run it.

See http://www.keytlaw.com/ for "Information & Articles about Arizona and United States Law"

Keyt is an Arizona/US lawyer, but the issues he raises are universal. I highly recommend studying his website and especially his section on Internet Law.

As Keyt says in one of his articles, the day the process server knocks on your door is one day too late!

ONE disgruntled user who lost real life money (or "value") to a crook on your sim can cost you everything you own and everything will ever own!

== Motivation ==
In order to be successful, any new world simulator needs to allow for financial transactions. While many residents enjoy the creative and social aspects of virtual life, others are there to provide them with the necessary means - and usually intend to be compensated.
Metaverses without a business component (allowing residents to make money) depend largely on the creativity of the makers and tend to fall into disuse as soon as competitive simulators with better graphics and better entertainment come along (e.g. Active Worlds).

== Play Money vs. Serious Money ==
There are two types of financial systems and currencies: one is purely an in-world affair (play money) and supports roleplay, the other is convertible into hard currencies (serious money).
While it is commonly agreed that implementing a serious in-world currency system (with all the security implications) is out of scope at least for the current phase of the OpenSim development project, there are still some functional decisions to be made.

There are several possible ways of handling money in a grid:
* no money support
* in-world play money for roleplay
* in-world currency supported, protected and converted by the grid owner (like SL)
* off-world payment implementation, no in-world currency
* in-world play money plus off-world payment capabilities (might be confusing)

OpenSim should allow for an implementation of any of those alternatives.

== Off-World Implementation ==
These are crucial in-world functions for off-world financial transactions:
* put a price tag on a prim, specifying amount and currency
* notification event (LSL) that resident X agrees to buy item / pay amount Y.

These functions are not crucial, since they may be implemented off-world:
* an in-world currency (use an internet payment provider or an e-currency instead)
* avatar account (use an internet payment provider or an e-currency instead)
* receive payment (can be handled off-world through osLoadURL - for most providers)
* give money (can be handled off-world through osHTTPRequest - for some providers)
* notify avatar of payment (can be done through IM or e-Mail)

== Wallet Plugin ==
It occurs to me that perhaps it isn't the job of the grid to keep track of every avatars financial transactions. Perhaps this should be left to banks and other financial organizations. I'm thinking that perhaps OpenSim should pull the money out of the grid and develop an independent bank server. Avatars could choose which "wallet" or "bank" to use for a transaction.

== A Different Idea ==

'''A Currency that Pays a Divident'''

The OpenSim project should have a currency that pays a divident. If users earn a divident just by using the game currency this will be a great incentive not only to participate in the game but also to use the currency in real life. Thus this increases the possibility that a market of things of value will develop in the game and maybe the currency will be used for real life transactions as well. A currency that pays a divident will prevail over any other form of virtual currency by means of the strategic advantage of directly benefiting the user. Convertibility to real currencies will depend solely on free market ability of the currency to provide goods and services and not some convertibility obligation undertaken by the company that hosts the server.

Implementing a currency that produces a divident would require suitable financial institutions, capital markets, and a mechanism to liquidate a part of current value of financial instruments. Through liquidating a sustainable part of current value of financial instruments the company that hosts the server would earn the game money funds which when converted to real currency would pay for its operational costs plus the funds needed to pay a divident. It would be in the best interest of the company that hosts the server to ensure that the financial structure operates efficiently for the benefit of the users so that the game currency has maximum value of convertibility to real life currencies.

The financial structure required could be as follows:

'''1. Central Bank'''

THe Central Bank would oversee the monetary volume, the amount to be liquidated and the keeping of individual money accounts of users free of charge but free of interest as well.

- All users would be shareholders to the Central Bank, owning no more and no less than one share each

- The monetary volume would be a fixed amount of currency for each share, say 100.000 units, which would be the nominal value of the Central Bank share.

- All financial transactions of users, Investment Banks and Capital Markets would be processed through the Central Bank's server software and console

- The Central Bank will determine how much of Investment Bank's current stock value must be held in liquid reserves

- The Central Bank will determine how much of those liquid reserves will be contributed to the Special Account in order to be distributed to the users as divident and to the company that hosts the server

- The Central Bank will have the power to dispense payments through the Special Account to the company that hosts the server, to shareholders and to in-game political institutions such as elected moderators

- Ideally the Central Bank management would be ellected by users, even better by Invesment Bank managers

- Any increase or decrease in monetary volume would be achieved solely by depositing or withdrawing funds to/from each user's account

'''2. Investment Banks'''

The Investment Banks would be the main user operated financial institution.

- They would be the only financial instrument users would be able to directly buy shares of.

- They would be the only vehicle available for investment in Capital Markets.

- They would be able to structure and trade financial instruments through the Central Bank console

- They would be able to lend money for projects

- Any user or group of users would able to open an Investment Bank through a console provided by the Central Bank if they provide capital equal to say 10 Central Bank Shares worth

- An individual who wants to trade the financial markets with his own money, should come up with enough capital to open an Investment Bank

- Investment Banks would freely be able to raise capital by issuing shares

- Their shares would be floated and traded in a separate market than Capital Markets through the Central Bank console

- They would be under obligation to keep a part of their investment portfolio in cash so the Central Bank can deduct a contribution to the Special Account

- The holdings in their investment portfolio would be open for every interested investor to audit

'''3. Capital markets'''

These would be the Exchanges where financial instruments are traded

- The Central Bank would provide the console for the Exchanges and handle the payments

- Anything of value could be traded on the Exchanges

- The financial instruments would be structured freely by the Investment Banks

- Individual loans would be structured as financial instruments and traded freely

- The coding of financial instruments would be open for everyone to audit

- An Exchange would be a user-managed institution, the user-managers would be able to charge a commision on transactions as compensation for managing the exchange

- The Exchanges would all be interconected, so the most efficient ones get the most business

'''Supporting Environment'''

The financial structure's legitimacy and effectiveness would benefit the most by a functional political proccess within the game and the development of legal and political institutions that would oversee its implementation. In this way the company that hosts the server would have relegated most of the work too the user community. In a maybe utopian scenario the company itself could be owned by the users. A lot of reated economic activity could evolve alongside the main structure such as auditing companies, programmers etc

'''Kickstarting a Project'''

Once the software is implemented as above this could evolve as essentially a game where the collective purpose of the users would be to develop and increase the value of the game currency and spread its use. A group of people willing to kickstart such a project would need to set up a server and a rudimentary mechanism to buy and sell shares to the Central Bank and thus opening user accounts. Integration with a payment system such as Paypal would help. A new user would be able to either:

- use real money to buy enough in-game currency from other users or the central bank as a provider of last resort to purchase his share to the Central Bank and so be entitled to a divident

- or start free and offer services or anything of value in-game so as to accumulate enough in-game currency to buy his share in the Central Bank and then be entitled to a divident

When a new user opens an account and purchases his share to the Central Bank, new in-game money is created up to the value of one Central Bank share. If he buys his share, the money is deposited in his account. If he does not buy a share and starts free the money is deposited to the Special Account for the benefit of all users. In this way the monetary volume is increased as new users come in and all all users benefit from attracting new users. A de facto mechanism for the convertibility of the in-game currency would thus be achieved and setting up a server for the game could prove profitable. Ideally various groups would be able to start different projects but all grids should be interconnected and maybe their currencies floated on a common exchange

== Simplest In-Grid Money ==

A unique avatar creates objects that may not be copied, may not be modified, but may be transferred. The object permission, and asset storage code of OpenSimulator must be very robust and dependable. The names of the objects are something like "1-gazoon," "2-gazoons," "5-gazoons," "10-gazoons," "20-gazoons," etc. Players agree to treat these objects as money and trade them. Making change will be a pain at times. The reason that the unique avatar gives "gazoon" objects to other avatars is left as an exercise for the reader.

== Web Transactions ==

We could also simply use external websites to sell objects in real world money (dollars, euros etc.). With the current advances in the in-world web browser, it shouldn't be too difficult and shouldn't take up too much time. Theres also the advantage of a decrease in fraud and there would no longer be a concern for the rise and dropping of L$ prices. Of course, the website would be the responsibility of the grid-owner. In terms of "fake currency", we would use the current implemented system (the L$ functions) and use it as fake/roleplaying money on a simulator level (meaning that it would be functional in only some sims and the sim owner would have control over the name of the currency and how it is distributed).

== Reference Implementations ==

See [[Feature_Matrix#Other_Simulation_Features]] for various currency options.

Scripting Documentation

2010-09-01T05:05:55Z

Karen Palen: Add troubleshooting reference

__NOTOC__
{{Template:Quicklinks}}

== Overview ==

*[[ScriptEngines|Scripting Engine]] - Xengine Script Engine Transition (By Melanie_T)
*[[Scripting Languages]] - Supported Scripting Languages
*[[LSL_Status|LSL/OSSL Status]] - Status and news about LSL and OSSL
*[[Non-LSL scripting]] - Information on C# and scripting in OpenSim with other languages

==About OpenSim scripting==
An important ingredient in Second Life is scripting. It is the engine that drives it all. In SL [http://wiki.secondlife.com/wiki/LSL_Portal LSL (Linden Scripting Language)] is the language you have to use. This language has its limitations, and is executed very slowly. But nevertheless it works and it gets the job done. 

OpenSim today supports LSL,OSL and C# scripts. But with limitations:
* Not all commands and events have been implemented. See [[LSL Status | LSL/OSSL Status]] for details on what commands work and which don't.
* The OpenSim script engine compiles the LSL code down to .Net code that is JIT'ed to CPU native code. In effect this means that a LSL script in OpenSim should run faster than in Second Life. Stability and security: see [[Script_Sandbox | Script Execution Sandbox]].

==How to use scripts in OpenSim==
Have a look at the [http://wiki.secondlife.com/wiki/LSL_Portal LSL wiki] to learn LSL. The current procedure to get a script working in OpenSim is:
* Create a new script in inventory. (Inventory -> Create -> New Script)
* Write whatever script you want there, or copy the script contents of another script in the pre-existing OpenSim library. Check [[LSL Status]] for what commands that are supported.
* Drag the script over to the contents of an object.
* If there is an error in the script when saving or when dropped into an object an error alert is displayed for a short time. Click on the alert to display the Debug Window and the script error.
* To deactivate a script, edit the script and uncheck 'Running'. This also stops error alerts when saving scripts.
* Deleting the script from the object will not always deactivate a script. If a script is running in a prim and the script is deleted, the script may persist in the prim - which can be useful. Be sure scripts are not running when you wish to delete them.

There are still some defects:
* Line numbers in error messages may miss by 1 or 2 lines.

* Linux/Mac users may need to upgrade the default mono to include "mono-complete" for some scripts. See http://opensimulator.org/mantis/view.php?id=5007 for details.

== How to contribute ==
The ScriptEngine is being developed by many developers. New developers are always welcome. If you want to contribute, even just a tiny little bit, have a look at the [[OpenSim.Region.ScriptEngine]] page. There is a lot of developer activity on IRC ([[Support]]), feel free to drop in.

== Additional Resources for Scripting (LSL)==
There have been many questions regarding scripts and tools for scripting lately. Presented here are a variety of Links to Resources which will help most people with Scripting LSL.

'''OspenSimulator Specific Materials:'''

* [[LSL_Status|LSL/OSSL Status]]

'''NOTE:''' Be sure to check the Discussion Pages which is on the tabs at the top.

'''Suggested Links for LSL wikis:'''

* [http://wiki.secondlife.com/wiki/LSL_Portal wiki.secondlife.com]

* [http://www.lslwiki.net/lslwiki/wakka.php?wakka=HomePage lslwiki.net]

* [http://rpgstats.com/wiki/index.php?title=Main_Page rpgstats.com]

* [http://www.lsleditor.org/ LSLeditor]

* [http://www.cheesefactory.us/slwm/LSL_Portal.html cheesefactory.us]

Note the Tutorials, Examples & Script Libraries

'''Off-World Local LSL Editing Tools (note they do not support osFunctions)'''

''LSL EDITOR''
* [http://sourceforge.net/projects/lsleditor/ LSLeditor SourceForge]
* [http://www.lsleditor.org/ Original Author's website with his latest LSLeditor version]
Now an Open Source project. New release is 17th May 2010 (Ver.2.4). A valuable tool and easy install.

''LSL Plus''
* [http://lslplus.sourceforge.net/ LSLplus]
Open source. Regualar updates. Not quite as quick to get installed as LSLEditor, but very good tool.

Others are listed here: http://wiki.secondlife.com/wiki/LSL_Alternate_Editors

'''Miscelaneous:'''

* [http://www.hilarymason.com/blog/secondlife/autoscript-creates-lsl-scripts-without-code/ AutoScript, Simple & Quick Code generator for simple things (ONLINE)]

* [http://code.google.com/p/lslsnippets/ lslsnippets ]

* [http://www.vtoreality.com/2006/free-offsite-storage-for-lsl-scripts-up-to-250k/186/ Free offsite storage for LSL scripts up to 250k ]

* [http://www.freeslscripts.gendersquare.org/index.php Free SL Scripts (library)]

* [http://s4sl.blogspot.com/ Scratch for SecondLife (Script Code generator with Nice Interface - UPDATED JUL.09.2009)]

* [http://www.peregrinesalon.com/2009/01/05/major-upgrade-to-animated-gif-to-animated-sl-texture-conversion-tool-v04/ Second Life Animated Texture Creator v0.4 - brought to you by Peregrine Salon]

== Additional Resources for Scripting (OSSL)==
There have been many questions regarding scripts and tools for scripting lately. Presented here are a variety of Links to Resources which will help most people with Scripting OSSL.
* [[OSSL_Implemented | OSSL Functions with examples]]

[[Category:Development]]
[[Category:Users]]
[[Category:Scripting]]

Performance

2010-08-27T07:22:54Z

Karen Palen: Add comment on home users

{{Template:Quicklinks}}

=Introduction=

OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.

==Hardware Requirements==

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. '''These are examples to help you in your selection, not necessarily recommendations.'''

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

{| border="1"
!Description
!Operating System (please add Mono version if appropriate)
!OpenSim version
!RAM/AVG_USE_%
!CPU
!#/type of regions
!# simultaneous avs
!#scripts/timers/Sensors
!Location
!#objectparts
|-
|hosted Xen VPS
|Ubuntu Intrepid (8.10)
|Unknown
|540MB/?
|1x quad-core 2.5GHz Xeon (L5420)
|1 region + 9 voids
|generally 1-2
|few
|Knifejaw Atoll & surrounding on OSGrid
|?
|-
|hosted Xen VPS
|Ubuntu Jaunty (9.04)
|Unknown
|360MB/?
|2x dual-core 2.0GHz Xeon (5130)
|1 void
|generally 1-2
|none
|Knifejaw Road on OSGrid
|?
|-
|Dedicated Server from A+
|Windows Server 2003
|Unknown
|1 Meg
|1x single-core 2.8GHz Celeron
|2regions per server
|6 at once with no issues
|Waterfalls, texture anims, window texture switchers, lots of sound loops
|Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid
|20000 prims per region
|-
|Amazon EC2 "high-CPU medium instance" (Xen VM)
|Windows Server 2003
|Unknown
|1.7GB
|1x dual-core 2.3GHz (Intel E5345)
|1 region with sailing race course
|7 avs, 4 in boats
|scripted start line
|Castle Rock, OSGrid
|
|-
|Dedicated Server from simhost.com
|SuSe 11.2 x64
|Unknown
|8gb / 50%
|4x Core2Quad Q9300 2.6ghz
|1 region (Wright Plaza) uses approx 4gb ram
|20-25 users
|Freebie Stores / Meeting Center / Video Theater
|@osgrid.org Heavy Use Sim
|17500 prims aprox 1500 scripts
|-
|Home machine
|Windows XP SP3
|0.7.0.1 (Diva r13558)
|3GB / 15-40% incl. Opensim and MySQL
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%
|11 regions
|1-6 users
|Many scripted objects (1934 scripts)
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]
|38,065 prims
|-
|Home machine
|Ubuntu Lucid 10.04 (32 bit pae)
|0.7.0.1 (Diva r13558)
|160Mb no users, add 5Mb/user incl Opensim and MySQL
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load
|4 regions (Diva default config)
|1-4 users (approx 20Kb/sec bandwidth/user)
|Few scripted objects (<10)
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]
|158 prims
|}

==Performance studies and blog posts==

These provide some interesting data on the performance limitations of OpenSim at various points in time.

* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue. Physical objects and max avatars are limited by single thread performance in OpenSim.
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]

==Performance hints==

Here are some specific things you might be able to do to improve performance

===Home Based systems===

The most obvious performance difference between a home based cable/dsl system and a "commercial" server is the upload bandwidth. A typical home system allows 100Kb/s upload with 12Mb/s download, a "commercial" system typically has a "symmetrical" bandwidth of say 12Mb/s UP AND DOWN! "Commercial" systems can essentially buy unlimited bandwidth as needed, but it does get expensive to buy bandwidth that you don't need!

In practice this limits the number of "external" users on a "home system" to 4 or 5, but LAN users (NPCs/bots etc.) are essentially unlimited.

A reasonable strategy (i.e. MY strategy) is to use the home system for experimentation and then move the entire sim to a "commercial" VPS service if the sim gets popular (and produces enough $$$ to pay the freight!)

===Running Squid on your region server as a reverse proxy to the asset server===
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/ 
2. Create your [[squid.conf]] configuration file. 
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/ 
4. Start everything up! 

Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.

=== GC_NO_EXPLICIT ===

Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.

$mono-svn-root$/mono
mono/metadata/boehm-gc.c

<pre>
Index: boehm-gc.c
===================================================================
--- boehm-gc.c (revision 105684)
+++ boehm-gc.c (working copy)
@@ -107,6 +107,10 @@
void
mono_gc_collect (int generation)
{
+ static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+ g_print("\n --------GC_NO_EXPLICIT \n");
+ return;
+ }
MONO_PROBE_GC_BEGIN (generation);

GC_gcollect ();
</pre>

Not only this, but I recompile the mono runtime:
<pre>--with-large-heap=yes</pre>

Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:

export GC_NO_EXPLICIT=1
and
unset GC_NO_EXPLICIT

What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.

Performance

2010-08-26T18:31:21Z

Karen Palen: /* Hardware Requirements */

{{Template:Quicklinks}}

=Introduction=

OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.

==Hardware Requirements==

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. '''These are examples to help you in your selection, not necessarily recommendations.'''

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

{| border="1"
!Description
!Operating System (please add Mono version if appropriate)
!OpenSim version
!RAM/AVG_USE_%
!CPU
!#/type of regions
!# simultaneous avs
!#scripts/timers/Sensors
!Location
!#objectparts
|-
|hosted Xen VPS
|Ubuntu Intrepid (8.10)
|Unknown
|540MB/?
|1x quad-core 2.5GHz Xeon (L5420)
|1 region + 9 voids
|generally 1-2
|few
|Knifejaw Atoll & surrounding on OSGrid
|?
|-
|hosted Xen VPS
|Ubuntu Jaunty (9.04)
|Unknown
|360MB/?
|2x dual-core 2.0GHz Xeon (5130)
|1 void
|generally 1-2
|none
|Knifejaw Road on OSGrid
|?
|-
|Dedicated Server from A+
|Windows Server 2003
|Unknown
|1 Meg
|1x single-core 2.8GHz Celeron
|2regions per server
|6 at once with no issues
|Waterfalls, texture anims, window texture switchers, lots of sound loops
|Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid
|20000 prims per region
|-
|Amazon EC2 "high-CPU medium instance" (Xen VM)
|Windows Server 2003
|Unknown
|1.7GB
|1x dual-core 2.3GHz (Intel E5345)
|1 region with sailing race course
|7 avs, 4 in boats
|scripted start line
|Castle Rock, OSGrid
|
|-
|Dedicated Server from simhost.com
|SuSe 11.2 x64
|Unknown
|8gb / 50%
|4x Core2Quad Q9300 2.6ghz
|1 region (Wright Plaza) uses approx 4gb ram
|20-25 users
|Freebie Stores / Meeting Center / Video Theater
|@osgrid.org Heavy Use Sim
|17500 prims aprox 1500 scripts
|-
|Home machine
|Windows XP SP3
|0.7.0.1 (Diva r13558)
|3GB / 15-40% incl. Opensim and MySQL
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%
|11 regions
|1-6 users
|Many scripted objects (1934 scripts)
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]
|38,065 prims
|-
|Home machine
|Ubuntu Lucid 10.04 (32 bit pae)
|0.7.0.1 (Diva r13558)
|160Mb no users, add 5Mb/user incl Opensim and MySQL
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load
|4 regions (Diva default config)
|1-4 users (approx 20Kb/sec bandwidth/user)
|Few scripted objects (<10)
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]
|158 prims
|}

==Performance studies and blog posts==

These provide some interesting data on the performance limitations of OpenSim at various points in time.

* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue. Physical objects and max avatars are limited by single thread performance in OpenSim.
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]

==Performance hints==

Here are some specific things you might be able to do to improve performance

===Running Squid on your region server as a reverse proxy to the asset server===
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/ 
2. Create your [[squid.conf]] configuration file. 
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/ 
4. Start everything up! 

Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.

=== GC_NO_EXPLICIT ===

Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.

$mono-svn-root$/mono
mono/metadata/boehm-gc.c

<pre>
Index: boehm-gc.c
===================================================================
--- boehm-gc.c (revision 105684)
+++ boehm-gc.c (working copy)
@@ -107,6 +107,10 @@
void
mono_gc_collect (int generation)
{
+ static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+ g_print("\n --------GC_NO_EXPLICIT \n");
+ return;
+ }
MONO_PROBE_GC_BEGIN (generation);

GC_gcollect ();
</pre>

Not only this, but I recompile the mono runtime:
<pre>--with-large-heap=yes</pre>

Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:

export GC_NO_EXPLICIT=1
and
unset GC_NO_EXPLICIT

What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.

Performance

2010-08-26T18:23:00Z

Karen Palen: /* Hardware Requirements */

{{Template:Quicklinks}}

=Introduction=

OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.

==Hardware Requirements==

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. '''These are examples to help you in your selection, not necessarily recommendations.'''

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

{| border="1"
!Description
!Operating System (please add Mono version if appropriate)
!OpenSim version
!RAM/AVG_USE_%
!CPU
!#/type of regions
!# simultaneous avs
!#scripts/timers/Sensors
!Location
!#objectparts
|-
|hosted Xen VPS
|Ubuntu Intrepid (8.10)
|Unknown
|540MB/?
|1x quad-core 2.5GHz Xeon (L5420)
|1 region + 9 voids
|generally 1-2
|few
|Knifejaw Atoll & surrounding on OSGrid
|?
|-
|hosted Xen VPS
|Ubuntu Jaunty (9.04)
|Unknown
|360MB/?
|2x dual-core 2.0GHz Xeon (5130)
|1 void
|generally 1-2
|none
|Knifejaw Road on OSGrid
|?
|-
|Dedicated Server from A+
|Windows Server 2003
|Unknown
|1 Meg
|1x single-core 2.8GHz Celeron
|2regions per server
|6 at once with no issues
|Waterfalls, texture anims, window texture switchers, lots of sound loops
|Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid
|20000 prims per region
|-
|Amazon EC2 "high-CPU medium instance" (Xen VM)
|Windows Server 2003
|Unknown
|1.7GB
|1x dual-core 2.3GHz (Intel E5345)
|1 region with sailing race course
|7 avs, 4 in boats
|scripted start line
|Castle Rock, OSGrid
|
|-
|Dedicated Server from simhost.com
|SuSe 11.2 x64
|Unknown
|8gb / 50%
|4x Core2Quad Q9300 2.6ghz
|1 region (Wright Plaza) uses approx 4gb ram
|20-25 users
|Freebie Stores / Meeting Center / Video Theater
|@osgrid.org Heavy Use Sim
|17500 prims aprox 1500 scripts
|-
|Home machine
|Windows XP SP3
|0.7.0.1 (Diva r13558)
|3GB / 15-40% incl. Opensim and MySQL
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%
|11 regions
|1-6 users
|Many scripted objects (1934 scripts)
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]
|38,065 prims
|-
|Home machine
|Ubuntu Lucid 10.04 (32 bit pae)
|0.7.0.1 (Diva r13558)
|160Mb no users, add 5Mb/user incl Opensim and MySQL
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load
|4 regions (Diva default config)
|1-4 users
|Few scripted objects (<10)
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]
|158 prims
|}

==Performance studies and blog posts==

These provide some interesting data on the performance limitations of OpenSim at various points in time.

* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue. Physical objects and max avatars are limited by single thread performance in OpenSim.
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]

==Performance hints==

Here are some specific things you might be able to do to improve performance

===Running Squid on your region server as a reverse proxy to the asset server===
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/ 
2. Create your [[squid.conf]] configuration file. 
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/ 
4. Start everything up! 

Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.

=== GC_NO_EXPLICIT ===

Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.

$mono-svn-root$/mono
mono/metadata/boehm-gc.c

<pre>
Index: boehm-gc.c
===================================================================
--- boehm-gc.c (revision 105684)
+++ boehm-gc.c (working copy)
@@ -107,6 +107,10 @@
void
mono_gc_collect (int generation)
{
+ static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+ g_print("\n --------GC_NO_EXPLICIT \n");
+ return;
+ }
MONO_PROBE_GC_BEGIN (generation);

GC_gcollect ();
</pre>

Not only this, but I recompile the mono runtime:
<pre>--with-large-heap=yes</pre>

Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:

export GC_NO_EXPLICIT=1
and
unset GC_NO_EXPLICIT

What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.

Performance

2010-08-26T18:21:39Z

Karen Palen: /* Hardware Requirements */

{{Template:Quicklinks}}

=Introduction=

OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.

==Hardware Requirements==

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. '''These are examples to help you in your selection, not necessarily recommendations.'''

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

{| border="1"
!Description
!Operating System (please add Mono version if appropriate)
!OpenSim version
!RAM/AVG_USE_%
!CPU
!#/type of regions
!# simultaneous avs
!#scripts/timers/Sensors
!Location
!#objectparts
|-
|hosted Xen VPS
|Ubuntu Intrepid (8.10)
|Unknown
|540MB/?
|1x quad-core 2.5GHz Xeon (L5420)
|1 region + 9 voids
|generally 1-2
|few
|Knifejaw Atoll & surrounding on OSGrid
|?
|-
|hosted Xen VPS
|Ubuntu Jaunty (9.04)
|Unknown
|360MB/?
|2x dual-core 2.0GHz Xeon (5130)
|1 void
|generally 1-2
|none
|Knifejaw Road on OSGrid
|?
|-
|Dedicated Server from A+
|Windows Server 2003
|Unknown
|1 Meg
|1x single-core 2.8GHz Celeron
|2regions per server
|6 at once with no issues
|Waterfalls, texture anims, window texture switchers, lots of sound loops
|Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid
|20000 prims per region
|-
|Amazon EC2 "high-CPU medium instance" (Xen VM)
|Windows Server 2003
|Unknown
|1.7GB
|1x dual-core 2.3GHz (Intel E5345)
|1 region with sailing race course
|7 avs, 4 in boats
|scripted start line
|Castle Rock, OSGrid
|
|-
|Dedicated Server from simhost.com
|SuSe 11.2 x64
|Unknown
|8gb / 50%
|4x Core2Quad Q9300 2.6ghz
|1 region (Wright Plaza) uses approx 4gb ram
|20-25 users
|Freebie Stores / Meeting Center / Video Theater
|@osgrid.org Heavy Use Sim
|17500 prims aprox 1500 scripts
|-
|Home machine
|Windows XP SP3
|0.7.0.1 (Diva r13558)
|3GB / 15-40% incl. Opensim and MySQL
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%
|11 regions
|1-6 users
|Many scripted objects (1934 scripts)
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]
|38,065 prims
|-
|Home machine
|Ubuntu 10.04 Lucid pae
|0.7.0.1 (Diva r13558)
|160Mb no users, add 5Mb/user incl Opensim and MySQL
|I7-920 (dual threaded quad core), 3.8Ghz, 6Gb RAM, 0-10% Load
|4 regions (Diva default config)
|1-4 users
|Few scripted objects (<10)
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]
|158 prims
|}

==Performance studies and blog posts==

These provide some interesting data on the performance limitations of OpenSim at various points in time.

* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue. Physical objects and max avatars are limited by single thread performance in OpenSim.
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]

==Performance hints==

Here are some specific things you might be able to do to improve performance

===Running Squid on your region server as a reverse proxy to the asset server===
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/ 
2. Create your [[squid.conf]] configuration file. 
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/ 
4. Start everything up! 

Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.

=== GC_NO_EXPLICIT ===

Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.

$mono-svn-root$/mono
mono/metadata/boehm-gc.c

<pre>
Index: boehm-gc.c
===================================================================
--- boehm-gc.c (revision 105684)
+++ boehm-gc.c (working copy)
@@ -107,6 +107,10 @@
void
mono_gc_collect (int generation)
{
+ static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+ g_print("\n --------GC_NO_EXPLICIT \n");
+ return;
+ }
MONO_PROBE_GC_BEGIN (generation);

GC_gcollect ();
</pre>

Not only this, but I recompile the mono runtime:
<pre>--with-large-heap=yes</pre>

Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:

export GC_NO_EXPLICIT=1
and
unset GC_NO_EXPLICIT

What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.

Performance

2010-08-26T18:19:58Z

Karen Palen: Add small sim data point for Mars Simulation

{{Template:Quicklinks}}

=Introduction=

OpenSim performance is a very complex issue. Performance can be affected by any number of things, including the number of prims on a region, number of regions, number of avatars, network quality between server and viewer, network quality between simulator and grid services, etc.

==Hardware Requirements==

Unfortunately, this is a very difficult question in light of all the factors mentioned above. Below are some examples of hardware people use/have used. Please feel free to add to the list, or to add any reports to the performance studies and blog posts section. '''These are examples to help you in your selection, not necessarily recommendations.'''

Object Parts ~= # prim

Sensors and Timers are generally more intensive then regular scripts, so please specify quantity of each.

{| border="1"
!Description
!Operating System (please add Mono version if appropriate)
!OpenSim version
!RAM/AVG_USE_%
!CPU
!#/type of regions
!# simultaneous avs
!#scripts/timers/Sensors
!Location
!#objectparts
|-
|hosted Xen VPS
|Ubuntu Intrepid (8.10)
|Unknown
|540MB/?
|1x quad-core 2.5GHz Xeon (L5420)
|1 region + 9 voids
|generally 1-2
|few
|Knifejaw Atoll & surrounding on OSGrid
|?
|-
|hosted Xen VPS
|Ubuntu Jaunty (9.04)
|Unknown
|360MB/?
|2x dual-core 2.0GHz Xeon (5130)
|1 void
|generally 1-2
|none
|Knifejaw Road on OSGrid
|?
|-
|Dedicated Server from A+
|Windows Server 2003
|Unknown
|1 Meg
|1x single-core 2.8GHz Celeron
|2regions per server
|6 at once with no issues
|Waterfalls, texture anims, window texture switchers, lots of sound loops
|Pleasure Planet Welcome center & Region Pleasure Planet in OSGrid
|20000 prims per region
|-
|Amazon EC2 "high-CPU medium instance" (Xen VM)
|Windows Server 2003
|Unknown
|1.7GB
|1x dual-core 2.3GHz (Intel E5345)
|1 region with sailing race course
|7 avs, 4 in boats
|scripted start line
|Castle Rock, OSGrid
|
|-
|Dedicated Server from simhost.com
|SuSe 11.2 x64
|Unknown
|8gb / 50%
|4x Core2Quad Q9300 2.6ghz
|1 region (Wright Plaza) uses approx 4gb ram
|20-25 users
|Freebie Stores / Meeting Center / Video Theater
|@osgrid.org Heavy Use Sim
|17500 prims aprox 1500 scripts
|-
|Home machine
|Windows XP SP3
|0.7.0.1 (Diva r13558)
|3GB / 15-40% incl. Opensim and MySQL
|4x Core2Quad Q6600 2.4 GHz. Use: generally, 0-10%
|11 regions
|1-6 users
|Many scripted objects (1934 scripts)
|[http://zonjacapalini.wordpress.com/2010/08/25/condensation-land-a-status-report/ Condensation Land]
|38,065 prims
|-
|Home machine
|Ubuntu 10.04 Lucid pae
|0.7.0.1 (Diva r13558)
|160Mb no users, add 5Mb/user incl Opensim and MySQL
|I7-920, 3.8Ghz, 6Gb RAM, 0-10% Load
|4 regions (Diva default config)
|1-4 users
|Few scripted objects (<10)
|[http://mars-simulator.hobby-site.org:9000/wifi Mars Simulation]- Based on [http://metatek.blogspot.com/2010/06/mars-simulation-for-distribution.html Erik Nauman's Open Blackboard]
|158 prims
|}

==Performance studies and blog posts==

These provide some interesting data on the performance limitations of OpenSim at various points in time.

* [https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html https://lists.berlios.de/pipermail/opensim-users/2010-August/005189.html] - Some interesting information from Mr Blue. Physical objects and max avatars are limited by single thread performance in OpenSim.
* [http://www.sciencesim.com/wiki/doku.php/vwperf/start http://www.sciencesim.com/wiki/doku.php/vwperf/start] - Links to ScienceSim performance studies, including some very recent ones.
* [[Improving Performance]] - An old page from July 2009 detailing some performance issues on OpenSim. Some of these issues are still valid (e.g. ODE issues).
* [[NHibernate Performance Testing]] — SQLite and MySQL performance tests with NHibernate.
* [[LibSecondLife performance problems]] - Another old page from November 2007 detailing issues with libsecondlife (now called libopenmetaverse).
* [http://opensim.cybertechnews.org/?p=71 Experiences from Operating a 3D Region Server in OSGrid - Part 1]
* [http://opensim.cybertechnews.org/?p=104 Experiences from Operating a 3D Region Server in OSGrid - Part 2]

==Performance hints==

Here are some specific things you might be able to do to improve performance

===Running Squid on your region server as a reverse proxy to the asset server===
1. Download and install the Squid Proxy from: http://www.squid-cache.org/Download/ 
2. Create your [[squid.conf]] configuration file. 
3. Change your asset_server configuration in your OpenSim.ini to point to http://localhost:3128/ 
4. Start everything up! 

Now assets will be cached in the squid cache on the region server, and will be served up much faster, especially on region restart.

=== GC_NO_EXPLICIT ===

Sometimes this patch applied to mono-svn has helped my sim run a lot faster and not slowly get bogged down.

$mono-svn-root$/mono
mono/metadata/boehm-gc.c

<pre>
Index: boehm-gc.c
===================================================================
--- boehm-gc.c (revision 105684)
+++ boehm-gc.c (working copy)
@@ -107,6 +107,10 @@
void
mono_gc_collect (int generation)
{
+ static int no_explicite_gc = 0; if (no_explicite_gc==0) {if (getenv("GC_NO_EXPLICIT")) {no_explicite_gc = 1;return;} else {no_explicite_gc = 2;}} else if (no_explicite_gc==1) {
+ g_print("\n --------GC_NO_EXPLICIT \n");
+ return;
+ }
MONO_PROBE_GC_BEGIN (generation);

GC_gcollect ();
</pre>

Not only this, but I recompile the mono runtime:
<pre>--with-large-heap=yes</pre>

Otherwise, the Sim is limited to 3GB RAM. Probably, this second peice is more important. But still, afterwards it's worth a shot to test with both to see if there is a difference in performance:

export GC_NO_EXPLICIT=1
and
unset GC_NO_EXPLICIT

What I think, (only a guess) is that Mono starts internally GC thrashing in fishing expeditions to gaining maybe 1k of RAM at time. And by having a large heap (>3GB), it is possible might keep mono less apt to do stop world complete collections as often.

Installing and Running Hypergrid

2010-08-19T04:40:04Z

Karen Palen: Typo

{{Quicklinks}}

== Installing & Running OpenSim in Hypergrid Mode ==
The setup for hypergrid differs depending on whether you run OpenSim as a standalone or as a grid. There also came considerable changes with version 0.7. If you are using an older version 0.6.x of OpenSimulator, then refer to [[Configuration for OpenSimulator 0.6.x]] further down this page.

== Configuration ==
In order for OpenSimulator to be accessible in the hypergrid, you must use an externally visible IP address or domain name. You also may need to set up port forwarding for all ports (TCP and UDP) that OpenSimulator and the regions use. Typically, these are port 8002 for an installation running in grid mode and port 9000 for standalones. Regions typically use ports starting at 9000. For more information, see [[Network Settings]].

=== Standalone ===
The configuration for hypergrid is activated in section [Architecture] in file OpenSim.ini. Ensure that the line for Include-HGStandalone is the only one that is uncommented in this section:
<source lang="ini">[Architecture]
;Include-Standalone = "config-include/Standalone.ini"
Include-HGStandalone = "config-include/StandaloneHypergrid.ini"
;Include-Grid = "config-include/Grid.ini"
;Include-HGGrid = "config-include/GridHypergrid.ini"
;Include-SimianGrid = "config-include/SimianGrid.ini"</source>

In StandaloneCommon.ini the network addresses in sections [LoginService] and [GatekeeperService] must be changed to your external network address:
<source lang="ini">[LoginService]
; ... (other settings in this section) ...
HomeURI = "http://example.com:9000"
GatekeeperURI = "http://example.com:9000"
InventoryServerURI = "http://example.com:9000"
AssetServerURI = "http://example.com:9000"

[GatekeeperService]
; ... (other settings in this section) ...
ExternalName = "http://example.com:9000"</source>

If you want to use a different port with these addresses, then you must adjust the HTTP listener port in section [Network] in OpenSim.ini, too:
<source lang="ini">[Network]
; ... (other settings in this section) ...
http_listener_port = 9000
</source>

As a last step, the regions must be configured according to the previous changes. See [[#Region Setup for both Grid and Standalone]].

=== Grid ===
To enable hypergrid for a grid, both the Robust server and the region servers (simulators) must be configured approprietly.

==== Robust Server ====
The Robust server is started with configuration file Robust.HG.ini instead of Robust.ini. If this file does not yet exist in your installation, create it by making a copy of Robust.HG.ini.example. Make the changes appropriate for your environment (e.g. adjust the database connection string). For hypergrid, the following settings are relevant:

<source lang="ini">[LoginService]
; ... (other settings in this section) ...
HomeURI = "http://example.com:8002"
GatekeeperURI = "http://example.com:8002"
InventoryServerURI = "http://example.com:8002"
AssetServerURI = "http://example.com:8002"

[GatekeeperService]
; ... (other settings in this section) ...
ExternalName = "http://example.com:8002"
</source>

If you want to change the port(s) used with these addresses, you will also need to adjust the ports in parameter ''''ServiceConnectors'''' in section [Startup] and probably the port configured in section [Network] as well.

After these adjustments, the Robust server can be started. On Windows/.NET:
Robust -inifile=Robust.HG.ini
Or, with Mono (e.g. on Linux or OSX):
mono Robust.exe -inifile=Robust.HG.ini

==== Simulator ====
The region servers (simulators) that connect to the Robust server read their configuration from file OpenSim.ini. To activate hypergrid for them, the line for Include-HGGrid in section [Architecture] must be uncommented:
<source lang="ini">[Architecture]
;Include-Standalone = "config-include/Standalone.ini"
;Include-HGStandalone = "config-include/StandaloneHypergrid.ini"
;Include-Grid = "config-include/Grid.ini"
Include-HGGrid = "config-include/GridHypergrid.ini"
;Include-SimianGrid = "config-include/SimianGrid.ini"
</source>

=== Region Setup for both Grid and Standalone ===
Finally, all your regions must use the same external address that is set for GatekeeperService, for example:
<source lang="ini">[Region One]
; ... (other settings in this section) ...
ExternalHostName = "example.com"
</source>

For the ports which are used by your regions, TCP and UDP requests must be forwarded through any firewall that is securing your network.

== Configuration for OpenSimulator 0.6.x ==

=== Installing ===

Checkout OpenSim, prebuild and build as normal or Download and install Binary Packages from the [[Main Page|MAIN Page ]] If you're running your opensim in '''Grid Mode''' mode with servers on other machines, you only need to modify your OpenSim.ini to enable HyperGrid.

If you're running in standalone and you want it to be network-able, or if you have your grid on loopback (127.0.0.1) change all the [Network] server addresses to. See below.

=== EXAMPLE Network Sections ===

==== Default Example, Network Settings for a Stand Alone: ====

<source lang="ini">[Network]
http_listener_port = 9000

grid_server_url = "http://example.com:9000"

grid_send_key = null
grid_recv_key = null

user_server_url = "http://example.com:9000"

user_send_key = null
user_recv_key = null

asset_server_url = "http://example.com:9000"

inventory_server_url = "http://example.com:9000"
messaging_server_url = "http://example.com:9000"</source>

==== Default Example, Network Settings for a Grided Server: ====

<source lang="ini">[Network]
http_listener_port = 9000

grid_server_url = "http://example.com:8001"
grid_send_key = null
grid_recv_key = null

user_server_url = "http://example.com:8002"
user_send_key = null
user_recv_key = null

asset_server_url = "http://example.com:8003"
inventory_server_url = "http://example.com:8003"
messaging_server_url = "http://example.com:8006"</source>

==== Network Settings for OSGrid Attched Servers: ====

<source lang="ini">[Network]
http_listener_port = 9000
grid_server_url = "http://osgrid.org:8001" ;default 8003
grid_send_key = "1234"
grid_recv_key = "1234"

user_server_url = "http://osgrid.org:8002"
user_send_key = "1234"
user_recv_key = "1234"

asset_server_url = "http://assets.osgrid.org:8003"
inventory_server_url = "http://osgrid.org:8004" ;default 8003
messaging_server_url = "http://osgrid.org:8006"</source>

==== Modifications needed to be applied to OpenSim.ini to enable Hypergrid ====

- Change the following line at the top of the OpenSim.ini
<pre>hypergrid = false to true</pre>
- NEXT, Add or Modify the ### WORLD MAP Section as shown

<source lang="ini">; ##
; ## WORLD MAP
; ##

WorldMapModule = "WorldMap"
MapImageModule = "MapImageModule"
WorldMapModule = "HGWorldMapModule" ;NOT INCLUDED IN DEFAULT OpenSim.ini.EXAMPLE</source>

''Information: HGWorldMapModule will, after teleporting to another grid, clean up tiles in your map left over from the grid on which you were previously.''

- NEXT, Modify the [Archictecture] Section at the bottom

Uncomment the appropriate Include-HG* = line by removing the semi colon and making sure that is the only ONE uncommented. (example shows for a Stand Alone HG enabled installation)

<source lang="ini">[Architecture]
;Include-Standalone = "config-include/Standalone.ini" ; DEFAULT UNCOMMENTED
Include-HGStandalone = "config-include/StandaloneHypergrid.ini"
;Include-Grid = "config-include/Grid.ini"
;Include-HGGrid = "config-include/GridHypergrid.ini"</source> 

Your OpenSimulator instance should now be ready for inbound & outbound Hypergrid use

== The 4096 Regions Limit ==
Due to a viewer issue, teleports to destinations that are more than 4096 regions away in any direction will not work as expected. Most viewers will do the teleport but the destination region will not be rendered and thus remain invisible to you. What this means in practice is that if you wish to teleport from a region located at cell coordinates (1000, 1000) you cannot go beyond (5095, 5095). To reach destinations that are placed at farer locations, you should either place your own region closer to the destination, or use some intermediate region that is reachable from both your region and the destination region.

Refer to [[Public Hypergrid Nodes]] to see some known grids and standalones and where they are located.

== Important Notes ==
Make sure you have a 'home' set. If your home region doesn't exist, the hyperlink TPs may not work. To set your home, go to one of your local regions and "Set Home" from the viewer.

To Enable scripted Teleporting between regions, standalone, HyperGrid etc, you can use osTeleportAgent function, Example here: [[OsTeleportAgent|OsTeleportAgent]]

== Linking regions (Optional) ==

=== Method 1 ===

On the console, type for example:
<pre>link-region <Xloc> <Yloc> osl2.nac.uci.edu:9006</pre>
Use Xloc and Yloc that make sense to your world, i.e. close to your regions, but not adjacent. replace osl2.nac.uci.edu and 9006 with the domain name / ip address and the http_listener_port of the simulator where the region is running you want to link to.
You can link to a specific region within an instance, by using the name of the region at the end, for example:
<pre>link-region 997 997 osl2.nac.uci.edu:9006:UCI Welcome</pre>

=== Method 2 ===

There is also some initial support for reading the links from a xml file.

Use the console command: link-region <URI> [<excludeList>]

The uri can be either the path of a local xml file or a xml document on a http server.

The format of the xml file is:

<source lang="xml"><Nini>
<Section Name="Region1">
<Key Name="xloc" Value="1002"/>
<Key Name="yloc" Value="1006" />
<Key Name="externalPort" Value="9006" />
<Key Name="externalHostName" Value="osl2.nac.uci.edu" />
<Key Name="localName" Value="OSGrid-Gateway" />
<Key Name="real-xloc" Value="10222"/> //optional field that gives the region's real location on its home grid
<Key Name="real-yloc" Value="10265" /> //optional field that gives the region's real location on its home grid
</Section>
<Section Name="Region2">
...
</Section>
...
</Nini></source>

[Note] The section names can be anything you want, but they all should be different and have no spaces in the name.

==== ExcludeList: ====

The exclude list is a single string paramater with the format: excludeList:<SectionName>[;<SectionName>]

This means that while reading from the xml file any sections that are listed in the excludeList will be ignored and no HyperGrid link created for them.

This could allow, link lists to be created on a webserver that everyone could add their own regions to, and then they just make sure they add their own section name(s) to the exclude list on their own region(s).

So for example, someone might create a editable online list for the up coming OpenSimulator's 2nd birthday. Which might look something like:

<source lang="xml"><Nini>
<Section Name="OSGrid-Party">
<Key Name="xloc" Value="1002"/>
<Key Name="yloc" Value="1006" />
<Key Name="externalPort" Value="9006" />
<Key Name="externalHostName" Value="osl2.nac.uci.edu" />
<Key Name="localName" Value="OSGrid-Gateway" />
</Section>
<Section Name="UCIGrid-Party">
...
</Section>
</Nini></source> I could then add my own region to the list with the section name "MW-Party". Then when I startup that region that I want to be part of this hypergrid, I use the command:
<pre>"link-region <URI of xml file> excludeList:MW-Party"</pre>
This is so that my region doesn't try to create a hyper link to itself.

=== Method 3 (dynamic) ===

Starting in r8193, if you're in an HG-enabled region, you'll be able to dynamically link sims, and TP there, in any one of these ways (and probably more). All you need to know is the target address, e.g. from the list below.

1) Type for example secondlife://ucigrid04.nacs.uci.edu:9007/ in the chat box, pull up the chat history and click on that link

2) Pull up the map and search for things like ucigrid04.nacs.uci.edu:9007

3) Using the embedded browser visit pages that have links like '''secondlife://ucigrid04.nacs.uci.edu:9007'''/ (there's one up at http://www.ics.uci.edu/~lopes/hypergrid/test.html)

Again, you can link to a specific region within an instance by adding the name of that region at the end, like this: '''secondlife://ucigrid04.nacs.uci.edu:9007:Gateway 7000/'''

=== Checking the 4096 Regions Limit ===
Due to the [[Installing and Running Hypergrid#The 4096 Regions Limit|4096 Regions Limit]], there is a check in OpenSimulator since version 0.7.0.1 which verifies that the intended link will be within reach of one of your regions. If none of the regions in your grid or standalone is located within a distance radius of 4096 regions from the region to be linked, then the link will be rejected. You can disable this check in StandaloneCommon.ini (for standalones) or Robust.HG.ini (for grids) with
[GridService]
Check4096 = false

=== Persistent Linked Regions ===
With grid mode, methods 1 and 2 will work on both the Robust console and the region console. On the region console, linked regions will not be stored in the database and will vanish when the region is shut down. Regions that are linked on the Robust console will be persistent over restarts until they are explicitly removed with unlink-region.

== Listing linked regions ==

To see a list of all linked regions, use the following command on the console (available since 0.7.1 r/13457, also in 0.7-post-fixes):
<pre>show hyperlinks</pre>

== Unlinking regions ==

On the console, type for example:
<pre>unlink-region osl2.nac.uci.edu:9006</pre>
or
<pre>unlink-region <local region name></pre>

Please note that region names can only have a maximum length of 32 characters when using MySQL as a database. If a linked region has a longer name, it will be truncated. The unlink-region command will only find a region, if the name is also truncated to a maximum length of 32 characters.

== Additional References ==

Implemented osFunctions: [[OSSL Implemented|OSSL Implemented]]

Enabling osFunctions: [[OSSL Enabling Functions|OSSL Enabling Functions]]

HyperGrid Security: [[Hypergrid Security|Hypergrid Security]]

Banning Foreign Users in Hypergrid: [[Banning Foreign Users in Hypergrid|Banning Foreign Users in Hypergrid]]

Public HyperGrid Nodes Listing: [[Public Hypergrid Nodes|Public Hypergrid Nodes]]

Hypergrid Inventory Access: [[Hypergrid Inventory Access|Hypergrid Inventory Access (proposal)]]

CATEGORY: [[Hypergrid|Hypergrid ]]

OsNpcCreate

2010-08-19T03:38:20Z

Karen Palen: Clarify username parameters per coding source

'''Function Syntax:''' osNpcCreate(string firstname, string lastname, vector position, key cloneFrom); '''Returns:'''  key

Example Required !

Startup script linux

2010-03-06T06:27:15Z

Karen Palen: Added simple script for a standalone

== Simple Standalone Sim Startup Script ==

=== Instructions ===

This script assumes that you will start the sim whenever you are using it.

The sim will run as a job in its own terminal.

To shutdown the sim you enter the SHUTDOWN command at the terminal prompt.

=== Script ===

#! /bin/sh
cd /home/opensim/diva-r11766/bin
export MONO_THREADS_PER_CPU=125
mono OpenSim.exe

== Grid Mode /etc/init.d script for Linux ==

=== Instructions ===

Tested on Debian 5. CHUIDS user to opensim user. Supports: start, stop, restart, status

To implement: Type: cat > /etc/init.d/opensim Paste in script from this page Press: CTRL+D Type: chmod +x /etc/init.d/opensim Script should now be located on server and be executable.

Type: update-rc.d opensim defaults Script should now be in your startup.

Modify header in script to adapt it to your installation folder and user.

NOTE: stop-command currently doesn't work properly (it doesn't do a soft shutdown). It will kill OpenSim first with kill pid, then kill -9 pid. So make sure you have saved your data. :)

=== Script ===

<code></code>

#! /bin/sh
### BEGIN INIT INFO
# Provides: OpenSim
# Required-Start: $local_fs $network
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Tedds OpenSim init.d-script
### END INIT INFO

# Put script in /etc/init.d/
# then execute: update-rc.d opensim defaults

set -e

#
# Directories
#
# Location of OpenSim installation
DIR=/home/opensim/OpenSim/bin/
# Different PID dir?
PIDDIR=$DIR

USER=opensim
SERVICES="OpenSim.Grid.UserServer.exe OpenSim.Server.exe OpenSim.exe"

#
# Kill values (in seconds)
#
# How long between each service being started
DELAY_STARTUP=10
# How long between each service is sent shutdown command
DELAY_KILL=10
# After shutdown has been sent to all we do another loop with "kill", then "kill -9". How long between "kill" and "kill -9".
DELAY_FORCEKILL=10

#
# Info on service handled by this script

# Name of service
NAME=opensim
# Description of service
DESC="OpenSim Server"

# Binaries
SCREEN=/usr/bin/screen
MONO=/usr/bin/mono

###########################
##### START OF SCRIPT #####
###########################

export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"

 

# Load LSB log functions
_lsbFile=""
if [ -e /etc/debian_version ]; then
_lsbFile="/lib/lsb/init-functions"
if [ -f $_lsbFile ]; then
. $_lsbFile
else
echo This script requires LSB init-functions file which doesn't exist: $_lsbFile
exit 1
fi
else
# [ -e /etc/init.d/functions ] ; then
_lsbFile="/etc/init.d/functions"
if [ -e $_lsbFile ]; then
. $_lsbFile
else
echo This script requires LSB init-functions file which doesn't exist: $_lsbFile
exit 1
fi
fi

# Lets use fancy output
log_use_fancy_output

# Check that target directory exists
if test ! -d "$DIR"; then
log_failure_msg "$NAME" "Target directory \"$DIR\" does not exist. Can not continue."
exit 1
fi

# Create a reverse order for shutdown
SERVICES_REVERSE=""
reverse() { SERVICES_REVERSE="$9 $8 $7 $6 $5 $4 $3 $2 $1"; }
reverse $SERVICES

# Check if a service is running
isrunning() {
ISRUNNING="0"
# Do we have PID-file?
if [ -f "$PIDDIR/$1.pid" ]; then
# Check if proc is running
pid=`cat "$PIDDIR/$1.pid" 2> /dev/null`
if [ "$pid" != "" ]; then
if [ -d /proc/$pid ]; then
# Process is running
ISRUNNING="1"
fi
fi
fi
#ISRUNNING="0"
}

#
# Process commands
#
case "$1" in
start)
# Start all services one by one
for server in $SERVICES; do
log_daemon_msg "Starting $NAME" "$server"

isrunning $server
case "$ISRUNNING" in
1) log_progress_msg "Process already started. Please stop first"; log_end_msg 1 ;;
0)
# Process is not running
# Start process and sleep...
exefile="/tmp/exe.OpenSim.$server.sh"

# Need to make external file, had big problems with screen params
echo \#\!/bin/bash > $exefile
echo cd $DIR >> $exefile
echo $MONO $server >> $exefile
chmod +x $exefile

cmd_screen="screen -S $server -d -m $exefile"
start-stop-daemon --start -b -x /bin/su -m --pidfile=/tmp/su.$server.pid --chdir "$DIR" -- - $USER "-c $cmd_screen"

# Delay between services that are started
sleep $DELAY_STARTUP

rm $exefile 2> /dev/null

# Make PID-file
ps afxu | grep "mono $server" | grep -iEv "grep|screen" | awk {'print $2'} > "$PIDDIR/$server.pid"

isrunning $server
case "$ISRUNNING" in
1)
# Process started ok
#log_progress_msg "Success";
log_end_msg 0
 ;;
0)
# Process didn't start... remove pid-file
rm "$PIDDIR/$server.pid" 2> /dev/null
#log_progress_msg "Failure";
log_end_msg 1
 ;;
esac
 ;;
esac

done
 ;;

 

stop)
_killCount=0

for server in $SERVICES_REVERSE; do
log_daemon_msg "Stopping $NAME" "$server"

isrunning $server
case "$ISRUNNING" in
1)
_killCount=`expr $_killCount + 1`
log_progress_msg "Sending shutdown command:";

# We add some backspaces to the command in case something is on the console already
echo `screen -S $server -X stuff \"

# Wait for it to shut down...
sleep $DELAY_KILL

isrunning $server
case "$ISRUNNING" in
1) log_progress_msg "is still running."; log_end_msg 0 ;;
0) log_progress_msg "has been shutdown"; log_end_msg 0 ;;
esac

 ;;
0)
log_progress_msg "is not running"; log_end_msg 0
 ;;
esac

done

# Check if any procs are still running
for server in $SERVICES; do
isrunning $server
case "$ISRUNNING" in
1)
log_warning_msg "Stopping $NAME" "$server is still running: Forcing kill"
echo `kill $pid 2> /dev/null`;
sleep $DELAY_FORCEKILL
echo `kill -9 $pid 2> /dev/null`;
sleep 1

# Now check again if it is still running...
isrunning $server
case "$ISRUNNING" in
0) log_progress_msg "Success"; log_end_msg 0 ;;
1) log_progress_msg "Process is still running... Even after \"kill -9 $pid\". WOW..."; log_end_msg 0 ;;
esac
 ;;
0)
#log_progress_msg "";
 ;;
esac
done

log_begin_msg "$NAME: All done (killed $_killCount procs)"; log_end_msg 0

 ;;

 

 

status)
# Count how many processes we need
PROCCOUNT=0
for i in $SERVICES; do
PROCCOUNT=`expr $PROCCOUNT + 1`
done

# Go through server PID files and count how many are running
log_begin_msg "$NAME: Running processed:"
_pidCount=0
for server in $SERVICES; do

isrunning $server
case "$ISRUNNING" in
1)
# This server is running
_pidCount=`expr $_pidCount + 1`
log_progress_msg "$server"
 ;;
0)
 ;;
esac
done

log_begin_msg " ($_pidCount of $PROCCOUNT processes are running)"; log_end_msg 0

# Check if running proc count matches requires proc count
log_begin_msg "$NAME is"
if [ $_pidCount -eq $PROCCOUNT ]; then
log_progress_msg "running"; log_end_msg 0
exit 0
else
log_progress_msg "NOT running"; log_end_msg 0
exit 1
fi
 ;;

restart)
$0 stop
$0 start
 ;;
*)
echo "Usage: /etc/init.d/$NAME {start|stop|restart|status}" >&2
exit 1
 ;;
esac

exit 0

Inventory Archives

2009-12-10T09:01:46Z

Karen Palen: clarify destination folder requirement

__NOTOC__
{{Template:Quicklinks}}
 

==Introduction==

OpenSim Inventory Archives (IARs) are a means by which inventory folders and items can be saved offline to a single file (an IAR). This file can then be loaded into a different OpenSim installation.

Like [[OpenSim Archives|OpenSim_Archives]], IARs save all the necessary asset data required to fully restore the items including textures and the other content of objects such as sounds and scripts.

IARs have been enabled in OpenSim since Git revision 5a64ca (post 0.6.6).

==Usage==

IARs are saved and loaded from the region console. Before performing either of these operations the user that owns the inventory to be used must be present in one of the regions run by the region simulator.

===save iar===

The command to save an IAR on the region console is

save iar <user name> <path> <password> [<filename>]

where

* <user name> is the name of the user to save inventory from

* <path> is the path to an inventory item or folder. If the path is for a folder, that folder and all its contents (both descendant folders and items) are saved. If the path is for an item, then only that item is saved.

Components of the path are separated by a forward slash ("/"). If you need to specify a path with spaces, you can surround the whole thing with double quotation marks (e.g. "Folder A/Folder B").

If a name or folder contains a forward slash ("/") then it can be escaped with the backslash (i.e. "\/") to stop it being seen as a path separator. Back slashes themselves need to be escaped with another backslash (i.e. "\\").

One further issue here is that it's not possible to distinguish between identically named folders or items on the path - the workaround is to rename your items/folders if you need to specify them in the path :)

* <password> is the password of the user.

* <filename> is an optional filename for the IAR. If none is supplied, then the filename user-inventory.iar is used in the current directory. I recommend that iars have the .iar extension.

====Examples====

Here's an example. Suppose you have an inventory structure like this

My Inventory
|
+-- FolderA
|
+-- FolderB
| |
| +-- ItemX
|
+-- ItemY

If you type

save iar John Doe FolderA password

then FolderA and everything in FolderA (FolderB, ItemX and ItemY) will be saved. On the other hand, if you type

save iar John Doe FolderA/FolderB/ItemX password

then only ItemX will be saved.

Since no filename was specified in either of these cases, the items or folders will be saved to a file called user-inventory.iar

===load iar===

An IAR can be reloaded to an OpenSimulator instance with the load iar command

load iar <user name> <path> <password> [<filename>]

where

* <user name> is the name of the user to whom to load the inventory

* <path> is the path to which the IAR should be loaded. This has to be a folder which already exists in "My Inventory". See the save iar command for more details.

* <password> is the password of the user.

* [<filename>] is an optional filename for the IAR. If none is specified, then the filename is assumed to be user-inventory.iar in the current directory.

====Examples====

Again, here's an example. Suppose that "David Hume" has recieved the IAR above containing FolderA, FolderB, ItemX and ItemY. David Hume already has an inventory structure like this.

My Inventory
|
+-- Folder1
|
+-- Folder2
|
+-- Folder3

David wants to load the IAR to Folder3, so on the region console he executes

load iar David Hume Folder1/Folder3 password

After a little while he ends up with the folder structure

My Inventory
|
+-- Folder1
|
+-- Folder2
|
+-- Folder3
|
+-- FolderA
|
+-- FolderB
| |
| +-- ItemX
|
+-- ItemY

where ItemX and ItemY are ready for rezzing.

== IAR files==

[http://justincc.org/downloads/iars/my-great-items.iar http://justincc.org/downloads/iars/my-great-items.iar] - justincc's initial example IAR.

====dmu1.iar====

[[Image:cadeira1.jpg]][[Image:BandeiraBrasil.jpg]]
[http://www.dmu.com/iar/dmu1.iar dmu1.iar] -
You can change the texture of the flag.

====dmu2.iar====

[[Image:arvoreDeNatal.jpg]][[Image:Sofa1.jpg]]
[http://www.dmu.com/iar/dmu2.iar dmu2.iar]

The "dmu" files have objects copied from many places; authorized to be copied. If you know any copyrighted problem about anyone, let us know.

Please feel free to place links to other IARs here.

==Further Information==

[http://justincc.org/blog/category/iars/ http://justincc.org/blog/category/iars/] - articles by justincc on IARs, including tutorials, background information and possible future developments.

==Use cases==

Possible uses

1. To distribute content to other OpenSim installations without need to transfer entire regions. One drawback with IARs for this use case is that creator names are not preserved unless the user has a profile on the target installation. One workaround is to include a notecard detailing the creator and license conditions of the content.

2. To backup a user's inventory. IARs are currently not that great for this. One can backup an entire inventory by giving a path of "/" to the save iar command. But a load IAR of the same will mean a duplicate set of root child 'standard' folders (Objects, Textures, Clothing, etc.). The loaded folders will not have any type icons.

==Current limitations==

* IAR loading and saving is currently done on a single thread. This may lock up the console for a while with very large IARs. This should be addressed in the future

* IARs cannot save folders or items that contain a forward slash in their name. This should be addressed in the future.

* Creator names are not preserved unless the profile exists on the target system. This problem will probably be addressed in the future.

==File Formats==

[[IAR Format|IAR File Formats]]

==FAQ==

Nothing yet.

==Bugs==

Please search the OpenSim Mantis for information on current IAR bugs.

==Current Status==

Operational but experimental. Bug reports are appreciated and there will almost certainly be quite a few right now. Suggestions for improvement are also welcome. The best place for these right now might be [http://justincc.org/blog/2009/09/14/introducing-opensim-inventory-archives-iars/ my blog post on IARs], since I'm bound to see them then.

Though we will strive to maintain compatibilty for old archives with newer OpenSimulator versions, please do not rely on these archives as your only backup for inventory.

[[Category:Users]]
[[Category:Support]]
[[Category:Tech Reference]]
[[Category:Help]]
[[Category:Configuration]]
[[Category:Getting_Started]]
[[Category:Development]]

Free Assets

2009-12-08T14:15:12Z

Karen Palen: Add forum reference and title

[[Category:Users]]
==Textures==
* [http://texturebarn.headfirstdm.com/ The Texture Barn]
* [http://www.tellim.com/texture_cd/ The Blender Texture Disc]
* [http://textures.z7server.com/save_all_textures.php z7Server texture packages]

<gallery widths="128px" heights="128px" perrow="6">
Image:Smoke.png | Smoke
Image:Brown_Eye.png | A Brown Eye
Image:Picketfence.png | A Picket fence.
</gallery>

Nebadon's Bush Texture : [http://www.nebadonizumi.com/bushes01.tga Bushes]

Vint Falken's Free Valentine Eyes:
[http://www.flickr.com/photos/vintfalken/2258351122/ 1]
[http://www.flickr.com/photos/vintfalken/2258351306/ 2]
 
http://www.vintfalken.com/free-full-perm-female-skins-sezmras-splendor/ 
http://www.vintfalken.com/free-full-perm-female-skin-textures/ 
http://torley.com/torley-textures-available-for-download-in-a-single-zip-pack 

==Heightmaps==
<gallery caption="A Simple Square Island" widths="100px" heights="100px" perrow="6">
Image:Square_island_1x1.png | 1x1 region
Image:Square_island_2x2.png | 2x2 regions
Image:Square_island_4x4.png | 4x4 regions
</gallery>http://guide.opendns.com/?url=www.nextlife.ca%2Fnuathens.zip&servfail

<gallery caption="A Complicated Maze" widths="100px" heights="100px" perrow="6">
Image:Maze.png | 1x1 region
</gallery>

==Buildings==

<gallery caption="Free OpenSim Buildings" widths="250px" heights="188px" perrow="6">
Image:Free_OpenSim_Assets_Modern_Building.jpg | [http://integratedtechnologies.eu/sites/default/files/modern_building_oar_tar.gz Download]
Image:Free_OpenSim_Assets_Cottage.jpg | [http://integratedtechnologies.eu/sites/default/files/09_11_08_house_oar.tar.gz Download]
Image:Free_OpenSim_Assets_Office.jpg | [http://integratedtechnologies.eu/sites/default/files/09_11_08_office_oar.tar.gz Download]
</gallery>

<gallery caption="Free OpenSim Buildings" widths="250px" heights="188px" perrow="6">
Image:Free_OpenSim_Assets_Small_Store.jpg | [http://integratedtechnologies.eu/sites/default/files/09_11_08_small_store_oar.tar.gz Download]
Image:Free_OpenSim_Assets_Medium_Store.jpg | [http://integratedtechnologies.eu/sites/default/files/09_11_08_medium_store_oar.tar.gz Download]
Image:Free_OpenSim_Assets_Large_Store.jpg | [http://integratedtechnologies.eu/sites/default/files/09_11_08_large_store_oar.tar.gz Download]
</gallery>

<gallery caption="Free OpenSim Buildings" widths="250px" heights="188px" perrow="6">
Image:Free_OpenSim_Assets_Fireplace.jpg | [http://integratedtechnologies.eu/sites/default/files/09_11_08_fireplace_oar.tar.gz Download]
</gallery>

==Full Sims==
'''Nu Athens'''

4 Full Sims with Faux City which was made by Lordfly Digeridoo for a roleplay experiment.
[http://www.sluniverse.com/php/vb/project-development/16014-nu-athens-interactive-story-opensim-2.html SL Universe posting on Nu Athens]

[http://techwizworld.net/Opensim/nuathens/ Download Nu Athens oar files]

== Opensim Archives - OAR Files ==

===How to load OAR files===
[[OpenSim Archives|How to load OAR files]]

===OpenVCE 3D Assets OAR===

The [http://openvce.net OpenVCE.net] virtual worlds assets described at http://openvce.net/vwassets provided by Clever Zebra and the OpenVCE.net team at AIAI in the University of Edinburgh are available as an OAR (Opensim Archive) file.

http://openvce.net/resources/downloads/

Get file "opensim-openvce.oar" from there (right click on the file in the above directory in your browser, and select download is the easiest way to obtain the materials). A "full" set of the buildings with a large 400 seat amphitheatre intended to be placed on the corner of 4 sims is also available via "opensim-openvce-full.oar".

Images of the buildings in place in Opensim are at:
[http://openvce.net/resources/downloads/opensim-openvce-1.jpg Image 1],
[http://openvce.net/resources/downloads/opensim-openvce-2.jpg Image 2]

==Skin PSD's==
<gallery caption="Free Skin PSD files" widths="250px" heights="188px" perrow="6">

Image:Skins.jpg | [http://eloheliot.blogspot.com/2007/12/my-psds-let-me-show-u-them.html Download Page]
Image:Skin2.jpg | [http://eloheliot.blogspot.com/2007/12/my-psds-let-me-show-u-them.html Download Page]
Image:Skin3.jpg | [http://eloheliot.blogspot.com/2007/12/my-psds-let-me-show-u-them.html Download Page]

</gallery>

Configuration

2009-12-04T07:19:34Z

Karen Palen: /* Note About Mono */

__NOTOC__
{{Template:Quicklinks}}
 
==OpenSim configuration file==
The simulator configuration is managed using a file called [[OpenSim.ini]]. This file is used regardless of whether the sim is running in standalone or grid mode. Detailed information on the options available for setttings in this file can be found [[OpenSim.ini|here]].
Please note, that the name OpenSim.ini can be changed via command line arguments (see above). Also, note that the default download does not include an OpenSim.ini file, but rather provides an example file. To get started editing your ini file, please cd into opensim/bin/ and copy OpenSim.ini.example to OpenSim.ini.

It is also possible to distribute the inifile settings over two files. This is useful if you want to run several OpenSim processes where most of your settings are identical but some settings differ.
The master file is read first, then the inifile is read. Settings given in the inifile overrule settings given in the master file.
The master file has the same format and the same keywords as the inifile, so the same documentation applies.

==Database==
Opensim's supports the following database-engines:
* SQLite (default - a lightweight database that comes bundled with OpenSim and can be used without requiring any extra configuration. It is mostly intended to get you up and running quickly, not for production use. A few features here (such as attachment persistence) have not yet been fully implemented.)
* MySQL (fully supported). This is the recommended database for any use beyond experimentation or small standalone applications.
* MSSQL (partially supported - some recent OpenSim features may not yet be implemented)

More information on database support can be found on the [[OpenSim Database support]] page.

==Standalone vs. Grid==
We recommend that you first get OpenSim running in standalone mode before you attempt to connect it to a grid or run your own grid. An OpenSim configuration consists of regions (run by region simulators) and 5 core backend services (which manage users, the grid, assets, inventories, and grid-wide messaging, collectively known as UGAIM).

A system running in '''standalone mode''' (that is, one with OpenSim.ini where gridmode = false) runs everything (all UGAIM services and one or more regions) in a single executable (OpenSim.exe).

In '''grid mode''', the five services ([[User Server|User]], [[Grid Server|Grid]], [[Asset Server|Asset]], [[Inventory Server|Inventory]], [[Messaging Server|Messaging]], or UGAIM) are not part of the region server. Instead, they can be run separately either on the same machine or spread out across multiple computers. In this mode, the OpenSim.exe acts solely as the region server, serving one or more regions that communicate with the core servers for asset, inventory and other data management.

Naturally, this means that running in grid mode is somewhat more complicated than running in standalone mode. It requires an understanding of UUID, X,Y location, server handshake passwords, estates and estate owners, and a couple of other settings. These are not difficult, but do require a little more care in setting things up.

If you want to run a grid of your own (either private or public) you would start the core services up before connecting a region simulator. If you want to connect your region server to a grid that someone else is running, you need only start the region server in grid mode (with the necessary security keys and location information mentioned in the last paragraph).

=== Standalone mode ===

When you start OpenSim in standalone mode, it will ask you several questions at the console. The first set of prompts that start with "NETWORK SERVERS INFO", you can just hit return to accept the defaults if you will be running in standalone mode. The prompts that start with "DEFAULT REGION CONFIG" are where you need to start paying attention. Some are self-explanatory. Here are explanations for the others: 

*Grid Location. OpenSim regions can be placed anywhere on a 65536 by 65536 grid. In standalone mode, it is safe to leave these X and Y locations at their defaults for the first region (additional regions will need different coordinates, of course).
*Filename for local storage. Safe to leave at default.
*Internal IP address; This should always be 0.0.0.0 (0.0.0.0 means "listen for connections on any interface", basically a wildcard) if you want to access this server from the internet or another server on your internal network, this should be the IP address assigned to the OpenSim Server. You should also set up the server to Use a Static IP address, and not DHCP
*Internal IP port for incoming UDP client connection. You can make this any port you want, but it is safe to leave at the default 9000. Each region on your server must have a unique port 
*External host name. If you will only be attaching to your sim from a SecondLife client on the same machine, you can leave this at the default 127.0.0.1. If you will be wanting to connect to it from a client on another machine or the internet, this should be the External IP Address of your router, not the Domain Name. (Hmm - Tried hostname (the one resolved by dns) and it worked out oke.)
*Be aware of [http://osgrid.org/forums/viewtopic.php?f=5&t=400&start=0&st=0&sk=t&sd=a loopback] problems when Running viewer & server(s) on the same machine (LAN) by using the "external" configuration. ('''You might notice endless waiting for region handshake'''.) See also [http://opensimulator.org/wiki/Troubleshooting troubleshoot hints]
*If your having Connectivity problems. [http://opensimulator.org/wiki/Network_Settings Be sure to read the Network Configuration Page]. This is important if you see Region handshake issues.

To connect to your new sim, start up secondlife with the following command line switches:

'''Client on same machine as OpenSim:''' -loginuri http://127.0.0.1:9000/ -loginpage http://127.0.0.1:9000/?method=login

Client on different machine or internet:''' -loginuri http://external_ip:9000/ -loginpage http://external_ip:9000/?method=login'''

To create a user:

type create user <first> <last> <password> <x_loc> <y_loc> in the server console. 

=== Grid mode ===

You want to run your own grid. Great! Assuming that you already got your sim running in standalone mode, here is what you need to do: 1. Current builds of OpenSim grid mode are using mysql to store the grid information. You must have this installed and configured if you want to run your own grid. See [[Mysql-config]] for more information. 

 

[[Image:Exclamation.png|left]]
NOTE: The grid servers are in the process of being redesigned. Therefore, there is a "legacy" way
and a new way of starting things. The most up to date information can be found in the configuration
file examples in your OpenSim kit.

The new system consists of services and connectors that are run in a server shell (Basic Universal
Server Technology, R.O.B.U.S.T.)

For information on running the legacy servers, see [[LegacyServers]]

'''More Details on ROBUST are Here -->'''[[ROBUST|'''ROBUST''']]''' <--  including Conversion From UGAIM To UGRM'''

===Starting the grid services===
As of OpenSim 0.6.7, R.O.B.U.S.T. has connectors for the asset and inventory functionality. Therefore, some of the legacy servers are still required to run. Following the steps below will get you up and running in no time!

* Configure the user server
::Start OpenSim.Grid.UserServer.exe
::You will be asked a number of configuration questions. If the grid servers are all on one machine, most defaults are safe to use, just press enter for all questions except fot the defult inventory server. The default inventory server needs to be given as http://127.0.0.1:8003, because R.O.B.U.S.T uses only one port.
::The user server will then load and display it's prompt:
User#
* Configure the grid server
::Start OpenSim.Grid.GridServer.exe
::Again, you will be asked a few questions and it's safe to accept the defaults if all servers are run on one machine. You will then see the grid server prompt:
Grid#
* Configure R.O.B.U.S.T.
::Copy OpenSim.Server.ini.example to OpenSim.Server.ini
::(on version 0.6.6 copy OpenSim.Services.ini.example to OpenSim.Services.ini - then use OpenSim.Services instead OpenSim.Server)
::Don't forget change ConnectionString accordingly your database settings.
Linux
bin$ cp OpenSim.Server.ini.example OpenSim.Server.ini
Windows
C:\OpenSim\bin> copy OpenSim.Server.ini.example OpenSim.Server.ini
For more information on the R.O.B.U.S.T. configuration file and more information if you are migrating from an earlier release of OpenSim, refer to [[R.O.B.U.S.T.]]

::Start OpenSim.Server.exe
The server will start up it's asset and inventory components and display the R.O.B.U.S.T prompt:
R.O.B.U.S.T.#
* Configure the message server
::Start OpenSim.Grid.MessagingServer.exe
::Answer the configuration questions. Again, if all servers are run on the same machine, it's safe to press enter for all questions
::The server will start and present you with it's prompt:
Messaging#

==Configuring regions==

When first run, a new OpenSim installation will ask you a series of questions to set up one region. If you want to change these settings or set up multiple regions, please see [[Configuring_Regions]]

==Starting the regions==
When using R.O.B.U.S.T., a setting that was not needed in standalone mode needs to be changed from it's default.
Open OpenSim.ini and find the section titled [Network]. Change the inventory_server_url to read http://127.0.0.1:8003.
[Network]
inventory_server_url = "http://127.0.0.1:8003"

Next, find the [Architecture] section, comment out the line that says
Include-Standalone = "config-include/Standalone.ini"
and uncomment the line saying
Include-Grid = "config-include/Grid.ini

save OpenSim.ini, and go into the config-include directory.
copy the following files
GridCommon.ini.example to GridCommon.ini
CenomeCache.ini.example to CenomeCache.ini
FlotsamCache.ini.example to FlotsamCache.ini

Open all these files (Grid.ini, GridCommon.ini, CenomeCache.ini and FlotsamCache.ini) and edit to suit your needs

You should now be ready to start up your sim. The mode that OpenSim.exe starts in is normally controlled by a setting in your OpenSim.ini. It defaults to standalone mode if that setting is not specified or the file is not found. If you wish, you can force opensim to start in gridmode on the command line as follows:
OpenSim.exe -gridmode=true
or:
mono OpenSim.exe -gridmode=true
With any luck, everything will come up without too many errors. 

If you have problems using the OpenDynamicsEngine on *nix, try setting your stack reserve level higher than the default with the following command;
<tt>ulimit -s 262144</tt> Or, run the opensim-ode.sh to start up OpenSimulator.

Go to the UserServer console, and type 'create user' to create a new avatar. It will prompt you for the name and password, and the X and Y of the sim that should be his home location. Use 1000 and 1000, or wherever you told your sim to live when you brought it up in standalone mode. At the console of any of these servers, you should be able to type 'help' to get a list of commands.

You should now be able to connect to your new grid with your secondlife client. You need to tell your client to point at the UserServer rather than directly at the sim, though:
secondlife -loginuri http://127.0.0.1:8002/
8002 is the default port for the UserServer, and that IP address should be changed to the server you are running the UserServer on, if they are not all on the same box. Happy OpenSimming! 
''Note: if you are using Windows Vista, remember to start servers as Admin. If not it will prompt you an error in console like "Error - Access denied"''

==Attaching your sim to someone else's grid==
To set up the region server (i.e., <tt>OpenSim.exe</tt>) to connect to an external grid, you should edit the <tt>OpenSim.ini</tt> file in the <tt>bin</tt> directory. In that file, there is a <tt>[Network]</tt> section with URLs for the grid, user, and asset servers, as well as send and receive keys (for a basic level of security). The addresses and send/receive keys will vary depending on the grid you are connecting to, and the grid operator should tell you what values to use.

The other file you may have to change is in your <tt>bin/Regions</tt> directory. This is where your individual region config files are. If you only have one region, it will by default be called <tt>Regions.ini</tt> in OpenSim 0.6.7 and later and <tt>regions.xml</tt> in OpenSim 0.6.6 and earlier.

This can be edited with any text editor. The grid owner may tell you what X and Y location you can place your sim at (you can't have multiple sims at the same location on the grid). If so, the fields you will need to change in this file are <tt>sim_location_x</tt> and <tt>sim_location_y</tt>. And the <tt>external_host_name</tt> should be set to the hostname or IP address of your simulation server (i.e., the machine that is running <tt>OpenSim.exe</tt>).
A list of public grids that you can attach your sim to is at [[OpenSim: Grids]]

==Running==

===Running OpenSim 0.6.7 and onwards in 64 bit Windows===
[[Image:Exclamation.png|left]]
As of OpenSim 0.6.7, the default physics engine for OpenSim was changed to the ODE engine. This is because ODE is by far the most advanced physics engine plugin currently in OpenSim. Unfortunately, it has the drawback in that it's library is not compilable under 64bit in Windows. Therefore, 64 bit Windows users may need to run

OpenSim.32BitLaunch.exe

instead of

OpenSim.exe

To launch their region simulator.

An alternative is to use the basicphysics engine instead or one of the other alternative physics engines bundled with OpenSim, though all these are far less functional than the ODE plugin.

===StandAlone===
'''Windows'''
cd bin
OpenSim.exe (or OpenSim.32BitLaunch.exe if using the ODE physics engine under 64 bit Windows)
On Windows Vista, it may be necessary to explicitly "Run as administrator" for opensim.exe to accept connections from a client, even when running as an administrator user. Navigate to the opensim\bin directory, right click opensim.exe, and select "Run as administrator".

'''Linux / Mac OS X'''
cd bin
mono OpenSim.exe

===Local Grid===
====OpenSim 0.6.7====
'''Windows'''
cd bin
OpenSim.Grid.UserServer.exe
OpenSim.Grid.GridServer.exe
OpenSim.Server.exe
OpenSim.Grid.MessagingServer.exe
OpenSim.exe (or OpenSim.32BitLaunch.exe if using the ODE physics engine under 64 bit Windows)

'''Linux / Mac OS X'''
cd bin
mono OpenSim.Grid.UserServer.exe
mono OpenSim.Grid.GridServer.exe
mono OpenSim.Server.exe
mono OpenSim.Grid.MessagingServer.exe
mono OpenSim.exe

====OpenSim 0.6.6 and earlier====
'''Windows'''
cd bin
OpenSim.Grid.UserServer.exe
OpenSim.Grid.GridServer.exe
OpenSim.Grid.AssetServer.exe
OpenSim.Grid.InventoryServer.exe
OpenSim.Grid.MessagingServer.exe
OpenSim.exe (or OpenSim.32BitLaunch.exe if using the ODE physics engine under 64 bit Windows)

'''Linux / Mac OS X'''
cd bin
mono OpenSim.Grid.UserServer.exe
mono OpenSim.Grid.GridServer.exe
mono OpenSim.Grid.AssetServer.exe
mono OpenSim.Grid.InventoryServer.exe
mono OpenSim.Grid.MessagingServer.exe
mono OpenSim.exe

===Note About Mono===
If you're using mono, you should increase the value of the mono environment variable MONO_THREADS_PER_CPU from its default of 5 to some number that works for your sim. The exact number depends on many factors including: the number of CPUs in your machine, what else you use that machine for, how many regions you have in your sim, how many of them are adjacent, how many scripts you have, and how many avatars you expect to serve at the same time. As a reference, Wright Plaza in OSGrid, which is running as a single region on a sim and routinely hosts meetings with 20 avatars, uses the value 125.

If this number is too low, the operation of your sim will start to break in all sorts of different ways. A common symptom is the freezing of all activity upon login of a new avatar. Other symptoms are a lot more subtle.

For example: $ export MONO_THREADS_PER_CPU=125

== Legacy Configuration Information ==
These are some pages containing some legacy configuration information of unknown accuracy.

[[OpenSim 0.6.6 legacy configuration information]]

== Additional Configuration Tasks (for advanced users) ==

===OpenSim.exe command line options===
OpenSim.exe has command line options which allow you to perform actions such as reading configuratio nfiles from a different directory. See [[OpenSim.exe Command Line Options]] for more details.

===Script engine===
OpenSim supports multiple script engines. See [[ScriptEngines]] for details. If you don't know what this means then the default script engine will be fine.

===Permissions Configuration===
OpenSim has a quite elaborate set of permissions. See [[OpenSim:Permissions(Server)]] for details. By default, permissions are not active on region simulators.

=== Logging ===
By default, OpenSim logs information to a file called OpenSim.log in the bin directory. See [[Logging]] for details on how to further configure this if required.

=== Configuration of region modules ===
* [[IRCBridgeModule]]
* [[Freeswitch_Module]]
* [[Offline Messaging]]

=== Configuration of Metaverse Exchange Protocol (MXP) ===
* [[Metaverse Exchange Protocol]]

=== Configuration of Web Server and Pages===
OpenSim contains a web server that can serve up a variety of pages. Some which come from external files and some are generated internally.
* [[External Files]]
* [[Internally Generated]]

FAQ

2009-11-10T15:12:29Z

Karen Palen: /* How do I isolate and delete a user's Trash items in a MySQL grid database? */

{{Template:Quicklinks}}
 

[[Category:Users]]
==About OpenSim==
===What is OpenSim?===
OpenSim is a platform for operating a virtual world, and supports multiple independent regions connecting to a single centralized grid. This is somewhat similar to the web, where anyone can run their own web server, tied together through the internet. It can also be used to create a private grid, analogous to a private intranet.

===What is a region?===
A region is what you see when you log into OpenSim. It is the physical place (well, virtual physical space) where avatars move and interact. It is a square patch of land which may contain an island, mountains, a plain, buildings, etc., or just an ocean.

===What is the grid?===
The grid is the level that organizes the regions and their positions in the world, and handles things that need to exist across regions, such as a user's inventory. You can think of it as similar to the world map.

===What does ... mean?===
See [[Technical_Reference | OpenSim:Technical Reference]] for definitions of some terms commonly used in OpenSim.

==Configuring OpenSim==
First, read [[OpenSim Configuration]].
===Where can I get a new UUID for my sim config?===
* See [[OpenSim Configuration]]

===Can I run multiple regions with OpenSim?===
* See [[OpenSim Configuration]]

===What databases can be used with OpenSim?===
* See [[OpenSim Configuration]]

==Running OpenSim==

===I get a bunch of ERROR: There was an error while scanning assembly:... 
errors on startup, but OpenSim appears to run normally. Is this a problem?===
No. These errors are being put out by the third party plugin scanning code. As we have it scanning the entire bin/ directory, it picks up dlls which don't have the correct information to be scanned, and so puts out this error. Don't worry about it :)

For the record, the current set of errors are

ERROR: There was an error while scanning assembly: /home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/PhysX-wrapper.dll (Could not load file or assembly '/home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/PhysX-wrapper.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.)

ERROR: There was an error while scanning assembly: /home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/ode-debug.dll (Could not load file or assembly '/home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/ode-debug.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.)

ERROR: There was an error while scanning assembly: /home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/ode.dll (Could not load file or assembly '/home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/ode.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.)

ERROR: There was an error while scanning assembly: /home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/openjpeg-libsl.dll (Could not load file or assembly '/home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/openjpeg-libsl.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.)

ERROR: There was an error while scanning assembly: /home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/sqlite3.dll (Could not load file or assembly '/home/caseyj/jc/it/v/virtual-worlds/second-life/servers/opensim/src/opensim-svn-minim/bin/sqlite3.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.)

===Errors about modules not found and RegionBanListItem could not be loaded===

This is caused if you upgrade from trunk through svn and copy new files in the same directory.
To solve these errors during the startup of opensim.exe remove the following files from your bin folder:

OpenSIm.DataStore.MSSQL.dll

OpenSIm.DataStore.MSSQL.dll.mdm

==OpenSim in the Wild==
===Are there test servers running OpenSim I can connect to?===
Yes. Check out our [[Grid List]]! There are often many private servers up for testing. Hang out on the IRC channel (Freenode #opensim), and troll for URI's.
=== Can I teleport from the Linden Lab Second Life grid to my Sim? (updated!)===
Yes and No, Since the new public beta, launched on july 31th 2008 by Linden Lab, it is now possible to connect opensim servers/regions with the Second life grid, however this is not intended for regular users. 
NOTE: currently it ONLY works with the preview/beta grid of second life, not the main grid.) 
It's in an early development stage and thus geared towards developers of virtual world/techniques, and is all but easy to setup. Furthermore, when an avatar is hopping from an SL region to an Opensim region, the avatar will be "ruthed", meaning it will be the default Secondlife avatar. NO assets (incl, shapes, skins, clothing etc) are tranfered during teleport, hence you wont have access to them, on the other grid. The beta test, is currently focussing on Teleportation between grids mainly. In the future, it should be possible to teleport WITH asset tranfers. But that wont be happening any time soon. If you want to try it out, read this page for more info on how to get started (with all the risks involved, don't say i didn't warn you): [http://blog.secondlife.com/2008/07/31/open-grid-public-beta-begins-today/ http://blog.secondlife.com/2008/07/31/open-grid-public-beta-begins-today/] 
For normal operation, stick to the regular versions of opensim.

==MySQL==
===How do I isolate and delete a user's Trash items in a MySQL grid database?===
NOTE: BACK UP YOUR DATABASE!

CAUTION: The Linux default directory for the MySQL database is /var/lib/mysql Many backup tools (e.g. backupPC) do NOT back up /var/*! Make certain that the database and not just the MySQL code (/usr/bin/mysql) is included in your nightly backups! The actual paths will be different for different operating systems and databases, but the problem is the same.

'''1.''' Locate the avatars UUID you wish to find the trash items of, in the '''users''' table 
This query will locate a specified users UUID: (replace User/Test with username/lastname)
<nowiki>SELECT `UUID` FROM `users` WHERE `username` LIKE 'User' AND `lastname` LIKE 'Test' LIMIT 0 , 30;</nowiki>
 
'''2.''' Use the avatars UUID to search the field_name '''AgentID''' in the '''inventoryFolders''' table, using '''Trash''' as the '''folderName''' to isolate the users Trash '''folderID''' 
This query will locate the users Trash folder entry: (replace 00000000-0000-0000-0000-000000000000 with UUID of user)
<nowiki>SELECT `folderID` FROM `inventoryfolders` WHERE `agentID` LIKE '00000000-0000-0000-0000-000000000000' AND `folderName` LIKE 'Trash'
LIMIT 0 , 30;</nowiki>
 
'''3.''' Use the '''folderID''' UUID obtained in the last query to find all of the trash items in the '''inventoryitems''' table, you can then delete them once you have isolated them. 
This query will locate the trash items of the avatar in question: (replace 00000000-0000-0000-0000-000000000000 with Trash folder UUID obtained in the last query)
<nowiki>SELECT * FROM `inventoryitems` WHERE `parentFolderID` LIKE '00000000-0000-0000-0000-000000000000' LIMIT 0 , 9999;</nowiki>
 
'''NOTE:''' These steps will not remove the associated assets from the assets table, just the items in the inventory '''inventoryitems''' table.

===How do I isolate and resolve duplicate inventory folder entries in a MySQL grid database?===
NOTE: BACK UP YOUR DATABASE! 

'''1.''' It's first a good idea to search for the affected avatars UUID in the '''inventoryFolders''' table to see the duplicate entries. When you see this, you'll see the problem of duplicate entries. The key here will be to find out which is being used. 

'''2.''' Upload a file inworld and name it something unique. This will isolate the UUID of your root folder that is being used (even though there are dups only one is being used) 

'''3.''' Search the '''inventoryitems''' table for your uniquely named item and locate it's '''parentFolderID''' 
This query will isolate the '''parentFolderID''' based on your search for the unique item (replace '''unique_name''' with your unique item name)
<nowiki>SELECT `parentFolderID` FROM `inventoryitems` WHERE `inventoryName` LIKE 'unique_name' LIMIT 0 , 30;</nowiki>

'''4.''' Check the '''inventoryfolders''' table against the '''parentFolderID''' UUID obtained in the last search. That is your root folder that is being used.. you can delete all duplicate entries that do not match that parentFolderID. In the end, you should only have one of each type (Trash, etc) 
This query will return all values that are NOT the parentID obtained in the last search. (replace 00000000-0000-0000-0000-000000000000 with the parentID located in step 3)
<nowiki>SELECT * FROM `inventoryfolders` WHERE `folderID` NOT LIKE '00000000-0000-0000-0000-000000000000' LIMIT 0 , 30;</nowiki>

==In World Questions==
=== Does in world scripting work yet? ===
Not fully implemented, but there is a lot of work going on here. Please see [[ScriptEngines]], [[LSL Status]] and [[OSSL Status]] for the latest info.

===Why do I walk through objects?===
Basicphysics doesn't support collisions between objects (just between you and the ground). There is active work on other [[PhysicsEngines | physics engines]] for OpenSim, the one that does most of the job and is most stable is the ODE (Open Dynamics Engine), which can be configured for use in OpenSim.ini.

===Can I customize my avatar?===
Yes. In order to do this:
* Click the Inventory Button
* Create -> New Clothes -> Shirt, Pants, etc
* Create -> New Body Parts -> Hair, Shape, etc
* Edit those from your inventory
* Wear them

Your avatar doesn't always face a nice direction for doing this, so you'll need to use the camera operations to see your face for some of the modifications. This is a known issue, will be fixed in the future. Also, you'll need to rewear you parts once you first join the environment. Right now default appearance is always "Ruth".

===Why do I look like I gas cloud right after I did the the previous steps?===
Second Life eliminated Ruth from their client. The Ruth we see in OpenSim is our own attempt of a yoga teacher and not truly Second Life's Ruth. When you create a shirt, pants, skin and shape and wear them without changing any parameters, the Second Life Viewer understands you are not Ruth. Since Ruth is no more, you become a cloud of gas. To fix it, either change a parameter of one of them before wearing all 4, or, if you already are a gas cloud, right click one of these items in your inventory and click edit. That should bring up the edit appearance menus. Just move any sliders and voilá.

===Why don't my terrain settings and prims stay through restarts?===
You haven't set it up to use a database. See [[OpenSim_Database_support|OpenSim Database support]] for info on how to set it up to use a database. (SqLite is the easiest of these to set up and should probably be used by anyone unfamiliar with any of the options).

===I used XEngine, but my recent update caused DotNetEngine to come on again===
There were some changes and you will need to change or create the line DefaultScriptEngine = "XEngine" in the startup section to get XEngine back. See [[ScriptEngines]]

===Why doesn't my world map update when I edit the terrain?===
There are three approaches depending on just how adventurous you want to be. From the least to the most adventurous:
* Wait two days. You will need to restart your sim at the end of the two days to get the updates.
* Exit the .xml file for the region. Change the value in the "lastmap_refresh" attribute to "0". You will need to restart the sim.
* Not for the faint of heart! Edit the "WorldMapModule.cs" file and change the "LazySaveGeneratedMaptile" method to change the "RefreshSeconds" value to something less than two days. Be sure to read the comments and understand why things are the way they are.

Once your terrain stabilizes, this won't be much of a problem, but it is nice to see the updates while you're furiously developing something.

===Why are my knees bent when I stand idle?===
This seems to be a result of the ODE Physics Engine on 64 bit systems. A fix is to edit OpenSim.ini and change the following line:
* av_capsule_standup_tensor_linux = 550000
to
* av_capsule_standup_tensor_linux = 1700000

Note that this line of code is under the [ODEPhysicsSettings] section of the OpenSim.ini file.

==Grid Mode==
=== After the shiny new grid is running, what is next? ===
* Make sure one can stop/restart UGA &S (sims). Check out any ordering issues of stop/restart UGA w/o stop/restart sim(s).
* Make sure one can add/delete both a region and a user from the database.
* Make sure it runs overnight and check it each morning by logging into 1 or 2 key sims.
* '<tt>tail -f userserver.log</tt>' and watch/understand the login process.
* Make sure when you logoff your system, you can log back on and get control of the UGAS consoles.

==Region Statistics on a Web Page==
===Information about your regions.===
Region statistics such as region name, avatar name, avatar position<x,y,z>, number of prims, and a lot of other information can be obtained on a web page by:
* Adding the following to the bottom of the [[Technical Reference/terms/OpenSim.ini | OpenSim.ini ]] file
[WebStats]
enabled=true
* Using a web browser and typing in the "Login URI" + "/SStats/" of your standalone server.
For example- <nowiki>http://127.0.0.1:9000/SStats/</nowiki>
The resulting web page is continually updated using AJAX, so there is no need to refresh the page to obtain current information. One possible use for this web page information would be to see who is logged on to the region in real time - without actually logging in. 
This web page provides region information similar to the kind generated by using various server console commands to obtain region statistics. See [[Technical_Reference/Server_Commands | Server_Commands]]

== Misc ==
=== You guys like April 1st, eh? Looks like the joke is on us... ===
Yes, every year we've had a piece of non destructive code in the unstable, unreleased, upstream subversion tree. The source tree that is only designed for testers and developers. In each case it has shown something that is possible in OpenSim that most people might not have realized. In 2008 this was an avatar created entirely from a Region Module (no user), in 2009 it was making all users a giant (and I mean giant) stick bug avatar. There will be more in the future, don't worry. The developers seem to have a sense of humor.

[[Category:Users]]

Download

2009-10-15T03:05:55Z

Karen Palen: /* Installers */

{{Template:Quicklinks}}
=Source code=
Here are the current released versions of OpenSim.

Please see [[Branches]] for more information on the repository branches and what they are for.

'''Please note:''' As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.

Also, please be aware that OpenSim requires that you have a fair amount of technical knowledge in order to set it up.

The latest source releases are always hosted at http://dist.opensimulator.org, the current latest releases is '''0.6.7''' and provided as:
* http://dist.opensimulator.org/opensim-0.6.7-release.tar.gz - best for Linux systems
* http://dist.opensimulator.org/opensim-0.6.7-release.zip - best for Windows systems

The only difference between the two is the archive format, the source is exactly the same.

== Release Code via Git ==

Instead of using a source archive release, you can pull specific releases from our git repository. For more information on installing and using Git, please see [[Using_Git]].

In each case you'll want to start with a clone:

git clone git://opensimulator.org/git/opensim

Then all other commands are run from inside the checked out directory.

* '''0.6.7 Alpha with post-release fixes''' (preferred)
git checkout -b 0.6.7-post-fixes origin/0.6.7-post-fixes

* '''0.6.7 Alpha release tag'''
git checkout 0.6.7-release

== Release notes ==

These are extracted from the subversion history log and correlated with the tagged releases. It should provide some idea of the changes between each tagged version. How ever, since the tagged releases are moved out of the trunk, the versions aren't an exact correlation. Please read and understand [[Release Cycle]] and [[On revisions, tags and branches]] before using this information.
* [[Recent]] (since last tagged version)
* [[0.6.6-release]] (SVN version 9961)
* [[0.6.5-release]] (SVN version 9667)
* [[0.6.4.1-release]] (SVN version 9009)
* [[0.6.4-release]] (SVN version 8960)
* [[0.6.3-release]] (SVN version 8506)
* [[0.6.2-release]] (SVN version 8068)
* [[0.6.1-release]] (SVN version 7880)
* [[0.6.0-release]] (SVN version 7176)
* [[0.5.11-release]] (SVN version 6676)
* [[0.5.10-release]] (SVN version 6422)
* [[0.5.9-release]] (SVN version 5970)
* [[0.5.8-release]] (SVN version 5111)
* [[0.5.7-release]] (SVN version 4818)
* [[0.5.6-release]] (SVN version 4488)
* [[0.5.5-release]] (SVN version 4239)
* [[0.5.4-release]] (SVN version 3879) (Not sure what happened to 0.5.3 & 0.5.2)
* [[0.5.1-release]] (SVN version 3724)
* [[0.5.0-release]] (SVN version 3184)
* [[0.4.5.3-stable]] (SVN version 2844)
* [[0.4.5.2-stable]] (SVN version 2772)
* [[0.4.5.1-stable]] (SVN version 2610)
* [[0.4.5-release]] (SVN version 2293)
* [[0.4.0-rc]] (SVN version 1953)
* [[0.3.2-release]] (SVN version 1385)
* [[0.3.1-devel]] (SVN version 1226) (Around here things start to get a bit confusing)
* [[0.2.1-release]] (SVN version 1224)
* [[0.3.0-devel]] (SVN version 1126)
* [[0.0.0-release]] (SVN version 1022)
* [[0.1.0-release]] (SVN version 1021)
* [[0.2.0-release]] (SVN version 1020)

=Binaries=
The OpenSim project only does source based releases, which you must [[Build_Instructions|compile]] yourself. Many members of our community provide binary installers that you can used based on those source releases. Links below are provided for convenience.

==Installers==

* '''0.6.6 Windows Installer (Post-fixes version r9993)'''
http://forge.opensimulator.org/gf/download/frsrelease/199/588/OpenSim0.6.6Setup.exe

* '''0.6.6 Mac OS X Installer (Post-fixes version r9993)'''
http://forge.opensimulator.org/gf/download/frsrelease/198/587/OpenSimulator-0.6.6-post-fixes-r9993.dmg

* '''Unofficial 0.6.6 Linux Debian and Ubuntu .deb packages
http://opensimulator.org/wiki/UnofficialDebPackages

==Diva Distribution==

* '''Preconfigured hypergrided standalone.''' Easy to setup and to keep up to date. Windows and Linux/Unix. Download the file diva-rNNNN.zip, unzip it, read README.txt and take it from there.
http://github.com/diva/diva-distribution/downloads

= Older Versions Archive =

All older versions of OpenSim are available from the Git repo (this includes fully converted versions of every change that existed in the subversion repository, including all old tags and branches). Please be aware that even if there is zero official support for the latest version, there's even less support for older ones. They are kept here for historical and technological reference only.

The 'official' release tags and branches are all available from:
git://opensimulator.org/git/opensim

The named branches are typically extremely experimental offshoots. Stick with recent numbered versions if you expect anything to work.

= Experimental Upstream Code =
'''There Be Dragons Beyond This Point'''

If you are truly feeling dangerous, adventurous, or want to help us test the next version of OpenSim you are welcome to grab the latest unstable code out of our git master repository. Any warnings previous expressed about the alpha nature of the code go double or triple if you are running directly off of master. '''Never, ever, ever, never''' run this in production environments, it is not suitable for that unless you are very familiar with the source code, and can hot fix any piece of it (that probably means you are an OpenSim core member). Feedback and testing on the unstable tree is appreciated, as that helps us make the next release better. If this scares you from using trunk, that was intended.

If it breaks, you get to keep both pieces.

* '''Latest git revision version (bleeding edge)'''
git clone git://opensimulator.org/git/opensim

* '''To checkout a specific revision'''
After creating the clone, chnage into the directory and:
git reset --hard ########

Where ######## is the unique hash of the version you are interested in.

Another option for obtaining the code is via subversion with our svn mirror. This mirrors all git changes since the old 10k1 changeset in subversion. It is synchronized every 15 minutes, so may be 15 minutes behind git master.

* '''Latest subversion revision version (bleeding edge)'''
svn co http://opensimulator.org/svn/opensim-track/trunk opensim

=Related Software=
[[Related_Software|Related Software Section - CLICK HERE]] 

''Pages by Category:''[[:Category:Users| User-pages]],[[:Category:Development| Developer-pages]],[[:Category:Scripts| Scripts]] 

[[Category:Users]]
[[Category:Developers]]
<cleanpage title=hide cats=hide />

Download

2009-10-15T03:02:39Z

Karen Palen: /* Installers */

{{Template:Quicklinks}}
=Source code=
Here are the current released versions of OpenSim.

Please see [[Branches]] for more information on the repository branches and what they are for.

'''Please note:''' As OpenSim is still at an alpha code maturity stage, there is absolutely no guarantee that functionality works or is stable, even in the numbered releases. Certain features may not work either because the code is in rapid evolution, or because functionality expected by the Linden Labs Second Life viewer has simply not been implemented yet. However, constructive feedback is still welcomed.

Also, please be aware that OpenSim requires that you have a fair amount of technical knowledge in order to set it up.

The latest source releases are always hosted at http://dist.opensimulator.org, the current latest releases is '''0.6.7''' and provided as:
* http://dist.opensimulator.org/opensim-0.6.7-release.tar.gz - best for Linux systems
* http://dist.opensimulator.org/opensim-0.6.7-release.zip - best for Windows systems

The only difference between the two is the archive format, the source is exactly the same.

== Release Code via Git ==

Instead of using a source archive release, you can pull specific releases from our git repository. For more information on installing and using Git, please see [[Using_Git]].

In each case you'll want to start with a clone:

git clone git://opensimulator.org/git/opensim

Then all other commands are run from inside the checked out directory.

* '''0.6.7 Alpha with post-release fixes''' (preferred)
git checkout -b 0.6.7-post-fixes origin/0.6.7-post-fixes

* '''0.6.7 Alpha release tag'''
git checkout 0.6.7-release

== Release notes ==

These are extracted from the subversion history log and correlated with the tagged releases. It should provide some idea of the changes between each tagged version. How ever, since the tagged releases are moved out of the trunk, the versions aren't an exact correlation. Please read and understand [[Release Cycle]] and [[On revisions, tags and branches]] before using this information.
* [[Recent]] (since last tagged version)
* [[0.6.6-release]] (SVN version 9961)
* [[0.6.5-release]] (SVN version 9667)
* [[0.6.4.1-release]] (SVN version 9009)
* [[0.6.4-release]] (SVN version 8960)
* [[0.6.3-release]] (SVN version 8506)
* [[0.6.2-release]] (SVN version 8068)
* [[0.6.1-release]] (SVN version 7880)
* [[0.6.0-release]] (SVN version 7176)
* [[0.5.11-release]] (SVN version 6676)
* [[0.5.10-release]] (SVN version 6422)
* [[0.5.9-release]] (SVN version 5970)
* [[0.5.8-release]] (SVN version 5111)
* [[0.5.7-release]] (SVN version 4818)
* [[0.5.6-release]] (SVN version 4488)
* [[0.5.5-release]] (SVN version 4239)
* [[0.5.4-release]] (SVN version 3879) (Not sure what happened to 0.5.3 & 0.5.2)
* [[0.5.1-release]] (SVN version 3724)
* [[0.5.0-release]] (SVN version 3184)
* [[0.4.5.3-stable]] (SVN version 2844)
* [[0.4.5.2-stable]] (SVN version 2772)
* [[0.4.5.1-stable]] (SVN version 2610)
* [[0.4.5-release]] (SVN version 2293)
* [[0.4.0-rc]] (SVN version 1953)
* [[0.3.2-release]] (SVN version 1385)
* [[0.3.1-devel]] (SVN version 1226) (Around here things start to get a bit confusing)
* [[0.2.1-release]] (SVN version 1224)
* [[0.3.0-devel]] (SVN version 1126)
* [[0.0.0-release]] (SVN version 1022)
* [[0.1.0-release]] (SVN version 1021)
* [[0.2.0-release]] (SVN version 1020)

=Binaries=
The OpenSim project only does source based releases, which you must [[Build_Instructions|compile]] yourself. Many members of our community provide binary installers that you can used based on those source releases. Links below are provided for convenience.

==Installers==

* '''0.6.6 Windows Installer (Post-fixes version r9993)'''
http://forge.opensimulator.org/gf/download/frsrelease/199/588/OpenSim0.6.6Setup.exe

* '''0.6.6 Mac OS X Installer (Post-fixes version r9993)'''
http://forge.opensimulator.org/gf/download/frsrelease/198/587/OpenSimulator-0.6.6-post-fixes-r9993.dmg

* '''[[UnofficialDebPackages|Unofficial .deb packages (Debian and Ubuntu)]]

==Diva Distribution==

* '''Preconfigured hypergrided standalone.''' Easy to setup and to keep up to date. Windows and Linux/Unix. Download the file diva-rNNNN.zip, unzip it, read README.txt and take it from there.
http://github.com/diva/diva-distribution/downloads

= Older Versions Archive =

All older versions of OpenSim are available from the Git repo (this includes fully converted versions of every change that existed in the subversion repository, including all old tags and branches). Please be aware that even if there is zero official support for the latest version, there's even less support for older ones. They are kept here for historical and technological reference only.

The 'official' release tags and branches are all available from:
git://opensimulator.org/git/opensim

The named branches are typically extremely experimental offshoots. Stick with recent numbered versions if you expect anything to work.

= Experimental Upstream Code =
'''There Be Dragons Beyond This Point'''

If you are truly feeling dangerous, adventurous, or want to help us test the next version of OpenSim you are welcome to grab the latest unstable code out of our git master repository. Any warnings previous expressed about the alpha nature of the code go double or triple if you are running directly off of master. '''Never, ever, ever, never''' run this in production environments, it is not suitable for that unless you are very familiar with the source code, and can hot fix any piece of it (that probably means you are an OpenSim core member). Feedback and testing on the unstable tree is appreciated, as that helps us make the next release better. If this scares you from using trunk, that was intended.

If it breaks, you get to keep both pieces.

* '''Latest git revision version (bleeding edge)'''
git clone git://opensimulator.org/git/opensim

* '''To checkout a specific revision'''
After creating the clone, chnage into the directory and:
git reset --hard ########

Where ######## is the unique hash of the version you are interested in.

Another option for obtaining the code is via subversion with our svn mirror. This mirrors all git changes since the old 10k1 changeset in subversion. It is synchronized every 15 minutes, so may be 15 minutes behind git master.

* '''Latest subversion revision version (bleeding edge)'''
svn co http://opensimulator.org/svn/opensim-track/trunk opensim

=Related Software=
[[Related_Software|Related Software Section - CLICK HERE]] 

''Pages by Category:''[[:Category:Users| User-pages]],[[:Category:Development| Developer-pages]],[[:Category:Scripts| Scripts]] 

[[Category:Users]]
[[Category:Developers]]
<cleanpage title=hide cats=hide />

Artist Home

2009-10-11T21:56:25Z

Karen Palen: /* Artist Documentation */

{{Template:Quicklinks}}

== Artist Documentation ==

This page contains information about content creation for OpenSimulator including best practices, guides, tools, examples, collaborative projects and of course Creative Commons licensed content.

Discussion group for people interested in creating content for Metaverse: [[http://groups.google.com/group/open-content-for-metaverse Open Content for Metaverse]]

Some useful resources of free material:

A great summary sheet: [[http://docs.google.com/View?docid=dgsbx7zg_9mzk6nxtc 3DCG for the hobbyist -- useful products and links]]

A hobbyist animators blog with all kinds of goodies: [[http://www.cgspeed.com/ cgspeed]]

A source for free animations, 3d models, textures, etc.: [[http://www.sharecg.com/ ShareCG]]

A huge 3d graphics source: [[http://www.renderosity.com/ Renderosity]]

A 3d Artists community: [[http://www.3dcommune.com/ 3dcommune]]

Runtime DNA: [[http://www.runtimedna.com/forum/downloads.php www.runtimedna.com Free Downloads]]

Adult oriented content: [[http://www.raunchyminds.com/gallery/categories.php?cat_id=15 RaunchyMinds Freebies Download]]

This is not an exhaustive list, please add to it if you can!

I have tried to include sites which have free Poser/Opensim compatible content which could be used for "personal use" in your own "world". You must check the licensing for any commercial uses.

== Textures ==

Textures are images used to cover surfaces of 3d models and terrain. Textures can be anything form 1x1 to 1024x1024 images. Most of the textures for buildings, items and clothes are usually 512x512.

=== Best Practices ===

=== Guides ===

* Creating tileable textures: [[http://www.gfxartist.com/features/tutorials/740]]

=== Tools ===

* [[http://www.gimp.org/ GIMP]] - GIMP is the GNU Image Manipulation Program.

=== Examples ===

=== Projects ===

=== Content Libraries ===
* [http://torley.com/torley-textures-available-for-download-in-a-single-zip-pack Torley Textures] is a collection of over 600 textures by Torley Linden. (New download location: http://torley.s3.amazonaws.com/Torley-Textures.zip)

== Models ==

Models are 3 dimensional objects which are formed from faces and textures. Models come in many flavors but currently OpenSimulator supports parametrized primitives and sculpted primitives. Parametrized primitives can be created in world with build functionality. Sculpted primitives are defined by a special bitmap image which can be created with 3d modeling programs which support sculptures.

Yet unsupported in core OpenSimulator are 3d models which can be created with 3d modeling softwares like Blender and be saved in various formats. RealXtend module to OpenSimulator already supports 3d models.

=== Best Practices ===

=== Guides ===

=== Tools ===

* [[http://www.blender.org/ Blender]] - Blender is the free open source 3D content creation suite, available for all major operating systems under the GNU General Public License.
* [[http://www.wings3d.com/ Wings 3d]] - Sculpty editor
* [[http://www.qavimator.org/ Qavimator]] - Animation for OpenSim avatars

=== Examples ===
[[Image:Biped.jpg]]

=== Projects ===

* [[OpenSimulator Avatar]]

=== Content Libraries ===

== Terrain ==

Currently OpenSimulator terrains consists of heightmap and textures for different directions and heights. OpenSimulator terrain can be imported in raw terrain format from several terrain editor tools.

=== Best Practices ===

=== Guides ===
* [[Tips#Terrain Tidbits|Terrain Tips]]
* [[Using L3DT]]
* [[Terrain making]]
* [[Detailed cross-region terrain making]]

=== Tools ===

* L3DT

=== Examples ===

=== Projects ===

=== Content Libraries ===

*[[Free Terrains]]

 

=== Additional Terrain Resources ===

'''TERRAIN EDITING'''

There is now a Plugin made and available for the free program GIMP by Domino Designs. See [http://dominodesigns.info/project/gimpterrainwhich http://dominodesigns.info/project/gimpterrainwhich] is easy to install and allows you to bring in RAW files and edit them.

GIMP is available free and downloadable at [http://www.gimp.org/downloads/ http://www.gimp.org/downloads/ ] GIMP is available for most Operating Systems and Platforms and is User Supported with many features and functions far beyond Terrain Editing.

 '''REFERENCES / SUPPLEMENTAL SOURCES & APPLICATIONS:''' [http://opensimulator.org/wiki/Tweaking http://opensimulator.org/wiki/Tweaking] Tutorial: Creating OpenSim terrain with Blender [http://stringofbits.net/2009/09/tutorial-creating-opensim-terrain-with-blender/ http://stringofbits.net/2009/09/tutorial-creating-opensim-terrain-with-blender/] Some Free & Some Not, Terrains @ [http://www.rexxed.com/category/terrain/ http://www.rexxed.com/category/terrain/]

Spinmass Virtual Creations, Has Two Products for Terrain Making and Generation which are Free Downloads. Look at Terrain Sculptor & Bailiwick. They are available from [http://www.spinmass.com/ http://www.spinmass.com/]

 '''Three easy to use Online Image Splitters'''

[Http://www.chami.com/html-kit/services/is/  http://www.chami.com/html-kit/services/is/]

[http://www.sliceimage.com/ http://www.sliceimage.com/]

[http://www.makeuseof.com/dir/online-image-splitter/ http://www.makeuseof.com/dir/online-image-splitter/] 

== Sounds ==

Sounds clips can be used within (scripted) objects and as part of gestures. Current OpenSimulator sound formats are PCM WAVE (.wav) 16-bit/44.1KHz/mono or stereo with a maximum length of 10.00 seconds.

=== Best Practices ===

=== Guides ===

=== Tools ===

* [[http://audacity.sourceforge.net/ Audacity]] - Audacity® is free, open source software for recording and editing sounds. It is available for Mac OS X, Microsoft Windows, GNU/Linux, and other operating systems.

=== Examples ===

=== Projects ===

=== Content Libraries ===

* [[http://www.freesound.org/ The Freesound Project]] - The Freesound Project is a collaborative database of Creative Commons licensed sounds.

== Music ==

=== Best Practices ===

=== Guides ===

=== Tools ===

=== Examples ===

=== Projects ===

=== Content Libraries ===

User Documentation

2009-09-11T20:48:09Z

Karen Palen: /* Platform specific */

{{Template:Quicklinks}}

[[Technical Reference | Technical Reference]] -> [[Technical Reference/terms | Terms]] -> [[User_Documentation | User Documentation]]

==Initial Setup==
* [[Download]] - Download instructions
* [[Dependencies]] - The other packages you need to install that OpenSim relies upon
* [[Build Instructions]] - How to build and compile OpenSim from Source
* [[Configuration]] - How to configure your OpenSim server up and running
* [[Upgrading]] - How to upgrade your OpenSim version so that you can use your existing data
* [[Connecting]] - How to connect a compatible viewer to OpenSim
* [[Troubleshooting]] - How to trouble shoot your OpenSim installation.
* [[Tips]] - Useful tips from users like you
* [[FAQ]] - Frequently Asked Questions
* [[Technical Reference]] - Technical Reference Guide

==Administrator Guide==
* [[Server Commands]] - Commands to control OpenSim
* [[OpenSim Database support]] - Dealing with databases
* [[Logging]] - Logging in OpenSim
* [[Custom Libraries]] - Describes how to add custom content to your OpenSim server
* [[Automating Tasks]] - How to make administrating a walk in the park
* [[Network Settings]] - NAT, Ports, Services and more...
* [[Management]] - All about being an effective administrator/moderator
* [[Performance]] - How to tweak OpenSim's performance
* [[Console-less OpenSim]] - How to run OpenSim without console
* [[Backups]] - How to backup your OpenSim data.

==Core Facilities==
* [[OpenSim Archives]] - Loading and saving whole region archives with OpenSim
* [[IRCBridgeModule]] - A core OpenSim module for integrating IRC with a simulator.
* [[Hypergrid]] - Information about how to configure the experimental hypergrid architecture
* [[GridInfo]] - how to provide information about your grid to smart clients

==RealXtend==
* [[ModRex]] - How to setup the RealXtend server module
* [[RealXtend Viewer Linux]] - This tutorial describes how to use the RealXtend viewer on Linux, using wine

==Scripting==
* [[Scripting Documentation]] - Everything you need to know about OpenSim scripting
* [[Scripting Library]] - A list of example scripts

==Tutorials==
===Platform specific===
* [[Linux Gridserver, the ubuntu way]] the quick and dirty way to install opensim under ubuntu (Linux)
* [[Wiimote]] - How to use a wiimote/nunchuk controller with the OpenSim viewer (Linux)
* [[Cacti]] - Generate Serverstats using the Cacti-Tool and SNMP (Linux)
* [http://sunredbeach.com/dokuwiki/doku.php?id=opensim:minimal-server Installing an openSUSE 11.1 Minimal server setup for an OpenSim server] - Quick and Dirty setup on an openSUSE 11.1 server

* [http://chapter-and-metaverse.blogspot.com Chapter & Metaverse] - Full suite of tutorials, tips and tricks, for the Windows user (Windows) Also very useful for Linux users!

===Cross-platform===
* [[OSGrid Region Registration]] - Describes how to link your region into OS-Grid
* [[Hints & Tricks]] - A page for Hints and Tricks
* [[Getting Started with Region Modules]] - The Hello World of OpenSim application development
* [[Building a bot]] - Getting started with bot design using libomv from the client side.
* [[pCampBot]] - Physical OpenSim bots
* [[Using L3DT]] - How to create custom terrains
* [[Detailed cross-region terrain making]] - A workflow for creating large cross-region custom terrains
* [http://update.multiverse.net/wiki/index.php/About_Terrain How to make a good Terrain (includes 4 programs to use)]

==Gforge Projects==
* [[OpenSimSearch]] - Search for your OpenSim
* [[Linux Gridserver]] - Linux Gridserver using the Moo tool
* [[Wixtd|WiXTD]] - Setup and usage of the WiXTD metaverse-portal
* [[ServerStats]] - RRD/Proc serverstats using the OpenSim module for Berlios Serverstats (Linux)
* [[JabberBridge]] - Jabber/Xmpp bridge for opensim (currently only works properly in Standalone mode)

==Unofficial Hypernauta's Basic Manual==
* If you are a real beginner it can be for you. Talking about "personal" worlds created using domestic computers. [http://www.dmu.com/opensime LINK]

==Contribution Policy==
* [[User_Wiki_Conventions|User Wiki Conventions]] - Read this carefully, before adding content to the wiki

[[Category:Users]]
[[Category:Support]]
[[Category:Tech Reference]]
[[Category:Help]]
[[Category:Configuration]]
[[Category:Getting_Started]]
[[Category:Development]]
<cleanpage title=hide cats=hide />