One of the most interesting developments in Opensim lately have been megaregions. Megaregions are non-standard “big” regions created by combining several standard, 256×256 meters regions. For example, you can combine four standard regions in a square to get a megaregion of 512×512 m. Megaregions are very convenient because of several reasons: for example the usual lag in region crossings disappears completely (since you are in the “same” region), and the same is true of vehicles. On the other hand, megaregion support is still experimental, and a number of things that work in normal regions don’t work or work only partially in megaregions. For example, you cannot define parcels outside of the SW region (this is due to the way parcel maps work), and therefore you can’t have independent music streams (for example) when x > 256 or y > 256.
Diva Canto’s distribution of Opensim directly supports megaregions. You can also migrate an existing non-megaregion installation to a megaregion configuration, if you follow certain precautions. Migrating from a megaregion configuration to a non-megaregion configuration is also possible — you change the setting that implements megaregions, “CombineContiguousRegions” to false, and it works as expected.
OAR support for megaregions is partial: since technically all the objects in the megaregion are stored in the SW region, when you take an OAR of the SW region you get all the objects of the megaregion but only the terrain for that same region — this means that you cannot fully rebuild a megaregion from an OAR, which is a pity (you will be missing the terrain files for all regions except the SW one).
In this post I’ll describe some experiments I made with an OAR manipulation tool I developped following a suggestion of Stefan Andersson. The tool takes as its input a megaregion OAR and splits it into several non-megaregion OARs, creating one OAR for each region that constitutes the megaregion and has objects in it. This is so because megaregions may have holes, and when a possible region does not have objects there’s simply no information in the megaregion OAR about whether a it’s a region with no objects (for example, a sea-only region) or a hole in the megaregion.
As I noted in my previous post “Moving and rotating OARs“, offline editing of Opensim Archives (OARs) opens a lot of interesting possibilities. In this article I present the results of several simple tests I have made by extending my “Zoe” OAR editor so that it supports (a very simplified sub-dialect of) SQL. Even in a simplified form, SQL has a lot of expressive power and allows to perform a number of pretty neat operation on OARs, when it comes to selecting and deleting parts of a region. Updating OARs, though, is much more complicated, because there is no “natural” semantics to apply when using the standard SQL UPDATE statement. Some simple cases can be singled out, however, where “natural” semantics actually make sense — and in some other “interesting” use cases, a custom pseudo-SQL statement seems to be sufficient. Continue reading
Format 0.2 Opensim Archives (OARs) include, since Opensim version 3c271b, a “landdata” directory that stores parcel data. For each parcel in the region there is a file in XML format in the directory. Amost all objects in Opensim are associated with a unique uuid that identifies them, and parcels are not an exception to that rule. Files in the “landdata” directory use the uuid of the parcel as their filename and have a “.xml” extension.
What’s inside each one of these .xml files? Let’s take a peek at a sample one:
<?xml version="1.0" encoding="utf-16"?> <LandData> <Area>6256</Area> <AuctionID>0</AuctionID> <AuthBuyerID>00000000-0000-0000-0000-000000000000</AuthBuyerID> <Category>-1</Category> <ClaimDate>1255170099</ClaimDate> <ClaimPrice>0</ClaimPrice> <GlobalID>bfbf7bd4-7d7b-4a35-aba0-c352201cddcf</GlobalID> <GroupID>00000000-0000-0000-0000-000000000000</GroupID> <IsGroupOwned>False</IsGroupOwned> <Bitmap>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAP//fwAAAAAA//9/AAAAAAD//38AAAAAAP//fwAAAAAA//9/AAAAAAD//38AAAAAAP//f wAAAAAA//9/AAAAAAD//38AAAAAAP//fwAAAAAA//9/AAAAAAD//38AAAAAAP//fwAAAAAA/ /9/AAAAAAD//38AAAAAAP//fwAAAAAA//9/AAAAAAA=</Bitmap> <Description /> <Flags>505454667</Flags> <LandingType>0</LandingType> <Name>Arrabal Tango Club</Name> <Status>0</Status> <LocalID>4</LocalID> <MediaAutoScale>0</MediaAutoScale> <MediaID>00000000-0000-0000-0000-000000000000</MediaID> <MediaURL /> <MusicURL>http://xx.xx.xx.xx:8000</MusicURL> <OwnerID>69af4428-cec0-48d8-a0d9-c05268facca5</OwnerID> <ParcelAccessList /> <PassHours>0</PassHours> <PassPrice>0</PassPrice> <SalePrice>0</SalePrice> <SnapshotID>00000000-0000-0000-0000-000000000000</SnapshotID> <UserLocation><0, 0, 0></UserLocation> <UserLookAt><0, 0, 0></UserLookAt> <Dwell>0</Dwell> <OtherCleanTime>0</OtherCleanTime> </LandData>
That’s the xml file for Arrabal Tango Club in Condensation Land — I’ve only obscured the music URL and wrapped the part between the <Bitmap> and </Bitmap> tags, which originally used only one line, with no intervening blanks. This string encodes the shape and position of the parcel in the region. How do we know that? Well, the parcel map has to be stored somewhere, and it has to be quite large, so the only candidate is the “Bitmap” string :-) Most probably this long string is a text encoding of binary data.
Indeed this is the case: the string is using the Base64 encoding (you can find that quickly by browsing the Wikipedia). After decoding the string, we get a binary chunk of exactly 512 bytes. I checked that all the terrain files have strings of exactly the same length, so this number had to mean something. Continue reading
Zoe (Zonja’s OAR Editor) is a simple offline OAR manipulation tool that I wrote recently. You can find a detailed description of its functionality in my recent post “Moving and rotating OARs”. In this post I’ll describe how to install and use Zoe. I’ve designed Zoe with simplicity in mind, so that currently it only implements some very basic operations — by combining these operations, however, a number of pretty cool things can already be done. I’d love to get some feedback about the functionality of Zoe — at the end of the post I’ll list some of the things that I want to add to it, but I’m open to suggestions.
[Update 20091216: ZOE v 0.1 has been released. You’ll find a manual and the download link here.]
…and some filtering too
Opensim Archives (OARs) are nowadays the standard tool to share and interchange full Opensim regions. Justin Clark-Casey, the core Opensim developer in charge of OARs, has lately added merge functionality to the loading of OARs. This means that you can merge (i.e., add) the contents of an OAR file to an existing region, without deleting its contents. This opens a plethora of interesting possibilities, but it also is the source of a lot of new problems. What if I’m very interested in merging an OAR with one of my existing regions, but I’d prefer the new contents to be placed differently from their original position? For example, I can be given an airboxed level at 1000 meters, but I might want to put it at 2000 m (for example, because I already have contents at 1000 m). Or I might be interested in an OAR with (say) some nice palace and gardens, but it’s located in the NE corner of the sim and I’d like to install it in the SW part of the sim.
At present, the “load oar” command does not allow for this kind of transformations. Indeed, it’s debatable whether Opensim should include code for this kind of application at all, or whether such manipulations should better be handled offline.
In this article I present a very simple (and highly experimental) OAR manipulation tool called ZOE (for Zonja’s Oar Editor :-)) that implements some very basic forms of filtering, relocation and rotation for OARs as a whole.