Major Bug: RTools (all versions) + WER + EPIC

This is a notice that there is an issue being researched in RTools which, in a particular circumstance, greatly increases the likelihood of Java crashing, taking down RTools with it.

This bug occurs when you launch a pairings window for a WER tournament, while EPIC is enabled.

Please avoid using this combination until a fix is researched and released. (early indications are that this issue may require significant code refactoring)

Thanks to Jeff Vandenberg @ BattleZone Games for discovering this.

Grand Prix Kansas City: Programming Lessons

For the next couple weeks, there will be periodic posts revolving around notes and experiences at Grand Prix Kansas City, where I assisted Rune Horvik in scorekeeping the main event, and Legion Events debuted RTools at the Grand Prix level. Additional posts will be based around scorekeeping notes/stories.

The following are just some of the notes that I made about how RTools was behaving during GPKC, and maybe some future ideas in updates.

:: The process of networking needs a local “Display All Windows” option. To setup the timers specifically, you needed to remotely spawn a timer window, then go to the remote machine and position it. If there was some way to locally spawn these windows, it would simplify things at least somewhat.

:: Static IPs will be a recommendation for any events which use the networking system. Almost every programming-related problem which we had could be solved by assigning static IPs to each remote machine.

:: The weekend was a shining example of “don’t trust the programmer to know the program”. I made about 80% of the mistakes during the entire weekend, mostly including pushing the wrong tournament to screens, but also including a nasty networking bug which kills the networking process on machines the command is pushed to, and is one that I pushed out twice during the weekend.

:: The timers proved themselves as a very strong networking tool, but the interface needs to be made in such a way that they are simple to setup and use.

Looking forward into ideas for a 3.3/4.0 update, I think the primary change will be a modified implementation of my plugins idea which was scrapped from 3.2, and may bring with it a new “advanced” interface. With an advanced interface, I could theoretically get rid of a lot of the random complexity that comes with feature interaction.
– Features like auto-updating windows, EPIC, and networking could be moved to this advanced interface, and there wouldn’t be a need to setup one button to two things, only one of which is expected.
– The advanced interface could take a more language-based model to how it handles things. As a theoretical, you could be filling in drop-down menus to complete this sentence: “From [list of opened tournaments], push [Pairings/Seatings/Timer/etc.] to [screen/printer/EPIC/IP address].” Then, you can either execute that command alone or add it to a list of commands, (like how the networking window is setup with tables) and execute several commands as a group. The one-click model of networking can thus be expanded and be significantly more flexible.

The other thing that is probably more of a priority is that the settings window needs an overhaul. RTools 3.2.43’s entire release set was based around shoehorning the 3.1 settings window into the 3.2 system. (which I forgot to do) The thing is, settings are much more of a  dynamic system in 3.2, and this can (and should) be much more effectively done. (as in, a drop-down of all possible settings values, and an area to make changes to those settings)

RTools 3.2.43

  • Fixed an issue where the “Event Settings…” window would not close.
  • Fixed an issue where the “Event Settings…” window did not propagate changes to tournaments.
  • Added an option in the “Event Settings…” window to push a tournament’s settings to the settings.ini file.
  • Added a settings.ini property (SettingsPersistent) to prevent RTools from overwriting any settings.
  • Added a notification when multiple players are entered with the exact same name.

I am also working right now on updating all website documentation, as well as creating a document on making manual changes to settings.ini, including a full directory of valid properties for the settings.ini file.

Grand Prix Kansas City: Analytics

For the next couple weeks, there will be periodic posts revolving around notes and experiences at Grand Prix Kansas City, where I assisted Rune Horvik in scorekeeping the main event, and Legion Events debuted RTools at the Grand Prix level. Additional posts will be based around scorekeeping notes/stories and program lessons.

During round 4 of Grand Prix Kansas City, I put some Google Analytics code on the index.php file of EPIC. The following are a smattering of statistics and interesting things which that data yielded.

:: Four events used EPIC during the GPKC weekend: GPKC, a PTQ for Philadelpha, a SCG IQ, and a Standard Sealed event. For these four events, there were a total of 5,427 page views, 2,829 of them unique from a total of 416 unique devices. Android browsers slightly out-edged iOS’s Safari, 45.40% to 41.28%, with the remainder coming from (in order) IE, Chrome, Firefox, Opera Mini, and various Blackberry phones. Approx. 85% of traffic could be traced directly to mobile browsers, and 99.35% of all traffic was direct (not from a link) traffic.

:: A total of 423 valid DCI numbers were accessed during the weekend. Over 250 of those were checked at least five times during the weekend. 167 were accessed 10 or more times. 7 were accessed 50 or more times. Top was 76.

:: During day 1 of GPKC, 358 people accessed EPIC. I cannot specifically determine who accessed it from within the building, however ~350 would be a decent assumption as to the number of players using it from the floor, adding the combined variance from outside lookups and also that the pairings from rounds 1-4 were not part of the analytics. This yields an approximate usage rate of 40% of the field.

This information would most likely be the most accurate compared to the entire weekend, as during Saturday no other tournaments were using EPIC.

