bjx.net

New New Blog Location

2014-01-24T23:08:00.001-06:00

New Blog Site: http://www.bradleyjx.net/
New Email: shizu@bradleyjx.net

New Blog Location + Contact Information

2010-11-17T19:31:00.001-06:00

New Blog Site: http://blog.bradleyjx.net/
New Email: bjx@bradleyjx.net

Blog Changes

2010-11-17T15:52:00.000-06:00

If you check the home site, you may have noticed that it was down for the past week or so. The short explanation is this:

bjx.net, the name, is hosted on a provider, while the actual hosting was done on a free service that I liked, and paid about $10 a few years ago to gain permanent access to SQL and a few other cool things. The downside was that you were truly dealing with the downsides of a free service, but they were pretty human in their responses.

Now, about a week ago, they had a vulnerability exploited on their site, which apparently triggered some of their automated systems for defending against DDoS and overuse. For some reason, my site was included in here, and was deleted/banned. Since it was a free service, and technically my account fell under a "legacy support" system when the ownership changed hands a while back, there wasn't much for me to do.

So, I shifted hosts to host content to the same provider as my name provider.

The big plus now is that now that I'm actually using a pay-for provider, I can actually use the FTP service pretty nicely. Coincidentally, my only reason for using Blogger was removed from Blogger in 2009, and the only reason I haven't switched over to Wordpress has been those FTP issues.

I'm fooling around with Wordpress right now, and should have a redirect link in this site sometime late this week. Note that the new blog will be a combination of this blog and some older blogs, so (like this blog) be ready for using tags if you are just here for RTools info.

---

Updates on RTools: um... I haven't touched the code since I released v.2.2.42, so there isn't anything. I have one more change in mind for 2.2, but other than that there isn't anything to report, really.

3.0, 3.1 Roadmap

2010-11-08T01:42:00.000-06:00

So, another weekend, and scorekeeping run #2, far more interesting than the first. The only notes on scorekeeping for me are that I need some more experience, and need to avoid being rushed unnecessarily. (the two biggest mistakes I made both occurred due to this) I also need to work on disconnecting my RTools-derived knowledge with my scorekeeping troubleshoot methods; I keep finding that opening a text editor and tinkering with the bare files is not the best course of action.

Also, typing out draft decklists is a pain.

---

As of now, here's the plans for 3.0 and 3.1 roadmaps

v.2.2 (current beta update):
A use case came up at the PTQ that seems more helpful than the current EPIC setup, and will involve the checkbox menu option being added in addition to the current one. When selected, the EPICupload.txt file will be created/modified whenever a timer is started, or a pairings window is spawned. The menu option will remain as a manual system.

v.3.0:
3.0 won't have any new features in it, and probably will have a couple stripped out. (8-man side event printout, I'm looking at you) The goal with this version is to make some heavy changes to the way which RTools connects to outside programs, and make about a 75% reduction in the amount of code used as part of the files used for this purpose for each individual program. In return, there is a code class which is part of all these connection classes, and that class will be much, much larger, as it integrates the code which was redundant in all the individual connection classes.

The benefit is very straightforward here from my end: bugs that exist with one program and not another should be entirely eliminated, and there should no longer be issues with one outside program not having features another does have. (though tiebreakers may be the wrench in that) Also, future changes require only one place with anything more than a little additional code, in comparison to the four locations I currently need to add code.

v.3.1:
3.0 is a "Version Update", 3.1 is a "Point Update". For how I think of programs, version updates are modifications to the architecture of the already-written portions of the program, and point updates are essentially feature upgrades. 3.1's major feature is networking. In essence, you will be able to control one RTools system from another.

Why? Well, there are a couple use cases which I feel like I would want to tackle:
- Breaking away the information from a particular machine enables organizers to be more flexible in where they run tournaments logistically within a space, and where they display this information. You can have a machine within the sales area of a store that runs the tournament, and a second machine's screen always facing the players with the information they need.

- In combination with other planned feature additions, this can provide a route towards eliminating any player limits to RTools' scrolling interfaces. Right now, I personally would say 250-300 players is the limit to the scrolling pairings, as a 300-player tournament would mean 90 seconds to go through all pairings. (at default settings) But, let's say you want to run this at an event with 1000 players.

At this size of an event, paper pairings are separated into name ranges, and posted at separate parts of the room in order to prevent too much crowding. If you do could do the same thing, but with projectors, you not only have a system which can speed up the inter-round tournament time, but also have a place to disseminate information for things like side events, and control it all from a single system in the area.

Now, this isn't saying that you can't use RTools at this large of an event already. From my experience with testing, if I had to setup a system to run a 1200-player tournament with RTools, I would only need an HD projector and that the computer being used have high specs. On that projector, have four tickers in the four corners used only as labelers, set to "Always on Top" and with name ranges (like "A-F") on them. Then, produce name-ranged pairings and put them where the labels are for those pairings. Scroll the four windows on the projector. It's possible to do, but relatively difficult, especially if you intend to other things on that machine.

