Metaverse Ink

A recent thread about financial contributions to the OpenSimulator project touched on issues that we don’t talk about that often in the opensim-dev mailing list: organizational, institutional and financial aspects of the project. These aspects are all different, but they usually go hand-in-hand. I thought I’d share my thoughts on this, and get some input from the community. As usual, goes without saying, these are my personal thoughts, and not any official statement from the core devs (hopefully this will become clear if you understand this post, and we can stop adding this disclaimer in every email/post).

The OpenSimulator project is fueled by a small group of developers who produce the the vast majority of the code and who have commit access to the socially-accepted-as-main GIT repository. I say “fueled” rather than “led” for obvious reasons: there has been only a vague sense of leadership, but nothing that deserves that name, at least not the traditional form of leadership that we’re used to; a visit to the main portal for this project, the Wiki, illustrates this point: that’s the closest to a Bazaar of information that one can get, complete with perls of dubious origin and products well beyond their validity date. I say “socially-accepted-as-main” rather than “main” or “official”, because that’s what it is: a social convention. Anyone can take the code and fork it, and this has been made even more appealing when we switched to GIT, which has much more powerful merging facilities, so it becomes technically a lot simpler to maintain extensions or alternatives to what’s in the socially-accepted-as-main repository. Yet most people in the community look at the code produced by the core developers as the official code.

Like so many other open source projects, the OpenSimulator project does not have any formal setup. This doesn’t mean that the project is an anarchy, though. Internally, the group of developers follows a few simple rules of engagement for deciding on all important aspects of the project, such as new developers, significant patches, etc. The issues are first discussed, then voted upon. Technical discussions happen publicly in the -dev mailing list, so that everyone can participate; discussions about new developers happen in the -core mailing list. The outcome of all voting is positive as long as there are no objections — much more stringent than a majority scheme, it requires a fair amount of consensus. The core developers listen to the community, but the only votes that count are those of the core developers. These rules of engagement are similar to those followed in many other open source projects. These are localized, case-by-case decisions that, overall, define the direction of the project.

Periodically, the group of core devs has internal existential moments of the kind “should we create a formal organization?” a-la Apache Foundation, for example. Invariably, the answer always converged to “no”, at least so far. The reasons behind this “no” boil down to no one seeing enough benefit to compensate for the hassle. The last time we talked about this, the idea almost took off; but it quietly landed again for lack of interest/time for actually executing it. The idea of a foundation is still up in the air; maybe next time we have an existential moment it will happen.

If a foundation were to happen, it would NOT be for taking in and managing donations for code development — for reasons that will be evident below. Otherwise, the foundation would effectively be a small company, which would completely defeat the mission of the project. For anyone interested in this, take a look at the finances of the Apache Foundation. The money raised there is to pay for servers, organize meetings and cover legal expenses… which come as a consequence of a having created a formal organization in the first place…

About the finances, and to put this in perspective: according to Ohloh, the OpenSimulator project has cost $5.5M to get to where it is now; that’s with an avg. salary of $55K/year… (ah!), and this estimate doesn’t count anything other than code in the socially-accepted-as-main repository. It doesn’t count testing time or all the projects in forge and elsewhere. Even with those hugely simplifying  approximations, that’s a burn rate of $1.6M/year.

Where does this money come from? Like in all independent open source projects I know, it comes from the following sources:

a) Voluntary time contributions from passionate people who have stable day jobs and enjoy developing OpenSimulator in their free time, for free. The reasons why people do that are well known and fall out of the scope of this post.

b) Generous contributions from companies and organizations who have some of their employees contribute to OpenSimulator as part of their day jobs. Current and past examples are: IBM, Intel, the University of California, Reaction Grid, 3Di, and others.

c) Contributions from individuals and organizations who contract with individual developers, usually to produce something very specific.

Note, again, that this is a burn rate of $1.6M/year (with Ohloh’s ridiculously low estimates)… Does anyone here believe that this kind of money can be raised from voluntary donations every year, so that the project could afford ‘hiring’ N permanent developers (if that were a goal, which it isn’t)? Obviously, not.

