One of the impulses for initially building RTools was that I had a bit of a breakthrough; I knew pretty well how Reporter v3 handled it’s tournament files from some past work, and I knew _where_ v4 was storing information, but I didn’t know _how_ it was. The file in question ended with “.dat”, and gave no hints in a text editor as to how to decode it.

Then, one day I randomly looked in that folder during a tournament, and saw the key to answering that. Actually, it was the lock, as there was an additional file in that folder with the same name as the storage file, but with “.ldb” as the extension. Immediately, I was able to get into the file and figure out how to get info from it, as “.ldb” stands for “database lock” and is used solely in relation to Microsoft Access databases. (which normally have “.mdb” as an extension rather than “.dat”, which somewhat implies either encrypted or binary data)

So, enough with that, here’s how DCI Reporter stores your information.

DCI Reporter v3

v3 (and v2/v1, though the format is different) stores all tournament information in datasets called flat files. These are simple text files with information stored like an Excel spreadsheet, separating the columns by either a tab character or a comma. When you have a tournament in v3, it gives you a 4-letter code for each tournament; this is the prefix that all data files use. In the folder where these files are stored, there will be several for each tournament. The ones you will usually see are:

301.dat – Tournament information
302.dat – Player information
303.dat – Round & Match information
305.dat – Condensed version of 303.dat (though this gives the match points for a round and 303 doesn’t)
308.dat – Pod information (note – this info is also stored in 302.dat)
320.dat – Event log

DCI Reporter v4

v4 is a work from the ground-up in more ways than the UI; the entire structure of how it stores tournament information is reworked, now taking the form of a Microsoft Access-formatted database stored way in the back of your computer at:

C:/Documents and Settings/[username]/Application Data/Wizards of the Coast/Event Reporter/TournamentData.dat (Windows 2000, Windows XP)
C:/Users/[username]/AppData/Roaming/Wizards of the Coast/Event Reporter/TournamentData.dat (Windows Vista, Windows 7)

The database itself is pretty straightforward from an architectural perspective, and pretty much follows the style that v3 had, though taking advantage of many of the cool things dedicated databases can do for both space saving and enabling the UI to be much simpler. The one interesting note is that every tournament is a team tournament in the database architecture; if it’s 1v1, the team size is simply one; however, if it’s 2HG, almost nothing needs changing from the database perspective. (and, nothing really changes currently in the UI as well, as multiplayer events are currently handled in all aspects as team vs. team, and never player vs. player)

What’s Not in the Databases…

The major thing is that tiebreakers are always programmatically generated by DCI Reporter, so any standings RTools produces must also be generated. It’s also an issue with v3 that there can be several areas holding the same piece of information, which has caused issues in RTools for handling things such as pod seating and drops, where initially the location I chose for accessing that information turned out to be the incorrect one.

Backing up your Databases…

v3 is easy; you just copy the files where you want them backed up to. v4 is the same method, though the file can be quite large with a bunch of tournaments in it. RTools v.1.1 will have a simple backup/restore tool for v4 databases, just so you won’t need to go in through hidden folders and copy that one file over.

“Seat All” is pretty much the most boring and mostly useless scrolling system good for just a couple specific occasions. (though, to be fair, a lot of the cool things this does fit that bill) For me, personally, this is the button I have pressed the least in a tournament, only using it on occasion to scroll who’s entered into the tournament, to make a last-call (and sanity check) for people to make sure they’re in the tournament.

But, with 1.1 there are a couple new things being added and moved around to make this button a bit more useful. Specifically, when you click on it with 1.1, you get a dropdown menu with different options:

“Alphabetical” – the current 1.0 “Seat All” button.
“Order-of-Entry” – in the order that the names were entered into the system.
“Random” – self-explanatory. (literally, Java has this cool easy way to sort lists by just telling it how to compare two items in the list; this sort returns a random number in that comparison)

In addition, if you are in a draft tournament, two more options show up:

“Draft – Pod Seating” – The current 1.0 “Pod Seating” button.
“Draft – Build Seating” – A seating where players in the same pod are seated away from each other. Essentially, it sorts players so that all the players in seat 1 are together, and goes up from there.

So, with this, the “Pod Seating” button is no longer needed and will be removed from the UI; the “Seat All” button is also renamed “Seating”. Note that if you work with the settings.ini file, any settings that you made with “Seat All” will need to be redone. This button, combined with the Pod Seating, will still use the same settings.ini variables.

I may also work on making these printable. There will probably also be some additional things added here before full release.