Possible future updates (or, updates that aren't directly on a roadmap):
- The "Free Window" may return in some form, probably as a menu option that is normally checked, which associates spawned windows with the tournament-based color settings. So, when it's unchecked, the windows have completely independent settings.
- An option may come in future versions with EPIC when multiple timers are visible, which asks which timer to use. (right now, the first-created timer is the one transferred)
- "Advanced Mode" for some windows. For instance, a pairings window that displays name ranges, a standings window that only displays active players, or a standings window with a point cutoff.

RTools 2.2 beta 2 up

2010-11-05T01:02:00.000-05:00

I finally figured a little feature that I've been working on off-and-on, but just haven't gotten a firm solution figured out has been ... well ... figured out, and it was small enough that it shouldn't cause any new issues, so it's getting shoved into the 2.2 branch and is the only change for this version.

The new feature is that the font size of timers is now generated automatically, rather than being set, and will fit itself into whatever the timer window's size is. (i.e. dragging the window larger will make the timer larger) The impetus here was this image. Yes, I actually actively look for RTools being used in the wild; even something as small as that. (keep looking, you'll see it...)

I saw that image and saw a use case I hadn't thought of before, and started looking into what I'd need to change to make timers scale automatically to just fit the window dimensions. The biggest problem is actually in the positioning of the timer text itself in that window. One interesting quirk about Java in the context I use for that timer is that it isn't easy to exactly center that text.

If you think of the timer window as a grid of pixels, the line of code which actually puts the text in the window needs to know the bottom-left pixel to start drawing from. This grid is generated using the top-left pixel as (0,0), and going to the right & down incrementing in positive numbers. Seems simple, right? Well, the top-left pixel isn't the pixel in the black space, but instead is located in the title bar; if you think of the title bar as covering up more black space, the top-left pixel is where it would be if it weren't covered up. The problem here is that different Windows skins have different heights for that title bar, and it can also be changed manually in your display settings. So, the usable space for the timer needs to be guesstimated to keep it guaranteed in a visible area no matter the computer. When it comes to automatic scaling, the issue came down to adjusting this somewhat-complex setup for positioning the text, and successfully accounting for this title bar while also not falling for a myriad of other quirks in this particular portion of the language.

So, that's just an overly-long explanation of what is different about beta 2, and also a little glimpse into a bit more interesting issue.

RTools 2.1 Released, 2.2 beta 1 up

2010-10-31T22:35:00.000-05:00

RTools 2.1 is posted out of beta, and is now the sole current version.

RTools 2.2 beta 1 is also posted. There will be no alphas of 2.2, as the 2.2 build is a hybrid build pushing some early 3.0 changes into the 2.1 codebase, and these changes are relatively minor, in comparison to the changes which are still being written with 3.0.

I expect 2.2 to be the new current version within the next two weeks.

3.0 Running Updates...

2010-10-27T22:00:00.003-05:00

Much of the program that doesn't need a major overhaul is plugged back in to the main interface; the program settings, the pieces that don't involve outside connections, and most of the new things are plugged in and working to the extent where they can right now. The v3 and WER hooks are also written, but the hook-agnostic portions, which are the largest part of the changes, are still untouched.

The plan at the moment is that once I get a stable system with these changes, alphas will start being done until the program gets every little thing back working right. Once I get that done, I will start working on tacking on two more things: name-ranges in pairings, and a networking system.

Update 1
Pairings have been launched successfully for the first time in 3.0. It's horribly incomplete, doesn't take byes or program settings into account, and displays your DCI number instead of your name, but it's at least launching!

Update 2 (10/28/10)
Today was kind-of interesting. Some minor improvements have shown up for 3.0, but I also decided to test the modularity of my code today, in order to look into some things I may want when scorekeeping next weekend. 30 minutes later, I had something that worked so well, it made me shift gears internally and decide to release a 2.2 update while continuing work on the 3.0 update. More on this later, but I intend on releasing 2.1 by the end of the month, with 2.2 coming in full release in mid-November.

A look at 3.0 in pre-alpha

2010-10-27T03:09:00.000-05:00

This is just a look at what I'm fooling around with right now in 3.0. The "Seating" button is rigged to work as if it spawned ticker windows. The contextual menus for the buttons now bring up a listing of all windows opened under that button's context for that tournament, so here we have three tickers, and right-clicking on the button assigned to tickers (there may not be one in the final release; this is just a test) gives you first a menu of all open tickers. Each menu option will give you that ticker's contextual menu.

Note that although this looks like 2.1 with an update, looks are a bit deceiving. In fact, that is the _only_ thing that works throughout the entire program at this point, and even it isn't working fully. (the menu system in the ticker needs to be moved a bit to let the options affect the window) No menu options or buttons actually do anything yet, as either the classes haven't been moved over yet (Tools options) or the spawned windows haven't been updated into the new setup that is required to enable this menu trickery. v3 is the only connection the program can make, and even then, the new code to actually use the connection hasn't even been written yet.