Basing developers’ compensation on direct donations is an unsustainable strategy for a large open source project of this kind. It’s great to hear from people who are willing to donate $1,000 to the project, we appreciate the gesture, but, really… the numbers just don’t add up, and such practice would create a lot of unwanted tension that would force the project into becoming more like a small company, which is something none of us wants. So we have to say no. That money is better spent on other things, like paying artists to create freely distributable content that enriches everyone’s virtual worlds — a really important detail for that first-time experience.

An hypothetical Foundation would not engage in that kind of activity; it would also not interfere with the existing rules of  engagement, which work well. So the pertinent question is this: if not for raising money for development, what would this possible foundation be for? I don’t have a good answer to that question. In some perspective, a foundation looks like a self-generating hassle — having to deal with taxes and lawyers is not something any of us enjoys, and the money raised would mainly be to deal with those. Maybe that possible foundation could hold copyrights for those developers who don’t want to hold them, and take on the consequent legal liability. Again, more lawyers.

One benefit I see in it is that, psychologically, this possible foundation would give a warm fuzzy feeling to the community at large, more or less like a legal marriage.The fact that a small group of us would come together to confront a premeditated hassle would be a bonding experience for this small group of people, and it would send the message that we are serious about our relationship with each other and the community at large. Personally, I don’t believe in the benefits of legal marriage [for me], so I have a hard time convincing myself that such formality is really needed in this project too. We have bonded by having serious disagreements from time to time, and being able to overcome them and still be producing awesomeness.

Another, more convincing benefit, would be the possibility of involving non-coders in this foundation in ways that the project, as is, isn’t prepared to take. For example, we could take in contributors of good documentation as members of this foundation. Having a formal relation with a formal organization might be a good incentive for some people to do that task really well — as opposed to being yet another voice on the cacophony of Wiki. Similarly to documenters, we might take in people for additional roles such as testers and community leaders in specific topics. The foundation would be a means to get ourselves more organized, just like legal marriage sometimes is a means to take on more responsibility.

So, the jury’s out on this. It’s not obvious that a foundation-anchored OpenSimulator project would be any better than what we have now. I’d be interested in hearing your thoughts on this.

But independent on that possible foundation, I hope this sheds some light on some of these important issues that are rarely discussed in the dev ML, but that show up implicitly in many posts. The fact that the OpenSimulator project isn’t a formal organization but a collection of individual developers (even if they are in the payroll of others) with their own motivations that must be relentlessly protected and respected; that it doesn’t accept monetary donations; where the roadmap is the collection of interests of the individual developers; that constantly reminds the community to take on their own initiatives; that sucks at doing PR; … in other words, the refusal to take on a traditional community leadership position … none of this happens by accident; it’s something that has been carefully considered from time to time among the core devs, and which we have agreed upon. It’s what works for us. So far. Like many marriages, we may end up needing  to create a formal unit because of external pressures.

Yesterday, Stefan wrote down his thoughts on Linden Lab’s troubles. I loved that post, he’s right on. Let me add to that by stating the importance of the work that many of the laid off Lindens did, and the role of OpenSimulator from here on, at the technological level and beyond.

Things are moving into 3D, including the Web. I’ve been very excited with everything that is going on with WebGL. Sure, WebGL is still not good enough to render very rich scenes like those we find in highly immersive games, especially when the scenes aren’t optimized, such as the case with user-generated 3D content. But I have very little doubt that the needed optimizations will happen, and that soon we will have immersion on the web browser. It’s already happening. People want it, Google wants, it will happen.

So, let’s fast forward to the time when the Web browser can render rich 3D scenes, which, at the rate that the Google people and the Unity3D people are going at it, it probably is only a couple of years away.

Technically, the client-side is not the whole story. In order to develop highly immersive real-time environments with that kind of viewer, we still need a server side that can serve those 3D scenes in real-time to several clients. HTTP alone won’t do, it’s too slow. All MMOs use some sort of UDP-based protocol for the rapid state change notifications. HTML5’s Web sockets are there precisely for that reason.

