Recovering from the disaster…

I’m ready now to try once more to get OpenSim into grid mode.  It seems clear that the previous problem was not a software bug in the code, but simply some bad changes in the configuration file, OpenSim.ini.  However, it may be that the only way to find out just what the right changes are will be to step the code through and see what happens.  A lot will be learned in that process.  To that end, another set of files was downloaded from the OpenSim website and installed on the laptop, which happens to also have Visual Studio 2005 installed.  An instance of MySQL was installed on the laptop as well, and is working well.  A build of OpenSim from the newly downloaded files succeeded.  Stepping through the code should not be so bad now.

Before forging ahead with the new build, I wanted to play a bit with the original build to get some preliminary data.  When OpenSim runs for the first time, OpenSim.ini does not yet exist.  After OpenSim is started on the command prompt, a long series of questions are asked, and the opportunity to take the default is given for most of them.  After OpenSim was stopped, OpenSim.ini appeared, apparently saving all those values given at startup.  To get grid mode running, several changes have to be made to the file.  That is when the problem started.

I tried deleting the modified version of OpenSim.ini, then starting OpenSim again.  I wasn’t asked plenty of questions, but OpenSim started again in standalone mode, and Test User and a second avatar created during the original standalone mode were present, and could log in.  That then is the fall back position to take.  If changes to OpenSim.ini to get grid mode are bad, at least you can get back to standalone mode as it originally ran.  Just delete OpenSim.ini and restart OpenSim.  Additionally, when I started OpenSim again without a copy of OpenSim.ini, one was seen to have been created when OpenSim was terminated.  Because there was no copy of OpenSim.ini present at startup, everything reverted to the original, including using the SQLite database which was run as default.

As for the new build, I trashed the idea of creating it on a flash stick to save disk space.  There were enough files to delete so that there is still a comfortable margin on the hard disk of the laptop with the Subversion server, an instance of MySQL and OpenSim running.  Subversion can probably be deleted as well, since absent some sort of new disaster, all work will continue on the build currently resident on the laptop.

There are some relatively minor problems that can be analyzed and fixed in due course.  First on the list will be fixing the bug that screws up the MySQL connection string when OpenSim.ini is saved in grid mode.  Then there are some additional things, such as any object I create seems to be phantom.  Along with that is the fact that the map can only see one avatar in the region when there are two.  I’ll have to see how to get some male avatars on, since the same female avatar gets assigned to every new user created.  Finally, I have to do something about the fact tht the avatar’s appearance can’t be changed, because permission is denied.

Still, things are going better than they might, and these minor things can be chased and fixed once grid mode is running correctly.  As always, I’ll keep you posted.

An Interim Report on OpenSim

As you may have seen from our next to last post, progress on OpenSim has ground to a halt.  The essence of the problem is this.  Downloading and doing a build, then starting up in standalone mode, which runs a single region, worked out just fine.  Moving to grid mode, such that more than one region could be running, required that the light weight database supplied, SQLite, had to be replaced with something more powerful.  The recommendation was to use MySQL, which fortunately was already implemented on our server.  We went through the drill to reconfigure to use MySQL, after which it was impossible to log anyone on in grid mode, and only the default test user when we backed down to standalone mode.  There did not seem to be any obvious errors in the reconfiguration we did, but nothing worked after the database switch.

Accordingly, a new strategy was formed.  First of all, OpenSim will cease being a team effort.  Other members of the group, Robo, JB, and Brunie, will work on other projects, including some LSL scripting, and some SL building for our SL site.  Yours truly, Ingemar, being the more experienced C# programmer of the group, will take on OpenSim.  This blog will for the time being be devoted to OpenSim work, so the use of the “we” will be dropped.  I’ve been the one who actually writes the blog all this time anyway, the other members of the group contributing but not blogging.

Fortunately there is no such thing as undocumented software when the software is open source.  The source code is always the ultimate documentation, whether it has any comments or not.  Add to that the appropriate IDE, in this case Visual Studio 2005, and no problem can elude you for long.

So, the first task is to get Visual Studio 2005 and the OpenSim build all on the same computer.  The initial build was done over the network, and that can take a lifetime.  Trying to step through the code to see what is going on will run with glacial slowness.  This means moving to the laptop, the hard disk of which is a bit full.  The approach then will be to trash the build I have now, download whatever the latest build is, and keep everything on a flash stick.  There are some 1 gigabyte sticks available here at the RL site, and if necessary the bigger ones are not all that expensive.