In short, when I talk about just getting to the main window as being the first stage in a rework, it really is just a small first step. The benefit, though, of getting to this point is that most of the decision-making has been completed in terms of how this update is going to come together. The template code is already written, and outside of the massive rebuilding of the connection code still to do, there isn't much needed to hook GUI elements back into the program.

...though, I will be using this update to do some rebuilding of GUI code anyways.

Random stuff...

2010-10-26T23:09:00.000-05:00

1. v.2.2 = v.3.0
With the amount of changing that has already occurred, I've decided to call the 2.2 update version 3.0. Just the pure amount of change being done is making this more and more clear.

2. v.3.0 progress report.
I am close to the point where I can reach the main GUI once again, with a new system plugged in to hook into outside programs. I'm still a ways away from getting windows spawned, as there is going to be two major changes made before those get plugged back in:
- All of the window GUI structures need some minor updates to standardize the systems.
- In 2.1, there was some code added to the main GUI that gave some contextual information, at the cost of some windowing restrictions being added. Some of the structural changes being done will make this system much more easily workable.

3. Somewhat Important Bug Notice
It's probably something everyone here does, but make sure that when you name your events, you use a unique name for each event. If you have two events with the same name, even if you select the "newer" event from the listing of events, (which are sorted by event date in WER, and the last time the back-end files were modified in other programs) which event will be added to the main window will not be guaranteed to be the event that you expect.

This isn't an easily-fixable bug, and I'm not sure if it will be fixed with the 3.0 update. I will need to do some more research into exactly where this comes from; it's easy to explain the bug, just finding the code and fixing that process isn't.

4. v.2.1 Release

I haven't had any issues come up (other than #3) in the last couple weeks, so I'll probably update 2.1 to a full release sometime in the next week or two. I will be moving the beta to the "Current Version" listing soon, though, and will consider it as such.

Getting back up, 2.2 programming has begun...

2010-10-19T00:49:00.000-05:00

Well, the good news is that my machine is back up and running, and the drive isn't in any danger of going bad. The bad news is I lost a battery in the process, and reconfirmed that this '05-built laptop can't run anything past XP. I'd love to run W7 on this machine, but half the driver support just isn't there.

I've started initial programming of some of the core changes of 2.2. There's a lot of major changes in the back-end here, so I'm starting on a fresh setup, without any of the 2.1 code initially. The plus side to this entire thing, though, is that once I get the new code written, a lot of the old code should just plop right into place. Essentially, the planned "core" changes are along the lines of:

- Rewrite the code which accesses back-end files. Essentially, this is simplifying the 500+-line classes which are used for each connection right now and bringing those down to 100-200 lines, at most. Then, move a lot of the logic and put it all into one place, so that as little code as possible is varying based on the connection. The huge benefit here is that there should be fewer issues in terms of things being different because of what connection the tournament is moving through.

- Making some adjustments to the windowing code, basically making it easier to keep track of the windows open and getting rid of some class structures that I did initially. The main benefit here is that I can make some 2.1 features easier to use, and probably get rid of some restrictions.

2.2 is currently only about 100 lines of code of an expected 7000-8500 when this is all done, so it'll be a while :)

BSOD

2010-10-16T02:05:00.000-05:00

The list of issues with my main programming computer has increased slowly in recent months, but tonight I started having some Blue Screens on my machine, and the symptoms look like they're due to a failing hard drive rather than something that would just require a reinstall. I am currently running a maintenance tool on it to see if there is a verifiable drive issue, and afterwards am lifeboating (removing the contents of the drive through a USB OS) the files and trying to get a stable OS on there.

Odds are this will take the weekend to get a definitive diagnosis.

In terms of RTools, there aren't any outstanding issues in the 2.1 build, so there's nothing immediately at issue here. Thankfully, I store the programming files on a Dropbox folder, so I have auto-backup on my code and don't need to worry about that. In terms of when the next updates will occur, the first BSOD actually occurred right after I branched the 2.1 code into a 2.2 branch, so work will be in the down-low rebuilding which I have planned once I have a windows system back up and running.

RTools 2.1.39 (beta 1), and the 2.2/3.0 roadmap

2010-10-13T16:59:00.001-05:00

Beta 1 is out for 2.1; this build is essentially what has been available for the past couple weeks, with a couple extra popups added in EPIC that proved to be useful.

The switch to beta is pretty much due to the same reasons that I switched 1.1 alphas into betas, in that any of the changes I want to make have far too much potential for breaking things already running fine, and I want to release a stable version with a solid number before I go in an tinker in major things.

---

The next revision will be either 2.2 or 3.0, and the following are amongst my list of things that may or may not be in it:

- A revamped Data Access Object (DAO) system. The system implemented today is based off of an extension of the original ideas for handling data, which was easy due to the only thing being needed was pairings. Now, each of these classes have seven of these "get something" classes, and it is becoming unwieldy and heavily redundant. If you think of the 1.1-2.0 change as being rewiring the internals of the program, 2.1-2.2 is rewiring the external connectors.

- Reworked window management. The restrictions added in 2.0 and 2.1 to windows have some benefits, but some feature requests have been directly in conflict with these, and there have been occasions brought up where the need for multiple timers and multiple pairings windows have become apparent. I'm currently looking at designing a system that will still give many the cool tricks of the current setup, while allowing for unrestricted windowing. (and yes, there's a setup I have in mind that makes EPIC work fine with this)

- Full program settings window. Recently, I've been holding back on the occasional addition due to the need to have a popup menu brought up, asking some random question. ("Send timer to EPIC", "Mask tiebreakers to EPIC", "Print Slips with Character Strip") The need is becoming easily apparent for a full programs settings menu, and I plan on turning the current tournament settings menu option into a tabbed window, adding all sorts of program settings in there.

- Advanced Pairings. This I'll actually probably be building a pre-alpha build for that "fakes" the functionality, as there is immediate need for this at one location that uses this program. This is just a way to bring up a pairings window with name ranges, so you can have one window with A-M pairings and another with N-Z.

Now, for me this is a different kind of change than the 1.1-2.0 changes, as I don't feel I'll be writing a ton more code initially; instead, it's just a lot of new creations and moving already-written code to new areas. Also, since most of these changes are pretty insulated against the rest of the program, I can really just work on one part at a time. One downside of this is that, unlike alphas for 1.0-2.1, the builds won't necessarily be getting progressively more stable as time goes on.

Update 10/14/10: I didn't change the version of the release, but I put in some quick updates to EPIC. The system now uses GET rather than POST in the form, which just means that the contents of the DCI field goes in the URL, making that page bookmark-able. I also removed some upload stuff that I don't have a quick way of implementing, but had as part of the page.

Updates coming from States...

2010-10-10T00:38:00.000-05:00

Future updates will have a couple minor changes prior to a full 2.1 release, thanks to some States use cases:
- I may setup EPIC's round clock to stop displaying once the time displayed is the same as the current time.
- An option will be somewhere to mask tiebreakers in EPIC.
- There will be some adjustments to match result slips, to try to squeeze a touch more room between two slips.

See the post I just made a few minutes ago for a look at WI states.

WI States - Scorekeeping

2010-10-10T00:35:00.003-05:00

States has a place for everyone, for one reason or another. From a player perspective, States is the largest "pure" tournament that is held in the US; no money on the line, and no route to larger events directly from it. One of the local players compares it to a family reunion, as it is probably the event with the highest casual-player-to-player-count ratio in competitive Magic. From a constructed perspective, States is the flagbearer of the new Standard, eight days from release to event causes all sorts of interesting tech at these events, and some of the best deck stories come from these events.

From my perspective, States has always been something that's somewhat special, just from a judging perspective. States '04 was my first major event, and where I certified. States '05-'07 were always the first times that I came home from college in the semester -- a particularly poignant point during my freshman year. 2008's shakeup was seen from abroad, and 2009 I wasn't able to drop down and help, so States '10 was the first time in a while I've been able to be around and help. This year, this was a new first, as this was the first major event I was (officially) scorekeeper rather than judging.

Normally, coming into an event as a judge, you brush up on rules and penalties, and make sure you have everything you need. With scorekeeping, most of the work is just interfacing with a pretty flexible program. The nice thing is, this is a program I know quite well, thanks to months of testing events through it. You see, about six months ago I began development of a program to replace a tool used at Legion Events for many years, which was most apparent in the scrolling pairings you see if you're familiar with them. The development has gone far beyond the original scope of the program, and has also had the nice side-effect of becoming probably one of the most familiar users with DCI Reporter, and especially the back-end files.

There was a nice coincidence between programming and scorekeeping as well, as in the weeks prior to States I was finishing work on a new program feature: web pairings. In short, you go to a website, enter in your DCI number, and get a ton of event information about the event right there, from round pairings to match history and other cool things. This event was the chosen event to debut this setup, mainly because I wanted to be running the system the first time it was used live, to handle any issues that could occur.

As an aside, I wasn't worried in the slightest about the system having issues: everything being done has been used in other parts of the program without issue. There were two other issues, though. For one, this was being run on my website, which is essentially hosted on a free provider and randomly craps out. They do a really good job for being the kind of provider they are, but the downside is you occasionally deal with random blackouts. The other issue came from my experiences as a judge: nothing similar to this (outside of SMS pairings) has been tried before, and the amount of information here has never been so freely available. The big point of contention is standings information, something that is pretty tightly controlled by staff at large events. The setup right now was simply an option to mask tiebreakers, which would be used in the final rounds to keep that information only to the printed standings.