Bottom-line: the server-side must serve more than HTTP.

There are a few of these game servers out there, the vast majority of them proprietary. Which is fine for the companies that own them. In the scenario where the browser is the 3D viewer, those companies can easily develop the necessary JavaScript components that talk to their back-end servers via WebSockets.

All these proprietary servers, however, are a bottleneck for the massification of 3D content on the Web. Just like for the Web itself, we need open source 3D scene servers. At the very least, we need open, standard protocols, so that people can focus on developing content without having to reinvent the network connectors, and the servers, from scratch all the time. (But with open standards come open implementations, so the result is the same: we need open source servers). Yes, we need an Apache for RT 3D scenes. Hmm, where did I hear that before…?

OpenSimulator, of course. When WebGL is good enough to render those rich 3D scenes, OpenSimulator will be there to serve those scenes in real-time to multiple clients. For free. This is the real importance of OpenSim, its main contribution. Another, secondary, contribution is all the research work that we have been doing in secure, portable identity with the Hypergrid. This is something that doesn’t exist on the Web, but it can be ported back. I’m not entirely sure the 2D Web needs it, but I’m pretty sure a web of virtual worlds needs it. Not all 3D environments will want to be connected in a web of peer servers; but many will.

In all of this, we must thank Linden Lab, especially Cory Ondrejka and Marc Lentczner, for making their protocol public; that made OpenSim legally possible. All other game companies are protective of their protocols, to the point that they go after anyone who tries to reverse-engineer them. That was not the case with Linden Lab, and we must thank them for that. They allowed us to focus on the server side. The fact that the client was available independently, for free, was no small thing either: it made the effort appealing to lots of people who got instant gratification of a Linden-like world on their own computers. More people means more eyes, more energy. MW and Lbsa were right on from the very beginning!

Going forward, the main challenge for OpenSim is to step back from the monstrosity of LLUDP and LLCAPs, which were designed for one very particular kind of environment, and figure out the minimum set of messaging that’s necessary to serve 3D scenes in RT to multiple clients. Minimum is good. The good thing about OpenSim is that the client protocols are plugin modules; OpenSim is not tied to any one particular client, not even LL (in theory; the reality of the code is a bit different… that’s why I say that stepping back from the LL protocol will be a challenge for OpenSim).

I feel like we’re parting ways with a long-time, dysfunctional, companion who decided to make a left turn, and I’m looking forward to what’s coming!

The news came yesterday after lunch: major layoffs at Linden Lab, as much as 30% of their employees. Lindens who had been there from early on, respected engineers, all laid off. All of those who had, at some point, been involved in the idea of virtual world interoperability — gone. Then the new vision: Second Life on a browser, accessible to the masses via well-known social networks. Wow. This is what I call a 90-degree course adjustment.

Clearly, I know nothing about the internal situation at Linden Lab. Probably their VC money has dried off, maybe their revenue is not enough to pay so many people. Who knows what’s behind a 30% ‘rightsizing’… But the new vision is an indication that this is not just about balancing the budget sheet; it’s about redefining what Second Life is. LL’s CEO wants it to be more like FarmVille than like World of Warcraft. Too many people have commented on his vision, I’m not going to do it. He’s the head of the company, he should try to make his vision come to life.

What I want to talk about here is what this 90-degree course adjustment entails for OpenSim. I confess yesterday I had that familiar feeling of having reached the point of having to stand and lead. Not me, personally. But the OpenSim project, as a whole. The torch is on us. Let me explain.

In spite of being inherently a rebellious project, OpenSim has always existed in the shadow of Second Life. The rebellious nature was, indeed, just a confirmation of that dependency; the kind of relationship teenagers have with parents. A lot of people in the OpenSim community have been assuming that, sooner or later, the large Second Life virtual world would be trading avatars and money with OpenSim-based grids. The Open Grid Protocol (OGP) prototype, first unveiled in the summer of 2008, was a teaser; a promise of what could come next. Many OpenSim core developers have been deeply involved in efforts for virtual world interoperability, first in the Architecture Working Group, and, recently, in the VWRAP working group at the IEFT. Both of these working groups were led by Linden Lab engineers… who have been laid off.

