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.
Subscribe to:
Comments (Atom)