As this was my first full event scorekeeping, Steve Port, the head of Legion Events, was around and took the lead during registration just showing the way to do things; I took a side and took care of DCI number lookups, as well as doing some traffic work. We ended registration at 145 players, at which point I took the helm and ran through the debut of the web system, with Steve watching and waiting to see just what this web thing could do. Now, from my standpoint at this event, my job for pairings was four steps, in order: setup pairings in Reporter, generate and upload the web pairings file, setup the scrolling pairings system, and print result slips. (no paper pairings, though!) Occasionally, this also included determining tables and getting names for random deck checks. Despite this seeming like a good bit of work, it's pretty straightforward and you can go from the last slip to players sitting within 30 seconds. (1-2 minutes if you use paper pairings)

The web system wasn't advertised prior to the event, and the only way someone would've known was through slips at the registration desk. The system wasn't really "known" until Pete Jahn's announcements as head judge, and quickly about 20% of the players looked into and started using it. Throughout the event, the praise for this was nothing short of amazing, and the reaction probably moved it for me from an interesting side-tool of the program to a full-on glaring advertisement avenue. Also, expect to see this very quickly at other events in Wisconsin and Minnesota, and possibly elsewhere.

The event itself actually was pretty uneventful, with the only issue from my end being an incorrectly-placed drop on a result slip that I should've looked into; thankfully, this is among the easier fixes for issues in scorekeeping. Another minor issue shows where my experience with the program, though. When I was entering in a penalty early in the event, I thought that I accidentally added two penalties to one player, and that Reporter wasn't allowing me to undo the problem. Instead of trying to find a fix, I closed the penalties window and opened the file system, opening the back-end text file that holds penalties with the intent of just manually changing that line to fix the issue. The file didn't show two penalties, and the problem was fixed when I reopened the penalties window.

We also used this event to try out another of the random features that this program has, in that it can print match result slips in a more compact and detailed form than in what Reporter produces. I shifted over to this starting in round 3, and it worked perfectly for what we were looking for. It also produced a great example of an issue that you would never think of in the abstract, but becomes quickly apparent when actually using the system. If you have ever cut several pieces of paper on a cut machine, you know that the paper shifts a bit when cutting, and you don't get the exact same place cut between sheets. When I made the slips, I didn't put enough space between pairings to account for this, and it made cutting a much more careful job than it should be. This is an easy fix from a programming standpoint, but also something that you would probably never think of in theory.

The worst problem of the day was simply a combination of bad luck and Wisconsin weather. At the store, there'd been occasional issues with the A/C system. The past couple weeks in southern Wisconsin have been a relatively cold October, hitting freezing in the night and not going past the 50s (10s Celsius) in the day. So, of course, today was 75 and sunny, and the A/C was pretty much dead throughout the day. The saving grace was that another part of the building was open in case we were in the 200-player range, and due to the player count this turned into a cold area for players to head over to between rounds, also benefiting by cooling the main room through fewer players. Also, we just did the entire top-8 in the other part of the building.

Overall, it was nice being on the other side of the event from what I was used to. I'm the kind of person that would rather judge than play, but I'd also rather scorekeep than judge. You stay more in the background, and just keep things going in the event. The downside is that I really am not in touch with the event; for instance, I was wondering why rounds were taking much longer than I thought they should, but since I wasn't on the floor watching matches I didn't see that they were W/U Planeswalker Control mirrors. I watched one match the entire day in any kind of judging capacity, that being one of the semifinals between handing out typing decklists and finishing entering results.

RTools 2.1.37 (alpha 13)

2010-10-01T22:55:00.001-05:00

Small update just for an EPIC fix. The "Round Ends" code had a slight issue with the minute portion; if the time was something like 12:03 PM, it would show instead as 12:3 PM.

I _want_ this to be the last update before States, so odds are there won't be anything in the next couple weeks for update. If it starts being a while without updates, I'll just start doing some code cleanup and release what is here as the 2.1 release.

I'm starting some design work on two separate things right now: one is related to either the 2.2 or the 3.0 update (haven't decided which it'll be) and the other is related to a new project I've been looking at in recent weeks, which would help with making testing towards the JLPT exam easier.

RTools 2.1.36 (Alpha 12)

2010-09-28T21:59:00.001-05:00

I will be posting alpha 12 (v.36) sometime tomorrow. There are several improvements with this update:

- EPIC updated slightly from the RTools side and significantly from the web side. The included EPIC web files includes the updated interface, as well as being able to handle the "Previous Rounds" code additions in RTools.

- Match result slips have adjustments to handle printers that do not follow normal margins. In addition, there is a strip added to the left-hand side of the printout, which is simply a character repeated. The goal here is to make match result slips more quickly identifiable when working with result slips in several different events.

- All scrolling windows have their contents shifted a tad to the right, as when used maximized with CRT screens the leftmost columns were somewhat difficult to read.

- Menu option added to export the local player database in WER into a format that is readable by v3 and WER. The export option in WER is only readable by other WER programs.

