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)