This is from the first build of the Personal Information Center, and only has the player’s Rank, Points, Tiebreakers, and round info. We’ll see how much more tournament info I could possibly add to this; there’s a lot of things I could theoretically add easily, though the amount of usefulness is what needs to be weighed. (note – as part of the system, to get to this screen, you’d need to select the tournament that you are in, so that’s why there’s no information what this tournament is on this screen)

The one thing to say on here is that it would not be trivial to add a round clock to this screen. RTools itself was built as a very modular program, which is very useful for working on individual components, but doesn’t work very well for a situation like this. In essence, when you click a button that spawns a window, the main program sets up all the information needed into a little package and dumps it into that new window, and there’s no links back between the main window and that newly-produced window.

Now, the current settings system gets around this, so it isn’t necessarily impossible to do, but then there’s a larger issue: if I have 3 timers running for 3 events, how do I link one timer to one event? Again, there’s something in the program that looks like it does something along these lines. (the “Tournament-Specific Colors” feature) The issue is that the feature essentially rides on the settings system’s links, which only makes updates in the program when those spawned windows open and close.

So, in terms of how the program is built currently, there is are two issues: there is no current way to push updates on minor updates, (i.e. resetting the timer, stopping the timer) and there isn’t a method to link tournaments to individual timers.

Now, this isn’t saying that this can’t happen. There’s some really cool UI and network things that I’m interested in trying that would involve building a messaging system and essentially turning those individual spawned windows into clients, with the main program being the server. Cool things like remote utility invocation: be on one computer, and launch a pairings window on another computer across the room. Not something that’s very usable in most situations, but both just something cool and a chance to learn the intricacies of such a system. Plus, things like pushing round clocks can just ride on this kind of system 🙂

RTools 1.1 is the first major feature update to RTools after full release, and it’s main feature addition is a connection system to a web interface. Once the program is connected, players in the tournament can utilize the web interface to access their player information for the tournament, including their rank, match history, tiebreakers, and have an additional location to find their round and pairing information.

As of June 21st, this system is functioning in personal testing via a personally-built WAMP server, and most of the work right now is just getting all sorts of cool data transferred over to be player-accessible, along with increasing the efficiency. (a 250-player tournament in round 8 requires around 2000 database calls and 3-4 minutes to upload all the needed information currently, I want to get this down to no more than 30 seconds)

The other issue is in finding a way to allow a single source for RTools to upload their information. The issue I’m trying to tackle is finding a free (or very cheap) place to store the web area and related databases. My current site runs everything I would need for this to work, but unfortunately doesn’t allow for RTools to connect into their server, instead only allowing for the connections to be made from within the server itself. So, if anyone knows of a place that I can use to make this possible, it would be great for more than just me 🙂

Depending on how successful I advance in making the system work efficiently and without hassle, beta versions may have this functionality available beginning the second week of July. Current alpha builds have the options visible, but those options will not do anything.

Note: If I can’t get a place running by early August, the web interface will be available as a download with RTools, along with the needed systems to build a database for the info, instructions on setting up a WAMP server on your local machine (it’s not hard at all), and making it easy for people to get to the computer to access their info.

RTools 1.1 has a planned release date within the second week of August.

RTools can -technically- handle multiplayer events in a strict sense – the program doesn’t crash, and it displays correct information. The information, however, may not be exactly what you want. So, this is just an FYI on the behavior of the program as of right now, v.1.0.0.

DCI Reporter v3
Luckily, the files that RTools accesses are pretty good for translating 1vs1 to multiplayer events. Pairings show up with each player being placed at their own table number, and their opponents have the same table numbers. So, a team of three players would have a player at table 4, 5, and 6, for example; the opponents would have the same table numbers between their three players.

Note that the “Seat All” currently seats by placing players on a team more or less across from each other. So, a team of three would have two players at one table, then the third player either a table above or below. If you want teams all on one side of the table, just run pairings in the tournament, use the scrolling pairings (ignoring the opponent column) and then just re-pair that round when you do the actual pairings.

Wizards Event Reporter
Unlike v3, WER handles it’s back-end files in a way where they end up being displayed in a very different way: by team wholly instead of by player. So, a pairing and seating will see two teams playing against each other, and the entire team will be at one table. On the scrolling screens, (and on printed pairings via WER, FYI) the pairings will be scrolling by team, defaulting on WER as showing “[Lastname] – [Lastname] – [Lastname]”, a very wide name especially for scrolling pairings.

Be prepared to make size adjustments here so all the pairings aren’t automatically sized and in all sorts of different sizes. Also, it will probably help immensely to slow down the speed (especially in the first round) so that people can find their names correctly and get their pairing right; besides, if you’re doing 2HG or 3-man, you have the added benefit of fitting 2x the number of players on a single line, so it scrolling at 2/3 the speed is still going through all the players faster than if it was a normal non-multiplayer event.

