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.
10.31.2010
10.27.2010
3.0 Running Updates...
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.
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
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.
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.
10.26.2010
Random stuff...
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.
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.
10.19.2010
Getting back up, 2.2 programming has begun...
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 :)
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 :)
10.16.2010
BSOD
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.
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.
10.13.2010
RTools 2.1.39 (beta 1), and the 2.2/3.0 roadmap
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.
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.
10.10.2010
Updates coming from States...
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.
- 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
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.
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.
10.01.2010
RTools 2.1.37 (alpha 13)
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.
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.
Subscribe to:
Comments (Atom)