New Blog Site: http://www.bradleyjx.net/
New Email: shizu@bradleyjx.net
1.24.2014
11.17.2010
New Blog Location + Contact Information
New Blog Site: http://blog.bradleyjx.net/
New Email: bjx@bradleyjx.net
New Email: bjx@bradleyjx.net
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 :)
Subscribe to:
Comments (Atom)