March Updates

RTools has been updated to v.3.3.60. It now supports exporting WER tournaments to PlayerLink, and also has new menu options to directly access PlayerLink tools.

PlayerLink has been updated to v.1.2.2, and brings with it a new internal structure, better customization, and a more customizable, better EventLink.

January Updates

Today, we’re just focusing on PlayerLink 1.2, as that’s where most of the development has been recently.

First off, I was calling the Albuquerque and DFW builds initially as v.1.2, but those were released as a v.1.1.1, as I focused on getting 1.1 features in a more stable form before dealing with the broader changes I was looking at. That means that this post, about 1.2, is actually about a new release coming up!

PlayerLink 1.2 should be released in early February; internally, I am at the fourth (and hopefully final) beta.

And, the changelog is large, partially because I’m actually recording everything I’m changing now:

Global:

The website’s internal structure has been rebuilt, in order to better fit many of the functions which have been developed after the original release. Files now are located in logical locations, rather than being spread out amongst the application.

The website’s files have been refactored entirely, taking advantage of better development practices and language functions.

The website now exclusively LESS files, simplifying the skinning of PlayerLink websites. More information on LESS can be found at lesscss.org. This consolidation reduces the total size of skinning files from five to one, and drops the total size by ~50%. The plugin is also updated from v.1.4.1 to v.1.6.1.

JQuery updated from v.1.10.1 to version 2.1.0, and is joined by the jQuery++ library for animations.

JQuery Tablesorter plugin updated from v.2.0.5 to v.2.14.5.

PlayerLink:

PlayerLink individual (personal, pairings, standings) pages use AJAX to respond to user input, reducing overall server load slightly.

PlayerLink pages now automatically skip the “Select Event” page if there is only one tournament uploaded.

PlayerLink pages — except for the main index page — will display the EventLink timer to the player, as long as the timer is running.

The default font has changed to Alegreya Sans, provided via Google Fonts.

When there are VIP tables, the VIP indicator (a “V”) has been moved into it’s own column, to create less clutter in the table number area on table fields.

Pairings and Seatings tables have additional usability features, including a header which remains visible as you scroll down the page, and alternating background colors on table rows.

The page footer will always be on the bottom of the window, irregardless of page height. (a.k.a. you’ll never have whitespace below it)

EventLink:

EventLink has additional modes now, including Clock + Scrolling and Timer + Scrolling.

EventLink scrolling has been rewritten. The new scrolling function should be more responsive, scrolls the same independently of screen resolution, and removes some incompatibilities and issues of the previous implementation. The variables which define the speed of the scrolling is also more easily adjustible.

EventLink admin and judge pages updated with some skinning and UI improvements.

November Updates

RTools 3

RTools 3.2.59 is now available, bringing with it a few bug fixes and functionality changes. The major fix today revolves around PlayerLink functionality – under a specific set of circumstances, a blank upload file would be generated. This version update also removes the Network Timers.

RTools 4 / Event Extensions 1.0

Development here is ongoing slowly, though I’m currently intending on having RT4 being specifically for larger events, like GPs. For this reason, RT4 will be the first version to be updated to support (what I presume to be called) WER Premiere. Initial release support on RT4 will be focused on events like GPs, with RTools 3.2 being supported for non-networking use cases.

PlayerLink

PlayerLink is currently having the majority of work being done on it, thanks to loosened policies and significantly increased usage. PlayerLink 1.2 will debut at two US events: Grand Prix Albuquerque and Grand Prix Dallas-Fort Worth. This update will integrate “PlayerLink Live”, debuted at Grand Prix Oklahoma City, and clean up the codebase significantly. Wait, PlayerLink Live?

PlayerLink Live

PlayerLink Live is a new feature for Event Extensions – instead of using RTools Network Connections to display your pairings in scrolling form from within a Chrome web browser! PlayerLink Live also enables your screens to function simultaneously as dynamic scrolling displays, as well as static event information for the rest of the round.

PlayerLink VIP

PlayerLink VIP is a method by which your VIPs can be seated in their own section of the tournament hall, all transparently and without any scorekeeper interaction! PlayerLink VIP also includes a method by which judges can translate DCI Reporter table numbers into VIP table numbers. (as match slips are the only table number which do not go through PlayerLink)

Event Extensions 4, Alpha 4a

