Importing OARs into megaregionsNovember 12th, 2009 at 8:20
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:
- 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.
- Start my empty 3×3 megaregion.
- 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.
- 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.
- 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.