There's no exact ETA for this update in terms of time. I just got a new external hard drive, and I'm using this opportunity to run some hardcore drive checking systems on my now-4 drives. This goes at the pace of a little more than 1GB/minute, and I have a little over 4TB to go through here. As the machine doing all this is my programming machine, I'll need to wait for a break in this overall new-drive process to actually get everything together and push it online.

Update 09/30/10 1AM: The update is online, with the updated EPIC files; the external transfers aren't going as well as I expected, so this computer is back to use for normal things. Also, this update pre-emptively changes all "September" listings to "October" a day early.

EPIC for 2.1 (and States)

2010-09-28T02:19:00.001-05:00

The last post was my functional version of EPIC. It was a design for me to easily get features into a website, and make sure that the programming worked.

This design is the (unskinned) version I'll be running at States: A little more compact, and a much more flexible design. There's no more need for horizontal lines separating sections, and there's also a ton less wasted space, with only minor issues currently with cramped information.

If you are interested in using this during States, the current web version in alpha v.30 works with all the newer versions so far, so you can look at the basics of getting it together on your website now. I'll have this newer setup bundled in the next public alpha release, which I will bring out no later than Oct. 6th. The only issue I want to fix before that is making changes to the result slips setup to fix some margin problems. (these problems don't show themselves in the compact sheet, so I think I'll only need to compare the two setups to find an easy fix)

A look at EPIC today...

2010-09-27T03:00:00.001-05:00

Another change in the alphas starting at v.34 is a slight upgrade to the EPIC system, bringing it in line with the features of the ill-fated first version.

To your right is the current information screen, taken straight from one of my test tournaments. Unlike the other screenshot, this isn't a dummy tournament or mockup, so I just cleared out some of the names. (yes, I know there's a random bracket in the text) This, minus the last section of previous round entries, is what I live-tested at last weekend's prerelease. States will be my official "debut" of the web system, and will use an interface based on this. How much it changes will depend just on how much time I have, but I am intending on making the overall setup look much less like a badly-formatted table (which it is) and actually make it look like something interesting.

Plus, I want to take a shot at looking at how this looks skinned with a different color scheme.

Prerelease EPIC etc notes

2010-09-25T04:19:00.001-05:00

I got the crazy idea this evening to try running EPIC in a live environment for the first time at a midnight prerelease, so that's just what I did. After a quick RTools patch (.31 or .32 will have this random issue I found fixed, I still don't know the cause but I quashed the source) we announced the plan to everyone just before round 1 began, and just had a ticker displaying the website to go to.

Now, this wasn't really an event that would have a strong use case for EPIC, but it still had a few judges, high-level players, and random folk. It's enough that with 4-6 people actually trying it, I could get some good feedback without any chance of server stress. I think about 10 people were using it at some point over the event, and the feedback received was entirely positive and gave me a good path to look forward to in continuing development. (namely, handling bad DCI entries better)

Sleep now, more talk later...

Update 09/25/10: There's a lot of minor notes and changes that I am looking at from one day of the prerelease weekend which I will be at this weekend. The big thing is that things really don't work perfectly when the event is 2HG. I'm not saying that it shouldn't be used, but that the more interesting things RTools can do start having issues once you start moving into team events.

Internally, RTools is at v.32, with the next alpha release probably being v.34. v.31 had a kludge implemented to allow EPIC to work with a specific event setup that I didn't test before, while v.32 made some adjustments to the display that were needed for the setup where I was. Before I release another alpha, I want to clean up these two versions, and also make some changes to the match slip pairing code.

I hadn't thought of that...

2010-09-16T22:00:00.001-05:00

"Why does the pairings window have that long break between the last pairing and the first pairing?"
The long answer is actually pretty involved. The scrolling system is based off of a previous program which was used in the upper midwest until this year. I built the RTools system initially in the same way as that other program.

If you visualize the scrolling window as a physical window, the scrolling system could be seen as a long sheet of paper behind that window. Every time it moves, the sheet of paper is just moving up until all the information is displayed. Then, the paper is reset to the top and scrolls down again.

So, why doesn't it do it? Because I haven't thought of it, and nobody ever brought it up! Sounds like a good idea, and after doing some implementation to see how this looks, it is most likely a much better setup.

The adjustment that needs to be made is to (using that analogy again) tape the top of the paper to the bottom, and turning it into a looping piece of paper. 2.1.28 has made the adjustments made to add this feature. (2.1.27 also had it, but the implementation was faulty)

Update (09/18/10)
2.1.29 is out to fix a couple bugs brought in with earlier alphas. There is a capitalization function in the program for names that was getting some new text strings sent to it, and those new strings were causing problems in standings by pods printout. Also fixed is an issue that came about with some of the EPIC refactoring, which caused byes to show up again in printed pairing functions. (the byes were checking for a specific signal value in the DCI number as a trigger for not showing, and those values were being overwritten by the new code that ensures DCI numbers will always be on printed result slips)

