so, i took sean’s shell script and gave that a spin. that worked mostly — i had to adapt it to mono 1.9.1 for the mono-doc stuff and also install additional mono packages. here’s the revised edition:

#!/bin/sh

# This is needed to pick up our built mono for commands
export PATH=/usr/local/bin:$PATH 

apt-get install build-essential bison gawk
apt-get install libglib2.0-dev
apt-get install libpng12-dev libx11-dev libfontconfig1-dev
apt-get install libfreetype6-dev libjpeg62-dev libtiff4-dev
apt-get install libungif4-dev libexif-dev libcairo2-dev
apt-get install libpango1.0-dev libgtk2.0-dev libglade2-dev
apt-get install libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
apt-get install libgnomeprint2.2-dev libgnomeprintui2.2-dev
apt-get install libpanel-applet2-dev libgtksourceview-dev
apt-get install libgtkhtml3.14-dev

BUILDDIR=/usr/src/local/mono/1.9.1
mkdir -p $BUILDDIR
cd $BUILDDIR

wget -c http://go-mono.com/sources/libgdiplus/libgdiplus-1.9.tar.bz2
tar xvf libgdiplus-1.9.tar.bz2
cd libgdiplus-1.9
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://go-mono.com/sources/mono/mono-1.9.1.tar.bz2
tar xvf mono-1.9.1.tar.bz2
cd mono-1.9.1
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://switch.dl.sourceforge.net/sourceforge/nant/nant-0.86-beta1-src.tar.gz
tar xvf nant-0.86-beta1-src.tar.gz
cd nant-0.86-beta1
make install --prefix=/usr/local
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/gtk-sharp212/gtk-sharp-2.12.0.tar.bz2
tar xvf gtk-sharp-2.12.0.tar.bz2
cd gtk-sharp-2.12.0
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/gecko-sharp2/gecko-sharp-2.0-0.13.tar.bz2
tar xvf gecko-sharp-2.0-0.13.tar.bz2
cd gecko-sharp-2.0-0.13
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://go-mono.com/sources/gnome-sharp2/gnome-sharp-2.16.1.tar.gz
tar xvf gnome-sharp-2.16.1.tar.gz
cd gnome-sharp-2.16.1
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://go-mono.com/sources/gtksourceview-sharp2/gtksourceview-sharp-2.0-0.12.tar.bz2
tar xvf gtksourceview-sharp-2.0-0.12.tar.bz2
cd gtksourceview-sharp-2.0-0.12
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/gnome-desktop-sharp2/gnome-desktop-sharp-2.20.1.tar.bz2
tar xvf gnome-desktop-sharp-2.20.1.tar.bz2
cd gnome-desktop-sharp-2.20.1
./configure --prefix=/usr/local
make
make install
cd ..

cd mono-1.9.1
wget  -c http://go-mono.com/sources/monodoc/monodoc-1.9.zip
unzip monodoc-1.9.zip
cd monodoc-1.9
./configure --prefix=/usr/local
make
make install
cd ../..

wget -c http://go-mono.com/sources/mono-tools/mono-tools-1.9.tar.bz2
tar xvf mono-tools-1.9.tar.bz2
cd mono-tools-1.9
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/mono-debugger/mono-debugger-0.60.tar.bz2
tar xvf mono-debugger-0.60.tar.bz2
cd mono-debugger-0.60
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/heap-buddy/heap-buddy-0.2.tar.gz
tar xvf heap-buddy-0.2.tar.gz
cd heap-buddy-0.2
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/mono-addins/mono-addins-0.3.1.tar.bz2
tar xvf mono-addins-0.3.1.tar.bz2
cd mono-addins-0.3.1
./configure --prefix=/usr/local
make
make install
cd ..

wget -c http://ftp.novell.com/pub/mono/sources/monodevelop/monodevelop-1.0.tar.bz2
tar xvf monodevelop-1.0.tar.bz2
cd monodevelop-1.0
./configure --prefix=/usr/local
make
make install
cd ..

note: you might want to adapt the setting of BUILDDIR!

