January 6, 2003

Progress is being made on getting rid of the char* in favor of UString continues.  Probably about 1/4 or so way there (perhaps a tad less).  We will refrain from updating CVS until is complete (for those of you who want a compliable version to work on).  Now, one thing is clear as we do this.  The code base is not substantially better, from a maintenance  perspective, then it was two years ago.  I am sure to those who did it, it is, but that could have been said about the original base as well.  This is all spilt milk, and in truth, if it wasn't in such shape, we wouldn't have a reason to exist!  So, there is a silver lining to everything.  Now, assuming we can get the char/string conversion complete, we need to begin to plan on the "true" code updates we want to do.

First, we believe we should get the user data interfaces defined.  We find the current "DFN" system somewhat lacking.  It does not meet our goals of standardization, nor is the data self contained.  What we mean by that, is a standard "syntax/approach" to writing data, and the data within any file should be self describing.  The DFN system is dependent on location to aid in describing what the "type" of data is (npc, item, etc).   If on transfers the file for editing, sharing, working with tools, there is no way for the recipitant to easily obtain what the data is.  Secondly, we desire a syntax that can easily describe the data content and type in a consistent manner for all our data files (Note the current UOX3 ini file does not contain { }, but the dfn's do.  In some files, the section header is [id], while other times is [ITEM id].).  So, we believe a common approach,  that will also ease migration of existing parsers, is to go back to the SECTION TYPE ID {  } syntax.  This meets our needs (however, we plan to have other "keys" then SECTION, as will be explained later).  We can live with the current "tags" that UOX3 has, and keep the "=" for the separator (with the "," separating multiple values). We plan to enforce this syntax for all text data.  For those of you who have all ready adopted the DFN system (what, all three users *smile*), this is easy to convert.  Basically we will be changing the first line of each section from [id] to SECTION TYPE ID . So a translator that can key off the directory for the type, should be fairly trivial to make.

Along the same lines of consistency, the data within a section will be TAG = VALUE.  The tags will be uppercase.  By there will always be tags!  Thus, some of the old loot or color lists (and in the DFN system, there are instances of no tags)  looked like :

Will look more like :

We solicit feedback. We know many don't like using the Sourceforge message boards, so leave us a post on www.uox3.org message boards concerning this topic!  Things like: Should the "=" be used, or should we revert back even farther the space ?  We want to hear your thoughts.

Now, for world saves.  Again, the same data syntax.  However, we are proposing changing the "region" files the current version of UOX3 uses, to something we believe to be a tad easier for users to understand and use.  We are proposing to adopt a single file for each of the following: items, npcs, multi's, characters.  Now, to minimize save time, we plan to use a "diff" approach. The server will write a complete version of each of those files on startup. During file saves, it will write "diffs" of each of them.  This is where, instead of SECTION,  you will see one of the following: EDIT, ADD, DELETE.  After that, it will follow the TYPE ID { } syntax. Thus, during the saves, we will only have to write what has changed. We belive this is what the current UOX3 was attempting to factor.  We believe the approach we are proposing , is a reasonable blend for shard users, tool developers, and general server use.  Again, feedback is appreciated!

If we can finalize on this, we will start documenting/publicizing the "tags" and the different TYPES, so people can start doing the data files as we work on migrating/fixing the code to a usable form.

January 5, 2003

We decided if we where going to patch the UOX3 JS source base, we ought to at least get it useable.  We have no idea how one can develop with all the warnings. Trying to find what warnings you might have caused is just about impossible. Our hats off to those who struggle with it.  We went ahead and did the tedious job of casting (for now) the items that where causing the warnings.  In addition, we also made UOX3 namespace clean.  All that is in our CVS, same module as our code. But you will see a directory now, uox3js.  We still don't think it is ready for any serious updates yet.  What we are currently doing is taking all C string processing out, and using our string class instead.  Hopefully we can get the code a tad easier to maintain, and might even address a memory leak or bug along the way.  After we have completed that, we are probably at the point, where we can integrate our section code.

January 3, 2003

Our first "unofficial" patch!  We will try not to make a habit of it, as looking through the code, it is clear we will want to do some reshuffling of the objects/methods/properties exposed to the user for JS.  However, for those that are using it, one probably would like to be able to get some data back from that nifty gump you created.  So, we decided to make a few code mods so one could!  This patch changes the onGumpPress event a tad.  Get it at our project file release page

January 1, 2003

So brings in a new year, and with it hopefully new opportunities.  We have the section parsing code, and our console pattern complete.  In addition, we have ZThread, Netxx, and Datetime all working under mingw.  Not a bad start.  One of the questions we where asked, if we would consider merging what we have with the current "official" UOX3 base. Well, that really isn't our approach.  There is some advantage, it would uncover any lurking bugs in the code modules we have completed. And it would give a head start on any users (Surely no one is that crazy!) who want to start working on data sets.  But it is a tremendous undertaking, as where would we stop?  Should we port it over to ZThread? Mingw?  Things we will have to consider and think about before the final decision is made on this.