I’ll go through the motions all over again, running the script which creates the Visual Studio project file, doing another build, and getting standalone mode running.  An instance of MySQL will have to be installed, since the resident SQL Server on the laptop is said not to work with some of the OpenSim features.  Then, the steps of reconfiguring to run grid mode will be tried again.  If something was just missed in the previous try, and everything works well this time, so much the better.  If not, I’ll proceed on the premise that the problem is in reconfiguring for MySQL rather than a code problem.  Then it will be a matter of digging through the source code to see where OpenSim responds to a logon, and stepping it until the problem is found.

We, or more correctly, I, will keep you posted.

A Final View of the Grass

A Field of AI Grass

Here is the final picture of the entire field of AI plant grass.  What with worrying with OpenSim, and of course worrying about Hurricane Ike, there has just not been time to get the AI bugs loose to keep the grass growth in check.  The crop has grown so large that the parcel object limit has been exceeded.  Also, with so many plants, the capacity of the sim to handle all those every 5 minute timer events may be slowing the sim down.  So, one blade of grass and its script have been saved, and the rest have been killed off from a message sent from the RL location of XorLabs Research.  It was received via the dish seen at the left of the picture, which in turn sent a message to each blade of grass to die.  We’ll start growth again once there is time to get the AI bugs out there to munch on it.

There’s been a slight disaster with OpenSim

It all seemed so grand!  We got our OpenSim instance all configured for grid mode, got everything started, and there were no errors.  A victorious post was written, but we thought maybe we ought to try to log on before publishing the post.  Opps! Can’t log on!  Neither the standard Test User account which gets created automatically, or other ones successfully created during standalone mode, could log on.  When we first tried to back up to standalone mode, no possible logins there either.

Eventually, we were able to get at least one agent to log on in standalone mode.  When trying to log on other agents, we got an error message that they were already logged on, even though they weren’t.  This problem hasn’t been fixed, but is under analysis and will be fixed in due course.  Still, disasters like this do lead to learning, and in fact a lot has been learned.  We will give the details as soon as everything is fixed, but some advanced warning might be in order.

Going from standalone mode to grid mode is a matter of moving from the SQLite database supplied with the build, to some other database of your choice.  As it turns out, you can have any database you want, as long as you want MySQL.   Two *.ini files have to be modified to accomplish that, the principal one being OpenSim.ini. Apparently a copy of this file is created after you run OpenSim the first time, and answer a lot of confusing questions, give up, and take the defaults.  In subsequent runs, if you make any changes from the OpenSim console, you will be asked if you want to save OpenSim.ini.  Under no circumstances should you do it!

The problem is that when OpenSim saves this file, it will screw up the connection string to your MySQL instance by removing the quotes from it.  You will get notice of an exception thrown in the OpenSim console about failing to access the database.  It can be fixed by editing OpenSim.ini and putting the quotation marks back.

The second problem comes with declaring the MySQL plugin DLL in OpenSim.ini.  The DLL file name given in the online documentation is incorrect, as there is no DLL by that name.  Instead of OpenSim.Framework.Data.MySQL.dll the correct name is OpenSim.Data.MySQL.dll.

In any case, we’ll be looking at this problem through much of today, and as much as can be done during the coming week.  With a little luch, perhaps a solution, and an explanation of it next weekend.

And now more on OpenSim

Meet Test User

You recall in a previous post that announced that we got a good build on OpenSim.  Today it was run in standalone mode with a single region.  All the defaults were taken except for the external host IP address.  Since we were logging in from another computer on the LAN, the address of the computer where OpenSim is currently running was used.  The SecondLife viewer is used to log on to OpenSim, and it must be started from the command prompt if running on Windows.  We have OpenSim running on the small business version of Windows Server 2003.  The command line argument is the URI of where OpenSim is running.  The default port, which we used when starting OpenSim, is port 9000.  So, from the command line, we entered:

secondlife -loginuri http://192.168.2.1:9000

Once the SecondLife viewer is up, we log on using the default master avatar, default name Test User, password test.  The SecondLife viewer logged on successfully and the lovely Test User, seen above, appeared.  Now her shirt is not the default version.  A slight modification was made to be more in line with her whereabouts, that being a small island out in the middle of an endless ocean.  You can’t see her feet, but she came to life the first time not wearing shoes.  She does look as though she has been shipwrecked and abandoned.  In the coming weeks we will try to give her some company and some shelter.  Also, she should have some place to shop, considering that by default she comes into being with L1000 in cash, with no place to spend it.