V4 of Event Extensions (formerly Event Extensions – RTools, formerly RTools, formerly probably a couple other things…) is at a point where it could theoretically be used at an event, and I am putting it out specifically for people to try out and tell me what breaks.

The following is just a changelog off of the top of my head. Right now, I’m guess in EE4 has about 35% the same codebase as 3.2, and that value will shrink as I continue relinking the entire codebase together…

– Data models (the parts the connect to outside programs) are partially rewritten, such that they do not unnecessarily read from event files if there have been no changes made.

– Timer has been rewritten, and now positions itself “right” in the window that it is in.

– Pairings module is rewritten. Pairings should run more efficiently with this update. Note that the v4 model of scrolling is to have all information displayed on the same window per machine, irregardless of where it comes from. So, once standings are available, it may be possible to scroll both a player’s pairings and standings together.

– All communications between program and window will be happening through a communications “terminal”, which will handle both local and networked communications identically. So, local events still work identically, but networked events don’t require extra windows anymore.

Known major issues:

– The pairings window does not report it’s open tournaments quite right back to the main window. As a result, you’ll be getting internal IDs for the windows (a long string of numbers) instead of the tournament name for each window.

– The communications system throws communication errors out quite frequently right now. I’m working on figuring out what’s causing that; I think I’m just not handling some of the directional talking correctly. (i.e. a request originating from the main window works, but from the pairings window itself throws something)

– A bunch of stuff isn’t in reconnected yet.

Updates…

Status update: Very early alpha builds of EE4 (which only implemented timers) were used at both Grand Prix San Antonio and Grand Prix Denver, bringing with it favorable testing and some good feedback on some of the interface changes.

I use EE here instead of RTools because they really are two different 4.0 programs. In the last couple days, in fact, I have been moving a large amount of RTools 3.3 and RTools 4.0 code into the EE4 branch. Some of these things I’ve mentioned before:

– New access objects which interface with external databases more effectively. (i.e. “EE talks with external programs better)
– Rewritten, more efficient display interfaces. (i.e. “All the windows can work faster than before)

Right now, 90% of the work I’m doing is plugging all the pieces together. The RTools 4.0 communication code (how the program talks with it’s windows and networked instances) is completely different from the EE communication code, which means a lot of little changes everywhere.

As an additional pain, some of this code is approaching two years since I last updated it, so things like basic program control has become something that I need to relearn occasionally. (for instance, this is the first time I’ve touched the tiebreaker-generating code in over a year)

Just posting…

I’ve really not touched RTools much in the last few months. The main reason is uncertainty; there just isn’t any reason for me to spend significant time on RTools 4. What I do want to touch on, though, is where RTools 4 was last left off in development:

– The database-access systems have been rewritten slightly, and been given some new code which detects for changes in the source files. This was designed to make auto-updating of windows a system-wide default, while still minimizing the potential for read/write conflicts.

– The scrolling engine (where pairings, standings, etc. are displayed) was rewritten. The revised engine uses 1/2 the classes, about 2/3 the total code, and runs about 20-30% more efficiently. If there is one thing I may decide to back-port into RTools 3.x, it would be this.

– The framework for a new networking system was in-place, greatly increasing reliability of the to-be system.

KTS + RTools

I’ve gotten word from more than one source that RTools is no longer working with KTS. KTS is an interesting beast for me, as I cannot readily access new versions of the program. Once I’m able to find a copy of the current version, I can do some looking around to see if I can fix whatever is going wrong.

EE – Network Timer

I’ve received a couple people noting that they still want to use the timer at larger events, and as a result I’m doing some re-jiggling of the timer code and will hopefully release it sometime in November. This will essentially be the timer + networked timers in RTools 3.2.x, with a few differences:

– The timer positioning code finally works right! The code to physically position the clock and labels was always a bit hit-or-miss, due to a whole bunch of programming concepts. (typographic positioning and insets, primarily) Now, everything is placed nicely and resizes nicely.

One downside here – font changing is disabled. This is due to how one figures out the space that a font takes up programmatically. In Java, (and other languages) this is done with a class called FontMetrics; essentially, you can feed this class a font and a context (the rules that govern where the font is being placed) and it can spit out a rectangle containing the full area the font takes up.

