Things have gone well since the last post. Multiple regions are running, and Jeannie can’t just walk through objects anymore. As an aside, I see from other WordPress blogs that she is ordinarily called Ruth in the trade. As it happens, RL Jeannie has Ruth as her middle name, so it all works out. As was common with us all in my generation growing up here in the Old South, she was known as a child by first and middle names. You can just hear her mother now, “Jeannie Ruth, get yo’ ass in this house, gal!” Ah, childhood!
But, back to business. Everything was accomplished with the modification or addition of four text files. Two were *.ini configuration files, and two were *.xml files. I have posted all four on my website, and have links to each as they are briefly discussed below.
OpenSim.ini was probably the most difficult to get correct. There are several places in which the storage is declared to be MySQL. The declarations are of two types. First there is the one for the dynamic link library containing the functionality to access that particular database type. Second, there is a connection string for the particular database. Put the file on a text editor and search “MySQL” to find all the requisite places. Note, by the way, that you will see the actual connection string, including the password, for the MySQL instance I use. No security breach there, as the server which is running OpenSim is on a private network not accessible from the internet or wireless monitoring.
Getting the object solid was a two line change in OpenSim.ini. Look in the “PHYSICS” section of the file. You will see the choice of a mesher, and a selection of the OpenDynamicsEngine, or ODE, as the physics engine.
There is a second file which relates to connection to MySQL, called mysql_connection.ini
which repeats the connection information for MySQL, once more giving out my secret password. If you happen to look at the actual URL when you view both of these *.ini files, you will see that the actual file on the website has the file extension *.txt. This was done to get them to display better on a browser. Of course, use the *.ini file extension in OpenSim.
Once grid mode is achieved, adding regions is quite painless. For each region running on OpenSim, there is an XML file in the bin/Regions subdirectory. OpenSim puts the first one there, and it is called default.xml with the content based on the answers you give the first time OpenSim runs. All that was necessary to add a second region was to add the file region.1000.1001.xml to the Regions subdirectory. The various XML files can be named anything you like. I used a convention mentioned on the OpenSim website which identifies it as a region file, and includes the grid position in the name. The default grid position is x=1000, y=1000, and I took the default initially. As is pointed out in the OpenSim documentation, these are not meters, just coordinates of slots in the grid. Hence, this second region is adjacent to the default by being one greater in one coordinate.
There are three things you need to change when you create the second XML file from default.xml. The first is the region name. These must be unique within the grid, whether it is your grid or someone else’s grid you decide to connect to. The second is the listening port. That first port is, by default 9000. Each region must have a unique listening port. I chose 9001, keeping it away from the ones in the 8000 range used by the subordinate servers.
The last thing to change is the region UUID. There is more than one UUID in the file, but the one for the region, labeled “sim_UUID” is the only one which requires changing. All regions must have a unique ID, but that only means unique within the grid where they exist. One way to get a new UUID is to use the GUID tool which is bundled with Visual Studio. Apparently there is a similar tool in Unix based on a cursory reading of some of the OpenSim website documentation. For your own grid, with only your regions in it, and you never connect to someone else’s grid. all you really have to do is change one digit to something else each time you add an XML file for a new region.
So, now what? I see further progress needs to be made along two fronts. First of all, this virtual world has to be fleshed out. More regions must be added, and some extensive terrain editing will be done. A world of little desert islands is just not enough. Additionally, a lot of objects are going to have to be built using the basic primitives. In the process of this, there will be some bugs, some of which may be due to configuration file errors, and some of which will turn out to be code errors. Those will have to be fixed.
The second area of effort needed, not that the basics are running, is to see if OpenSim is really going anywhere, and if it is do I want to go there too. There is a lot about OpenSim just on the WordPress blogs, and I need to look at all of it more carefully to see what the rest of the world is doing. Notwithstanding the occasional frustrations cataloged here previously, playing with OpenSim is great fun. But, could this be my escape from Programmer Hell? Is there a shot at making a living with thing while I’m having fun? Realistically, I rather doubt it. However, let’s see where this ride takes us.