RTools 2.1.27 (alpha 3)

2010-09-15T22:22:00.001-05:00

A couple more features coming in with 2.1.26+ (alpha 2): (more explanations on that numbering in a minute)

- Result Slips going through WER will have DCI numbers added.
- Seatings has an additional option to just show a master list of players. (one-column)
- EPIC is added to the download, as a ZIP file in the RTools_docs directory.
- Context menus (right-click menus) are now accessible from the main window.
- The java icons in the windows are now RT logos. (this was a really old issue; I just figured out I was over-complicating the problem)

I may be holding off on updates for an extended period of time in the near future.

---

There's also another change starting with alpha 2, and that's to the version numbering which I have been using. The system that I was using was great for pre-1.0 releases:

X.Y.Z
X = Full (Major) Release number
Y = Update (Minor Release) number
Z = Revision number

Another way to put it was that Z was for bugfix updates, Y was for feature upgrades, and X was for major changes. (not necessarily upgrades) This worked really well initially, but I actually have never built another program that I actually version-ed into 1.0 and beyond, and there's some annoying aspects to it. Namely, it's really hard to use this system and make incremental updates. When working on 1.1, (and going through now on 2.1) it's a bit of a change, though. For instance, while I was adding features to 2.0, during many of the points the program itself was stable and running fine; the only issue was that the releases weren't much, so in the end a bunch of features just got added together in large numbers of alpha releases, rather than being released as actual releases.

So, the change I'm making isn't actually changing what those numbers mean, but instead changing when those numbers get reset. Before, an update to one number reset all numbers before it. So, going from 1.0.x to 1.1 reset the x to 0.

What's changing is that the x will now be incremented on all releases, private or otherwise; in addition, it'll probably only be reset on major updates. (v2 to v3) So, when I put out what would be 2.1.0a2, it will instead be 2.1.26 (alpha 2). (2.0 had 20 alphas and 3 betas) Full releases won't have any suffix to the version release, but now almost all updates will at least have legitimate version numbers, rather than 2.1.0aXX.

EPIC Update

2010-09-14T02:42:00.002-05:00

