Source: http://habrahabr.ru/company/wargaming/blog/231065/

Continuing from part 1. Before we go on however, there is something I would like to add to this entire story. Last night, I was contacted by Edrard (you know, the guy from Kiev, who, amongst other things, takes care of FTR tech side). He told me that the XVM story, as written by iBat, is not complete, because iBat, either intentionally or simply by forgetting, did not mention Edrard’s role in XVM creation.

The Noobmeter mod was originally an European mod, created for EU server. The mod was converted into Russian only after it appeared on EU forums and the person who converted it was Edrard personally, along with some other guy. This other guy was the person who actually invented the Russian name for it (Olenemer) and it was Edrard, who programmed the first server part for the Noobmeter mod on Russian side. Edrard also invented the original efficiency rating and was also involved in further development of these mods.

Either way, back to the story.

Assembling the XVM team

As the number of players using the noobmeter grew, the server (hosted on cheap VPS) became overloaded. The result was this:

About the same time, iBat hired for his own purposes at Hetzner the cheapest “separate” server they had (EQ4: Intel Core i7-920, 8 GB DDR3, 2x 750 GB SATA II HDD). Seeing the trouble the mod was in, he contacted his friend bkon and offered assistance with hosting it. Over next few days, the mod server part was installed successfully, making the mod working relatively well again. Around February-March 2012, a forum for tech support and configuration exchange was estabilished.

A little history first though. The first version of OTM was created by Nicolas Siver. In November 2011, he got fed up with it and stopped developing it – two friends, sirmax and however continued to work on it, releasing the version for patch 0.6.7. They had also the idea to create noobmeter and sirmax is one of the main developers of the XVM client part to this day. iBat joined the team in January 2012, first as a server host, a bit later he bacame a server mod part developer and after that he became a support system developer (for example the statistics activation widget).

In mid-2012, bkon left the developer team, but others joined in turn: Mr13 (CEO and PR), XlebniDizele4ku (client side developer) Mr A (helped with client side development and compiled the release builds), Mixaill (organized the continuous working of the project, interaction between clientside translators) and q4x2 (*nix specialist and serverside developer).

What followed was the issue with RU official forums, from where the mod was practically banned and here’s why. As the mod became popular, so grew not only its user base, but also the abuse of the mod for “unsportsmanlike” activities: insulting players based on their stats (or vice versa, bad players insulting good ones). When that happened, the offended players went to the official forums to complain and demanded a ban for the “offensive” mod. After some time, without any “declaration of war” (contact from developers or WG staff), all the topics on the forum, related to the noobmeter and XVM were deleted and the rules of the forums were amended with a special rule, banning players from “posting links to any mods that show player statistics in the game”. The official reason for this was that these mods cause additional load to Wargaming servers. Any attempt to somehow change this and to de-escalate this conflict was stonewalled by the moderator “I was ordered to do it – I did it” attitude or by community managers unwilling to do anything. The XVM developers proposed various compromises, for example to limit the amount of mod queries to the server, to estabilish a time schedule when the queries would be sent, but nothing happened. After a few months, the XVM devs caved in and did split the XVM into “full” version and “light” version, the light had everything connected to player statistics removed. This caused the “light” version to be allowed again on the forums, the moderators stopped deleting links to XVM light and the influx of new users via the forums started again.

Configuration and Editor

As was written earlier, the XVM and the OTM both had config files. At first, it was in XML format. There were only a few settings and it was enough to change them manually by editing the file. As the number of settings and users grew however, two things became clear:

- XML is not very comfortable for manual changes
- whatever format would be chosen, WYSIWIG editor is needed

The history behind the editors was such: there was never enough time to make them (it’s like this even now), because they always lag behind the latest features in the newest mod version. The very first editor was based on Adobe Air and was made by Nicolas Siver. The XVM team used the very same editor for quite some time, but it became obsolete after a while, because it didn’t have the newest mod settings. iBat tried to make at one point a new editor based on HTML/JS, but nothing came of it. This attempt had one fatal flaw – in order to make it work as WYSIWIG, a large chunk of functions had to be reworked into Action Script and then it had to be kept up to date. The applet variant did not allow taking a part of the code from the main branch and to recieve visually appealing parameters “for free”. The current editor is here.

The next thing to happen was a transfer from XML to JSON. The new config was called xvm.xvmconf. It wasn’t strictly speaking JSON – it allowed comments. Thanks to that, more advanced users could modify the config even without editor by reading the comments. The devs did also not forget the backward compatibility. For once, the client, if the new format config was missing, loaded the old XML config instead (this particular feature was removed not so long ago, as there was more than enough time to get used to the new version). It was also possible to open the old config in the online editor and to save it in the new format.

By Spring 2013, one more thing had to be addressed. With the growth of features from one patch to another, the config became bigger and bigger. It was hard to view, to orient in and it became difficult to find errors such as missing signs and letters. There was an idea to split it into multiple files, but the JSON format, unlike XML, does not allow links between files. The solution was a JSON format extension, called by us JSONx.

There was actually just one change – as a value, it was possible to pick a link to any object in the same or another file. There are two variants of writing it: short and extended

Short:

“name”: ${“file”:”path”}

Extended:

“name”: { “$ref”: { “file”: “<filename>”, “path”: “<path-to-value>” }, [overrides] }

The short format is a special variant of the extended one. The extended format allows you to override the default values. The “file” parameter is also not mandatory – if it isn’t there, current file will be used. The “path” parameter shows the path to the file hierarchy. It’s possible to see it in this example:

Root.xc

{
  "configVersion": "5.1.0",
  "colors": ${"colors.xc":"colors"},
  "colors2": {
    "$ref": { "path": "colors" },
    "ally_dead": "0x009900",
    "enemy_dead": "0x840500"
  }
}

colors.xc

{
  "def": {
    "al": "0x96FF00", // союзник
    "en": "0xF50800" // противник
  },
  "colors": {
    "ally_alive": ${"def.al"},
    "ally_dead": ${"def.al"},
    "enemy_alive": ${"def.en"},
    "enemy_dead": ${"def.en"}
  }
}

Here, you get the following:

- loading of root.xc begins
- “colors” parameter of the root.xc file links to the colors.xc file and defines it as object called “colors”
- parameters in the “colors” section of the colors.xc file link to the “def.al” and “def.en” values of the same file
- parameter “colors2″ of the root.xc file links to the “colors” object, copies its value overrides the “ally_dead” and “enemy_dead” values with others

As a result, you get a valid JSON code, parsed by standard rules.

{
  "configVersion": "5.1.0",
  "colors": {
    "ally_alive": "0x96FF00",
    "ally_dead": "0x96FF00",
    "enemy_alive": "0xF50800",
    "enemy_dead": "0xF50800"
  },
  "colors2": {
    "ally_alive": "0x96FF00",
    "ally_dead": "0x009900",
    "enemy_alive": "0xF50800",
    "enemy_dead": "0x840500"
  }
}

The extension of the config files was changed to “xc” (from “xvm config”) and the config boot file became “xvm.xc”. Separate files and folders with obvious names are responsible for respective UI elements. It allows you to make your own config easily by using various elements you like.