Thread history
Viewing a history listing
| Time | User | Activity | Comment |
|---|---|---|---|
| 01:27, 31 January 2013 | Chase-san (talk | contribs) | New thread created | |
| 01:28, 31 January 2013 | Chase-san (talk | contribs) | Comment text edited | |
| 01:28, 31 January 2013 | Chase-san (talk | contribs) | Comment text edited | |
| 20:25, 16 February 2013 | Chase-san (talk | contribs) | New reply created | (Reply to Version 0.9.6) |
| 00:52, 17 February 2013 | Chase-san (talk | contribs) | New reply created | (Reply to Version 0.9.6) |
| 00:56, 17 February 2013 | Chase-san (talk | contribs) | Comment text edited | |
| 03:04, 17 February 2013 | Voidious (talk | contribs) | New reply created | (Reply to Version 0.9.6) |
| 09:31, 17 February 2013 | Chase-san (talk | contribs) | New reply created | (Reply to Version 0.9.6) |
Updating the result windows on the fly doesn't seem like it would be particularly difficult. But I don't know the structure of your code at the moment, so I could be wrong.
Assuming a singular method that displays the windows given a result set.
a la "void showResultsWindow(resultSet)", could make it "ResultWindow showResultsWindow(resultSet)", keep it in a map "HashMap<ResultSet,ResultWindow>", and update the window based on updates in the set "ResultWindow window = map.get(resultSet); window.updateData(resultSet); window.markTableDirty();"
Mark table dirty would be this piece of thread safe code "RepaintManager.currentManager(table).markCompletelyDirty(table);"
Keeping the window in a map also allows you to just move that window to the front if someone tries to open the same result window twice. Though you make require a listener to determine if the window was closed, so you can remove it from the hashmap. Just hiding it could be problematic if someone keeps the application open for a long time and runs many different challenges.
It would be nice to have a season counter as well. That you can see without getting the wiki output.
Also I saw the logo in about, and my eyes bled. So here is a doodle.
Also before I forget. You should have it do at least 3-4 battles per bot before 'smart' battles kick in. This is just in case you got two flukes in a row. Where as 3-4 in a row become considerably less likely. I only mention this because I just got two flukes in a row (a really high score at that).
It does sprinkle in random battles among the bots with lowest battles. I didn't want to do 3-4 for everyone up front because that largely nullifies the usefulness of smart battles if you're doing 500 bot test beds. But as it is, if you're running several thousand, everyone will get to 3 or 4 at least, I'm pretty sure.