In the wake of these layoffs, the idea that Second Life will be part of a larger web of virtual worlds is today more remote than ever. There’s no one left in Linden Lab to carry the interoperability torch, at least not of the kind we were thinking. It looks more likely that Second Life will be part of the Web itself, complete with the Web’s inability to deal with portable identity, and therefore eager to serve the largest pool of users on the Web, the 400 or so million Facebook users.

It’s always hard when the driver we were relying on suddenly makes a left turn from where we thought we were going. The question for OpenSim now is this: do we really want to follow Linden Lab on that left turn? Or do we take the torch and lead?

Personally, the last thing I want to do is to be involved in one more Facebook app. That’s the kind of interoperability project that I give my undergrad students on a 3-week time period. Not only it’s technically uninspired, but it’s missing the core of what I believe interoperable virtual worlds can bring to the Web itself: true, S2S portable identity. Not just “this is me” a-la OpenID, but “this is me, and I have a lot of baggage that I want to access while I’m visiting your site.” The vision of interoperable virtual environments is as exciting to me now as it was 3 years ago.

As usual, I don’t speak for the entire OpenSim project. And it’s probably too early to internalize what this course adjustment really means for OpenSim. But one thing is for sure: if there is going to be a web of virtual worlds, a decentralized S2S system of 3D environments that can seamlessly exchange user agents securely, that web will be made of OpenSim servers entirely, for the foreseeable future. Second Life is out of the picture.

As OpenSim becomes more stable, many people are looking into developing new businesses on top of it. That is great! An ecosystem of businesses is exactly what we want to happen, if OpenSim is to fulfill its potential. However, let me add a word of caution in the form of a personal plea regarding doing businesses on top of OpenSim: be careful with what you patent, or you may put yourself out of your business before you even create it by placing obstacles on the way of the infrastructure.

Ever wondered why it’s taking so long for a web of virtual worlds / 3D web to emerge? Here’s a fact: there’s plenty of wonderful game engines and MMO platforms that have one thing in common: they are all proprietary. Not only that, but they aim at being the only game in town, all 20 of them. Some of them are very successful in their own businesses, but none of them will become the common infrastructure for interoperable virtual worlds. Infrastructures must be owned by everyone and no one in particular.

Enter OpenSim. At this point, OpenSim is one of only two open source virtual world platforms with which one could imagine developing that much needed infrastructure for immersive interconnected virtual worlds to bloom. (The other one is OpenCobalt, a Smalltalk platform; Sun’s Wonderland has just been discontinued by Oracle, and its future is unclear) OpenSim has been created from day 1 with the goal of becoming the Apache server for virtual worlds. It’s still young, so there’s still a few things to do in order to accomplish that goal. Please let us finish! Don’t start creating obstacles by filing patents that are infrastructural in nature. Those patents will be a nuisance, and ultimately useless for your business because one of two things will happen: either (1) what you patent is so important that it will be critically missing from the common infrastructure because of your patent, therefore the infrastructure will never happen; or (2) what you patent can be done in a different way, in which case that other way will make it to the common infrastructure, and your patent-based business will miss the point.

I know that investors, before they invest, and managers in large companies, want to know where your own beef is when you’re dealing with an open source platform. In the US, “beef” usually means protected Intellectual Property in the form of patents.  Some large companies are particularly aggressive when it comes to filing patents on absolutely everything for which a patent hasn’t been filed yet, no matter where the idea came from, and no matter the merits of the claims; in those companies, employee compensation is, in large part,  based on the number of patents filed, so the employees quickly learn how to play the patent game (this practice is an aberration, and one of the reasons why I decided to take a job in Academia). I don’t have a simple solution for this need to patent, but just this general advice: patent OpenSim-related infrastructure at your own peril. For starters, you won’t gain any friends among some of us core developers (me, at least). You’re putting the whole effort in jeopardy. I will use every resource I have available in the UC in order to shoot your merit-less patent applications down. Second, I can guarantee you that if something you patent is with merit but critical, I won’t stop until I find another way of doing it that doesn’t step over your patent.

