RTools 1.1.0b1 and 2.0.0a1 posted.

Published / by bradleyjx

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…

RTools – How 2.0 works…

Published / by bradleyjx

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 – The July 2010 Roadmap

Published / by bradleyjx

— 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.

An EPIC demo…

Published / by bradleyjx

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.

RTools “1.1.0 preview” available

Published / by bradleyjx

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.

“Wouldn’t it be great if…” Ideas and Updates

Published / by bradleyjx

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.

RTools – 64-bit update (Fix included!)

Published / by bradleyjx

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.

The Anime Watchlist – July 2010

Published / by bradleyjx

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


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.

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.



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…

RTools 1.0.0 and 64-bit Windows – A Second Issue…

Published / by bradleyjx

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%.

RTools 1.0.0 and 64-bit Windows

Published / by bradleyjx

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.