Welcome to UOX3!  As "unofficial" as it gets!

********  DISCLAIMER ********

If you are looking for the "official" UOX3 web site, we believe it to be here.  If you are looking to run a shard immediately, then you probably want to go to one of these locations: RunUO, Wolfpack, or Lonewolf.  Many more options for emu's can be found at Smithy's Anvil.


Still with us?  Ok, so what is this place then.  It is a small hobby/project to rewrite UOX3.  "Unofficial" as we are NOT part of of the "official" or "formal" UOX3 development team.  However, back in UOX3 infancy, many programmers routinely released their "version" of  UOX3. Then another developer would pick up that, merge what they liked, and release their version.  We are reverting back to UOX3 roots, and adopting that model.

 Basically, we feel that UOX3 is in need of an overhaul.  Plus, we thought it might even be fun to do.  There are plenty of emu's out there, most far "ahead" of UOX3 in terms of stability, flexibility, and or features.  So, why not have some fun doing a rewrite.  We have a few guiding principles as we accomplish this rewrite:


We have toyed on and off with emu's for the last few years.  Basically, a common theme on the open source emus, is to take a rather old code base of UOX3, and start modifying it.  Over time, this creates a rather distinct code base, and the project becomes a distinct emu in its own right.  However, what if you don't like the core code base to start with?  Those that have chosen to start from a clean slate have decided to not open their source. Thus, one has nothing they can leverage off from.

A few years ago UOX3 went into a "big build" phase, that took almost two years to complete.  During this time, we thought a new, cleaner base would emerge, as well as new features.  It was quite ambitious, and raised expectations to a new high.  Also during this time, the development source was not viewable to anyone not on the "official" team.  When the "big build" was released, it did indeed have many new features.  It also had not started with a clean base, but fused many of the new features to the existing UOX3 core. From this projects perspective, the release was less then expectations (probably an impossible goal given how high they had been raised), and brought with it the legacy issues as well as a new set of problems.  It now faces the delimina of having to face more changes, after a two year period of change.  In addition, with lack of insight into the development code, it is not clear it benefited from feedback from users, other coders, etc.

We also noted the Lonewolf project. They are taking quite an evolutionary approach.  Where the project evolves to new features. With this approach, they have achieved a very stable emu.  However, the code base reflects this approach, with adaptors to handle the merging of new approaches with old implementations.  A challenge in its own right, that the Lonewolf team had done an admirable job with.  But not something that has our interest.

So, with these as our background, we decided to have our own "big build".  Hopefully, to learn from others, and have some fun.  Our expectations are pretty humble, to get back to the same level of features as the current state of UOX3.  And we realize that by the time we get there, we will be totally eclipsed by all other projects.  But if we have some fun doing it, then we are still ahead.  And who knows, we may not be that far behind!

Now lets get address the question most often asked:  "Why not be part of the official team?".  The answer is rather complicated, but we will take a shot at the answer.  Basically, we have fundamental differences in our approaches with the "official" team. We saw how they ran their big build, and here is where we differ:

  1. Few major features will be added until a new code base is established using the principles mentioned above.

  2. Development code will be available to anyone during the process. 

There are also many minor reasons that make the two projects incompatible:

  1. We are essentially using the "scp" syntax, as we see no advantage to the "dfn" syntax. A change that the "official" team just went to.

  2. We are starting from scratch, essentially stating it is ok if the current code is not used.

  3. We are using a different complier. 

Those "minor" reasons are pretty substantial differences between the projects.  It would be unfair to ask the "official" team to accept those changes, we probably wouldn't.  Oh, and the last reason, we don't even know if we could join!  It would be presumptuous to assume anyone can be part of any team. However, our code base is always available, so one can always benefit from it if desired.