This is just one region, and in grid mode OpenSim can have lots of regions.  We’re still learning how to do all that; we told you this was going to be a learning experience.  There are lots of questions yet.  How do we get OpenSim running in grid mode so that there can be other regions?  How can we connect this region to existing grids on the web?  Can two grids get tied together with a single region connected to both and bridging between them?  When we find out, we’ll tell you how it’s done.  For now, Test User will just have to be imprisioned on her isolated island.

The Grass Is Growing!

Life is good.  The RL site of XorLabs Research survived Hurricane Ike, and there is electric power, hence air conditioning!  And, the kinks are out of the AI Plant scripts and it has propagated.  Above you can see the original plant, a simple blade of grass, and the four seedlings which it spawned.  They are being blown by a strong wind in the Green Goblin sim, hence the leaning.

As I write, however, power has just been lost once more.  We will have to stop for now, make a quick post using the Sprint card, then sign off for now.

Just in case you thought we forgot about the AI plants …

This is definitely going to be a short post, as Hurricane Ike is hot on our trail, and there are some things to do so that the RL contingent of XorLabs can ride it out.  Just wanted our faithful readers to know that some modifications have been made to the script, and the new script is running in Plant 0 now.  Seems that we screwed up in calculating the new position for the child plants to be rezzed from the parent, resulting in trying to get llRezObject() to rez something more that 10 meters from the plant running the script.  Under those conditions, llRezObject() will quietly fail to do anything.

It looks as though the code bugs are fixed, so after we get a population of plants in the ecopod, we can turn the AI bugs loose to feed on them.

As for OpenSimulator, that has had to wait due as mentioned to the coming of Ike, but also due to starting a new RL job located well on the other side of Houston from home.  Assuming everything doesn’t get too destroyed in the next couple of days, there should be time to start the task of configuration of OpenSimulator, and possibly getting a single region going.

See you after the storm!

And now, a few thousand words about OpenSim

Strictly speaking, it should now be called “OpenSimulator”.  However, it still gets called “OpenSim” and in fact that is the name of the executable file, so we’ll stick with OpenSim.

Most importantly, understand that XorLabs Research does not claim to be an OpenSim expert.  There is plenty of programming experience here, much of it in recent years with Visual Studio, in C++ and more recently, C#.  All the required hardware and software are available here at the RL location.  But, we just started with OpenSim, and what you will see here is a chronicle of our progress.  You will see the problems we encountered and how we solved them.  Reading this blog will let you learn as we learn.  Also, understand that we are not insiders at OpenSimulator.org, merely folks like you readers who learned about OpenSim and wanted to try it.  Their documentation is a bit disorganized, but in fairness that is to be expected in a project which is being made public in the course of being developed.  Some hardworking folks are developing it and we, the public, are getting it partially finished as the OpenSimulator.org folks finish it.

It is possible to run OpenSim on a variety of processors and operating systems.  Additionally, you can build it from source, or download an executable.  We aren’t going to elaborate on all these options, we are going to elaborate on how we are in the process of doing it.  Specifically, our RL system will run OpenSim on a Dell PowerEdge 400SC running Windows Server 2003 for Small Business Server.  The initial build was done over the network using Visual Studio 2005 running under Vista Business on a Dell Latitude D820 laptop.  That rather cumbersome arrangement resulted from problems getting Visual Studio to load on the PowerEdge, with which we need not burden you with here.

With all those provisos and caveats, let’s begin.

The first step is to get the source code.  The starting point is the OpenSim website.  An open source version control system known as Subversion is being used there to maintain the latest version of OpenSim available for download.  Version control is quite common in projects which have multiple programmers working on the project.  We don’t plan to use version control due to the way we work on things.  However, we did download and install Subversion primarily to get the client tool svn to simplify downloading.

A version control system allows programmers to check out parts of the code to work on in a way that prevents other programmers on the project from trying to work on the same piece of code.  OpenSimulator.org maintains a repository on their site from which you can check out the latest build.  You can run the client application svn on your own computer and it will automatically download everything you need to do a build of OpenSim.  So, our first step was to download and install Subversion.

