D2 is meant to be a personal virtual world server, so some of these addons have limitations that reflect the spirit of a personal virtual world. For example, in D2 you can create at most 2 groups. I have an unlimited version of Groups, too, but that is meant for larger worlds.

Anyway, you can find all the information about these addons here. The Wifi web app has been extended with some minimal support for managing groups.

These addons are works in progress, and I will keep improving them. This is their first release to the public, so expect some hickups. Please report those issues here, but make sure to read the documentation first.

Have fun!

If you are updating your D2 in Linux from r20232-b to the latest, you will very likely encounter the following problem:

$ mono Update.exe
Using download link http://metaverseink.com/download/diva-r22043.zip
Your current release is diva-r20232-b. Available release is diva-r22043
New release available. Updating…
Downloading new release from http://metaverseink.com/download/diva-r22043.zip to /tmp/diva-r22043.zip. This may take a few minutes.
……………………………………………………………:-)
Extracting new release to /home/opensim
* Unable to unzip. Please try updating later. (Reason: Path is empty)
*********************************************************************
Your installation has been updated. The new release is in
>> /home/opensim/diva-r22043 <<
Your regions have been migrated.
Please read the RELEASENOTES to know what changed.
If you made changes to OpenSim.ini, please copy that file over
or change the new one.
*********************************************************************

<Press return to exit>

In other words, the Update tool fails to unzip the new package.

This is due to a bug in a library included in OpenSim 0.7.4, on which diva-r20232-b is based. The offending library is called Ionic.Zip.dll. Here is what you need to do in order to get past this issue.

1 – Download this version of that library and place it in your current d2 bin folder, diva-r20232-b/bin. You can overwrite  the one that’s there, or move it somewhere before placing the new version there. Note that some download tools (e.g. wget) don’t overwrite files and instead give them new names. Make sure the new version has the right name.

2 – Run the Update tool again.
$ mono Update.exe

Voila! Problem solved.

The latest D2 release has the correct version of Ionic.Zip.dll, so hopefully this won’t happen next time you need to update.

127.0.0.1 localhost
127.0.1.1 nile.ics.uci.edu nile

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Yesterday, I spent a lot of time harassing just about everyone in my University’s Networking Support department because I couldn’t get an OpenSim server to serve clients anywhere. We know that OpenSim networking is hard. But, damn it, I’m one of the core devs of OpenSim, and I have a pretty good idea of what’s involved in the protocols between the server and the client. I’ve had lots of OpenSim servers running successfully in all sorts of networks, including my University’s. Well, the problem turned out to be… Ubuntu!

The default installation of Ubuntu comes with a horrible hack in /etc/hosts:

127.0.1.1 nile.ics.uci.edu nile

Yes, this maps the domain name to an interface in localhost, for reasons explained here. As stated in the Debian Reference:

“This is really improper because system hostnames and domain names are two very different things; but there you have it.”

How does this impact OpenSim?

Upon client login (over TCP), OpenSim sends its UDP address to the client. In doing so, it needs to send the actual IP address, not the domain name — the client expects the IP address. Due to that entry in /etc/hosts, OpenSim was getting nile.ics.uci.edu translated into the localhost IP… Fail!

Fix: either remove/comment that line from /etc/hosts or replace it with the external IP address of that server, if it has one.

Conclusion: bad Ubuntu! (Debian may suffer from the same problem)

It’s been a while since I last posted about HG 2, but it’s finally coming to life! HG 2 is all about letting grid operators define policies for access control to their grid’s assets and users. I thought I’d show how it is taking shape, so that you’ll be ready for it in the next OpenSim release.

HG Inventory

Inventory is much more secure than in HG 1.5, and the My Suitcase folder is playing an even more important role in that.

The first difference you will notice is that this folder is now under the root folder — see picture on the left. In HG 1.5, My Suitcase was at the same level as the root folder. That posed some issues, because the viewers can’t really handle that. So we had to make up Web applications (like D2 Wifi) to make inventory manipulations between the Suitcase and the other folders. Kind of hacky. That’s not happening anymore. In HG 2, My Suitcase is inside your normal inventory tree, so you can easily copy items back and forth between that folder and others.

Like in HG 1.5, the My Suitcase folder is special: it is the folder tree that receives objects you collect while you are visiting other grids. But now it is even more special: it is the only folder tree that is accessible to you (and therefore to the rest of the Internet) while you are traveling. Period.

