New Blog Site: http://blog.bradleyjx.net/
New Email: bjx@bradleyjx.net
11.17.2010
Blog Changes
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.
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.
11.08.2010
3.0, 3.1 Roadmap
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.
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.
11.05.2010
RTools 2.2 beta 2 up
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.
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.
10.31.2010
RTools 2.1 Released, 2.2 beta 1 up
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.
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.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.
9.28.2010
RTools 2.1.36 (Alpha 12)
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 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)
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)
9.27.2010
A look at EPIC today...
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.
9.25.2010
Prerelease EPIC etc notes
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.
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.
9.16.2010
I hadn't thought of that...
"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)
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)
9.15.2010
RTools 2.1.27 (alpha 3)
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.
- 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.
9.14.2010
EPIC Update
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)
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)
9.11.2010
RTools 2.0.0 beta 3
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.
- 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.
9.07.2010
Update on Standings discrepencies
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.
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.
9.06.2010
RTools 2.0.0 alpha 17
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.
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.
8.26.2010
History of RTools - 2007 through August 2010
This isn't here for any reason in particular, but it's just something that I wanted to write and get down somewhere...
RTools has a history that began in 2007, with the release of DCI Reporter v3. At this time, a program called Tournament Board functioned as the augmentation program, which functioned with DCI Reporter v2. As a stop-gap measure, I had looked at making a program which converted v3-compatible files to v2 files, only to the point where Tournament Board could see these produced files as v2 files, and then use them successfully. I had also gotten back in touch with the original programmer, who was happy to be contacted about the issue and setup v3 functionality with some assistance from the converter code which I had written.
Flash forward to 2009 and the release of Wizards Event Reporter. (WER) When I first looked at WER, I had the same thought as before in regards to compatability, and began looking for a route of access to back-end files. I had localized the file in question to one very deep in Windows' OS, but I had no idea how to work with this .dat file which looked to be encrypted in some way.
At the same time, though, in past months I had looked around at figuring out ways to build the scrolling pairings interface into a Java program. At the time, I was only familiar with the high-end Java GUI libraries, and the furthest I have gotten was a set of text fields which updated automatically. It looked cruddy, but gave me the hooks to v3 for future use.
These two issues came together quickly in early 2010. I had just graduated and was looking for something to do while job-searching, and had solved both issues within a week of each other. The latter was solved first through me experimenting with the low-level Java UI (java.awt) interface. From here, I was able to achieve a window which had a piece of text moving down on the window; this quickly scaled to the current scrolling windows and checked one piece off.
The former issue was solved through a lucky break when fooling around with WER at home. I had randomly a windows explorer open to the folder that contained that encrypted file, and I suddenly noticed a file called "TournamentData.ldb", which tipped me off immediately to the solution. The test was to try to open that .dat file through Microsoft Access. I got all the tables immediately, telling me WER used a Microsoft Access database file to store everything, and giving me the link I needed to go straight towards building a new version of Tournament Board. When I thought of a name, I had randomly thought that Tournament Board was called "Reporter Tools", and called my version "RTools" as a successor. Sounds better than "TBoard", at least.
Feature parity was the initial goal for the original release of RTools, but the goals quickly became greater whenever I saw things being printed at local events. The most eggrerious thing was, for me, result slips being used once again at these events. Way back, Tournament Board made this great printout which we used both for FNMs and prereleases: at FNMs, you got one sheet with all results on them at once, while prereleases gave you a half-sheet with all result slips, making it trivial for a judge to carry all results with them. At the local store, this also was shown with pods for drafting, where we kept posting pairings on a sheet with 30-odd players crowding around to find their location.
The latter began the advance in features which the program is now being known for. Pod seatings turned into all forms of seating for events. Standings came from having the interface available and wanting to tackle coding tiebreakers. Further advances were spawned from both requests and "enabling" features that people wanted in WER that weren't yet available. Result slips, tickers displaying outstanding results, the 8-man draft print interface, and many other small features came from these requests and needs. For comparison, Tournament Board's features were the equivalent of RTools' pairings, ticker, and clock, with the printer functionality solely being the equivalent of RTools' compact sheet pairings.
RTools has a history that began in 2007, with the release of DCI Reporter v3. At this time, a program called Tournament Board functioned as the augmentation program, which functioned with DCI Reporter v2. As a stop-gap measure, I had looked at making a program which converted v3-compatible files to v2 files, only to the point where Tournament Board could see these produced files as v2 files, and then use them successfully. I had also gotten back in touch with the original programmer, who was happy to be contacted about the issue and setup v3 functionality with some assistance from the converter code which I had written.
Flash forward to 2009 and the release of Wizards Event Reporter. (WER) When I first looked at WER, I had the same thought as before in regards to compatability, and began looking for a route of access to back-end files. I had localized the file in question to one very deep in Windows' OS, but I had no idea how to work with this .dat file which looked to be encrypted in some way.
At the same time, though, in past months I had looked around at figuring out ways to build the scrolling pairings interface into a Java program. At the time, I was only familiar with the high-end Java GUI libraries, and the furthest I have gotten was a set of text fields which updated automatically. It looked cruddy, but gave me the hooks to v3 for future use.
These two issues came together quickly in early 2010. I had just graduated and was looking for something to do while job-searching, and had solved both issues within a week of each other. The latter was solved first through me experimenting with the low-level Java UI (java.awt) interface. From here, I was able to achieve a window which had a piece of text moving down on the window; this quickly scaled to the current scrolling windows and checked one piece off.
The former issue was solved through a lucky break when fooling around with WER at home. I had randomly a windows explorer open to the folder that contained that encrypted file, and I suddenly noticed a file called "TournamentData.ldb", which tipped me off immediately to the solution. The test was to try to open that .dat file through Microsoft Access. I got all the tables immediately, telling me WER used a Microsoft Access database file to store everything, and giving me the link I needed to go straight towards building a new version of Tournament Board. When I thought of a name, I had randomly thought that Tournament Board was called "Reporter Tools", and called my version "RTools" as a successor. Sounds better than "TBoard", at least.
Feature parity was the initial goal for the original release of RTools, but the goals quickly became greater whenever I saw things being printed at local events. The most eggrerious thing was, for me, result slips being used once again at these events. Way back, Tournament Board made this great printout which we used both for FNMs and prereleases: at FNMs, you got one sheet with all results on them at once, while prereleases gave you a half-sheet with all result slips, making it trivial for a judge to carry all results with them. At the local store, this also was shown with pods for drafting, where we kept posting pairings on a sheet with 30-odd players crowding around to find their location.
The latter began the advance in features which the program is now being known for. Pod seatings turned into all forms of seating for events. Standings came from having the interface available and wanting to tackle coding tiebreakers. Further advances were spawned from both requests and "enabling" features that people wanted in WER that weren't yet available. Result slips, tickers displaying outstanding results, the 8-man draft print interface, and many other small features came from these requests and needs. For comparison, Tournament Board's features were the equivalent of RTools' pairings, ticker, and clock, with the printer functionality solely being the equivalent of RTools' compact sheet pairings.
8.24.2010
RTools 2.0.0 Primer 2.0 (for A14)
(note - this is being written to be the new go-to link for people to read before downloading the 2.0 alpha)
In general, alpha builds that I release are plenty usable, but are simply builds that are focusing on adding or changing code, rather than fixing code. Early alpha builds may have features disabled simply in order to provide the most up-to-date versions to interested parties with the portions that knowingly do not work correctly removed. As alpha builds advance, newer functions may appear without full functionality as well, or non-standard functions may temporarily appear.
RTools 2.0 has several new changes, as well as adjustments in how the program is used. As of this writing (alpha 14), many of these are already in the program. The overall difference between 1.0 and 2.0 has been a paradigm shift in how information moves within the back-end of the program. The original idea of RTools' back-end was to spawn new windows much like new programs: independent from the program itself, just doing it's own thing. As features were added, the need became more and more apparent that an internal messaging system and inter-feature connections system was necessary. 2.0 has rebuild this internal structure, pushing individual tournaments as the center of RTools' paradigm and allowing for many new and improved internal tweaks that were more kludges in 1.0 and 1.1.
The following is a listing of the major new features of the program:
:: The main window now reacts to events in the program relating to how a tournament's state. If you have a timer that is reaching or at 0:00, the timer button will begin flashing. The other three buttons will also indicate which window is opened as part of the main scrolling display window.
:: Windows which utilize the "Outstanding Matches Only" functionality will now update the listings automatically every few seconds.
:: Preferences and settings are now granular to a tournament (rather than the entire program) and there are new windows to facilitate changing these settings. There are also options to save and load these preferences.
There are several changes to the workflow of the program, as well. Again, the following is just a selection of the more immediate differences.
:: In 1.0, you choose a program to interface with and RTools gives you all events found in that interfaced program. In 2.0, you still are given the options to select an event, but events are now loaded into the main window. When you load a new tournament, it's added to the main window's dropdown.
:: Settings are tournament-based now, rather than (mostly) either window-based or program-based. Now, making adjustments to an event's settings is much more intuitive, and settings are handled in a much better way, from both the front-end and back-end.
:: A single tournament only has a single window for any pairings, seating, or standing window. If you have one window up continuously on a second monitor or projector, the window will simply update to the new data when you click on the button. This is designed to supplant the functionality to automatically launch new windows on secondary monitors, while simplifying the entire process of handling multiple tournaments, both front-end and back-end.
As of this writing, RTools is in it's 14th alpha, (2.0.0a14) with no timetable for shift to beta or release. Release is dependent on the evolving status of EPIC, and the continuing additions that are being made to 2.0 alpha.
In general, alpha builds that I release are plenty usable, but are simply builds that are focusing on adding or changing code, rather than fixing code. Early alpha builds may have features disabled simply in order to provide the most up-to-date versions to interested parties with the portions that knowingly do not work correctly removed. As alpha builds advance, newer functions may appear without full functionality as well, or non-standard functions may temporarily appear.
RTools 2.0 has several new changes, as well as adjustments in how the program is used. As of this writing (alpha 14), many of these are already in the program. The overall difference between 1.0 and 2.0 has been a paradigm shift in how information moves within the back-end of the program. The original idea of RTools' back-end was to spawn new windows much like new programs: independent from the program itself, just doing it's own thing. As features were added, the need became more and more apparent that an internal messaging system and inter-feature connections system was necessary. 2.0 has rebuild this internal structure, pushing individual tournaments as the center of RTools' paradigm and allowing for many new and improved internal tweaks that were more kludges in 1.0 and 1.1.
The following is a listing of the major new features of the program:
:: The main window now reacts to events in the program relating to how a tournament's state. If you have a timer that is reaching or at 0:00, the timer button will begin flashing. The other three buttons will also indicate which window is opened as part of the main scrolling display window.
:: Windows which utilize the "Outstanding Matches Only" functionality will now update the listings automatically every few seconds.
:: Preferences and settings are now granular to a tournament (rather than the entire program) and there are new windows to facilitate changing these settings. There are also options to save and load these preferences.
There are several changes to the workflow of the program, as well. Again, the following is just a selection of the more immediate differences.
:: In 1.0, you choose a program to interface with and RTools gives you all events found in that interfaced program. In 2.0, you still are given the options to select an event, but events are now loaded into the main window. When you load a new tournament, it's added to the main window's dropdown.
:: Settings are tournament-based now, rather than (mostly) either window-based or program-based. Now, making adjustments to an event's settings is much more intuitive, and settings are handled in a much better way, from both the front-end and back-end.
:: A single tournament only has a single window for any pairings, seating, or standing window. If you have one window up continuously on a second monitor or projector, the window will simply update to the new data when you click on the button. This is designed to supplant the functionality to automatically launch new windows on secondary monitors, while simplifying the entire process of handling multiple tournaments, both front-end and back-end.
As of this writing, RTools is in it's 14th alpha, (2.0.0a14) with no timetable for shift to beta or release. Release is dependent on the evolving status of EPIC, and the continuing additions that are being made to 2.0 alpha.
2.0.0 alpha 13 out tonight...
So, there were nine things from the last post that were going to be adjusted in the next few alpha builds. Here's where they stand for 13:
1: done.
2: done.
3: done.
4: not started.
5: not started. I may hold off on this until 2.1.
6: not started. I may hold off on this until 2.1. (the idea doesn't sound as useful after a couple days of letting it sit)
7: fixed. The issue was that there was a list of player IDs that was being checked to find byes, and the bounds were determined from a source that wouldn't show the final player if they had the bye.
8: I've found that this is an issue of Reporter v3 updating their files more than RTools, as RTools gets these numbers directly from the file that contains player information.
9: done.
I also just plowed through and got a first build of a tournament preferences panel up. It's essentially all right-click options in one place, minus a few which will require me to make more windows for. (i.e. a font window minus font size options) There will probably also be a second preferences panel for program settings. They'll include save/load functionality, and there are buttons on the tournament panel, but they are non-functional currently.
Alpha 13 will be out sometime later today.
1: done.
2: done.
3: done.
4: not started.
5: not started. I may hold off on this until 2.1.
6: not started. I may hold off on this until 2.1. (the idea doesn't sound as useful after a couple days of letting it sit)
7: fixed. The issue was that there was a list of player IDs that was being checked to find byes, and the bounds were determined from a source that wouldn't show the final player if they had the bye.
8: I've found that this is an issue of Reporter v3 updating their files more than RTools, as RTools gets these numbers directly from the file that contains player information.
9: done.
I also just plowed through and got a first build of a tournament preferences panel up. It's essentially all right-click options in one place, minus a few which will require me to make more windows for. (i.e. a font window minus font size options) There will probably also be a second preferences panel for program settings. They'll include save/load functionality, and there are buttons on the tournament panel, but they are non-functional currently.
Alpha 13 will be out sometime later today.
8.23.2010
Post-Nationals Aftermath
Walking into Nats for the grinders, I had no idea how much RTools would be used during the weekend. Initial thoughts were modest: I don't believe it was launched once on Thursday, instead running events completely via paper and judges holding the timers. Me just being panicky over anything going wrong at all, I was perfectly fine with this :)
Walking in Friday, I see the fruits of preparation working nearly perfectly. The main event has both a clock and timer running, and the tournament-based colors working flawlessly on the side events. Me being me, I'm watching every scroll and every timer for _anything_ going even close to wrong.
Friday night, I leave with some feature requests for the next day, and a couple bugs to look at. I also do all I can to make sure that the standings aren't shown again like they were at the end of Friday.* I did get out of the convention center a tad early, as I expected the changes to take 2-3 hours in coding and would've otherwise had 8 hours between leaving for the night and needing to be back. Somewhat fortuitously, the fixes ended up being done in less than an hour, and gave me a nice night of sleep.
Saturday: I was on the main floor, and it was uneventful. I did have one of the appeals which the HJ, Eric Shukan, liked talking about :) Interesting fact: On the main floor all three days, no appeals caused overturned calls. No issues, so a relaxing evening.
Sunday: So, somehow the exact same issue affects two events at the same time, and never happens in any of the dozens of other events. I also thought I lost my keys for about 7 hours, and the ended up being under the pants I wore for the first half of the day. (not the worst of my life, though close)
Now, the aftermath of this event will bring a ton of changes and fixes to future alpha builds, thanks to a lot of good usability feedback...
- All options to change background colors in windows are being removed. Let me know, though, if you have a use for this. This is just the easier of two options I have for adjusting this.
- Some people have been telling me that preregistered players were showing up in places they were not supposed to, and I thought that I fixed this for 1.1 and 2.0 alphas. Alphas 13+ will have the fixes that were made for pairings also get done for seating and standing displays.
- Windows that take advantage of some form of outstanding tables being displayed will now automatically update every 5-10 seconds.
- I will be working more expediently on getting rid of ambiguous behavior in the program whenever you press the "Cancel" button in a window.
- Timer windows will have some changes to the right-click menu to allow for you to customize the timer label, when it's part of the window. I may just default the label to be of a size that will fit-to-window, automatically changing the font size on it's own instead.
- There may be an option added to the pairings window to remove the point totals from pairings. This option would be for late rounds of larger tournaments when players are paired to random tables rather than by rank, to make it less trivial to simply find where the top players are seated.
- A bug appeared where the final player on the scrolling pairings was being cut off if that player also has a bye. I'm still looking into why this is; I have the tournament files in question to look at, but I have not yet been able to duplicate or localize this issue.
- Another bug has shown where the point totals on pairings are a round behind when the pairings go up. Again, I have the files in question but have not yet duplicated or localized the issue.
- The ticker is getting a couple issues fixed that popped up. First, when you change the message, it will no longer move the window back to the default placement. (top-left of the primary window) In addition, the font size adjustment wasn't working for some reason during Nats, and this has been fixed.
I also have my first feature plan for 2.1, (or possibly 2.0 if the development takes longer than I expect) which has also been a feature that I have somewhat been dreading to build, that being a unified settings/preferences window. Each tournament and window only has about 20 explicit settings, though this can jump to about 40 when you include implicit, settings.ini, and developer settings. The issue is that I tend to be a very hands-on builder for GUI windows, and settings windows are detailed jobs, with each area of text, each editable text area, and every other element on the window needing to be written, placed, and handled individually.
Alpha 13 will be the next release, which should be out late Tuesday or Wednesday. It'll have adjustments on issue numbers (going in order above) 1, 2, 3, 5, 9, and possibly 6. Also, there should be some expansions to the areas in which RTools is being used in the next few weeks, especially towards the west coast :)
*For those that haven't seen this, RTools, Reporter v3, and WER all will display different standing tiebreakers for events. I believe I have a good reverse-engineer on how both v3 and WER handle tiebreakers, but RTools uses neither method, instead opting to strictly follow the MTR to-the-letter. Having them scroll at Nats isn't a bad idea, as they're the documented tiebreakers, but the scrolling tiebreakers being different than the tiebreakers that a cut or prizes will be based on isn't a good idea.
Walking in Friday, I see the fruits of preparation working nearly perfectly. The main event has both a clock and timer running, and the tournament-based colors working flawlessly on the side events. Me being me, I'm watching every scroll and every timer for _anything_ going even close to wrong.
Friday night, I leave with some feature requests for the next day, and a couple bugs to look at. I also do all I can to make sure that the standings aren't shown again like they were at the end of Friday.* I did get out of the convention center a tad early, as I expected the changes to take 2-3 hours in coding and would've otherwise had 8 hours between leaving for the night and needing to be back. Somewhat fortuitously, the fixes ended up being done in less than an hour, and gave me a nice night of sleep.
Saturday: I was on the main floor, and it was uneventful. I did have one of the appeals which the HJ, Eric Shukan, liked talking about :) Interesting fact: On the main floor all three days, no appeals caused overturned calls. No issues, so a relaxing evening.
Sunday: So, somehow the exact same issue affects two events at the same time, and never happens in any of the dozens of other events. I also thought I lost my keys for about 7 hours, and the ended up being under the pants I wore for the first half of the day. (not the worst of my life, though close)
Now, the aftermath of this event will bring a ton of changes and fixes to future alpha builds, thanks to a lot of good usability feedback...
- All options to change background colors in windows are being removed. Let me know, though, if you have a use for this. This is just the easier of two options I have for adjusting this.
- Some people have been telling me that preregistered players were showing up in places they were not supposed to, and I thought that I fixed this for 1.1 and 2.0 alphas. Alphas 13+ will have the fixes that were made for pairings also get done for seating and standing displays.
- Windows that take advantage of some form of outstanding tables being displayed will now automatically update every 5-10 seconds.
- I will be working more expediently on getting rid of ambiguous behavior in the program whenever you press the "Cancel" button in a window.
- Timer windows will have some changes to the right-click menu to allow for you to customize the timer label, when it's part of the window. I may just default the label to be of a size that will fit-to-window, automatically changing the font size on it's own instead.
- There may be an option added to the pairings window to remove the point totals from pairings. This option would be for late rounds of larger tournaments when players are paired to random tables rather than by rank, to make it less trivial to simply find where the top players are seated.
- A bug appeared where the final player on the scrolling pairings was being cut off if that player also has a bye. I'm still looking into why this is; I have the tournament files in question to look at, but I have not yet been able to duplicate or localize this issue.
- Another bug has shown where the point totals on pairings are a round behind when the pairings go up. Again, I have the files in question but have not yet duplicated or localized the issue.
- The ticker is getting a couple issues fixed that popped up. First, when you change the message, it will no longer move the window back to the default placement. (top-left of the primary window) In addition, the font size adjustment wasn't working for some reason during Nats, and this has been fixed.
I also have my first feature plan for 2.1, (or possibly 2.0 if the development takes longer than I expect) which has also been a feature that I have somewhat been dreading to build, that being a unified settings/preferences window. Each tournament and window only has about 20 explicit settings, though this can jump to about 40 when you include implicit, settings.ini, and developer settings. The issue is that I tend to be a very hands-on builder for GUI windows, and settings windows are detailed jobs, with each area of text, each editable text area, and every other element on the window needing to be written, placed, and handled individually.
Alpha 13 will be the next release, which should be out late Tuesday or Wednesday. It'll have adjustments on issue numbers (going in order above) 1, 2, 3, 5, 9, and possibly 6. Also, there should be some expansions to the areas in which RTools is being used in the next few weeks, especially towards the west coast :)
*For those that haven't seen this, RTools, Reporter v3, and WER all will display different standing tiebreakers for events. I believe I have a good reverse-engineer on how both v3 and WER handle tiebreakers, but RTools uses neither method, instead opting to strictly follow the MTR to-the-letter. Having them scroll at Nats isn't a bad idea, as they're the documented tiebreakers, but the scrolling tiebreakers being different than the tiebreakers that a cut or prizes will be based on isn't a good idea.
8.18.2010
Current Buglist for 2.0.0
The versions out are still the last updates that will be (openly) released until after US Nationals, but a couple issues have sprung up with all alphas 10 and fewer:
- Pairings + "Outstanding Matches Only" is not correctly connected. It doesn't hurt to do it, but it won't change the pairings screen to the correct pairings.
- The Compact Sheet and Result Slips printouts for pairings sometimes has the player names reversed. I don't see a direct issue in the code that is causing this to happen; the issue seems to be related to how Java's database system handles "ambiguous" (arguably) ordering rules. I have localized the line of code which needs to be changed, and am working on removing all ambiguity from that line.
I'll be shoving these fixes into the Nats build ASAP, but don't expect the fixes to be in a normal alpha build until next week. The former should not exist as an issue in 1.1, though the second may. I'm really not sure, as this is the first event I've heard of this issue out of several dozen I've worked with personally with the lines in question written the way they are.
- Pairings + "Outstanding Matches Only" is not correctly connected. It doesn't hurt to do it, but it won't change the pairings screen to the correct pairings.
- The Compact Sheet and Result Slips printouts for pairings sometimes has the player names reversed. I don't see a direct issue in the code that is causing this to happen; the issue seems to be related to how Java's database system handles "ambiguous" (arguably) ordering rules. I have localized the line of code which needs to be changed, and am working on removing all ambiguity from that line.
I'll be shoving these fixes into the Nats build ASAP, but don't expect the fixes to be in a normal alpha build until next week. The former should not exist as an issue in 1.1, though the second may. I'm really not sure, as this is the first event I've heard of this issue out of several dozen I've worked with personally with the lines in question written the way they are.
8.13.2010
RTools: 1.1.0 out of beta, 2.0.0 at alpha 9
My typing speed is near full again (though on 9 fingers...), and I did some test runs on my 1.1.0 code to make sure that I could still run it from bare code. (as I was worried about accidentally losing some code via accidentally working on 1.1 code when I was making 2.0 changes) Everything appears to be working fine, and I've just changed the numbering to a full release, as well as shifted a couple 2.0 fixes into the 1.1 release build.
2.0.0 is also at alpha 9. There's some cool visual cue changes with this version that may be worth looking at, as well as some minor code changes in the background. I'm starting to go through a cleanup process in the code to start getting it ready for a release, as I'm planning on pushing 2.0 to a firm beta or release next week. (I'm judging at US Nats, Legion Events uses this program pretty extensively for events and is doing most of the running at Nats, so combine those and I want the up-to-date system working perfectly as to not have any late-night coding scrambles)
Enough parenthesis, download links are ready.
2.0.0 is also at alpha 9. There's some cool visual cue changes with this version that may be worth looking at, as well as some minor code changes in the background. I'm starting to go through a cleanup process in the code to start getting it ready for a release, as I'm planning on pushing 2.0 to a firm beta or release next week. (I'm judging at US Nats, Legion Events uses this program pretty extensively for events and is doing most of the running at Nats, so combine those and I want the up-to-date system working perfectly as to not have any late-night coding scrambles)
Enough parenthesis, download links are ready.
8.06.2010
RTools 2.0 Alpha 6 coming...
My typing speed is about 1/3 what it usually is at this point, (though increasing in ability quickly) but in my field tests with RTools 2.0, there were a couple issues with a couple minor combinations of features not working fully yet, so build updates are slowly starting up again.
There are three bug fixes currently fixed in internal builds:
- WPN material requests (added in WER as of 4.0.6) no longer show as valid tournaments in RTools.
- A very specific situation (involving byes and a still-to-be-determined set of additional actions) occurred at an event here that prevented pairings from displaying at all during that round. This occurred because of some copypasta SQL code that wasn't exactly right for the job, and that code was fixed.
- The hooks for printing standings by pod are back in correctly.
Note that there are a couple things to do before 2.0 shifts from alpha releases to beta:
- Add in a tiny bit of code to make some settings.ini stuff that I changed with 2.0 backwards-compatible.
- Modify the tournament listings to not list events far in the future. (the place I test at this past week had 20 events before the one they wanted, as every event they were holding up to the Scars of Mirrodin Game Day was already entered into their tournament listings)
- Make some of the 2.0 restrictions optional. Namely, I'm probably going to make a settings option that will invoke the timer restrictions currently in the program as of alpha 4, just so that when you want to use EPIC when it's launched that the ability is there. Otherwise, there doesn't need to be quite as much in terms of restrictiveness. I'm going to keep the one-pairings-window paradigm, though.
- I also want to have 2.0 shipped with EPIC 100% ready from the side of RTools. I can pretty much make it work on every step up until the actual web work right now, and I really should get the networking stuff taken care of now, when I don't have to worry about the actual movement of data and web issues.
I'll put A6 up in the next day or two; 2.0 looks to be an October release currently, heavily dependent on job prospects and hand conditioning.
There are three bug fixes currently fixed in internal builds:
- WPN material requests (added in WER as of 4.0.6) no longer show as valid tournaments in RTools.
- A very specific situation (involving byes and a still-to-be-determined set of additional actions) occurred at an event here that prevented pairings from displaying at all during that round. This occurred because of some copypasta SQL code that wasn't exactly right for the job, and that code was fixed.
- The hooks for printing standings by pod are back in correctly.
Note that there are a couple things to do before 2.0 shifts from alpha releases to beta:
- Add in a tiny bit of code to make some settings.ini stuff that I changed with 2.0 backwards-compatible.
- Modify the tournament listings to not list events far in the future. (the place I test at this past week had 20 events before the one they wanted, as every event they were holding up to the Scars of Mirrodin Game Day was already entered into their tournament listings)
- Make some of the 2.0 restrictions optional. Namely, I'm probably going to make a settings option that will invoke the timer restrictions currently in the program as of alpha 4, just so that when you want to use EPIC when it's launched that the ability is there. Otherwise, there doesn't need to be quite as much in terms of restrictiveness. I'm going to keep the one-pairings-window paradigm, though.
- I also want to have 2.0 shipped with EPIC 100% ready from the side of RTools. I can pretty much make it work on every step up until the actual web work right now, and I really should get the networking stuff taken care of now, when I don't have to worry about the actual movement of data and web issues.
I'll put A6 up in the next day or two; 2.0 looks to be an October release currently, heavily dependent on job prospects and hand conditioning.
7.29.2010
WER 4.0.6 Update works with RTools
Feel free to update WER to the current version; the large list of changes only created one small bug with RTools and is still works fine.
The only thing to note is that WER's feature addition of allowing WPN Material requests from WER has created a minor issue, where some of those requests appear as tournaments in RTools. RTools will not function well if you choose this "tournament", but works fine outside of that.
I'll fix these showing once my hand heals.
Also, take a look in WER at all the new features, especially the round timer that mirrors functionality in RTools' timer. Let me know if there are things in WER's implementation that would be helpful in RTools.
The only thing to note is that WER's feature addition of allowing WPN Material requests from WER has created a minor issue, where some of those requests appear as tournaments in RTools. RTools will not function well if you choose this "tournament", but works fine outside of that.
I'll fix these showing once my hand heals.
Also, take a look in WER at all the new features, especially the round timer that mirrors functionality in RTools' timer. Let me know if there are things in WER's implementation that would be helpful in RTools.
7.28.2010
RTools 2.0.0 status
Quick post: I broke a bone in one of my hands a few days ago, so typing and/or coding has pretty much slowed to a crawl right now.
2.0.0 is on alpha 4 and being tested locally. Given the state of my typing ability currently, I may look at just adding one thing to 2.0 before shifting to beta. (making some of the changes more flexible by making a settings option that makes RTools compatible with EPIC, putting in the current restrictions on window counts)
Look at 4-6 weeks until any more updates occur.
2.0.0 is on alpha 4 and being tested locally. Given the state of my typing ability currently, I may look at just adding one thing to 2.0 before shifting to beta. (making some of the changes more flexible by making a settings option that makes RTools compatible with EPIC, putting in the current restrictions on window counts)
Look at 4-6 weeks until any more updates occur.
7.22.2010
1.1.0 beta now "current release", 2.0.0 alpha 2 up.
1.1.0 has enough of a lack of issues that I'm just making it the current version.
2.0 now has a second alpha up.
- All connections from v1 now work on v2. (the method to activating new ones is different, email me if you need these)
- settings.ini hooks put back in. Not all the internal hooks to settings are back in, so the only lines that do anything are the license key line, program default locations, and the connection line.
- The program should have feature-parity with v1.
I'm actually surprised how much work that I've gotten done with this in the past few days, and it's to the point where I'm quashing bugs on v2 along with v1, and will probably actually beta v2 next week.
2.0 now has a second alpha up.
- All connections from v1 now work on v2. (the method to activating new ones is different, email me if you need these)
- settings.ini hooks put back in. Not all the internal hooks to settings are back in, so the only lines that do anything are the license key line, program default locations, and the connection line.
- The program should have feature-parity with v1.
I'm actually surprised how much work that I've gotten done with this in the past few days, and it's to the point where I'm quashing bugs on v2 along with v1, and will probably actually beta v2 next week.
7.20.2010
RTools 1.1.0b1 and 2.0.0a1 posted.
1.1.0 beta 1 is now posted. I don't anticipate any changes to it before full release.
The other news is that my work on 2.0 has reached the point where I can actually get GUIs working like they were before. To celebrate, I have the first alpha release of 2.0 put together, to anyone that wants to give feedback on where the program is headed.
There are a lot of caveats to this version, however.
- WER-only.
- settings.ini is not functional. You will need to enter a license key on every launch, and you won't have any settings storage.
- Printing of pairing window items does not order correctly.
- Pod Printing options do not work at all.
- Printing of standings are very, very incorrect.
There are probably a whole mess of other issues currently, but I haven't gone down the functionality list to test everything yet, focusing instead on just getting all the hooks between pieces of the program back hooked up. This is mostly done, outside of a couple hooks that need to be made between ancillary software connections. WER and DCIRv3 are considered the primary connections, and both of these are hooked up pretty nicely on my personal builds. The reason WER is the only one hooked up right now is because v3 only works right currently if you save your tournament files in default locations; WER's location is the same no matter what computer you're on. This'll be fixed quickly once I get the the settings.ini hooks plugged in again.
The new paradigm stuff all works, though. If you close a running timer and click on the timer button again, it'll re-show the old timer, still running. You can have a window up on your projector/monitor in fullscreen showing draft seatings; when your ready for pairings, pushing the pairings button in 2.0 just repopulates the data in that screen, so you don't have to move windows anymore. (Ticker and Clock still work exactly like before) Settings are also fully tournament-oriented, so changing a color somewhere in the tournament affects the entire event; the "Tournament-Based Colors" button now is "Multiple Event Mode" and just gives a random color default to a new event. Once everything's hooked in and bugs squashed, I have access to a whole boatload of new data to ship onto EPIC.
...I may get this out by US Nats...
The other news is that my work on 2.0 has reached the point where I can actually get GUIs working like they were before. To celebrate, I have the first alpha release of 2.0 put together, to anyone that wants to give feedback on where the program is headed.
There are a lot of caveats to this version, however.
- WER-only.
- settings.ini is not functional. You will need to enter a license key on every launch, and you won't have any settings storage.
- Printing of pairing window items does not order correctly.
- Pod Printing options do not work at all.
- Printing of standings are very, very incorrect.
There are probably a whole mess of other issues currently, but I haven't gone down the functionality list to test everything yet, focusing instead on just getting all the hooks between pieces of the program back hooked up. This is mostly done, outside of a couple hooks that need to be made between ancillary software connections. WER and DCIRv3 are considered the primary connections, and both of these are hooked up pretty nicely on my personal builds. The reason WER is the only one hooked up right now is because v3 only works right currently if you save your tournament files in default locations; WER's location is the same no matter what computer you're on. This'll be fixed quickly once I get the the settings.ini hooks plugged in again.
The new paradigm stuff all works, though. If you close a running timer and click on the timer button again, it'll re-show the old timer, still running. You can have a window up on your projector/monitor in fullscreen showing draft seatings; when your ready for pairings, pushing the pairings button in 2.0 just repopulates the data in that screen, so you don't have to move windows anymore. (Ticker and Clock still work exactly like before) Settings are also fully tournament-oriented, so changing a color somewhere in the tournament affects the entire event; the "Tournament-Based Colors" button now is "Multiple Event Mode" and just gives a random color default to a new event. Once everything's hooked in and bugs squashed, I have access to a whole boatload of new data to ship onto EPIC.
...I may get this out by US Nats...
7.17.2010
RTools - How 2.0 works...
I guess I mentioned RTools 2.0 last post, so I should get go into what to expect.
RTools 1.0 has a system that is based around working with tournament software. When you launch the program, you are asked what program you want RTools to interface with, and you are given everything that that program has. The drop-down menu gives you everything that RTools can find, not just what you need.
The plus of this is that it takes out several steps that existed in the previous software; a connection was made only on an individual tournament basis and not by program, and you needed to connect using the tournament codes the software provided.
The change going forward will be by merging these two paradigms. When you launch 2.0, you will get a screen asking you to make a connection, and it will have two steps: choose the program you wish to connect to, and choose the tournament from that program. The tournament will then be loaded into RTools and placed in the drop-down in the main window. If you want to add another tournament, the "..." button currently in the UI will do this, as well a menu option.
This seems like a bit of a back-step, but the changes allow some back-end code changes which will have some increased benefits...
- The paradigm of a tournament rather than a program means that settings can be used on a tournament basis much more easily. Every tournament will have it's settings encapsulated, and it would just be a menu option to make a settings change apply to all open tournaments.
- By associating a window directly with a tournament, you can avoid having multiple timers or pairing windows open at the same time for that event. Attempting to open a second one will just have the first one be brought to the front, and possibly refreshed with new data. It also doesn't interfere with other events, as the whole system separates the two tournaments from each other.
- Regular updates can be sent directly to already-opened windows, allowing for things like an automatically-updated list of remaining tables updated every 30 seconds.
- The program can access all tournament information now, opening a path to place RTools-specific data onto EPIC. (such as round clocks)
This does come at one feature downside though, as settings get a little rough to integrate using this system as there are no longer universal settings. The plan right now is to scrap all settings code from the initial 2.0 builds in order to focus more on how the new inter-component settings will operate, and then re-insert the settings system in a simpler form.
I have already broken off the 2.0 code separately from the soon-to-be-released 1.1 codebase, and have started a lot of the core work needed to implement this. So far, the timer/clock windows are the only system that I have converted fully, with the next step being the UI. That way, I have a path to test the core settings changes, while also having the UI updated into the new form. After that comes reworking the access object classes, which are what do all the talking between RTools and the tournament programs. Then, it's just getting each button to work the way it did before I decided to mess everything up.
---
Update (07/20/10): Version 2.0.0 alpha 1 is running now; this doesn't sound like much, but it's actually a huge step for me. The major issue with such drastic revisions is that at a certain point early on in the coding, you lose most of your ability to debug visually; it's like tearing apart an engine: at some point early on, you won't be able to turn the engine on again until you've made your changes and almost finished the rebuilding process. This version means that I have the GUI back up and running after the core changes have been done. At this point, the WER access object is the only one converted (though the others will be relatively trivial, since it's just the same steps as converting the first one), the only buttons "hooked up" are the ones that don't display a "pairings-based" window, and the menu is useless.
This also gave me the first opportunities to test out the new tricks with making the program tournament-centric, and everything works as planned. The demo right now would involve launching a timer, starting it, closing it, waiting a few seconds, then launching a timer again from the main window. v1 behavior would bring a new window up; v2 behavior brings back the old timer, still running like it never left.
RTools 1.0 has a system that is based around working with tournament software. When you launch the program, you are asked what program you want RTools to interface with, and you are given everything that that program has. The drop-down menu gives you everything that RTools can find, not just what you need.
The plus of this is that it takes out several steps that existed in the previous software; a connection was made only on an individual tournament basis and not by program, and you needed to connect using the tournament codes the software provided.
The change going forward will be by merging these two paradigms. When you launch 2.0, you will get a screen asking you to make a connection, and it will have two steps: choose the program you wish to connect to, and choose the tournament from that program. The tournament will then be loaded into RTools and placed in the drop-down in the main window. If you want to add another tournament, the "..." button currently in the UI will do this, as well a menu option.
This seems like a bit of a back-step, but the changes allow some back-end code changes which will have some increased benefits...
- The paradigm of a tournament rather than a program means that settings can be used on a tournament basis much more easily. Every tournament will have it's settings encapsulated, and it would just be a menu option to make a settings change apply to all open tournaments.
- By associating a window directly with a tournament, you can avoid having multiple timers or pairing windows open at the same time for that event. Attempting to open a second one will just have the first one be brought to the front, and possibly refreshed with new data. It also doesn't interfere with other events, as the whole system separates the two tournaments from each other.
- Regular updates can be sent directly to already-opened windows, allowing for things like an automatically-updated list of remaining tables updated every 30 seconds.
- The program can access all tournament information now, opening a path to place RTools-specific data onto EPIC. (such as round clocks)
This does come at one feature downside though, as settings get a little rough to integrate using this system as there are no longer universal settings. The plan right now is to scrap all settings code from the initial 2.0 builds in order to focus more on how the new inter-component settings will operate, and then re-insert the settings system in a simpler form.
I have already broken off the 2.0 code separately from the soon-to-be-released 1.1 codebase, and have started a lot of the core work needed to implement this. So far, the timer/clock windows are the only system that I have converted fully, with the next step being the UI. That way, I have a path to test the core settings changes, while also having the UI updated into the new form. After that comes reworking the access object classes, which are what do all the talking between RTools and the tournament programs. Then, it's just getting each button to work the way it did before I decided to mess everything up.
---
Update (07/20/10): Version 2.0.0 alpha 1 is running now; this doesn't sound like much, but it's actually a huge step for me. The major issue with such drastic revisions is that at a certain point early on in the coding, you lose most of your ability to debug visually; it's like tearing apart an engine: at some point early on, you won't be able to turn the engine on again until you've made your changes and almost finished the rebuilding process. This version means that I have the GUI back up and running after the core changes have been done. At this point, the WER access object is the only one converted (though the others will be relatively trivial, since it's just the same steps as converting the first one), the only buttons "hooked up" are the ones that don't display a "pairings-based" window, and the menu is useless.
This also gave me the first opportunities to test out the new tricks with making the program tournament-centric, and everything works as planned. The demo right now would involve launching a timer, starting it, closing it, waiting a few seconds, then launching a timer again from the main window. v1 behavior would bring a new window up; v2 behavior brings back the old timer, still running like it never left.
7.14.2010
RTools - The July 2010 Roadmap
--- 1.1.0 --- (August 2010)
1.1.0 is pretty much just at the point where I'm doing small things right now. (though, I call match slips a small thing) I should be switching this from alpha (features still being made) to beta (bug squashing only) in the next week or so. I'm waiting on one last possible feature addition to work on, but I don't have anything major on my plate.
--- 1.2.0 --- (~October 2010)
This should be the EPIC update. There's also a couple other things which I have part-way coded, or working in some form, that I'll hold off on releasing until here. The EPIC code isn't dependent on 2.0 coding, so I may turn this into 2.1 if 2.0 gets finished before I find a host.
--- 2.0 --- (~2010)
Now, I should clarify how I use version numbers. In a version 2.4.3, 3 indicates that this is the third minor update, with only minor feature changes and bug fixes. the 4 says that there have been 4 updates that I can't consider small, usually for a feature I don't call minor or for a compilation of smaller features. The 2 defines the "build" which the program is; by this, I mean that this is the second time which I have worked on the core of the program and changed just how the program executes through the things it needs to do.
With a lot of the updates since 1.0 (well, the 0.5 beta), there has been a bit of a fragmentation in terms of how the program treats tournament data. The issue is that the original builds treated each window as it's own program, and when you launch a window, the main program compiles and sends all the relevant data to the window; this new window just does it's thing on it's own, and doesn't care about the main program.
Now, if you look at the current program, there's are things which talk between each other in various forms. The settings system and tournament colors are the most glaring, but there are other internal systems that now need to talk to each other. This means that there are sometimes two ways which information is stored, for two different systems to use in different ways; doesn't sound like much, but it's a bother when you need to make sure that two different places are changed always. But, EPIC has one feature in particular that I can't implement because of this fragmenting: a round clock inside the web interface. Since the round clocks are completely separate from the main program, (except for the tournament colors...) there's no way I can ask for the time and send it to the web server.
The fix for all this is to decrease the scope which the back-end has to work though. Right now, everything works on a program-basis; if I press the Pairings button, the program does a bunch of things on the program level, and tells other functions to get the info it needs before it finally goes into the window/printing system. What I want to change this to is a tournament-based system at the back-end. Meaning, what you see doesn't change all that much, but what actually is occurring behind-the-scenes is much different.
For example, when you say you want a timer for a tournament, right now a new one is simply spawned. In the new system, there will automatically be a timer associated with that tournament. If you haven't used it since opening the program, you get a new one. If it's opened already and behind windows, it'll just regain focus. If you closed it earlier and it was still running, it'll come back up as if it was never closed.
The huge benefit to this, though, for a timer (along with other parts) is that since the entire tournament's windows are managed through a single location, it's much easier to do something like get the time from the window, and stick that number somewhere where it would be accessible to EPIC.
The system will also benefit with better settings management. When you first go to a new tournament, the tournament will acquire default settings from the program defaults; however, if you change a setting, it'll be associated directly with that tournament and the windows in it. In essence, how "Tournament-Based Colors" works, but much more efficiently integrated and for fonts, background colors, etc.
1.1.0 is pretty much just at the point where I'm doing small things right now. (though, I call match slips a small thing) I should be switching this from alpha (features still being made) to beta (bug squashing only) in the next week or so. I'm waiting on one last possible feature addition to work on, but I don't have anything major on my plate.
--- 1.2.0 --- (~October 2010)
This should be the EPIC update. There's also a couple other things which I have part-way coded, or working in some form, that I'll hold off on releasing until here. The EPIC code isn't dependent on 2.0 coding, so I may turn this into 2.1 if 2.0 gets finished before I find a host.
--- 2.0 --- (~2010)
Now, I should clarify how I use version numbers. In a version 2.4.3, 3 indicates that this is the third minor update, with only minor feature changes and bug fixes. the 4 says that there have been 4 updates that I can't consider small, usually for a feature I don't call minor or for a compilation of smaller features. The 2 defines the "build" which the program is; by this, I mean that this is the second time which I have worked on the core of the program and changed just how the program executes through the things it needs to do.
With a lot of the updates since 1.0 (well, the 0.5 beta), there has been a bit of a fragmentation in terms of how the program treats tournament data. The issue is that the original builds treated each window as it's own program, and when you launch a window, the main program compiles and sends all the relevant data to the window; this new window just does it's thing on it's own, and doesn't care about the main program.
Now, if you look at the current program, there's are things which talk between each other in various forms. The settings system and tournament colors are the most glaring, but there are other internal systems that now need to talk to each other. This means that there are sometimes two ways which information is stored, for two different systems to use in different ways; doesn't sound like much, but it's a bother when you need to make sure that two different places are changed always. But, EPIC has one feature in particular that I can't implement because of this fragmenting: a round clock inside the web interface. Since the round clocks are completely separate from the main program, (except for the tournament colors...) there's no way I can ask for the time and send it to the web server.
The fix for all this is to decrease the scope which the back-end has to work though. Right now, everything works on a program-basis; if I press the Pairings button, the program does a bunch of things on the program level, and tells other functions to get the info it needs before it finally goes into the window/printing system. What I want to change this to is a tournament-based system at the back-end. Meaning, what you see doesn't change all that much, but what actually is occurring behind-the-scenes is much different.
For example, when you say you want a timer for a tournament, right now a new one is simply spawned. In the new system, there will automatically be a timer associated with that tournament. If you haven't used it since opening the program, you get a new one. If it's opened already and behind windows, it'll just regain focus. If you closed it earlier and it was still running, it'll come back up as if it was never closed.
The huge benefit to this, though, for a timer (along with other parts) is that since the entire tournament's windows are managed through a single location, it's much easier to do something like get the time from the window, and stick that number somewhere where it would be accessible to EPIC.
The system will also benefit with better settings management. When you first go to a new tournament, the tournament will acquire default settings from the program defaults; however, if you change a setting, it'll be associated directly with that tournament and the windows in it. In essence, how "Tournament-Based Colors" works, but much more efficiently integrated and for fonts, background colors, etc.
7.13.2010
An EPIC demo...
Yes, I'm going to milk that acronym.
First, the bad news. This demo does not mean that I have found a suitable area with a database to make the Event Personal Information Center work in production. It means that I found a very high-latency, casual-use-only area to run larger-scale testing of this system. It means that I can work on code / database optimization, and work with both RTools and EPIC in order to make the whole system better.
The best reason to give for why I can't release this is that an update for my test event takes almost 5 minutes to transfer for online access. (for reference, it is a 103-person event in round 6) If I scale this, a 24-man FNM in round 3 would take over a minute, which is an amount of time that is unacceptable for me in advertising a program which should be making events faster.
So, this you can access this system here. It will ask you for a DCI#; unless you feel like guessing numbers, you can just use 12345678, which I setup (manually) to work as a real player in the one event which is currently setup in the web interface.
Again, the release of this as a full feature is primarily dependent on finding a server containing a SQL system and accessible from programs outside the server.
First, the bad news. This demo does not mean that I have found a suitable area with a database to make the Event Personal Information Center work in production. It means that I found a very high-latency, casual-use-only area to run larger-scale testing of this system. It means that I can work on code / database optimization, and work with both RTools and EPIC in order to make the whole system better.
The best reason to give for why I can't release this is that an update for my test event takes almost 5 minutes to transfer for online access. (for reference, it is a 103-person event in round 6) If I scale this, a 24-man FNM in round 3 would take over a minute, which is an amount of time that is unacceptable for me in advertising a program which should be making events faster.
So, this you can access this system here. It will ask you for a DCI#; unless you feel like guessing numbers, you can just use 12345678, which I setup (manually) to work as a real player in the one event which is currently setup in the web interface.
Again, the release of this as a full feature is primarily dependent on finding a server containing a SQL system and accessible from programs outside the server.
7.12.2010
RTools "1.1.0 preview" available
I've posted a link in the Downloads page to a preview release of RTools 1.1.0.
In my personal setup, this version is "1.1.0a9", the 9th alpha build. The version is as stable as any release I would give, but there are still interface tweaks and changes being made to it, as well as some feature additions still being finalized. For instance, between a8 and a9, the Timer stopped blinking on/off at 0:00; also popped in is a first-run build of a tool that prints out everything you need to run an 8-man draft side event. (have an 8-man draft tournament with pods made in Reporter, set the output to the printer, then Seating > Draft - Pod Seating)
The important thing about this release is that it is 64-bit ready, (as long as you have 32-bit Java) so if that is a problem for you, the solution is this update. The only UI-related change is that the "Pods" button is gone, replaced by the "Seat All" button on the top row, renamed "Seating". It now produces a drop-down which, when you are in an event with drafts, will conveniently have options appear for draft pod seating. See? No more button which is only conditionally usable :) It's good UI!
The documentation's also updated a bit, but that's not as newsworthy.
In my personal setup, this version is "1.1.0a9", the 9th alpha build. The version is as stable as any release I would give, but there are still interface tweaks and changes being made to it, as well as some feature additions still being finalized. For instance, between a8 and a9, the Timer stopped blinking on/off at 0:00; also popped in is a first-run build of a tool that prints out everything you need to run an 8-man draft side event. (have an 8-man draft tournament with pods made in Reporter, set the output to the printer, then Seating > Draft - Pod Seating)
The important thing about this release is that it is 64-bit ready, (as long as you have 32-bit Java) so if that is a problem for you, the solution is this update. The only UI-related change is that the "Pods" button is gone, replaced by the "Seat All" button on the top row, renamed "Seating". It now produces a drop-down which, when you are in an event with drafts, will conveniently have options appear for draft pod seating. See? No more button which is only conditionally usable :) It's good UI!
The documentation's also updated a bit, but that's not as newsworthy.
7.10.2010
"Wouldn't it be great if..." Ideas and Updates
I would say about 50% of the feature additions for RTools, beyond just the basic functionality, came from a sentence with this line in it.
Today, two new features were suggested to me, both of which make sense and are currently in varying stages development:
- Match Slips: DCIRv3 orders the sheets in increasing order, or in a way to make it so that cutting on a paper cutter gives you the slips already in order. WER has the former, but not the latter. RTools will fill this gap, and also increase the slip density to 5 per sheet. (plus, one or two other neat little things)
- Side Draft Printing: If you've judged as many single-elimination drafts as I have, you could be handed a bracket (or even just a player list) and be off, knowing player seating and everything you need to go. However, not every judge has done hundreds of these, and it takes a while in DCIRv3 to print out all the needed stuff. In WER, it's a bit worse, as there really isn't anything to do this. So, RTools will soon have some functionality added to print out a half sheet of paper, containing everything you need to run an 8-man single-elimination draft, including draft seating and a bracket, both prefilled.
The first internal (Madison) test for match slips will be this weekend, and the testing for side draft functionality will be after the match slips are finished.
Now, there's a lot of other things that I've been talking about in recent weeks in terms of future updates, and I want to just give a brief update as to where these features are.
- Seating updates: All these changes have been completed. There is one small bug which I am trying to figure out in regard to v4 and the random seating, but outside of that things are ready here.
- 64-bit: I made a post a little while back with information on getting beyond the roadblocks that RTools has with 64-bit Windows. Currently I can get RTools running flawlessly on a virtual Windows 7 x64 machine I have been testing the fixes with.
- EPIC: I added "Event" to the front of the "Personal Information Center" specifically because of the acronym, and because it's been the reaction many people have had when I have talked to them about just what this can already do, and even could do. Right now all the relevant code is in a very early stage, just because the walls that I need to overcome are more related to finding a suitable web server than coding issues. If I work on anything during this time, it will be database optimization.
The problem with sending tournament files from RTools to the web interface is that there's no way to look in the files and know that if a previous round match has been changed. For instance, if you're in round 4 and a round 2 match result needed to be changed, there's no way to tell whether that change has occurred. As such, the current system literally deletes the entire tournament on the web interface and re-sends everything.
The way that I will work this interface and "fix" this issue is to provide two options with the transfer: Quick and Full. Quick and Full will both update player information completely, (as the web interface doesn't calculate anything; they're sent calculated from the program) but the quick transfer will only update two rounds: the detected current round and the previous round. This will allow you to pretty much transfer every time your do a new round pairing, and both get the match results and the new pairings.
So, EPIC will be worked on as a bit of a side-project for now. I'll probably look to work as scorekeeper for a PTQ and test-run EPIC during that event on a custom server setup. This is really the big wait-and-see part of the program right now.
- Release Timeline: First beta sometime during the next week. Full release should still be in the area of GenCon.
Today, two new features were suggested to me, both of which make sense and are currently in varying stages development:
- Match Slips: DCIRv3 orders the sheets in increasing order, or in a way to make it so that cutting on a paper cutter gives you the slips already in order. WER has the former, but not the latter. RTools will fill this gap, and also increase the slip density to 5 per sheet. (plus, one or two other neat little things)
- Side Draft Printing: If you've judged as many single-elimination drafts as I have, you could be handed a bracket (or even just a player list) and be off, knowing player seating and everything you need to go. However, not every judge has done hundreds of these, and it takes a while in DCIRv3 to print out all the needed stuff. In WER, it's a bit worse, as there really isn't anything to do this. So, RTools will soon have some functionality added to print out a half sheet of paper, containing everything you need to run an 8-man single-elimination draft, including draft seating and a bracket, both prefilled.
The first internal (Madison) test for match slips will be this weekend, and the testing for side draft functionality will be after the match slips are finished.
Now, there's a lot of other things that I've been talking about in recent weeks in terms of future updates, and I want to just give a brief update as to where these features are.
- Seating updates: All these changes have been completed. There is one small bug which I am trying to figure out in regard to v4 and the random seating, but outside of that things are ready here.
- 64-bit: I made a post a little while back with information on getting beyond the roadblocks that RTools has with 64-bit Windows. Currently I can get RTools running flawlessly on a virtual Windows 7 x64 machine I have been testing the fixes with.
- EPIC: I added "Event" to the front of the "Personal Information Center" specifically because of the acronym, and because it's been the reaction many people have had when I have talked to them about just what this can already do, and even could do. Right now all the relevant code is in a very early stage, just because the walls that I need to overcome are more related to finding a suitable web server than coding issues. If I work on anything during this time, it will be database optimization.
The problem with sending tournament files from RTools to the web interface is that there's no way to look in the files and know that if a previous round match has been changed. For instance, if you're in round 4 and a round 2 match result needed to be changed, there's no way to tell whether that change has occurred. As such, the current system literally deletes the entire tournament on the web interface and re-sends everything.
The way that I will work this interface and "fix" this issue is to provide two options with the transfer: Quick and Full. Quick and Full will both update player information completely, (as the web interface doesn't calculate anything; they're sent calculated from the program) but the quick transfer will only update two rounds: the detected current round and the previous round. This will allow you to pretty much transfer every time your do a new round pairing, and both get the match results and the new pairings.
So, EPIC will be worked on as a bit of a side-project for now. I'll probably look to work as scorekeeper for a PTQ and test-run EPIC during that event on a custom server setup. This is really the big wait-and-see part of the program right now.
- Release Timeline: First beta sometime during the next week. Full release should still be in the area of GenCon.
RTools - 64-bit update (Fix included!)
Alright, I have a (virtual) machine on my computer which I have been using to try to find a fix for this, and I have a pair of things which will fix the two separate problems: one from my side and one from yours.
- My fix: taking care of the program not loading at all.
A beta release for 1.1.0 will be available in the next few days. Everything in the program that worked in 1.0.0 has not changed in 1.1.0, so upgrading shouldn't affect how current 1.0 features work. This version will, among other things, be using a different "jar wrapper" program which works fine in 64-bit Windows. And, as said earlier, it brings the program size down quite a bit, down to 200kb.
- Your fix: The database-connection issue for v4.
The fix for this is to have _only_ 32-bit Java installed on your machine. This can be done in no greater than two steps:
1: Go to your Control Panel -> Add/Remove Programs (Control Panel -> Programs in Win7) and see if there an entry along the lines of "Java (64-bit)". (the 64-bit is the important part) Uninstall this.
2: If there is not an entry still there for "Java" that doesn't say 64-bit, go here and download 32-bit Java. (Select "Windows" and NOT "Windows 64-bit" from the Platform drop-down)
Now, there looks to be a more permanent fix for this latter issue. However, it would require some two things for me to do:
- Pack RTools into an installer system, as I would need to run a command-line command that would make the WER database accessible by a Java program.
- Learn how to use a particular program's command-line interface.
Realistically, this looks like it'll be roadmapped for v.1.3ish, mostly because the issue isn't really a 100% dealbreaker now that I have a pretty solid understanding of what is really going on.
- My fix: taking care of the program not loading at all.
A beta release for 1.1.0 will be available in the next few days. Everything in the program that worked in 1.0.0 has not changed in 1.1.0, so upgrading shouldn't affect how current 1.0 features work. This version will, among other things, be using a different "jar wrapper" program which works fine in 64-bit Windows. And, as said earlier, it brings the program size down quite a bit, down to 200kb.
- Your fix: The database-connection issue for v4.
The fix for this is to have _only_ 32-bit Java installed on your machine. This can be done in no greater than two steps:
1: Go to your Control Panel -> Add/Remove Programs (Control Panel -> Programs in Win7) and see if there an entry along the lines of "Java (64-bit)". (the 64-bit is the important part) Uninstall this.
2: If there is not an entry still there for "Java" that doesn't say 64-bit, go here and download 32-bit Java. (Select "Windows" and NOT "Windows 64-bit" from the Platform drop-down)
Now, there looks to be a more permanent fix for this latter issue. However, it would require some two things for me to do:
- Pack RTools into an installer system, as I would need to run a command-line command that would make the WER database accessible by a Java program.
- Learn how to use a particular program's command-line interface.
Realistically, this looks like it'll be roadmapped for v.1.3ish, mostly because the issue isn't really a 100% dealbreaker now that I have a pretty solid understanding of what is really going on.
7.09.2010
The Anime Watchlist - July 2010
Finished Series / Watched Movies
---
Fullmetal Alchemist: Brotherhood
Better than the original, though the climax is so much better in the original than this version. When this series was in the early 30s for episodes, I wrote that there seemed to be too many subplots and wandering groups ("Inuyasha Syndrome") forming; it fixed itself as the series moved on, but it somewhat fell flat right at the end, when the pace needed to be shifted between different kinds of climaxes, and then somewhat just jammed together into the final sequence.
Last three episodes were amazing, though.
New Series
---
Hey, look, first season since Sora no Woto that I'm picking up newly-made shows, and the first since Bakemonogatari that I'm doing more than one.
Highschool of the Dead
Ok, if you haven't watched any of this yet, it's essentially a fanservice show. However, it proves that almost any series is made infinitely better just by throwing in "during a zombie apocalypse" to the synopsis. But, no matter how much the fanservice is glaring -- and it's surprising just how glaring it is -- the OP/ED alone makes up for it. The rest is just entertainment gravy.
Occult Academy
Now, I was the antithesis of sold on this series after the first episode, but sooo many people are telling me how good this series should be that I can't help but to keep rolling with it for a while.
I also intend on picking up either Mitsodomoe or Ookami and the Seven Companions from this season; I'm too epic-ed out from HOTD to start either at the moment.
Actively Watching
---
None.
Passively Watching
---
Bakemonogatari, Shakugan no Shana S
Both of these fall under the "there hasn't been anything new for a while" banner, though technically I think both are actually complete through their OVA/internet releases. Haven't gotten around to checking that out...
Naruto: Shippuuden
Yeah, I'm about 80 episodes behind at this point; I should really look at marathoning this thing sometime, as I haven't heard anything bad about the direction the series is moving.
Bleach
Here's my problem: I finished the filler arc, and am still reading the manga as it's being released. The series got back to the story, and it just seems a little boring in comparison to where the manga has already reached. So, I'm a little slow here.
To Aru Kagaku no Railgun
I'm actually stalled right after the first arc here; I've pretty much just randomly been watching one or two episodes of this at a time; not much to say about it, though I want to get to the end, as there's supposedly a season 2 greenlit.
Dropped
---
Nada.
Looking forward to...
---
Umineko Chiru still. I'm hearing rumblings that the fall lineup is supposed to be relatively insane for releases, though I'll wait and see on that. There's also a couple series that I'm thinking of plowing through, because I keep hearing the second season is among the best in anime, but you need to get through a dull first season first...
---
Fullmetal Alchemist: Brotherhood
Better than the original, though the climax is so much better in the original than this version. When this series was in the early 30s for episodes, I wrote that there seemed to be too many subplots and wandering groups ("Inuyasha Syndrome") forming; it fixed itself as the series moved on, but it somewhat fell flat right at the end, when the pace needed to be shifted between different kinds of climaxes, and then somewhat just jammed together into the final sequence.
Last three episodes were amazing, though.
New Series
---
Hey, look, first season since Sora no Woto that I'm picking up newly-made shows, and the first since Bakemonogatari that I'm doing more than one.
Highschool of the Dead
Ok, if you haven't watched any of this yet, it's essentially a fanservice show. However, it proves that almost any series is made infinitely better just by throwing in "during a zombie apocalypse" to the synopsis. But, no matter how much the fanservice is glaring -- and it's surprising just how glaring it is -- the OP/ED alone makes up for it. The rest is just entertainment gravy.
Occult Academy
Now, I was the antithesis of sold on this series after the first episode, but sooo many people are telling me how good this series should be that I can't help but to keep rolling with it for a while.
I also intend on picking up either Mitsodomoe or Ookami and the Seven Companions from this season; I'm too epic-ed out from HOTD to start either at the moment.
Actively Watching
---
None.
Passively Watching
---
Bakemonogatari, Shakugan no Shana S
Both of these fall under the "there hasn't been anything new for a while" banner, though technically I think both are actually complete through their OVA/internet releases. Haven't gotten around to checking that out...
Naruto: Shippuuden
Yeah, I'm about 80 episodes behind at this point; I should really look at marathoning this thing sometime, as I haven't heard anything bad about the direction the series is moving.
Bleach
Here's my problem: I finished the filler arc, and am still reading the manga as it's being released. The series got back to the story, and it just seems a little boring in comparison to where the manga has already reached. So, I'm a little slow here.
To Aru Kagaku no Railgun
I'm actually stalled right after the first arc here; I've pretty much just randomly been watching one or two episodes of this at a time; not much to say about it, though I want to get to the end, as there's supposedly a season 2 greenlit.
Dropped
---
Nada.
Looking forward to...
---
Umineko Chiru still. I'm hearing rumblings that the fall lineup is supposed to be relatively insane for releases, though I'll wait and see on that. There's also a couple series that I'm thinking of plowing through, because I keep hearing the second season is among the best in anime, but you need to get through a dull first season first...
7.08.2010
RTools 1.0.0 and 64-bit Windows - A Second Issue...
I'm not going to get into as much detail into this as the first post's explanation, but there is actually a second roadblock to getting RTools working on 64-bit Windows, though this one is specifically in regards only to WER-related needs; in the current system, v3 works fine under 64-bit Windows with modifications to fix the first 64-bit issue.
The issue is in regards to the back-end database that is used in WER and how Java connects to it. In short, it uses a library that is present by default in x86 Windows, but not in x64. So, when RTools tries to connect to WER's database, it gets back an error saying that no valid connection method was chosen in the code.
So, how does this get fixed? I'm still looking into this one; there's a route that involves some pretty steep licensing costs, but I'm looking for specific methods to do this without needing to ship additional libraries with RTools. (or pay a licensing fee of almost $1000)
Here's one plus, though: In the current alpha version with the new wrapping process, the size of the program has dropped almost 60%.
The issue is in regards to the back-end database that is used in WER and how Java connects to it. In short, it uses a library that is present by default in x86 Windows, but not in x64. So, when RTools tries to connect to WER's database, it gets back an error saying that no valid connection method was chosen in the code.
So, how does this get fixed? I'm still looking into this one; there's a route that involves some pretty steep licensing costs, but I'm looking for specific methods to do this without needing to ship additional libraries with RTools. (or pay a licensing fee of almost $1000)
Here's one plus, though: In the current alpha version with the new wrapping process, the size of the program has dropped almost 60%.
7.06.2010
RTools 1.0.0 and 64-bit Windows
There's been a couple reports of RTools having a really random issue that shows up specifically when you run the program; the program brings up the "What Version" window, then doesn't do anything and seems to just quit.
The issue has been localized to a program that I use in relation to the creation of RTools releases, and 64-bit versions of Windows. RTools itself is written in Java, and Java programs, by default, produce files that end in '.jar' when setup to be a runnable application. If you check, though, you'll see that RTools uses the '.exe' extension, which is many times more common for programs.
Early in development, I decided to use what's called a "wrapper program" on RTools; this program takes the .jar program and wraps it in a .exe file. The primary reason is so that Windows treats RTools like a normal program, instead of .jar, which can be mistaken for an archive file. There's a few extra benefits to this:
- The wrapper checks if Java exists on the computer, and gives you the option to download it through the program if you haven't already.
- The wrapper obfuscates the program code. Unobfuscated .jar files can be decompiled with relative ease, to the point where people can read the code I've written; this can go much further, to where someone could copy all the code without my knowledge and released as a new program.
This wrapper program has a slight issue, however, in that the program doesn't make the created .exe program in a way that is compatible with 64-bit versions of Windows. This actually made trying to find this issue more difficult, as the first time I experimented with this issue on a 64-bit Windows 7 machine, I was working through the development environment I was coding in to try to isolate the problem, and as such was not working with release (.exe) program under the wrapper.
I'm currently looking through a couple options for fixing this; the three immediate options in my mind are:
- Find a new .exe wrapper program that is 64-bit compatible
- Obfuscate the Java program and release a .jar program instead of a .exe
- Do the same as above, but also release a custom .exe program (in C++) that does nothing but launches the obfuscated RTools .jar. (the upside being that nothing changes in how a person finds and uses the program, the downside being that updating would slightly more complicated)
There will be a 1.0.1 update when this is done which fixes this issue. This issue will also be fed into the 1.1 update.
Sidenote: The way things look right now, there would be too many questions and issues in regards to setting up the EPIC (Event Personal Information Center) code until I can setup a personal server to run this back-end stuff. As a result, I'm probably leaving EPIC out of the 1.1 release, instead releasing 1.1 as an update to the seating visuals, some new utilities, and a bugfix rollup.
The issue has been localized to a program that I use in relation to the creation of RTools releases, and 64-bit versions of Windows. RTools itself is written in Java, and Java programs, by default, produce files that end in '.jar' when setup to be a runnable application. If you check, though, you'll see that RTools uses the '.exe' extension, which is many times more common for programs.
Early in development, I decided to use what's called a "wrapper program" on RTools; this program takes the .jar program and wraps it in a .exe file. The primary reason is so that Windows treats RTools like a normal program, instead of .jar, which can be mistaken for an archive file. There's a few extra benefits to this:
- The wrapper checks if Java exists on the computer, and gives you the option to download it through the program if you haven't already.
- The wrapper obfuscates the program code. Unobfuscated .jar files can be decompiled with relative ease, to the point where people can read the code I've written; this can go much further, to where someone could copy all the code without my knowledge and released as a new program.
This wrapper program has a slight issue, however, in that the program doesn't make the created .exe program in a way that is compatible with 64-bit versions of Windows. This actually made trying to find this issue more difficult, as the first time I experimented with this issue on a 64-bit Windows 7 machine, I was working through the development environment I was coding in to try to isolate the problem, and as such was not working with release (.exe) program under the wrapper.
I'm currently looking through a couple options for fixing this; the three immediate options in my mind are:
- Find a new .exe wrapper program that is 64-bit compatible
- Obfuscate the Java program and release a .jar program instead of a .exe
- Do the same as above, but also release a custom .exe program (in C++) that does nothing but launches the obfuscated RTools .jar. (the upside being that nothing changes in how a person finds and uses the program, the downside being that updating would slightly more complicated)
There will be a 1.0.1 update when this is done which fixes this issue. This issue will also be fed into the 1.1 update.
Sidenote: The way things look right now, there would be too many questions and issues in regards to setting up the EPIC (Event Personal Information Center) code until I can setup a personal server to run this back-end stuff. As a result, I'm probably leaving EPIC out of the 1.1 release, instead releasing 1.1 as an update to the seating visuals, some new utilities, and a bugfix rollup.
Subscribe to:
Comments (Atom)