…well, a couple of hours later i seemed to be back in business, hardy heron was installed on “my” x60 and i was just about do another OpenSim build — when i noticed that nant was seg faulting! now, wait a moment, it clearly was not supposed to do that. ok, can happen, what with new libs and all that. so, let’s walk on over to /usr/local/src/mono/nant-0.86b and do a re-install. should be easy, peasy…

…except it wasn’t: mono’s compiler mcs kept seg faulting as well! hmmm.

ok. let’s reinstall mono. following my own script i started the re-install — which crashed as well after about 5min of mucking around.

panic stations!

googling around it transpired that this would happen when running hardy heron with a custom compiled kernel of pre-2.6.24 vintage — which i was

i’m happy to report that with 2.6.25 mono is running again

as of OpenSim’s subversion release r4390 the basic support for running OpenSim without such a console is in the code base and all you need to do is invoke OpenSim with the -background True commandline parameter:

% mono --debug OpenSim.exe -background True

note: that’s just a single dash for -background True!

another patch is on its way that not only adds code to properly shutdown OpenSim when the admin_shutdown XmlRpc method is invoked but it also adds the shutdown.py script:¹

you can either pass in the server URI and password to use via commandline parameters, or you can create .opensim-console.rc in your home directory and set default values:

[opensim]
server = http://127.0.0.1:9000/
password = secret

then all you need to do to shutdown your OpenSim server is: invoke shutdown.py

you start up your freshly compiled TestClient¹…

% mono --debug TestClient --first Foo --last Bar --pass secret
...
1 avatars online>

and then you issue the voiceaccount command to obtain the voice account credentials:²

1 avatars online> voiceaccount
DEBUG [libsecondlife]: New CAPS request to 
https://sim4042.agni.lindenlab.com:1204/cap/…. initiated
Voice Account for Ghostly Writer: 
    user “x2MOzi4T1Sq-qsfh77_Mnag==”, 
    password “XXXXXXXXXXXXXXX”
1 avatars online> DEBUG [Ghostly Writer]: Voice version 1 verified

…this tells us the voice account user name³ and password⁴. next you can issue the voiceparcel command to obtain the parce voice info details for the parcel you are currently on…

1 avatars online> voiceparcel
DEBUG [libsecondlife]: New CAPS request to 
https://sim4042.agni.lindenlab.com:12043/cap/… initiated
Parcel Voice Info request for Ghostly Writer: 
    region name “Zurela”, 
    parcel local id 26, 
    channel URI sip:confctl-243489@bhr.vivox.com

…which returns the region, parcel local ID, and the channel URI (the “conf call”) for that parcel.

repeating the whole exercise with OpenSim gives us this output:

% mono TestClient.exe --first Foo --last Bar --pass secret \
        --loginuri http://127.0.0.1:9000/
DEBUG [libsecondlife]: New CAPS request to http://127.0.0.1:9000/ initiated
DEBUG [Foo Bar]: Setting InventoryRoot to d8913a4b-…
DEBUG [Foo Bar]: Login status: ConnectingToSim: Connecting to simulator…
INFO [Foo Bar]: Connecting to (127.0.0.1:9000)
INFO [Foo Bar]: Received a region handshake for user error (127.0.0.1:9000)
DEBUG [libsecondlife]: New CAPS request to 
http://127.0.0.1:9000/CAPS/… initiated
DEBUG [Foo Bar]: Login status: Success: Welcome to OpenSim
Logged in Foo Bar
Type quit to exit.  Type help for a command list.
1 avatars online> DEBUG [Foo Bar]: Got capabilities: 
    UpdateNotecardAgentInventory 
    NewFileAgentInventory 
    FetchInventoryDescendents 
    MapLayer UpdateScriptTaskInventory 
    UpdateScriptAgentInventory ParcelVoiceInfoRequest 
    ProvisionVoiceAccountRequest
INFO [Foo Bar]: Connecting to (127.0.0.1:19999)
INFO [Foo Bar]: Received a region handshake for solid (127.0.0.1:19999)
1 avatars online>
1 avatars online> voiceaccount
DEBUG [libsecondlife]: New CAPS request to 
http://127.0.0.1:9000/CAPS/… initiated
Voice Account for Foo Bar: 
    user “xJ_Mn9bMsTkWxiduZkM4zSw==”, 
    password “$1$a857bc518438f33c16504831a5a47dd0″

and voiceparcel:

