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
[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.