What else can you do to make your investors/managers happy? Here are some options:

a) Code faster. Be the first to have the implementation of something important, then you can try to grab the market before the open source solution comes around. But no patents, please — see above.

b) Create interesting, engaging services. If people like what you provide, they will come.

c)  If you really must, patent methods for doing something faster/cheaper/better. Optimizations of published processes are always desired by potential customers.

d)  Again if you really must, patent specific applications of the infrastructure that focus on the vertical that you are trying to make a business on.

Needless to say that this post is my own view of things and in no way reflects any official position of the OpenSim core developers.

The OpenSim Library has been a neglected part of OpenSim since I can remember. Apart from a few animations and example scripts, there hasn’t been anything interesting there. Even though it was possible to add things to it, the process was so cumbersome and error-prone that no one cared to do it. So the Library stagnated. That stagnation has finally come to an end.

As of today, it is now possible to add any arbitrary elements to the OpenSim  Library simply by using IARs. I’m going to explain it below. For starters, the latest release of the Diva Distro already has some new freebie content in the Library (see picture above — zoom in). I added three outfits, 2 female and 1 male, that you can use to replace the horrible Ruth avatar; and I added a very small collection of objects. They are available to everyone with the latest diva distro, diva-r11766. (Remember that to use the content in the OpenSim Library you first must copy it to your own inventory, and then wear it or rez it.)

I have a larger object collection available from the github site. I didn’t include this in the distribution, because it’s quite large, larger than the distribution file itself. You can download it and place it under bin/Library if you want.

You can add more IARs to your Library, so that the content of your choice can be made available to all your users. The process is very simple: produce or get one or more IARs with your favorite content, and place them under bin/Library — that’s all. The content of those IARs will be added to the OpenSim Library automagically.

A few details. In general, IAR content is placed at the top level of the Library. If, however, if you are careful with the name of the IAR files, you may be able to control their placement better. For example, if you want to add things under, say Clothing Library, name your IAR something like “Clothing Library part1.iar”. When the first 2 words of your IAR file name match one of the existing subfolders of the Library, the content will be placed under the match. Content always adds up, so you can have several IARs, and they will all be loaded.

One important limitation: this only works for standalones, for the time being — which is what the diva distro is all about anyway. It will be nice to make this work for grids, but that will require substantial changes in the way IARs are coded.

Enjoy!

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.

Today, while we were doing load tests in Wright Plaza, I was also doing another kind of load test on my standalone. This one relates to server-side bots. I was able to have a 3×3 megaregion with ~2,000 prims, 200 bots and my client connected to it!

My client was quite happy. The only thing that didn’t seem to be working was the walking animation. Apart from that, I was able to walk, fly, chat and generally interact without much lag. Pushing it to 300 didn’t quite work well yet, I was stuck in 10, 10, 10 on login.

Mind you, server-side bots are a very light load on the server, much lighter than a regular client and lighter than a libomv bot. For starters, they don’t connect over the network, so there is no packet sending/receiving. Then, these particular bots I’m developing aren’t that smart yet, so they don’t request any assets from the server — their load is essentially the physics that comes with them and all the updates that are sent to regular clients as the bots move around.

I have been playing with server-side bots lately because I am involved in projects that require them for simulations. I will have to have at least 500 of these. We’re very close… I’m quite happy with the results today!

Goggle has announced its 3D Building maker for Google Earth. It looks really nice and simple. I think Google is getting that most people aren’t expert 3D modelers, and as such, simple tools that produce simple models will go a long way in modeling the entire planet.

Google’s intention is great at face value. However, I can’t help but wonder what will Google do with all that content produced by thousands of people around the world. If Goggle ever monetizes Google Earth, will it give back to the creators of those buildings? Or, like what Google does on the Web, will it take the content and run its own business without paying back to content producers?