We found a zipped Subversion executable for Windows on the Tigris.org site here.  It was downloaded to our PowerEdge server. unzipped and installed.  The location of svn is automatically entered in the PATH environment variable during installation, so you won’t have to add the path to it when you run svn with the Command Prompt.  The location to the latest build of OpenSim can be accessed starting at the main OpenSimulator.org webpage by clicking on the “User Docs” link at the top of the page, then clicking on “Download” under the Initial Setup section at the top of the page.  The “Download” like will take you to a page where download information ia available for both source code and complete executables.  In the first section of this last page, labeled “Source” you will see “Latest Subversion revision (Bleeding edge” and a link under it.  Don’t click on it, just write the link down.  You will use svn to do the download.

The svn application is accessed from the Command Prompt.  Note that if you will be downloading to a Vista computer you will probably have to run the Command Prompt as Administrator.  You need to supply two command line arguments, the link where to get the code, and the path on your computer where you want it downloaded to.  The link is the one mentioned in the paragraph above.  The location on your computer where you want it to be loaded is your choice.  Here is the command we used:

svn checkout http://opensimulator.org/svn/opensim/trunk/ C:/OpenSim

Yes, we used the forward slash for the destination even though it’s on Windows.

After the mass of files has been downloaded, you will need to create a Viaual Studio project file.  In the main directory where you downloaded OpenSim, there is a batch file named runprebuild.bat.  Run that on the command prompt to create the the project file. The project file is OpenSim.sln and it will be on the same directory as the batch file.

If you don’t run Visual Studio 2005, you can always use Visual Studio Express.  It’s free and can be downloaded at the Microsoft.com site.  Visual Studio Express can be downloaded with all its languages, but you can just download it with C# only, since that is the only language you will need.  Also, be sure that your computer has the .NET Framework 2.0 or later.  With all this in place, click on the project file to open the project, and do a build.  The initial build will take a while so be patient.

If all the foregoing went well, you should have a working version of OpenSim.  There is some configuring to do, which will be covered in the next post.  However, you might check to see that the executable will run.  Open Windows Explorer to the bin subdirectory of your OpenSim directory and just click on OpenSim.exe.  A Command Prompt will come up and an incredible amount of verbage will start to flow onto it.  Once you see that, you can be satisfied that your build worked.  Once OpenSim is configured, and we’ll talk about that next time, you will log on to it using the Second Life viewer.

Now for a change of pace

Several necessary modifications have been made to the AI plant script, and the plant has once more been launched in the XorLabs ecopod.  For a while we at the XorLabs group will watch as it spreads (we hope) throughout the ecopod, and will post the modified script later.

For now, we are going to shift our efforts to an exciting new project known as OpenSim.  Some very creative folks are working on this new open source virtual world application.  Several people active with .NET in Second Life are involved, and apparently Microsoft is interested enough to put a couple of its programmers on it full time as well.

It is possible to download a copy and get it running on your own computer, then link it to instances of OpenSim running on other computers.  Our efforts are going to be directed to getting an instance running on our own computers and learning all about it.  Once we feel that we are sufficiently familiar with it, we will be launching an instance on the internet and experimenting with linking with other versions already open and running.

Now the interesting thing about this application is that once a copy of it is running on some processor, and is linked to other existing instances, it will be possible to have your avatar move around from one instance of OpenSim to the other.  Also, it has been demonstrated that an avatar can, under appropriate conditions, migrate between Second Life and a running version of OpenSim.  This opens up worlds of possibilities (pardon the pun) which we hope to exploit.

The next several entries will be devoted to the trials and tribulations of learning about OpenSim, and getting it running on one of the computers on our RL network.  Stay tuned, we think you are going to like this!

The testing continues …

The first AI plant was allowed to run for several days. While it was observed to be growing on schedule, it never spawned any seedlings. A thorough examination of the code for the plant showed some errors which had been overlooked before, and the script was modified accordingly. The original plant has been deleted, and the edited script is going to sit and mellow for a day or so, after which I will go back to it and give it the once over before launching the plant again.

By now there have been several errors in the original code, a link for which was provided a couple of posts back. As I said, there was no evidence that it would run as it stood, and now there is quite a bit of evidence that it would not. The script won’t be posted again until it has been verified that it is working. For now, what was posted in the previous post will be a good exercise for budding LSL scripters to find all the errors. Happy hunting!