Now, the problem is that most fonts won’t use that full space up; if I were to base the window size directly on this, there would be about 20% wasted space on top. So, I have to make adjustments for the specific font such that it fits nicely into the space it says it needs. If I were to use another font, the relationship of space may not hold in the same way, so for now I just need to settle on everyone using the same font.

– The one thing I’m researching now is kind of the same thing that I was researching at the stage RT4 ended in – building a solid, usable networking system. This is something that I want to get right on this redevelopment, so I’m taking some time figuring it all out.

…test, test…

So, something killed my wordpress install, and I wasn’t really able to get time together to fix it in any form until today. So, we’re here for the time being while I get more time to re-skin this new install.

So, what’s changed since [looks]…

…ugh, it’s really been down that long? Oh well…

Name Finagling
One of the things I’ve been doing is starting some additional pieces of code which go beyond just what RTools has been. The decklist tool was an early idea of this, but now I’ve got a few other tools, and may have more coming. (the extension system idea from ~1 yr ago worked well, but I don’t really want to complicate RTools more with extensions. So, here’s the core message of changes:

  • “RTools Event Extensions” (or just “Event Extensions”) is the over-arching name of the project.
  • “EPIC” has been renamed “PlayerLink”. I live near another Epic, and confusion has occurred enough times already; plus, EPIC was more of a “let’s make a cool-sounding name” which just ended up crashing.

New Stuff

  • “Reporter Network Adapter” — RNA enables DCI Reporter v3 tournaments to be run using multiple scorekeepers.
  • “JudgeLink” — A option in PlayerLink, JudgeLink is for events where you only want your staff to be able to access the tournament information which can be uploaded to the web.

Program Updates

  • RTools is now on v.3.2.54. the .53 update was 95% rebranding and updating of some text strings in the program. The .54 update modifies the behavior of the .50 update’s warning dialog, and allows you to bypass the block at your own risk. (not all machines are affected by this bug, which still has not been fixed on the JVM side)

 

RTools 3.2.52

RTools 3.2.52 brings with it a small, but important fix, related to the last part of this article on the GP Austin coverage.

The issue itself: When we began the deck registration period, we started all four clocks together. The way the networking system works, there is occasionally slight delays between each clock starting, but a .5-1 second delay isn’t a big deal, and the total delay here was about 2 seconds between the four clocks. (that just told us that it would be better to use two clocks for the event, which we ended up doing) I noticed, however, that the clock we labelled “4” (the furthest right of the four from where we were observing) was about 5 seconds off the others after a couple minutes. At that point, I got out my iPhone and started another timer to track against this one clock.

It became quickly apparent that the clock was not counting time correctly. The big thing that cleared out almost all non-RTools issues was that the “4” machine was identical to “2” and “3” in hardware and software, and neither of those two were exhibiting this.

How RTools does timers: One value is stored in memory for any given timer. When the clock is stopped, it is the number of milliseconds remaining on the clock; when it is running, it is the UNIX time stamp that is when the clock will hit 0:00. RTools queries the current UNIX time stamp a couple times a second, and displays a quick calculation and conversion of the stored memory and queried time stamp as the remaining time. This code has literally not been touched since it was first built, due to it’s simplicity and robustness.

What caused the issue: As far as I have been able to tell through testing, the issue is with the route I used to get the time from the computer. There are two “big” ways of getting a time representation in Java: System.currentTimeInMillis() and System.nanoTime(). (I had never heard of the latter before this weekend) The former on Windows is a direct call to a simple Windows-maintained location, while the latter is a more complex (and slower) call to hardware-maintained locations. I was calling the former, and apparently Windows can’t be trusted 100% to maintain that number. (though, to be fair, this is the first time this has happened in tens of thousands of hours counted by RTools timers)

What the fix is: I replaced all instances of the former call with the latter call. A little extra conversion code was also added, as the latter call is one million times as sensitive as the former and behaves in a slightly different manner. (we’re talking milliseconds and nanoseconds of precision here – nothing that would affect us for tournament operations)

 

RTools 3.2.50

This update will be available later tonight, and only have a couple small things:

  • If you push web pairings using WER, RTools will throw a visible error message rather than crash. (the underlying bug is in Java itself, and a workaround has not yet been found)
  • A Java Virtual Machine (JVM) flag will be added which will allow the usage of FTP uploads with Java 1.7. (Java 1.7 makes a shift from IPv4 to IPv6 as the preferred way to path network traffic, and in Windows this causes major issues)