We hit a milestone today in OpenSim. We piled up 52 avatars in OSGrid’s Wright Plaza sim, under 600M of RAM, and after an uptime of 10 hours. It eventually crashed, probably due to a lurking ultra-conservative lock somewhere in code. But hey! — this is fantastic news for OpenSim-based worlds. I can see 1.0 on the horizon.

Over the last few days, one of the key components of OpenSim, the code that deals with packets from/to the clients, has been replaced  with a new packet handler written by Intel’s John Hurliman. This is proving to be a Good Thing. Also last week we have identified and eliminated a major memory leak that was making OpenSim eventually run out of memory.

Hopefully when we get to 1.0 we will be able to consistently support 50+ avatars simultaneously under 500M of RAM and without crashing.

There is a new diva distribution available. It is packaged out of the bleeding edge OpenSim, revision 11056. If you have the previous release installed, you can simply run Update.exe.

In the past 2 weeks there has been a lot of plumbing in OpenSim, and things have improved considerably. First and foremost, we have identified and eliminated a memory leak that was causing OpenSim to use all memory over time, and eventually crash. Now OpenSim runs on much more reasonable memory footprint, and stays within that limit [for much longer].

Second, we have rewritten the grid service from scratch. The grid service is the part of OpenSim that manages region registration and lookup. All OpenSim installations have a grid service, even if they are standalones. In fact this distinction between standalone and “grid mode” is becoming fuzzier and fuzzier. So much so that it is now possible to have grids by stitching together standalone installations of OpenSim — without having to run any other servers!

Here are the instructions for how to do it with the diva distro. Instructions on how to do it with stock OpenSim can be found elsewhere.

Instructions for setting up a serverless grid with the Diva distro:

1 - If you want the second instance on the same machine, copy the entire folder of your diva distro into another folder on that machine. If you want the second instance on another machine, copy it to that other machine. Leave the original unchanged. In the copy (or copies), do the following steps.

2 - Edit Regions/RegionConfig.ini, and change the following fields for each region: (a) the name; (b) the RegionUUID; (c) the Location; and eventually (d) the InternalPort. For example, in my case my first region in my original instance is:

[Diva’s World 1]
RegionUUID = “9ca5b0b5-0b1e-47b7-ac30-7e0230152de0″
Location = “6178,3371″
InternalPort = 9000

In the copy on the same machine I have:

[Diva’s World 5]
RegionUUID = “854a1e57-95f2-42f9-b3c7-2488e0e0bd92″
Location = “6176,3371″
InternalPort = 9004

A couple of important notes:
* Please use truly random UUIDs. Here is a site that generates them for you: http://www.guidgenerator.com/.
* In my case I wanted to place the new 2×2 megaregion to the West of my original megaregion. Hence the coordinates 6176,3371 on the first region of the copy — the X coordinate is 2 to the left, the Y coordinate is the same.
* Megaregions need to be specified like what they are in that file: the first region is the SW corner, the second is the NW corner, the third is the SE corner and the fourth is the NE corner. Make sure you preserve this order when you make the changes in their coordinates.
* The InternalPorts must be unique for each region, on each machine. In my case, my second instance is on the same machine, so I had to change it. If your second instance in on another machine you can use the same InternalPort numbers of the original megaregion.

Do the necessary changes for the other three regions on that file.

3 - Edit config-include/MyWorld.ini. The only thing you need to change here, if at all, is in the [Network] section, the http_listener_port. If your second instance is on the same machine, you must change this port — for example 9001; this port needs to be unique per instance, per machine. If your second instance is on another machine, you can leave it as is. In any case, leave the server urls as they are for the original instance.

Et voila!

Login as usual. You will notice that the SW corner of your original instance now has neighbours to the left. In principle, you can cross back and forth, and teleport between regions as normal. In practice, crossing between instances with megaregions is still under heavy work and may produce surprising behaviour. For example, crossing from the original SW corner to the copy SE corner may end up being an auto-teleport, or you may get stuck in limbo, etc. Don’t be alarmed, this is “normal” behaviour for the time being, and these quirks will be fixed in future releases. For the time being,whenever you want to switch instances I recommend teleporting between SW corners of the different instances — that works pretty reliably.