1 avatars online> voiceparcel
DEBUG [libsecondlife]: New CAPS request to 
http://127.0.0.1:9000/CAPS/… initiated
Parcel Voice Info request for Foo Bar: 
    region name “user error”, 
    parcel local id 1, 
    channel URI sip:54a9888b-…-85d45956bc1b@secondlife.zurich.ibm.com

a bit different, but in essence the same.

i’ll try and explain what we’ve achieved so far in the following sections. if you are impatient and want to skip the pretty pictures and high-level explanations you can use the following mini-table of contents:

• asterisk-opensim integration
• automatic SIP account creation
• automatic conference call setup
• setting it all up
• setting it all up: AsteriskVoiceModule
• setting it all up: asterisk-opensim.py
• setting it all up: MySQL database
• setting it all up: asterisk

asterisk-opensim integration

with the first iteration we refactored OpenSim’s capability system so that region module’s could contribute their capabilities to the seed capability and added a very simple, plain VoiceModule.

the second iteration (subversion r4236) now has a new voice module, AsteriskVoiceModule. also, in share/python/asterisk you should find a python XmlRpc server called asterisk-opensim.py. together with the open-source asterisk VoIP server both bring us quite a bit closer to our goal of voice support for OpenSim.

to understand how AsteriskVoiceModule and asterisk-opensim.py and your SecondLife client play together, let’s take a look at the following figure:

automatic SIP account creation