Look at how your inventory will look like in HG 2 when you are outside your home world — see picture on the left. As the picture shows, all your folders except My Suitcase are shown as (Unavailable). You can still see them, and unfold them. You may even be able to access items that are already cached in your viewer’s cache (textures, notecards, etc.). But if you try to access any items outside My Suitcase that aren’t cached in your viewer while you are outside your home world, the operation will fail. For example, rezzing objects from those folders will fail.

Items inside My Suitcase, however, will be available. My Suitcase will also be the tree where all the items collected while traveling  will go. Once you are back home you can then move them into other folders.

In short: the Suitcase is now really the only thing you’ll have available while traveling (but keep on reading for some exceptions). That means that it is also only the only thing that is available for rogue grids to mess with. Treat it as your own real-world suitcase: it may be stolen or badly damaged. But the rest of your belongings are safe in your home world.

[UPDATE 9/23] I should be more clear. The existing HG1.5 inventory service, which lets users still access their entire inventory abroad, will still be available in the future. Grids can continue to use that. They can even use the normal inventory service (HG1.0 style) on the Hypergrid, which has no restrictions whatsoever about inventory manipulation. Both of these, however, especially the normal inventory service, are horribly insecure and expose users to all sorts of risks regarding their inventory. Unless the networked grids have 100% trust in each other, I don’t recommend using them.

Appearance

Appearance in SL/OpenSim is a very tricky thing. Your appearance as an avatar consists of two things: wearables (shape, clothes, etc.) and attachments (prim hair, etc.), which can be arbitrarily complex objects with textures, scripts, etc. Additionally, the viewer “bakes” all the wearables into a set of textures, and those are the ones that are actually passed around between your viewer and the viewers of all other people around you. To make things even more complicated, the attachments have a nasty dependency with your inventory — they are objects that must be somewhere in your inventory, and the viewer must know about them being attached to you.

Why am I telling this? So that you understand some of the challenges regarding inventory access and asset access control related to your appearance.

Your appearance’s assets will be copied to the worlds that you are visiting, even if the items that you are wearing are not in the Suitcase folder. If we didn’t do that, you’d always have to switch into an appearance whose items would be in your Suitcase, and that would be a pain. So, your appearance items (your clothes, body parts and attachments) are the only exceptions to the rule “the only items available outside are items under the My Suitcase folder.”  They are copied, and, as such, assume that they will be publicly available.

But this is not good enough for some grids. Suppose you are a user of a commercial grid wearing a very expensive avatar. That grid may not want any of its assets to be exported to other grids, including the avatar that you are wearing — that refusal of service can now be done (read on). But if you arrive at the destination without any wearables and attachments, you will be seen there as Ruth, even if you see yourself wearing the same expensive avatar because it is cached in your viewer as you travel. Projecting a Ruth image to others is not something we consider a good user experience, so we had to fix this somehow.

There is a configuration variable that grids can set regarding the use of “allowed appearances for Hypergriding.” That is, grids can create one or more appearances with assets that they don’t mind being publicly shared, and then force their users to wear one of those appearances before hypergriding out. The picture on the left shows the warning message when a user is wearing something that is not part of the allowed HG appearance assets, in this case, it was the sphere attachment.

Unfortunately, due the lack of appropriate viewer features, the appearance switch has to be done explicitly by the user, it can’t be done automatically. So if the user gets this warning message when she’s trying to HG TP, she needs to replace her outfit with one of the official ones. In the case in the picture, it’s a folder called HGOutfit.

 Assets Access Control

The access to a grid’s assets in the Hypergrid is done via a service called the HG Asset Service. Grid owners can now configure that service by specifying policies for exporting their grid’s assets to the outside world. For example, they can say that it’s ok for others to access textures and sounds but not scripts or meshes, or any other combination — the policy specification language takes the entire set of asset types. Grid owners can also specify which kinds of assets the grid can import from other grids.

The specification is done under the section [HGAssetService], something like this:

[HGAssetService]
    HomeURI = "http://127.0.0.1:9000"
    ;; The asset types that will never be exported
    DisallowExport ="LSLText, LSLBytecode"
    ;; The asset types that will never be imported
    DisallowImport ="LSLBytecode"

When these policies are specified, those types of assets will never be imported/exported, no matter what users and the rest of the world may do.