General Changes:
– Release Version
– RTools >> RTools Lite, RTools+ >> RTools
– “Tournament-Based Colors” added.

Timer Changes:
– When the timer is at 0:00 or displaying negative time, the display will show both red and the chosen color.
– Ability added to display the timer’s title as larger text within the window in addition to displaying in the title.

Bug Fixes:
– (v4) Pairings that involve multiple byes now display correctly.
– (v3) Pod Seating gives seat numbers consistent with what v3 displays. Previous versions displayed the seating in the order the players were listed physically in v3’s Pod Management, not looking at the seat number column.
– (v3) Pairings no longer display pre-registered (but not enrolled) players as having a bye.

 —

Version 1.0.0 adds a couple features which are for events with several tournaments. The main addition is “Tournament-Based Colors”, which modifies how some code interacts in order to individualize individual tournaments as part of an event.

When the option is selected (from the Settings menu), settings for windows are now linked to the name of the tournament, with emphasis in maintaining the color options between windows of an individual tournament. In short, if you change what tournament you are in, the default color will change. If you go back to the first event, you’ll get back the color settings for that event.

Default colors are as follows:
White (FFFFFF)
Grey (888888)
Blue (3333FF)
Light Blue (99FFFF)
Aqua (009999)
Light Aqua (66FFFF)
Green (009900)
Light Green (66FF66)
Purple (990099)
Pink (FF00FF)
Yellow (FF0000)
Orange (FFA500)
Peach (FFAA66)
Brown (885522)

There is also an option added in the Timer to display the name of the title in the window itself, larger and easier for players to read. (and, thereby, link their tournament to a color) With the “Tournament-Based Colors” selected, the timer’s title defaults to the tournament name.

If you’ve been to a major tournament in the upper midwest, you’ve probably seen a projector used for event information. You may have received your pairings from the projector, or had your round clock on it. RTools provides that functionality, but also much more.

In the abstract, RTools is a set of tools designed to make the running of a tournament easier and with less paper. It has features useful to local stores, all the way to running world-level events. It has time-saving functions that are useful for 8-man tournaments, as well as 800-man events.

For events at the store level, you have many useful features to save paper, save time, and make the tournaments you run be able to run more smoothly.
– RTools comes with a purpose-built round timer with audio notification on reaching the end of time, so you can be notified as to the end of the round even if you are doing other things at the time.
– Instead of printing out match result slips, print out a condensed sheet of match results, allowing you to have 32 matches printed on one sheet, rather than eight. If you don’t normally use slips and just take results verbally, RTools will give you a very low-cost way to have paper-based results, which are most useful in clearing up result disputes and maintaining records.
– If you have a second monitor (or a TV that can act as a second monitor, or a projector), you can use it as a route for displaying your event pairings every round, without the need to either verbally announce pairings or post paper pairings every round, saving both time and paper. You can also use this to have a constant location displaying a round timer, as well as event announcements. Just place the secondary display near the computer you are using, and you have your source for displaying all the information RTools can provide.
– Run tournaments through both DCI Reporter v3, and Wizards Event Reporter.

For events run at the level of a Premier Tournament Organizer, there are additional features within the program which make these events much simpler. Many of these features assume that you have some sort of secondary monitor available, and is especially useful in situations where you would have a projector as that monitor.
– RTools’ timer has the ability to continue counting after reaching the end of time in the round, while still acting as if the time has expired in the round. This is especially useful when you need to keep track of time extensions, as the timer will show precisely the amount of time since the round had ended, ending the need for keeping track individually between judges.
– Beyond the ability to scroll pairings, the program also has the ability to do an alphabetical “Seat All Players”, scroll pod seatings, and also display/print standings, including by-pod.
– As a round ends, you may want to pass on to your judges the tables that have not given a result slip to the scorekeeper. Both the scrolling pairings and ticker have the ability to display their info in a specialized way to pass this information on. When enabled, pairings will only show the pairings of players that have not turned in their match result, and the ticker screen will default to a listing of tables that have no result entered.
– When running several tournaments at the same time, events can be customized to use different colors for different events. The colors can be setup such that a tournament’s timer and pairings-based windows default to tournament-unique colors, linking tournaments to colors for the players. This can also be further linked by using functionality in the timer to display it’s window title in a larger form in the window itself, displaying the tournament name and round.

If there’s some idea that you have to make the program even better, or some functionality that would make your life easier when running a tournament, or if you’re a judge and you have some way to speed up your tournament life, let me know! It may be trivial to add such functionality into this program, and get you going to a faster, easier tournament scene.