:: Location information is the real story here. Kansas was 7th in terms of US state traffic on the site, and Missouri was 3rd — a distant 3rd, in fact, to Minnesota and Illinois, each having 2x-3x the traffic numbers. Other states in the Top 10 (in order) included Texas, Colorado, New York, Wisconsin, and Pennsylvania. One other somewhat surprising state is Ohio, in 20th and at a negligible amount of traffic.

Also from this information, Wisconsin shows the highest number of pages visited per trip to the site; my hypothesis on this is that since some Wisconsin players were already familiar with EPIC, their usage would lend to more advanced use. In this case, a higher number of pages visited per trip implies that multiple DCI numbers were looked up using a single smartphone. (several states outside the top 10 show very high numbers here, implying that groups were all checking pairings on a single smartphone)

Grand Prix Kansas City : Human Nature

For the next couple weeks, there will be periodic posts revolving around notes and experiences at Grand Prix Kansas City, where I assisted Rune Horvik in scorekeeping the main event, and Legion Events debuted RTools at the Grand Prix level. Additional posts will be based around scorekeeping notes/stories, program lessons, and analysis on the statistical data received from EPIC during most of the weekend.

The stage-side view of the tournament was one of the more interesting demonstrations of human learning which I have seen. The first occasion the scrolling system was used was when we were seating everyone. I believe the best description of this was mass confusion; this was the one occasion where it seemed that things were going slower than with paper pairings.

RTools was being run in a completely new way here. A playset of 46″ TVs were flanking the side of the hall that the main stage was on. Each TV was being displayed in portrait mode, able to display 32 pairings at a time. (normal TVs are in the 14-16 range) Everything was being run remotely, and we had just spent most of the morning getting the remote machines to a point that we weren’t worried about them changing IPs. Nothing like this had ever been tried before.

In retrospect, the issue was pavlovian: as players, when we are presented with paper pairings, we instinctively don’t pay attention until we are within a few feet of the postings. While this works decently enough with paper, scrolling names only display a portion of their total information at a time, in return for much greater viewing distances. In that first listing, players were not taking advantage of the additional viewing distance, and as such a portion of the players were not paying attention as their names passed by. Once they were “in front”, within a couple feet of the screen, they then needed to wait a minute for their name to come around again, causing a pretty annoying cycle to watch.

During round 1, however, things began to change, as you could see people beginning to adjust. With EPIC’s assistance, we began seeing players adjust to the different format. Reports from the far end of the room (which Steve Port and others purposely spent time at to watch) showed steadily increasing usage of EPIC, while players began to pay attention to pairings at steadily longer distances.

After round 1, some of the more senior judges, as well as both the head scorekeeper and myself, all agreed that we should start posting at least one set of paper pairings in addition as a secondary source for slacking players. The argument was that we would save time by giving those stragglers a place of guaranteed pairings, without having to wait for 30 seconds to a minute for their name to come up. We didn’t get the opportunity in Round 2, though, as there wasn’t visibly anyone to post the pairings for by the time we got pairings ready to post.

By round 4, we were easily going faster than by paper. Players were visibly just hanging around the hall, grabbing their pairings online when the time came; others stayed by their playgroup, and when pairings were announced, the people with smartphones disseminated the information to others in the group. By the end of the day, we found ourselves around an hour ahead of schedule.

The real story for me came on Sunday, when I was scorekeeping for the PTQ.  The players were constantly surprising me in how quickly they were finding their pairings, dramatically reducing the expected turnover rate for an event like this. By round 3, players were already seated by the time I had finished my bookkeeping of the previous round (a minute, tops, due to 95% of it already being done during the round) and we were hitting sub-3-minute downtimes from last slip to clock restarting. It’s really quite something to look up after feeling that you _just_ put up pairings, and find all the players already shuffling up at their table. You wonder if you actually put pairings up at all, and that’s quite an interesting feeling.

Even more stunning (or telling of today’s pre-ban Standard) was that despite this speed, the GP Day 2 outpaced us by 30 minutes through the periods we were both running rounds.

3.2

Good news: 3.2 is out, on the download links, and good to go.

Bad news: I’m waiting until tomorrow to buy into decent wireless, so I can’t use the machine that I wrote all my stuff on. Hopefully that will be up tomorrow. Worst case is Monday.

Keep an eye out on GPKC coverage – RTools is live, and we have confirmed that our plans can actually work!

RTools 3.2.40 (beta 1)

Five months is easily the longest between RTools releases, and June 16th is going to be the full release.

– Byes are now being distributed in networked and auto-updating windows.
– Printer interfaces are threaded.
– Client-based (non-web-based) documentation mostly updated for 3.2 update.
– Bunch of other random tiny things.

Still on the 3.2 to-do list. (though some of this may wait until later)