Going one step deeper into content protection, commercial grids with protected content may want to physically separate their internal asset server from their HG asset server, i.e. they can operate over completely different databases. Their internal asset server can continue to be behind the firewall. With the Robust architecture, this has been possible for a while. But now it is possible to make that physical separation meaningfully regarding the user’s Suitcase folder. When that separation is in place, the assets for the Suitcase items will be stored in the HG asset server database, and users cannot copy items back and forth between the Suitcase and the other folders. The items in the Suitcase folder will be  unavailable in the users’ home world, and become available only when the user is traveling. This may be a desired feature, as commercial grids may not like the import of freebies from the outside. This requires some advanced configuration, but that’s the kind of security barriers that need to be in place for commercial grids to start experimenting with the HG.

For the time being, asset access control is done in bulk, based on asset types, and specified by the grid operator. There is no fine-grain asset access control [yet]. What this means is that grid users cannot express their own policies regarding their own objects, they are at the mercy of the grid operator. Bringing that specification up to the users will require some User Interface work (possibly on the viewers) that isn’t done yet. We’ll leave that for HG 2.5.

Users Access Control

In an HG Teleport, there are always two independent authorities involved: the home world of the user and the destination world. These can now be configured, also independently, regarding HG travels. It is now possible to control who goes where. This is the basis for the emergence of HG sub-networks — groups of grids connected to each other, but not to everyone, via the HG.

Incoming HG visitors

The control of which kinds of users can visit our world is done in a service called the Gatekeeper. It is now possible to specify whether the grid accepts foreign users or not, and, if it does, from which domains those users should be. When a user tries to HG TP to a grid in which she is not allowed, she gets a message like the one seen on the picture on the left “Destination does not allow users from your world.”

The configuration looks like this:

[GatekeeperService]
...
  ; ForeignAgentsAllowed = true
  ;;

  ;; If ForeignAgentsAllowed is true, make exceptions using AllowExcept.
  ;; Leave blank or commented for no exceptions.
  AllowExcept = "http://griefer.com:8002, http://enemy.com:8002"
  ;;
  ;; If ForeignAgentsAllowed is false, make exceptions using DisallowExcept
  ;; Leave blank or commented for no exceptions.
  ; DisallowExcept = "http://myfriendgrid.com:8002, http://myboss.com:8002"

The fine-grain control of specific users can continue to be done with ban lists and other mechanisms that already exist. The kind of control we added in HG 2.0 is domain-based, so all users from those domains will / will not be allowed in. That is what allows the emergence of HG sub-networks.

Outgoing local users

Conversely, the home world of users also has a say about where the users can and cannot go. That is done in a service called User Agents. When a user tries to HG TP to a grid which her home world doesn’t want her to go, she gets a message like the one seen on the picture on the left “Your world does not allow you to visit the destination.”

On this side of things, the policy specifications are based on the user-level. That is, users at different levels may be subjected to different restrictions.

The configuration looks like this:

[UserAgentService]
...

;; Are local users allowed to visit other grids?

;; What user level? Use variables of this forrm:
 ;; ForeignTripsAllowed_Level_<UserLevel> = true | false
 ;; For example:
 ForeignTripsAllowed_Level_0 = false
 ForeignTripsAllowed_Level_10 = true ; true is default
 ;;
 ;; If ForeignTripsAllowed is true, make exceptions using AllowExcept.
 ;; Leave blank or commented for no exceptions.
 AllowExcept_Level_10 = "http://griefer.com:8002, http://enemy.com:8002"
 ;;
 ;; If ForeignTripsAllowed is false, make exceptions using DisallowExcept
 ;; Leave blank or commented for no exceptions.
 DisallowExcept_Level_0 = "http://myfriendgrid.com:8002, http://myboss.com:8002"

Last week I packaged a release of the Diva Distribution (D2) for OpenSimulator 0.7.4. I’m glad to see that D2 continues to be very popular. Not just there’s already a large number of downloads, but other distributions such as sim-on-a stick also continue build on it. D2 is very easy to install because of the Configuration tool that comes with it. It’s also very easy to keep up-to-date because of the Update tool that is included.

Nevertheless, medium-to-advanced users of D2 often want to change a thing or two from what comes in the package. One thing that I often hear is people not wanting to use mega-regions and, instead, wanting to use plain regions. Another thing I often hear is wanting to add more regions. These are all perfectly good things to do with your D2 installation. However, there’s the wrong way and the right way of changing the default configurations. If you change them the wrong way, things may work fine for a while, but they may break in the next update. This post explains the right way of changing the D2 configurations.