when the SecondLife client logs in to the Linden Lab grid or to an OpenSim grid, among the first things it does (once it got its seed capabilties from the grid) is to ask the grid server for the voice acount details (#1, ProvisionAccountRequest in the figure above). these voice account details basically are your avatar’s SIP account details which your SecondLife client is going to pass on to SLVoice(.exe).¹ in our case, AsteriskVoiceModule deals with the incoming caps request from the SecondLife client: it

• retrieves the avatar’s UUID and base64-encodes it, and
• generates a one-time password (otp), and then
• it then issues an account_update XmlRpc call to our asterisk-opensim.py XmlRpc server running on the same box as our asterisk server (#2, account_update).

asterisk-opensim.py checks that the XmlRpc call is correct and then updates the MySQL database that we use to configure asterisk in realtime by adding a dialplan for the UUID of our avatar (which basically creates a SIP account for our avatar)(#3, update extensions_table) — the MySQL database becomes effective (#4) the next time asterisk queries the database for its dialplan.

once asterisk-opensim.py has done its job, it tells AsteriskVoiceModule that it was successful (#5). AsteriskVoiceModule then returns the newly created (or updated) voice account information to your SecondLife client (#6).

Your SecondLife client then passes that information on to SLVoice which has nothing better to do than go and register with our asterisk server…

…well, it would, except, SLVoice as packaged with the normal SecondLife client does not know about our asterisk server. we’ll need to supply a replacement SLVoice client before we can claim success!² you might want to check out the voipforvw project for one example of such a replacement.

ok, so, we now have a SIP account, and our potential SLVoice replacement has registered with the asterisk server (well, once we’ve got it, that is ;-)) — how do we actually get voice and get to talk to other avatars? that’s what the next section is all about…

automatic conference call setup

lacking a proper spatial sound module for asterisk, we are just going to assign a conference call number to each and every region in our grid. sure, the idea being that whenever you avatar enters a new region, your SecondLife client will dial into the conference call for that region and leave the conference call of the old region.

how does your SecondLife client get the conference call number then? well, it turns out that the SecondLife client issues a ParcelVoiceInfo request to the grid each time it enters a new region³. again, the figure below illustrates what happens.

our AsteriskVoiceModule will receive the ParcelVoiceInfo call (#1) and will in turn issue a region_update XmlRpc call to asterisk-opensim (#2) containing the region’s UUID⁴.

asterisk-opensim verifies the XmlRpc call from AsteriskVoiceModule and will then add records to asterisk’s MySQL database (#3) to

• create (or update) a conference call with the region UUID as the dial-in “number”
• create appropriate dial plan entries for that conference call

asterisk will pick up the changes the next time it goes through its dial plan (#4)

and, once done, asterisk-opensim returns success: true to AsteriskVoiceModule (#5), which then returns the region voice details to your SecondLife client (#6):

• region_name — the name of the region your avatar is currently in
• parcel_id — i assume this contains the local ID of the piece of land your avatar is on
• channel_uri — basically, the UUID of the region plus the value of the conf_domain parameter from the [AsteriskVoiceModule] section from OpenSim.ini

your SecondLife client passes the received information on to the SLVoice application which will then dial into to the conference call (#7) for the new region (and leave the old conf call for the old region).⁵

setting it all up

to make this all work we need to

• enable AsteriskVoiceModule
• configure asterisk-opensim.py
• setup asterisk’s MySQL database
• configure asterisk to query the MySQL database for its dial plan

the following sections explain each step in more detail.

setting it all up: AsteriskVoiceModule

to enable the AsteriskVoiceModule you need to add the following lines to OpenSim.ini

[AsteriskVoice]
enabled = true
; SIP account server domain
sip_domain = testserver.com
; SIP conf server domain
conf_domain = testserver.com
; URL of the asterisk opensim frontend
asterisk_frontend = http://testserver.com:49153/
; password for the asterisk frontend XmlRpc calls
asterisk_password = bah-humbug
; timeout for XmlRpc calls to asterisk front end (in ms)
asterisk_timeout = 3000
; salt for asterisk nonces
asterisk_salt = some_secret_here

what do the individual parameter mean:

enabled

if true enable the module. make sure you have the plain vanilla Voice module disabled

sip_domain

the SIP domain to append to UUIDs for user accounts (can be empty)

conf_domain

the SIP domain to append to UUIDs for region conference call IDs

asterisk_frontend

the URL of the asterisk-opensim.py front end

asterisk_password

the password required for the asterisk-opensim.py XmlRpc calls

asterisk_timeout

AsteriskVoiceModule will wait this long for XmlRpc calls to asterisk-opensim.py to succeed (in ms)

asterisk_salt

salt to use for generating random one-time password for user SIP accounts

setting it all up: asterisk-opensim.py

asterisk-opensim.py is configured through it’s own config file. you supply the path to the config file via the --config option (just invoke asterisk-opensim.py with --help to get usage instructions). the config file looks like this:

[xmlrpc]
baseurl = http://127.0.0.1:53263/
debug   = true

[mysql]
server   = localhost
database = asterisk
user     = asterisk
password = asterisk
debug    = true

[mysql-templates]
tables = /path/to/create-table.sql
user   = /path/to/create-user.sql
region = /path/to/create-region.sql
debug    = true

we have three sections:

[xmlrpc]

here you configure the base URL for the account_update and region_update XmlRpc calls (currently you cannot supply a path name, we only take hostname and port)

[mysql]

here you configure which server to use, the name of the asterisk database, the user name and password of the MySQL user and whether you want debugging output or not.

[mysql-templates]

these are the path names to the templates that we use to create the required MySQL tables and also to update user account and update region conference calls. also, you can switch on debugging here.

setting it all up: MySQL database

setting up MySQL is pretty easy: you only need to create the asterisk database and the asterisk user:

# mysql -u root -p
mysql> create database asterisk;
Query OK, 1 row affected (0.02 sec)

mysql> use asterisk;
Database changed
mysql> grant all on asterisk.* to 'asterisk'@'localhost' identified by 'asterisk';
Query OK, 0 rows affected (0.09 sec)

mysql> quit;
Bye

that’s it. asterisk-opensim.py will take care of creating the necessary tables for you.

you might want to change the user name (the 'asterisk part of 'asterisk'@'localhost') and password (again, the 'asterisk' part in identified by 'asterisk') — but make sure you adapt your [asterisk-opensim.cfg](#setup-asterisk-opensim) and your asterisk configuration accordingly.

setting it all up: asterisk

we need to configure asterisk to use the ODBC database interconnect (also called asterisk realtime).

in your asterisk configuration directory — on ubuntu that’s /etc/asterisk — you need to make sure that you have

sipusers => odbc,asterisk,ast_sipfriends
sippeers => odbc,asterisk,ast_sipfriends
extensions => odbc,asterisk,extensions_table

in extconfig.conf

then in res_odbc.conf you need to have the following section:

[asterisk]
enabled => yes
dsn => asterisk-connector
username => asterisk
password => asterisk
;pooling => no
;limit => 5
pre-connect => yes

this assumes that your asterisk database is “asterisk”. likewise, that the MySQL username and password is ‘asterisk’ — if you used different values in your MySQL setup , you, of course, need to reflect that here.

then, you need to have the following extensions.conf:

[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]
CONSOLE=Console/dsp


[avatare]
switch => Realtime/@

finally, you need to have an empty sip.conf:

# mv sip.conf sip.conf.backup
# touch sip.conf

that’s about it, really.

installing pre-reqs

apt-get install build-essential bison gawk
apt-get install libglib2.0-dev
apt-get install libpng12-dev libx11-dev libfontconfig1-dev 
apt-get install libfreetype6-dev libjpeg62-dev libtiff4-dev 
apt-get install libungif4-dev libexif-dev libcairo2-dev
apt-get install libpango1.0-dev libgtk2.0-dev libglade2-dev
apt-get install libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
apt-get install libgnomeprint2.2-dev libgnomeprintui2.2-dev 
apt-get install libpanel-applet2-dev libgtksourceview-dev
apt-get install libgtkhtml3.14-dev

installing libgdiplus

wget http://go-mono.com/sources/libgdiplus/libgdiplus-1.9.tar.bz2
tar xvf libgdiplus-1.9.tar.bz2
cd libgdiplus-1.9
./configure --prefix=/usr/local
make
make install

installing mono

wget http://go-mono.com/sources/mono/mono-1.9.tar.bz2
tar xvf mono-1.9.tar.bz2 
cd mono-1.9
./configure --prefix=/usr/local
make
make install

installing nant

wget http://switch.dl.sourceforge.net/sourceforge/nant/nant-0.86-beta1-src.tar.gz
tar xvf nant-0.86-beta1-src.tar.gz
cd nant-0.86-beta1
make install prefix=/usr/local

you now have the base setup, which is sufficient for building and running libsecondlife and opensim. the following packages are add-ons that are nice-to-have but not necessary-to-have. i do recommend installing the monodoc & mono-tools stuff, however — it makes live easier

gtk-sharp

wget http://go-mono.com/sources/gtk-sharp210/gtk-sharp-2.10.4.tar.bz2
tar xvf gtk-sharp-2.10.4.tar.bz2
cd gtk-sharp-2.10.4
./configure --prefix=/usr/local
make
make install

gnome-sharp

wget http://go-mono.com/sources/gnome-sharp2/gnome-sharp-2.16.1.tar.gz
tar xvf gnome-sharp-2.16.1.tar.gz
cd gnome-sharp-2.16.1
./configure --prefix=/usr/local
make
make install

gtksourceview-sharp

wget http://go-mono.com/sources/gtksourceview-sharp2/gtksourceview-sharp-2.0-0.12.tar.bz2
tar xvf gtksourceview-sharp-2.0-0.12.tar.bz2
cd gtksourceview-sharp-2.0-0.12
./configure --prefix=/usr/local
make
make install

monodoc & mono-tools

to get the monodoc C# documentation viewer (recommended!) we need to install the monodoc package and the mono-tools package. monodoc itself needs to be installed inside the mono-1.9 source directory¹ from above.

cd mono-1.9 # this is the source directory from the above
wget  http://go-mono.com/sources/monodoc/monodoc-1.9.zip
unzip monodoc-1.9.zip
cd monodoc-1.9
./configure --prefix=/usr/local
make
make install
cd ../..

next, install mono-tools:

wget http://go-mono.com/sources/mono-tools/mono-tools-1.9.tar.bz2
tar xvf mono-tools-1.9.tar.bz2
cd mono-tools-1.9
./configure --prefix=/usr/local
make
make install

configure will mumble about gecko-sharp.dll not being build, that’s ok, just ignore it.

as mentioned in an earlier post, opensim’s libsecondlife sources are not contained within the main opensim source tree, you need to check those out separately:

% svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs

then, just go into the newly checked out opensim-libs directory and run nant to build libsecondlife.dll…

% cd opensim-libs
% nant

…and once it’s done, copy bin/libsecondlife.dll to your opensim/bin directory.

done. enjoy.

yet — top gear moment! — how hard can it be to split out the terrain map from L3DT into region sized parcels and then just write a nice little script to load them individually?

well, it turns out: not very hard.

step-by-step from scratch to finished grid…

someone on the #opensim-dev IRC channel mentioned the other day, that L3DT would run fine under wine on linux. having bought the professional version (just USD 34.95 or so),¹ i took note, as so far i had just been running it under vmware. sure enough, on l3dt’s web site is a HOWTO describing the linux setup.

install wine & then L3DT

so, first install wine (didn’t have a need for it on my box until now):

# apt-get install wine

next, download the development version of l3dt from the bundysoft website, then run the installer through wine:²

# wine /downloads/L3DT_PRO_dev-2.5.3.1.exe

that will install a runable l3dt on your ubuntu box. start it up and we are ready for that slartibartfast feeling.

becoming slartibartfast

either via “file->new project” or by clicking on the “new map” icon, start a new, well, map. you should be faced with the following dialog box:

select “design/inflate” and then click on next. on the design map size dialog box which should now be facing enter the desired grid size you want to cover — highlighted below in red — and make sure that the horizontal scale is 1.00 m. note, too, that the one OpenSim region translates to a 4×4 L3DT area; in the screen shot below, i’m aiming for a 4×4 OpenSim grid area, thus, i need to have a 16×16 L3DT area:

once you have entered your value, click next and you should get to the design map parameters dialog, which is a bit of a misnomer, i think, it really should be called slartibartfast parameters as this is where we get to be slartibartfast:

here, you can muck around and tune your future grid terrain to your hearts content. just pick and choose (you can always restart). once you are done and want to give it a go, click next again — leading you to the calculation queue dialog, where you tell L3DT what maps you are interested in. you absolutely do need the heightfield map (this is going to be what we load into opensim later), i always turn on everything

again, click on next and you will get to the water flooding dialog:

i like my water levels at 20m and am a huge fan of the sea, thus the entries in the highlighted area. next and we arrive at the texture settings dialog:

if you want to, click on the make high-resolution texture check box (i usually do). click through the next dialogs and then watch L3DT do its job.

sooner or later³ your terrain will be ready! my terrain looked like this:

exporting our terrain

next, we need to export our newly created terrain. to do so, first save your projects via “file->save->save project” or via the “save project” icon. then, select the heightfield map via the map selection icon…

…and select the heightfield entry…

…which should update the display area to show the heightfield map — which looks a bit like an x-ray of our terrain:

next, we need to export the map using the RAW format. click on the “export this map” icon…

…and in the export map dialog click on split map into tiles (mosaic map) (highlighted in red below) and enter a name for the terrain map in the file name field (highlighted in yellow, i used slartibartfast).

click next and select the RAW file format (highlighted in red) and adjust the tile size to 256 and click on options…

select the Mode (ComboSelector) entry by double clicking and change it to 32-bit floating-point (metres)…

and then click on OK and finish the rest of the dialog by clicking on OK again.

you should end up with a set of files named slartibartfast_x0y0.raw, slartibartfast_x0y1.raw, and so forth.

importing the works into opensim

finally, we are about to import our opus magnus into opensim. to do that we need to

• rename all *.raw files to *.r32 so that opensim does not mistake them for LindenLab raw files
• create a command script to load the terrain into each region separately.

first, though, copy the *.raw files to the bin directory of your OpenSim installation:⁴

# cp *.raw /opt/opensim/bin

next, rename:

# for i in *.raw ; do  r=$(basename $i .raw); mv $i $r.r32; done

now, create a command script for opensim which looks roughly like this:⁵

change-region Xanadu Blue
script terrain load slartibartfast_x0y0.r32
change-region Shangri-La
script terrain load slartibartfast_x0y1.r32
change-region Torchwood
script terrain load slartibartfast_x1y0.r32
change-region 13th Floor
script terrain load slartibartfast_x1y1.r32
change-region Skybreaker
script terrain load slartibartfast_x2y0.r32
change-region Hyperion
script terrain load slartibartfast_x2y1.r32
change-region Aurora
script terrain load slartibartfast_x3y0.r32
change-region Flotsam
script terrain load slartibartfast_x3y1.r32
change-region Shutdown
script terrain load slartibartfast_x0y2.r32
change-region User Error
script terrain load slartibartfast_x0y3.r32
change-region Core Dump
script terrain load slartibartfast_x1y2.r32
change-region Division by Zero
script terrain load slartibartfast_x1y3.r32
change-region Gondor
script terrain load slartibartfast_x2y2.r32
change-region Misty Mountains
script terrain load slartibartfast_x2y3.r32
change-region Rivendell
script terrain load slartibartfast_x3y2.r32
change-region The Shire
script terrain load slartibartfast_x3y3.r32

save.

start up OpenSim, and once you have the console prompt, issue

Region# :
command-script slartibartfast.cmd

this should result in quite a bit of output by opensim telling you that it’s doing the terraforming!

a new landscape!

login to your opensim grid and explore your new terrain!

short detour: when we talk of “endian issues” we refer to the way a CPU organizes data internally. to quote wikipedia:

endianness is the byte (and sometimes bit) ordering used to represent some kind of data. Typical cases are the order in which integer values are stored as bytes in computer memory (relative to a given memory addressing scheme) and the transmission order over a network or other medium. When specifically talking about bytes, endianness is also referred to simply as byte order.

the terms big endian and little endian are much older than computers, much older. they originate with the inhabitants of jonathan swift’s Lilliput and Blefuscu and refer to the way they would crack an egg open: big endians started at the big end.

for reasons shrouded in the fogs of history, intel x86 CPUs are little endian, motorola CPU generally are big endian as are PowerPC CPUs.[^1]

anyhow, to return to our story, we were suspecting endianess issues with OpenSim — and the underlying libsecondlife. following up on clues provided by Neas Bade i started looking at openjpeg-libsl (the native code library responsible for doing most of the JPEG2000 coding). that turned out to be a dead end more or less.

turning my attention to the terrain handling, it transpired that the terrain when generated was looking fine (you can save a generated terrain via OpenSim’s region console — which i did and then examined it using [the gimp][]). loading it back in from the data stores (OpenSim supports a number of data storage adapters) however, returned a corrupted terrain image. that lead to fix #1: serialization of the terrain in the SQLite and MySQL data storage adapters was fine, but reification was borked.[^2]

unfortunately, while OpenSim would now restart fine, we still could not connect as the client would barf violently on the terrain data OpenSim was handing out looking at the code in OpenSim that supplied the client with the ill-digested terrain dope it transpired that this time it was libsecondlife that was cracking the eggs open from the little end only. actually, it was doing so in two places: LLUUIDs were not properly serialized and packed bits were completely oblivious of the fact that one could start cracking the eggs open at the big end. bug fixes #2 and #3 (this time to libsecondlife).[^3][^4]

so, what steps do you need to take to get OpenSim running on PPC? here are the instructions:

1. check out opensim itself:
   • svn co http://opensimulator.org/svn/opensim/trunk opensim
   • build according to instructions
     • ./runprebuild.sh; nant
2. check out opensim-libs:
   • svn co http://opensimulator.org/svn/opensim-libs/libsl1550 opensim-libs
   • build: cd opensim-libs; nant
   • you should end up with a sparkling new libsecondlife.dll in bin
   • copy that one over into the opensim/bin directory.
3. enter opensim-libs/openjpeg-libsl and do
   • a make, and then
   • copy the newly built libopenjpeg-libsl-2.1.2.0.so into opensim/bin as well
4. almost there! enter opensim/bin and edit libsecondlife.dll.config and remove the cpu="x86" tag in the last dllmap line, so that it looks like this:

start OpenSim.exe and enjoy.

well, here’s your chance to become a grid master, a grid superlord — just 3 easy steps to start your own grid:

• install mono & subversion (a simple apt-get install mono subversion on ubuntu boxes)
• check out OpenSim:

        % svn co http://opensimulator.org/svn/opensim/trunk opensim
        % cd opensim
        % ./runprebuild.sh
        % nant
        % cd bin
        % mono ./OpenSim.exe

• connect to your now running OpenGrid like so:

        % secondlife -loginuri http://127.0.0.1:9000

voila! your very own “grid” — admittedly not yet that 16 region grid i mention in the beginnig, but!, we are getting there

coming up next: i want more regions!