With this belief, we started on the arduous process of making sure that, while making the Mote project a reality, we do not break the chain of backward compatibility. Most developers would consider this wearing the proverbial ball and chain, even before any work was started. Even the last crop of developers that handled the official MapTool project was bent on dropping it in favor of writing their 1.4/2.0 (or whatever version stamp they eventually settle on), something that they've stood by for years while informally designing their next VTT. It was at this state that we picked up MapTool, to make it into Mote, and we considered early on that building around the 1.3 source, and ensuring backward compatibility was vital to the project's future.
One of the most important tasks to ensuring a smooth transition from MapTool to Mote, and eventually Mote-X, is the conversion, and translation process for all the inherited MapTool models. All of these models will need a modern counterpart, only preserving useful information, when necessary.
This a big reason why we have not added to existing models, such as the ones defining what campaigns, and tokens, are. We guess that, when these were initially designed, the bias leaned toward portability, and the ability to take components out from the top-level Campaign, and export them out as standalone components of their own e.g. macros, sets, maps etc. That still makes a lot of sense now, but some aspects will not stand under the demands of a modern application.
One good example is the library token. We think that this took the token concept a bit too far, though it may have been for the convenience of riding the propagation mechanism by which tokens make it into other clients. For starters, since it is a token, it has to be placed on map to associate with a campaign. Since it is on the map, it has to be drawn when its map is active. It has to be named a special way i.e. lib:something, in order to delineate it from other tokens, and if you're writing code for tokens in the MT source, you have to be mindful to check for this special naming at all times.
This tight coupling is common to current MapTool models. A glaring disadvantage is a token always gets propagated to everyone, each time a change, big or small, gets made. So, if you increment property X by 1, in a library token of not-so-trivial size, the library token needs to be sent to everyone anew. In a small scale, private network of connected friends, this is not such a big deal. When planning a large scale service, these irrelevant bytes add up, and quickly.
Some of the steps to solve this problem were implemented in Mote. This contributed some of the bugs that get reported in, but it will benefit everyone in the long run. The more radical aspects of the change, however, have been withheld in favor of doing them in Mote-X. Doing it in Mote will contribute far too much complexity that we are inclined to handle.
In Mote-X, libraries will be Libraries, backed by the more conventional methods of updating stored information across interested clients. They will not be associated with a framework by putting them on a map, but will follow our conventions of association that govern all framework-related resources. They will referenced by a primary ID, unique to itself, which is then referenced by a human friendly secondary ID, that is enforced to be unique within the framework, as well. MapTool had these in it's system, and when they were used, it brought all the obvious conveniences. But it is obvious to anyone who checked out its source, that authorship was manifold, since some parts followed a standard, while other parts circumvented standard, to make it easier for that particular dev.
The token will have its own counterpart in Mote-X. In all respects, tokens will cease to exist on the conceptual aspect, as well as in name, under the Mote-X system. Of all the models, this was the most deconstructed one.
To be continued...
(up next): UI, UX, and the user work flow in Mote-X).