First of all, let me explain how the D2 configuration is designed. D2 uses a hierarchy of configuration files, each possibly overwriting  configuration variables defined in the parent. The hierarchy is shown in the picture on top of this post: the first config file is OpenSimDefaults.ini, the second is OpenSim.ini, the third is DivaPreferences.ini and the forth, and last, is MyWorld.ini. OpenSimDefaults.ini and OpenSim.ini are the regular OpenSim configuration files; the other two are specific to D2. DivaPreferences, as the name says, contains my preferences. If you look in there, there are several modules and connectors that you really don’t want to mess with; it also contains some of my preferences, such as mega-regions (CombineContiguousRegions=true) and permissions. MyWorld, as the name says, contains the configuration variables that are specific to your world — things like URLs, names, etc. But it can have much more.

OK, so having explained this, let me explain how to change configurations the right way. Remember, the hierarchy is overwritable, meaning that settings in the lower levels overwrite settings in the upper levels of the hierarchy. So, whenever you want to change something in your D2 installation, you should do it only, and exactly, in MyWorld.ini. Here is an example.

Suppose you want to use normal regions instead of mega-regions. That is established by the variable CombineContiguousRegions in the [Startup] section. If you look carefully, that variable is first defined in OpenSimDefaults.ini as false (so, no mega-regions). OpenSim.ini uses that default. DivaPreferences.ini, however, overwrites it to true (so, mega-regions are on). If you want to set it back to false, edit your MyWorld.ini and add that variable like this

 [Startup]

  ...

    CombineContiguousRegions = false

Reboot your world, and the change will take effect. (WARNING: if you have been building on the default mega-region of D2, I strongly advise you not to make this particular change, because your buildings in all but the SW region will become phantom)

You can do the same for just about any configuration variable you may want to change! — physics, voice, etc. If the section doesn’t exist in MyWorld.ini, simply add it there.

Why MyWorld.ini and not the other configuration files? Because the next time you update your D2 installation, the new package will bring along new OpenSimDefaults.ini, OpenSim.ini and DivaPreferences.ini files that reflect eventual changes to configurations in OpenSim; the changes you made in those files will not be carried along to the new installation. Of all the 4 configuration files depicted in the picture above, the only one that is preserved between updates is your MyWorld.ini file.

I hope this clarifies things! And happy Virtual-Worlding!

Like many of you, I read Maria’s article last December saying that Vivox was giving free voice service to small OpenSim worlds. I thought that was a nice gesture, but I confess I found it hard to believe, so I didn’t act on it. Until yesterday.

I decided to give it shot, because my projects could really use inworld voice, and I had nothing to loose just for asking. Yesterday was Sunday. To my surprise, I got a reply within 1 hour of my request. I filled out the license agreement. This morning an email was waiting for me with the precise instructions, down to the lines that I needed to add to my .ini, and a link to the blog post that Kitely wrote on how to enable voice. I just had to copy-and-paste the config, and I had voice working in 10 minutes! — 9 of which were spent figuring out which buttons to press on the viewer to enable voice all over.

I couldn’t believe it! Someone at Vivox must really like OpenSim! Wow.

D2-ers, don’t miss out on this fantastic opportunity! See Maria’s article and take it from there. No need for complicated and costly licenses. No need for horribly complicated and fail-ful Freeswitch installations. Small worlds just got as powerful as the big ones — or even more powerful, because big, commercial worlds need to pay for the service, and the small ones don’t. At least for the time being.

I usually don’t write about the future, I prefer to write about things that are already done and working. But I’m going to make an exception, because people are starting to ask about configurations of the Hypergrid that pertain to the next level; we’re almost there, but not yet. I am going to give an overview of what’s in the works right now that will result in the next big bump in the HG number: the big two-point-oh.

As usual, some context first.

The very first version of the Hypergrid, HG 1.0, was done back at the end of 2008, and continued through 2009 and 2010. That first version was just an exercise in feasibility and in interacting with the opaque, black box viewer. Could I trick the viewer to think that it was still on the same grid while in reality sending the user to a different grid? — that was the humble goal of HG 1.0. HG 1.0 was not concerned with security at all, as the main goal was to figure out how to use the viewer in ways for which it had not be designed. Once I mastered the signaling of agent teleports, it was time to take the HG to next level: more security all around.

