Importing OARs into megaregions

OpenSim now supports the concept of megaregions — several regions stitched together without borders. I love megaregions. For the kinds of applications that I am involved with, megaregions are a must — try sending traffic over a region border! (horrible). The diva distro comes with a megaregion.

However, megaregions have a few quirks and because of those quirks many people don’t use them. One of the major show-stoppers is importing content from existing non-mega regions. Yeah, it doesn’t work very well. But if you know the right incantation, it’s actually quite workable. I have been doing this regularly for the past 3 weeks, so I thought I’d make the incantation more public. I’m going to describe my exact situation — extrapolate for yours.

I am working on an application over a 3×3 region area. My team is building the content in a regular 3×3 region with borders, for historical reasons. The final deployment is in a 3×3 megaregion, since the application includes several dynamic behavior modules and I don’t want to deal with border crossings in them. So here is what I do.

Every few days I go to the console of my team’s building sim and save each region in an oar — that’s 9 oar files. I bring them to my development machine. Then I do the following steps:

  1. Clear my DB from all existing prims. I do this directly on the DB with a SQL statement — DELETE FROM prims; DELETE FROMĀ  primitems; Poof! there goes all content! If you’re starting from scratch you obviously don’t need to do this.
  2. Start my empty 3×3 megaregion.
  3. Import each oar file into the corresponding region: change region <region>; load oar <region.oar>. This is a bit tedious and makes me want to add something to OpenSim to handle this better. But, while that multi-region oar-importing support doesn’t exist, I have to do it one by one — 9 times in my case. Depending on how fast you type these commands, you may or may not be interrupted by OpenSim’s backup thread. This is a thread that writes new content in memory into the DB, it kicks in every minute or so. When this thread kicks in, you will see lots and lots of error messages, possibly in red, complaining about all sorts of things. Ignore it and type faster.
  4. When I’m done loading my 9 oars I do the magic incantation on the opensim console: fix-phantoms
    That’s right, this is the magic incantation. Again, you will likely see lots of error messages flying through the console. Ignore them.
  5. Then I wait for the next run of the backup thread, so that all prims are stored correctly on the DB. When the backup thread kicks in, you will see lots of debug (non-error) messages on the console saying that it’s writing objects in your SW region. Done!

Well, not quite. There’s another thing I do to clean things up. In megaregions, all prims are supposed to be in the SW region, and that region only, for example, in coordinates <345, 456, 40>. There should be no prims in any other region. However, I always end up with a few prims not being able to cross, for some reason that I still don’t understand. So I shut my megaregion down, I go again to the DB directly and I inspect the prims table again:
SELECT Name, GroupPositionX, GroupPositionY, RegionUUID FROM prims WHERE RegionUUID != ‘<SW region UUID>';

On my regions I usually get a couple of hundred prims in this situation. Also on my regions, they all happen to have very suspicious negative coordinates. I know by experience that these prims will never be placed right, they’re just junk. So I delete them:
DELETE from prims WHERE RegionUUID != ‘<SW region UUID>';

As it turns out, they don’t seem to make any difference, at least in my case.

Upon restarting the sim, I still see error messages on the console related to prims failing to cross. I haven’t been able to track what the problem is. But the good news is that when I login to it, all important content seems to be there in the right place.

This has been working very well for me for the past 3 weeks. It’s not perfect yet, but it’s quite workable.

3 replies on “Importing OARs into megaregions”

  1. Per Pegler says:

    I agree this is workable, somehow it even works when I do not clear the DB first. I started that mainly because in my case I run 4 instances of 4 megaregions using the same DB so I do not want to start fresh all the time, ( my knowledge of SQL and MySql is limited) I am trying to take the easy way out and loading a new Oar on top of the old one, then typing the magic fix-phantoms and it is working for me so far. I do have some cleaning up to do after but last I did a load oar I only had 6 prims to clean up.

    I use WampServer to set up my DB, PHP and Apache and do my cleaning from PhpMyAdmin. The megaregions are so easy to move around in that I forget all the draw backs and other temperamental quirks they have. I still have problems with terrain textures, saving terrain and saving an oar from a non root region. I know since all prims end up in the SW this might not be possible. This is a draw back if you want to work and save inside the megaregion but if used as as show case and finished product not a problem and many work a rounds are possible.

    The idea of a team working in regions (256X256) and uploading in to megaregions is good even using the same DB for two or more megaregions makes life easy.

    The hypergrid part that will in the end connect it all together is also working reasonably well.
    Diva thank you so much for sharing your knowledge and hard work much appreciated I for one am impressed at how well this is working :-)

  2. WhiteStar says:

    There is now a WIKI page @ for MegaRegion Implementation as well, it’s a Good Supplement to this article. Reference:

  3. […] then checked whether the insidious red error messages appeared by using this novel method of loading OARs, but unfortunately they still appear, so that […]

Comments are closed.