I decided today to make some adjustments towards what I was trying to do with EPIC, and looked at making it work without the database work which I was trying to do. I put together a rough system which basically exported player information via RTools into a text file, which you could then remote-upload to a website and access the data from there. (essentially what v3 does with it's files)

With some major caveats, I do have a path currently where a user can theoretically get tournament information online using this system. Some major things don't work yet...
- Players with byes don't show up. (has to do with how the DCI numbers are currently retrieved, actually a bug but not a visible one)
- v3 only (_much_ easier to do for proof of concept testing than WER)
- No more than one tournament at a time.

So, I do have the opportunity now to expand this into something that's usable without a ton of work; it'll also give me the impetus to resolve an inconsistency in accessing back-end files, which you would see currently in that WER events + match result slips do not print DCI#, while v3 events do.

The one thing which I will be thinking about is whether this modified EPIC system really needs the ability to have more than one tournament at a time in it's system. Since we're no longer worrying about databases, you could instead tell different tournaments to go to different websites, each with a back-end file. The total size of the entire system is currently under 50kb including data, so we're not talking about much in terms of movement.

I would say that the best part of this change in thought is just how long it would take to make an update now. Before, my personal builds were taking 2-3 minutes for a reasonably-sized event to update fully. (not what we're looking for in this kind of software) There is more click-labor in this method, but we're talking about:
- A menu option
- Navigating to a website
- Browsing for the exported file and entering in a short password. (just to make it slightly difficult for someone without knowledge to go in and use it)

You're looking at 15 seconds for this, 2-3 times during a round. Why 2-3? Well, remember me talking about an impetus of the 2.0 changes being the ability to make timers accessible in EPIC? Well, the second update would be re-uploading with the round clock running in order to show on EPIC when the round will end. The third update would be for standings posts at later rounds, just so the numbers get updated.

Just so you know, this stuff is all 2.1 updates at this point, but at the same time this is the first time where I see nothing actually preventing me from releasing this in-full. Although 2.1 shouldn't be out until towards the end of the year, I fully expect that by 2.1 alpha 10, the system will be functional, and all the web application files will be in the downloads for people to setup their own systems.

Update 09/14 5:00PM
The program now works with WER as well as v3 in personal testing. Still getting byes sorted out, as that is a non-issue issue turned into a bug with these upgrades. Bonus: WER match report slips have DCI numbers on them now.

Update 09/15 1:00AM
Byes are being handled mostly at this point. I had the opportunity to go through all the motions during an event tonight and make sure I could get a working system going. The huge plus here is that I can not work entirely on interface improvements from the web end. Since this setup is much more modular than a normal event, I can make the interface a little bit more customizable.

One note is that this system doesn't work with team events at all. There's a myriad of reasons for this, mostly centering around the fact that most of the code in RTools is not designed for multiplayer events. Instead of going through and truly building things in to handle multiplayer as an extension of single-player, RTools rides off of information that is already present in the places where single-player info is stored. (essentially, for a team event, the location that a single-player event stores information has the team's information in it's place) These issues are not things that I have looked into fixing in the slightest, as the amount of work needed to make all this work would need rewriting of all the hook code, which is about 2-3x the amount of code work that the 2.0 update required. (2.0 changed how data was being moved around in the program, this would require changing how that data is acquired, stored, and used, essentially changing everything that _wasn't_ changed in the 2.0 update)

RTools 2.0.0 beta 3

2010-09-11T20:39:00.001-05:00

One (probably) final beta for 2.0, with one fix and one addition.

- There's a dialog that pops up when there is less than 1 month remaining in the license term. It displayed an incorrect date for when the license would expire, and this has been fixed in this beta.

- If you looked at earlier alphas/betas in the 1.1 and 2.0 era, there have occasionally been options in the menu to split or join v3 tournaments. (i.e. what they do at huge GP tournaments) There were some issues with the implementation, and I took another shot at the split portion. It appears to be working perfectly this time, so the option is restored for this beta. I may or may not figure out the join portion by the time the full release is done.

Note that I have seen other implementations of this in program form, and this one works slightly differently. The main implementation I have seen takes a preregistration pool and splits it. This one takes a fully-setup tournament and splits it randomly, (splitting byes) creating two new tournaments files.

Update on Standings discrepencies

2010-09-07T15:49:00.001-05:00

I spent a couple hours today looking again at the standings code, and doing some comparisons to standings produced in WER to try to figure out just where my algorithm deviates from theirs.

I was able to find an error with my side of the coding today, revolving around my interpretation of this line, from Appendix D of the MTR:

"A player’s byes are ignored when computing his or her opponents’ match-win and opponents’ game-win percentages."

I had interpreted this to mean that, when you are looking at the computing tiebreakers, if one of your opponents had a bye in a round, that 2-0 win is to not be recorded when computing that player's portion of your OMW%/OGW%. However, looking at how both v3 and WER calculate tiebreakers, they interpret this line to mean that if a player has a bye themselves, they don't count that bye as anything when calculating tiebreakers. (so that you don't need to worry what a bye's PGW% is when calculating it as part of the averages to find your OGW%)

If I change my algorithm to take this into account, everything _almost_ matches, and the things that don't I can centralize directly to errors in v3 and WER's calculations. I'm fine with this being a mistake on my part from interpretation :)

So, this gives me the opportunity to add a new dropdown to the Program Settings menu I'm currently building: "Standings calculated via: ", with the three options being "MTR", "v3", and "WER". (MTR will be default) If you have RTools set to be compatible to one of these, the standings _should_ match perfectly.

The adjustments to bring standings in alignment to the MTR will be in A18; the Program Settings menu will be around A20. (I'm changing the download site right now to bring up A17)

Update (09/07/10 8pm)
In my personal (bare-code) build, the standings now work quite well. There's a bug with printing standings through RTools, though that looks more like a remnant of the 2.0 crossover and should be a simple fix. With the fixes I will be bringing into A20 and possibly A21, I may be looking to shift to beta builds. Almost certainly before I hit A25.

RTools 2.0.0 alpha 17

2010-09-06T22:30:00.001-05:00

The updates are being slow right now, due to some busy times as well as just taking a break after a few weeks of very quick updates.

Alpha 17's only visible change is that I found how to do anti-aliasing in Java's core GUI library and implemented it pretty much immediately, so timer/clock/ticker/pairings text should look cleaner starting with this alpha build.

There are four "projects" that are in the alpha currently:

- 2.0 Paradigm transitions
These have been completed for a while now, and just some small adjustments have been made in past weeks. One thing that does need fixing is how the timers are affected by menu options and settings changes. I'm pretty much going to go back to how I initially built the timers for 2.0, before I started getting worried about people not liking the inability to have multiple timers per tournament and trying to kludge something.

- EPIC
This is at a point where I'm just looking for the right server, then things will be in live builds quickly.

- The settings menus.
This is the main thing I'm finishing right now; most tournament settings are working right now, and I want to get a program settings menu in place as well. As part of this, I also need to change the font selection GUI to allow font sizes over 200 and just turn it into a text field. (The timer was being used at SCG Open Minneapolis, and we needed a 500pt font for that event; if I didn't have the settings menu built to a point then, I would have needed to use RT1.1)

- Notification panes on the main window for all open windows.
So, if I open a pairings window, the main window will get a little taller and give a little line of info on the pairings window. I can right-click on that area and get the same reaction as right-clicking on the pairings window, (i.e. starting the scrolling from there) and also get windowing options from the main window.

At this point, I want to finish the settings menus and finish the timer adjustments, then get 2.0 out as a full version. After that, the notification panes will probably be 2.1, and EPIC is looking to be 2.2.

Oh, and 2.0a17 will be around in the next day-ish.