The next version was HG 1.5. The conceptual work for it started in early 2009, although the actual coding only happened much later. This was because in order to implement the Hypergrid as a collection of additional, optional services that don’t interfere with the simplest configuration, OpenSimulator itself had to be considerably refactored. That took a long time. HG1.5 came with OpenSim 0.7 in July of 2010. It featured identity security as well as a semi-secure (or semi-insecure, depending on whether you are an optimism or a pessimist) Hypergrid inventory. It also had all the right architecture for enabling HG Instant Message and Friends. That’s where we are right now.

So let me explain what we’re working on for HG 2.0

Inventory

Hypergrid Inventory is going to be 100% secure and the Suitcase will finally be usable without external Web apps. This required some heavy hacking in order to understand how to further trick the viewer into submission (i.e. use it beyond its specs), but we did it. Here is what will happen. When a user goes out, her entire home inventory tree will be removed from the viewer and replaced with the Suitcase folder tree only. That’s the only portion of the user’s inventory that will be exposed to the outside and to the user while the user is hypergriding. That way, the user’s home inventory will be out of reach and completely protected. Once the user returns to the home grid, the Suitcase wannabe-root folder is replaced by the user’s real inventory tree again.

Depending on configuration, the Suitcase folder may or may not be available to the user when she is in her home grid. When it is available, it will be a regular folder under “My Inventory”; the user can then move stuff from/to the Suitcase to/from other folders using the viewer.  But some grids may not want their users to bring in stuff from the outside, they want to continue to segregate content, so availability of the Suitcase folder in the home grid will be configurable.

Appearance

The appearance that a traveling user has may or may not be the same as the appearance that she had when she left the home grid. Again, this will be configurable. But the idea here is that  some grids don’t want to allow the export of appearance assets at all, so they may provide generic appearances to their traveling users, and dress them with their appearances when they come back. Other grids may not care about this, and appearance will be preserved.

User Access Control

There will be a means to specify several policies of access control: who can go out and where, who can come in and from where. These policies are based on several pieces of information about the users themselves and about their grids of origin.

So for example, it will be possible to specify that only users of a certain level can Hypergrid out, while others under that level can’t (a requirement often heard in educational settings). It will also be possible to specify a limited set of grids that the users can visit; or a set of grids that the users cannot visit.

On the receiving end, it will be possible to specify only a limited set of grids whose users are allowed in; or a set of grids whose users are not allowed in; or no foreigners allowed in at all.

Assets Access Control

There will be a means to specify whether the grid allows asset exports to other grids, and which grids, as a whole. HG 2.0 will not support the specification of fine-grained asset exports, i.e. I can’t say that this particular set of assets can go out, while that other can’t. This will require a means for people to be able to express that, and we don’t have that means yet.

≈

What this amounts to is that the Hypergrid will be able to support different policies that better reflect different levels of comfort that people have regarding opening up their worlds. Grids that deal with protected content will be able to continue to protect that content while allowing their users to visit other grids, and even collect items there, and allowing foreign users to come in and mingle — without any asset ever being exported or imported from/into their main storage. Grids that deal with kids will be able to block them from hypergriding while allowing certain privileged staff to go out and get content and knowledge from other grids. Secretive grids will be able to prevent foreign visitors while allowing their users to go out. Grids can have only one or two regions available to foreigners, while the rest is off-limits. Communities can make up small networks of worlds that allow Hypergrid exchanges only among themselves. Etc.

I hope this clarifies where we’re going with the Hypergrid!

I know that the first question that everyone will ask is: when? My guess: sometime this summer, hopefully early.

Hi everyone! I’m happy to announce the personal Hypergrid Teleporter! Its goal is to make your Hypergrid travels a bit easier and more enjoyable. Get it here as iar.

Let me first give a bit of context. Hypergrid teleports have been possible for a long time. Using plain OpenSim installations, traveling on the Hypergrid can be done in a couple of ways: (1) via the Map by typing in the HG address in the search box; or (2) by establishing the hypergrid link in the OpenSim console with the “link-region” command. While this works well, it’s a bit inconvenient. The Map process gets very confusing if you are using Viewers 2-3, because these latest viewers assume that there is only one map. The link-region command assumes that you have access to the server console, which obviously not everyone has.

In order to make things easier, we have seen systems like the Hypergates emerge. The Hypergates establish a centralized service where people can register their worlds, and others can travel to them using an inworld teleporter — a scripted object that uses osTeleportAgent at its core. The inworld object is really neat; it’s inspired in the Scifi TV series Stargate SG-1. The object  is relatively powerful and complex. When you click it, you are presented with a series of options about where to go. Once you choose your destination, you step in and, with luck, you are teleported there. I say “with luck” because two of the major characteristics of the Hypergrid as it exists today are (1) the fact that many worlds are turned off as much as they are turned on, especially those hosted in people’s homes; and (2) the annoying 4096 travel distance limit. So, for a number of reasons, the teleport may not succeed.