– Bug: RTools’ seatings and standings don’t work when a WER tournament has a player enter and drop prior to round 1.
– Bug: When remotely pushing header font information, pairing headers sometimes also incorrectly modify the header font information. (into very weird combinations)
– Bug: EPIC Standings give the standings inclusive of drops, irregardless of whether you selected drops to be shown.
– Bug: (still need to confirm this one) If there are no players with a bye, but there are dropped players, a dropped player will be displayed as having a bye. (usually the last name alphabetically that has dropped)
– Bug: Multiplayer tournaments do not display standings information. (and, by extension, point totals in pairings)
– The “Label in Window” functionality of the timer hasn’t been touched since before the variable sizing was implemented, and needs some work done to work with that update.
– There’s a terminal-based interface for interacting with network windows that I’ve been working on, (due to it being much simpler to use for working with those parts of the program) which needs a good amount of work done to it for production use.

RTools 3.2.38 (alpha 10)

Alright, I finally have a release of the new setup of 3.2.

There’s several major changes that come in the back-end, but from the front-end there are just some minor things worth noting right now:

– v3 tournaments differentiate between Awarded and Round byes.
– settings.ini lines can now take a much larger range of inputs. (more on that later)

…that’s it. There’s a lot of small things coming, but that’s the only one written right now. Current buglist (or to-do list) is as follows:

– Byes are still not populating through network windows
– Work on the header text – figure out how we want this to be size-wise. (there’s a random issue with remote settings changes [coming soon] causing scrolling window headers to change sizes)
– Thread printer interfaces
– 2HG Issues (see the last post)

I’m waiting on some feedback on the system that does remote settings changes before I actually release it; it also does at least some form of remote Timer management, so I want to make sure that is working in an acceptably useful way.

Update on 3.2 progress

The major “breaks everything” (revamping the internal settings system) part of the update is about 50% un-broken. Once I finish this, though, the next step is to do a lot of testing to see if there is any performance hit with how I am first trying this system. Normally, I wouldn’t be quite as worried about performance, but the first major event using this is in the upper echelon of player counts.

The next steps beyond getting the program back in operational order are pretty much as follows (in no intensively particular order):

  • Build a way for an external application to remotely change the settings of network windows.

This is one of the random impetuses (Firefox doesn’t like me using “impeti” for the plural) for the setting overhaul: so that ALL settings can be affected outside of the program, whether by settings.ini files or directly in the case of networked windows.

  • Thread the printer interfaces.

Right now, the scrolling windows freeze while RTools tells a printer what to print.

  • Fix a major bug where byes are not passed through into network pairings.

This is because, currently, the network pairings window gets it’s pairings from a slightly different system, which is used when you want to auto-update pairing windows. It does it this way currently because the same system gets table numbers in the ticker, and wants to avoid getting a bunch of “0”s in the listing due to various byes, drops, etc.

  • See if there’s a straightforward way to differentiate between awarded byes and pairing byes. If so, implement it in v3 and in the network system.

Just because it would be good to have.

  • Stress-test the hell out of the entire networking system.

Because I haven’t done it.

  • Some random bugs:
  1. The 2HG pairings/standings interface currently does not take in match results, and as such do not show data regarding points or tiebreakers.
  2. If there are no players with a bye and there are dropped players, RTools currently displays a player having a bye that is actually dropped.

—–

Update (5/12/11): The base of the setting changes is complete, and I implemented the awarded/round byes during this as well. There’s some work that needs to be done in terms of getting some settings to propagate correctly, but I should be able to get a working alpha release out sometime this weekend.

I’m finding some major error-checking work that needs to be done with the networking interface. That, and I still need to finish my little plugin side-project.

RTools 3.2.36 (alpha 8)

I got a disclosure on some upcoming plans for RTools, which basically is that Grand Prix Kansas City will be rocking the full suite of RTools, to the point where we’re probably having no posted pairings in the main event. This means EPIC and the Networking system will be in full force and being demo-ed the whole weekend!

Well, besides the fact that I’m panicking (slightly) over the modifications I need to make for this event. The .36 release is internal-only, as some of the changes I was casually working on are not yet finished. (namely, the plugin interface still has this habit of duplicating information several times over, making a fully-equipped plugin menu enormous) The main plan right now is to work for the next week or so, making some ground-level changes in the code. Mainly, this means changing the internal settings interface from a static setup (all the settings are named and found through very specific means) to a dynamic setup. (settings are accessed through mappings)

This enables me to heavily beef up a side-program I’ve been fooling around with, which is essentially a terminal interface to the networking system. In essence, the dynamic settings will allow me to push settings from this terminal interface to individual screens. (which suddenly became a very important thing to have) The terminal also allows me to monitor and remote-control network windows much more easily than in a GUI.

Some other things which will be done going into the next several alphas:
– Modifications to the timer, centering in on a new setup for negative time display.
– Fixing a bug where byes do not show in remotely-launched windows. (this is the same bug that causes auto-updating windows to not display byes)
– The majority of the settings system will probably be incompatible with previous releases as of the next release. I’ll build an internal converter and possibly some sort of default .ini file with all the changeable lines inside it already. (if you were around in the 1.x days, it’ll look familiar)
– The printer interface is getting threaded. In realistic terms, this just means that printing something off won’t randomly cause the scrolling windows to freeze.

More to come…