I like the idea of inworld teleporters like the Hypergates. They make HG travelling a lot more fun than using the map. But the Hypergates is a bit too complicated for me. I wanted to have a much simpler object that just teleports me to a specific world that I already know and like. After all, osTeleportAgent is super easy to use.

Hence, the Metaverse Ink Hypergate Teleporter! It’s also Scifi-inspired, in this case the Star Trek teleporter. Let me explain how it works.

First of all, the Metaverse Ink Hypergrid Teleporter uses osTeleportAgent, an OS function that requires special permissions. The owner of the world needs to enable it. In the Diva distro, this function is enabled by default, but restricted to the estate owner and the land owner. So only those users can run this teleporter.

When you rez the teleporter, it comes with a default destination, the UCI Grid. You can try it as is. So how do you actually teleport? Very simply by walking in and stepping on the platform, just like the picture at the very top of this article illustrates. There is a 2 sec delay just for the fun of being showered with a particle beam, and then the teleport starts. The teleport may still fail, for a number of reasons. One of them is the 4,096 limit. Other reasons may be the cause; for example, the destination may not be accepting HG agents, or it may be misconfigured, etc. If the teleport fails for some reason, you will be told so.

You can change the destination by editing the object and setting a new destination in the Description field (see picture of the left). For example, if you want to set it to OSGrid, change the Description field to, for example,
http://hg.osgrid.org jump4000 (that’s accessible to the lower grids, jump8000 for the upper ones).
Close the editing window.

In order to get immediate feedback on whether that destination is up or down, “touch” the platform of the teleporter (the bottom part). This will perform a status check. If the destination is up and running, you will be told so, and the yellow particle beam will continue to flow; if the destination is off, you will also be told so within 30 seconds, and the particle beam will stop.

The teleporter performs an automatic status check on the destination every hour. If it can’t reach it, it turns itself off; if it can reach it, it turns itself on. In either case, it checks it again one hour later. So you can just let it be, and be assured that the particle beam  represents the status of the destination within 1 hour error margin. For example, on the left you can see 4 teleporters, each one set to a specific destination. The left-most one is offline at the moment I took the picture.

You can always check again any time you want by “touching” the platform.

But there’s more!

If you touch the top part of the teleporter, the search icon, it launches the Web browser on the Metaverse Ink Search page. Depending on how you have that configured, it may launch it embedded in the Viewer or external to it. What i’m about to explain works in both cases, although I personally prefer the embedded browser.

That first page has a few Hypergrid addresses that I personally recommend. You can go there simply by clicking on the Web links! That’s right — HG teleports can be triggered by Web links too! This works particularly well for OpenSim 0.7.3.1 and later.

But you can also search for other worlds using the search box on the top left of the page. I confess that I have been neglecting the Metaverse Ink Search engine, because I have been busy making the Hypergrid actually work. MI Search has issues on worlds running Opensim versions before 0.7.3.1, especially grids. But I am restarting to work on it. So as worlds upgrade to Opensim 0.7.3.1, MI Search will work  much better!

There are many improvements in OpenSim, most notably the new LSL NPC stuff — this allows you to create and manipulate Non-Player Characters (bots) directly from scripts. Really cool!

Hypergrid-wise, the most noteworthy development is the support for Friends across the Hypergrid. As explained in a previous post, I have created a world-to-world social network platform in OpenSim! Diaspora, anyone? Well, I get to actually do it and deploy it in  your worlds

Have fun!

P.S. I also made a new release for Wifi that works with Robust 0.7.2. Enjoy!

As the title says.

Over the weekend, I added the machinery for the new V2 map to work with vanilla OpenSim. If you want to try it out, watch out for the several changes in configuration files, especially those in .ini.example’s — make a diff to see what changed.

Note that viewer 2 is even more radical than viewer 1 when it comes to regions placed above 2,048. Most likely, the map won’t work there at all. (I haven’t tried it)

Also note that, for the time being, V2 map will get considerably confused on HG teleports. The first step was to make the map work. The next step is fixing the map for the Hypergrid. There’s a brute-force way of doing it, and there’s an elegant way of doing it. The elegant way of doing it requires collaboration with viewer developers. Let’s see what we can do together…

Enjoy!