Talk:Darkcanuck/RRServer

Initial Discussion

Fire away...

Just a suggestion for an additional check. I have never seen score a bot more than 8000 points, so this could be checked too. When examining the results that messed up the original roborumble rating beyond repair, I saw results of 20000 against 16000 (Thats what you get when running OneOnOne with MELEE=YES). For the time being I let my client running (unattended) for ABC's server, as I don't really have the time for bughunting. Your effort however seems promising. Good luck. -- GrubbmGait

• Thanks! That's a good check, will be combining that with the survival >=35 (also your suggestion I think) once I rearrange the error handling and failure output to the client. Then I'll look into ELO... --Darkcanuck
• Your checks have both been implemented. -- Darkcanuck

Looking very nice! I have a couple questions and thoughts I thought I'll mention. So what is this "Ideal" column in the results mean? One thought I had about ratings, is perhaps it would be best to make the APS fill missing pairings with Glicko-based estimates? I'm thinking that would give the best long term stability/accuracy once pairings are complete while having something a more meaningful before pairings are complete before the pairings are complete. --Rednaxela 01:18, 26 September 2008 (UTC)

Thanks! I've just posted a bit more about ratings here. The "Ideal" column is my attempt to reverse calculate a rating based on a bot's APS. I just inverted the Glicko formula for "E" (expected probability) to yield a rating given if given E (i.e. APS) and a competitor's rating and RD. For the latter two I used the defaults (1500 and 350) so theoretically if the APS represents the score vs an average bot (and there's a uniform distribution?) then the rating might converge to the "ideal" value. But I have no idea if it works, just wanted to see how close it might be. I'm not sure you could fill in the pairings using Glicko + APS -- the reason systems like Glicko exist is to get around the problem of incomplete pairings, so the Glicko rating should be enough in itself. If it's accurate, that is -- we'll see once the ratings catch up to the pairings already submitted... -- Darkcanuck 03:39, 26 September 2008 (UTC)

Ahh, I see. Thanks for the explanation. If the Glicko rating doesn't converge very very close to the "Ideal" then I'd say it alone might not be the best fit alone for Robocode due to how complete pairings are not hard to get. The reason I suggest using APS and filling missing pairings with Glicko-based percent estimates, is because my proposed method will be guaranteed to always converge to an exact APS ranking order when pairings are complete, and would quite surely be at least slightly better than APS when pairings are not complete. Perhaps I'm more picky than most, but I'd consider a hybrid necessary if "Glicko" doesn't in practice converge to "Ideal" to within an accuracy that preserves exact rankings with APS (which I think is very plain and simple the most fair when there are complete pairings). I suppose we'll see how accurately Glicko converges :) --Rednaxela 04:25, 26 September 2008 (UTC)

Be careful about the "ideal" convergence concept! Keep in mind that I made this value up and it doesn't really have a statistical basis of any sort. I was just curious what a naive reversal with a single data point might produce, in order to get an idea of what neighbourhood DrussGT's rating might be in, for example. I also wanted to get a sense whether I had programmed the formulas correctly. I wonder though, if we're abusing these rating systems by using %score instead of absolute win/lose values (1/0)? Would the Glicko rating converge more rapidly to match the APS scale if I had chosen win/loss? I'm very curious, but no so much as to interrupt the current rebuild, which may take longer than I thought. -- Darkcanuck 04:54, 26 September 2008 (UTC)

Well, I'm not talking about the convergence to that "Ideal" column. I'm talking about convergence of the relative rankings as opposed to specific rating numbers. If the rankings, don't converge to exactly the same order as APS, then I think there's issue enough to justify a hybrid that uses APS, with ELO or Glicko to estimate missing pairings. --Rednaxela 05:10, 26 September 2008 (UTC)

Gotcha. I suppose you could keep track of the rating (Elo or Glicko) and just use it to calculate expected scores for missing pairings. Then generate an estimated APS for full pairings. We'll have to see how well the ratings stabilize. I'm thinking I should have used Glicko-2 instead, since it includes a volatility rating to account for erratic (read problem bot) performance. -- Darkcanuck 06:22, 26 September 2008 (UTC)

Started sending the results to your server, as long as you relay them to ABC's server. What is the delay btw? --GrubbmGait 10:08, 26 September 2008 (UTC)

Thanks for joining in! I have no plans to stop relaying results and have been doing so for almost a week now. If by "delay" you mean occasional slow connections, it's due to the scoring update and I've posted it on the known issues page. I have this process cranked up at the moment while I try to get the ratings to catch up, but it will get faster soon. :) -- Darkcanuck 15:25, 26 September 2008 (UTC)

Great job with his server, you can always get the ranking/battles_* files from my server and sumbit them all into yours. I'm also experimenting with mySql atm. My SQL skills are a little rusty but it's all coming back pretty fast :).

I also have a few doubts about the new ranting method. The first one is: why? From what I understand Glicko is an ELO extension for rankings where the match frequency is not uniform between participants, which is not the rumble's case? As an experiment it's very cool, but for me the "old" ELO method is time tested and proven to work great, and should be the default sorting method for the ranking table. --ABC 11:23, 26 September 2008 (UTC)

I also have some doubts about if Glicko will actually give better or much different results than ELO, however I'm not sure ELO is really the best default ranking system when full pairings are easiest to get. I suppose we'll see once your server gets to full pairings, but I'm strongly suspecting there will be some ranking deviations from the APS ranking, which I think is hard to argue is in any way biased. --Rednaxela 13:26, 26 September 2008 (UTC)

I have doubts as well, but I wouldn't have known until I tried it. My major objection against Elo is the lack of a clear, published implementation. It was easier to implement Glicko than to sort through the RR server code. If someone can clarify this for me, sure I'll try it out. Why not? -- Darkcanuck 15:25, 26 September 2008 (UTC)

Bravo

I just want to leave a note saying you're awesome. :) It's really nice having someone put effort into improving the rumble itself. Good work! --Simonton 03:27, 11 October 2008 (UTC)

Oh, and FNL, if you're reading this, that goes double for you :). --Simonton 03:30, 11 October 2008 (UTC)

Style

Do you think you or I could restyle the page, some basic css could go a long way to making the page look more modern and less of an eyesore. An example of my work is here, though it wouldn't look like my page there but it will be clean (and it will validate). Currently its not even setup as a webpage. Which means it will render in quarks mode by all browsers, which is a very slow and cpu intensive rendering mode.

In fact there is alot you can do to both reduce html elements and increase rendering speed. Such as changing the <td><b> combo into just <th> tags, because thats what they are for <td> = table data, <th> = table header, with some css you can justify thier alignment, it wouldn't require much css, as such alot of css is actually undesirable in a simple page such as this, but css is perferred over tags because it is actually faster in most cases (very old or poorly designed browsers being the exception).

Chase-san 08:02, 14 October 2008 (UTC)

• I very strongly agree! It's on the roadmap, but I've focused on the data side first. The current "pages" were based on a view-source from the old server. A little css and valid xhtml would go a long way. I also want to switch to a template system (maybe Smarty or Zend?) for easier reading and better reuse -- having html mixed in with php makes for some very ugly code. If you want to style some static content and send it to me, that would be great! --Darkcanuck 15:04, 14 October 2008 (UTC)

xhtml is very nice, while most browsers support true xhtml (except IE and Konqueror), the ones that do not, control a large enough majority where it would have to be described as text/html anyway. This mitigates the real purpose of an xhtml page but is nice to have the framework in place for when they catch up (all the work that would have to be done is switching the content type). I think using Smarty or Zend is overkill unless you plan on extending the system further and I only suggest them only if you plan on doing something like roborumble.org. They are template engines, meaning you would have to make templates for them, which jsut adds alot of extra overhead on something simple like this. Remember KIS, keep it simple. --Chase-san 21:36, 14 October 2008 (UTC)

If you really want a really nice super-quick super-simple "template engine" I suggest you consider this. Instead of bothering with special "template" languages, you write your templates just in PHP, and all the "template engine" does is set up variables making really clean shorthand like <?=$title;?> all that's needed to put some variable in the template. I once tried it when hacking around and found it to be a really nice KIS approach to "template engines". Also the author put the code there in public domain, so there are no issues using it in here as we see fit. --Rednaxela 03:47, 15 October 2008 (UTC)

I at one point designed my own KIS template system, it was simular to others except that the content to replace was in {}, for example {title} and then for other parts I did things like <table>{row_start}<tr><td>{row_num}</td><td>{row_data}</td></tr>{row_end}</table>. All this was kept in a seperate file and required parsing, but otherwise was fairly simple that it was a template engine but also it only used half a dozen commands and you used the functions to fill in the data. I will see if I can locate it or remake it if you like the sound of using a template but still want to keep it very simple. --Chase-san 22:41, 15 October 2008 (UTC)

Thanks for the suggestions guys, but I'm sticking to my original plan (Smarty). If the template engine ever becomes the bottleneck, then I'll look into something custom. --Darkcanuck 02:13, 16 October 2008 (UTC)

Okay, cool. I would like to work on a template for the actual score page then, I am great at css and making it cross-compatible with other browsers (namely IE, Firefox, and Safari (I use Opera, so obviously it will work for that too)). Unlike making robots, web pages are not very time consuming. Do you have any kind of messenger we could talk (I have or can get any of them) --Chase-san 04:08, 16 October 2008 (UTC)

Excellent! Don't use messenging much, and I'm currently travelling at the moment so email is better: jerome-at-darkcanuck-net --Darkcanuck 23:43, 16 October 2008 (UTC)

Team Rankings

Is it an idea to get the battles for teams from Pulsars server? I think they have no weird results, and your ranking will at least have a teamranking then. --GrubbmGait 17:57, 24 October 2008 (UTC)

Good idea! I'll grab the battle file, but need to figure out how to exclude older team versions to keep the server load down. --Darkcanuck 01:58, 25 October 2008 (UTC)

Table Sorting

Very nice things things lately! I do have a couple little gripes though. One thing, is I think it would be more natural if first click does 'highest-first' unlike how TableSorter seems to operate by default. Secondly... ugh... it's so damn slow to sort. Even on my fairly modern system there's a very ugly delay when sorting the table (a 20 year old machine could sort the data faster with static code probably... not everyone uses Google Chrome or an experimental FF build) and I imagine this would become a very annoying delay on anything older. Not only is the JS sorting slower than server-side but there's no indication of it processing/loading which irks me a little. Perhaps if the JS sorting is stuck there should be a little line or two of code to makebo a 'loading...' indicator of some sort? In any case, great work lately! --Rednaxela 21:39, 26 October 2008 (UTC)

The problem with javascript when sorting big tables is not the sorting in itself but the big number of DOM document chand hges when you generate the resulting table HTML. I'm currently developing a small javascript application at work that sorts a table of around 500 entries pretty much instantaneously. It only shows the top 5 entries as a table (similar to DC targeting, curiously :)), if I generate the 500 rows it becomes very slow. --ABC 23:14, 26 October 2008 (UTC)

After some reading, I found that apparently TableSorter's slowest part, is how it READS the data from the DOM every time you sort. Perhaps a more efficent method would be to send the data in both HTML form and JSON form, and let the script change the order of the rows in the DOM based on the data efficently parsed from the JSON and stored in the JS memory. I think that model would have the fewest DOM operations and thus be the most efficent way to do client-side sorting. On a related but diverging note... once at that point, it might not be that much more work to do 'live' score updates... (which would also reduce bandwidth use in the face of mad-refereshers). I may be tempted to try and code such a fancy efficent-sorting live-updating score view some time... --Rednaxela 00:19, 27 October 2008 (UTC)

Well, it's faster than re-requesting the page, which the old sort did. :) But if you find a way to speed it up, I'm all ears -- javascript is pretty new to me. I don't like the default sort order either, but there didn't seem to be an option to start with a descending sort. The Glicko columns are also a little weird due to the RD value in brackets. I'm not sure I follow the bit about "live updates" though, the current pages are as live as you can get. Scores are updated every time a new result is uploaded. --Darkcanuck 05:47, 27 October 2008 (UTC)

Actually, I'm finding it very distinctly slower than re-requesting the whole page (of course my campus internet here is pretty damn fast). Well, I think it certainly be sped up by methods like I said above with sending the data in JSON form and keeping in JS memory, though it would likely involve using our own code instead of TableSorter (or mangling TableSorter considerably beyond recognition). And what I mean by "live updates", would be using "AJAX" stuff to every minute or so ask the server if there have been any more recent updates, the server sends any in JSON form and the results page gets updated without refreshing. --Rednaxela 12:35, 27 October 2008 (UTC)

Contributors

Just another small idea, can you distinguish the contributors per month? Long time ago, late 2004 I think, we had a sortof ranking of contributors when rebuilding the rankins after a servercrash. (He, sounds familiar . . ) This way 'new' contributors see their names without the need to scroll way down. Also: every ranking is a competition ;) --GrubbmGait 19:00, 28 October 2008 (UTC)

Are you saying you don't like my score of 410,000+? ;) (melee is the key to high numbers, btw) Good idea to split the numbers out in more detail. I guess I could add some more columns to the users table to make some rolling counts. What interval would be best: once per day to keep a 30-day window, or start fresh every month to make a new competition? --Darkcanuck 05:40, 29 October 2008 (UTC)

Well I personally think "once per day to keep a 30-day window" would be best for being a more meaningful and current reflection of things, but starting fresh each month would be best if we want to have something like a 'monthly rumble contributor award'. Of the tradeoff, I'm leaning to the former myself. Of course, if we really wanted we could just track both :) --Rednaxela 14:53, 29 October 2008 (UTC)

Ok, we now have current month and last-30-days upload rankings, split by game type. I've tried to scale the melee numbers to match the actual number of battles run (45 pairings uploaded per battle?). Hopefully someone will start to submit team battles (can't get my client to work). --Darkcanuck 23:51, 30 November 2008 (UTC)

Partecipant list

Can you please create a mirror of the official participant's list on your server (updated automatically)? That's good if the official page is off-line, like now ^-^ --Lestofante 22:05, 1 Dic 2008 (UTC)

Try this: http://darkcanuck.net/rumble/particip1v1.txt . I just uploaded my copy to the server and added the 'pre' tags the rumble client is looking for. Once the old wiki comes back I'll try mirroring all of the participant lists -- shouldn't be difficult, just a daily 'wget'... --Darkcanuck 03:35, 2 December 2008 (UTC)

Thank, now my client work. Here the modify: PARTICIPANTSURL=http://darkcanuck.net/rumble/particip1v1.txt. For the mirroring system just don't use only a wget but use a little script that control the integrity of the list.--lestofante 09:37, 2 December 2008 (UTC)

Survival

One thought is, now that removing the Glicko-1 column has cleared up a little space... maybe those survival percents that are in the details pages could be included? I think it would be nice to be able to easily see what bots are strong survivalists ;-) --Rednaxela 23:42, 2 December 2008 (UTC)

Too easy! :) --Darkcanuck 04:53, 3 December 2008 (UTC)

Nice. Now just to wait for all the bots to return so I can see how good 'RougeDC survival' really ranks in that... :) --Rednaxela 05:05, 3 December 2008 (UTC)

It could be a long wait -- reactivation is just as slow as removal. But at least clients won't be fighting over the two. --Darkcanuck 05:13, 3 December 2008 (UTC)

Aye, but at least based on the rate at which my client is currently uploading bots of which some need to be reactivated, I think there's a good chance it may be back to normal in less than 12 hours from now. --Rednaxela 05:29, 3 December 2008 (UTC)

"Suspicious Battle List"

One thought I had is that bad 0 scores could be filtered by taking a look at the expected score, and discarding 0 results where it they seem unreasonable. Of course, an alternative to automatic rejection, would be making a "suspicious battle list" page that could be watched for manually initialting removals. I would imagine it would take no more than a single SQL statement of moderate complexity to list suspicious uploads. --Rednaxela 06:25, 29 December 2008 (UTC)

Neat idea. Although bots which throw the occasional exception may get a lower than expected score once in a while. Rather than run a query against the battles table, the server could flag battles as they're submitted if the score deviates too far from the expected value. What do you think a good range would be, considering some bots have very high PBI's? --Darkcanuck 06:48, 29 December 2008 (UTC)

Well I think running a query against the battles table is necessary due to the number of bad results that are already in the server, which I'd consider quite important to fix and manually searching for all of them would be time intensive. As far as what kind of deviation? Well because of such high PBI cases I'd say something roughly like the following would be good. Flag them if: 1) The battle deviates from the Glicko-2 expected result by more than 50, or 2) The battle deviates from any results submitted by *other* clients by more than 30, or 3) The score is exactly 0 when the expected score is anything greater than 20
Of course, I strongly believe we can't get a really strong idea of exactly what thresholds are good until we to do some queries on the battles database to determine what level of sensetivity is most correct. --Rednaxela 07:07, 29 December 2008 (UTC)

Rednaxela has a good suggestion; I second the motion. I've been seeing the occasional outlier where one or the other bot in a 1v1 match gets 0% bullet score over 35 matches, then in a second battle from the same uploader, it gets a more reasonable score. Results like those would be easily detected with the mechanism proposed above. -- Synapse 00:39, 20 June 2009 (UTC)

Please make a note of these as you see them so we can take a closer look. --Darkcanuck 02:55, 20 June 2009 (UTC)

apv.TheBrainPi 0.5 vs synapse.Geomancy 1 -- Synapse 05:46, 20 June 2009 (UTC)

synapse.Geomancy 1 vs elvbot.ElverionBot 0.3 -- Synapse 05:46, 20 June 2009 (UTC)

See Talk:Geomancy for a continuation of this discussion.

I like this idea, but for 2) it might be a problem if the bad battle is submitted first, and it causes all subsequent battles from other clients to be ignored. Instead a decision should be made, if there is a deviation between battles of more than 30%, which battle is the bad one. --Skilgannon 01:52, 20 June 2009 (UTC)

Well, about #2, I said "*other* clients" in plural. What I meant, was that it would only trigger the #2 check if there were multiple distinct clients that gave a result rather different than an outlier. --Rednaxela 02:19, 20 June 2009 (UTC)

Eventually I'd like a system where users can flag any battle to add it to a suspect battles list. Then we can figure out what to do with them. Although this may be quite difficult given randomness, bots which throw the occasional exception (eg. DogManSPE) and the fact that every large real-world system has outliers.

Well yes, this is why I say "suspect battles list" as opposed to "automatically remove". As far as cases like DogManSPE, well, we could check a bot's tendency to have "outlier" battles overall, and use that as a "baseline". If that baseline is exceeded by a certain amount by either a particular client or robocode version, then it could be considered suspect, in a way that considers cases like DogManSPE. --Rednaxela 05:16, 20 June 2009 (UTC)

Source code

Can I've your server source, please? I've write PHP and MySQL for over 3 years now and I've palnned to create new Thai RoboRumble for my country! Hope you'll give it to me. You can email me at email found on my user page. » Nat | Talk » 09:20, 10 February 2009 (UTC)

Rumble ideas

Hi! I'm very thankful to you for doing the new engine. I was thinking about brand new femto and haiku rumbles. What do you think about it? In my opinion it'd be fantastic if there were these kind of categories. They seem to be really cool and exiting, but unfortunately, there isn't any ranking or challenge for them. Femto can't be hard to implement, maybe haiku is a harder task. I imagined new categories for them with new participants list for them, but I can imagine that the actual bots can have this kind of rank, but then it would lose its importance. --HUNRobar 17:55, 14 February 2009 (UTC)

In femto battle, we really need to modify RR@H client. For Haiku, I think not. It require human to detect how many lines are there. But, wait a minute, I'm now creating my new Rumble Server which support many old rumble ideas and these rumble! That why I want his source code above. If you want to test your haiku bot or femto bot, you can see old ranking and bot in robocode little league by Kawigi. » Nat | Talk » 01:48, 15 February 2009 (UTC)

Valid versions

By the way Darkcanuck, just to let you know:

• I'm quite sure 1.6.1.4 (NOT plain 1.6.1) is at least as rumble-stable as 1.6.0 is, and is better because it fixed how ITERATE was broken.
• Also, I'm pretty sure EVERY single version from 1.6.2 to 1.7.1 Beta 2 have been bad for rumble.
• 1.7.1 Final look like they're probably good for rumble except for:

1. http://sourceforge.net/tracker/?func=detail&aid=2727675&group_id=37202&atid=419486
2. http://sourceforge.net/tracker/?func=detail&aid=2627698&group_id=37202&atid=419486

--Rednaxela 07:34, 3 April 2009 (UTC)

• Agree. I really like 1.7.1, even in alpha version, compare to 1.7.0.2, which have a ton of bugs =D I'm figuring out what behind SandboxDT and sure that Fnl is fixing another bug so expected 1.7.1.1 with better rumble :-) » Nat | Talk » 16:07, 3 April 2009 (UTC)

Ok, I can add 1.6.1.4 to the list -- but it won't matter much since that client won't report it's version number either. Nice summary though. (and you know I filed that 1.7.1 melee bug right?) Anyone interested in patching the 1.5.4/1.6.0/1.6.1.4 rumble jar(s) with the version check from 1.6.2? --Darkcanuck 15:40, 3 April 2009 (UTC)

• Either user won't download patched version. I'll try to do. Just getting head spinning around checking out from robocode svn :-) » Nat | Talk » 16:07, 3 April 2009 (UTC)

I see you patched your client already. Just few suggestion, you can (mostly) detect from user suffix. Most user suffix their name with version (except deewiant) so you can check with that. » Nat | Talk » 19:11, 5 April 2009 (UTC)

Yes, but I like guarantees that the right version is being used. :) I've patched both 1.5.4 and 1.6.1.4 to report the client version and I'll post the new jars later today. Once rumble users have switched, then I can turn off the workaround for older clients. --Darkcanuck 22:08, 5 April 2009 (UTC)

I've been using 1.6.0 for the rumble, for what I understand I should install 1.6.1.4 (actually the version I develop with) and replace with the patched jar? Has it been tested, even a little bit, to ensure no side effects, or should I set upload to not for a while? --zyx 03:52, 6 April 2009 (UTC)

I've tested both jars on my system and they seem to be fine. If you want to stick with 1.6.0 I can patch it tomorrow -- I got lazy and only did "ol' reliable" (1.5.4) and the latest stable version. Right now I'm using 1.6.1.4 myself, although I can't get that one to work on my Mac. --Darkcanuck 04:20, 6 April 2009 (UTC)

I tested 1.6.1.4 a fair bit and for a period of time it was what I was using for rumble. And also, like I note above, that version fixes the ITERATE option which has been broken for a long time (it still ran with ITERATE=YES in older versions, but it didn't choose the best bots properly after the first iteration). --Rednaxela 04:17, 6 April 2009 (UTC)

No no, I don't want to stick to 1.6.0, I used 1.6.1.4 as my first rumble client, then read that official versions were 1.5.4 and 1.6.0 so I downgraded to it, so actually 1.6.1.4 is what I'd like to use. When I saw Rednaxela's post above I already decided to switch, I don't use ITERATE, but I still prefer the newest stable version, and since is the version I develop in, even more. My question was related to the patched jar's, sometimes one change affects more than one would like it to, so I asked if you tested it, relatively enough :-p. I will run the patched 1.6.1.4 later tonight, probably with UPLOADS set to NOT just in case, and tomorrow let it upload if ok, or report any weird behavior if I see one. Good job anyways. --zyx 05:20, 6 April 2009 (UTC)

FYI, SVN revision r2352 is the update where it is added. (I think you knew already, Darkcanuck) Actually, I saw only few lines of changes :-) BTW, it's engine for 1.6.2 (AKA melee bugs version) not for old engine. There is a lot change to 1.6.2. Just shame of myself, as I said above to create a patch, but I not even start yet. I don't think you need to patch 1.6.0.1, as everybody but Darkcanuck and GrubbmGait use 1.6.1.4 (at least after this night) AFAIK, no bot that can run on 1.5.4 or 1.6.0.1 can't run on 1.6.1.4, or any? If everybody use 1.6.1.4, I shall release a bot with underscore in version again =D » Nat | Talk » 07:48, 6 April 2009 (UTC)

Zyx, why don't you use ITERATE? David Alves said somewhere that ITERATE is twice faster than using shell script. » Nat | Talk » 07:48, 6 April 2009 (UTC)

Probably because of that, I don't like my processors temperature when ITERATE is on. I have a shell scripts that sleeps after every iteration and it can be set how many roborumble iterations to run per one meleerumble iteration. And I know that ITERATE is much faster because the initializing version check takes quite some time. I have a modified version of RoboRumble, that basically does the same thing but it doesn't upload results(stores to files) and has a Thread.sleep(X), that I use to test new versions of my bots, and that one is faster and I can still sleep after iterations. Although adding the Sleep into the official version would be really simple, I would still be missing my roborumble/meleerumble relation, also Darkcanuck has a bit of fault, since the server is faster it's harder for the processor to cool down :-S. --zyx 08:28, 6 April 2009 (UTC)

I went ahead and patched 1.6.0 anyway -- but this one I haven't tested. The other two have been tested for both one-on-one and melee, and I've been using 1.6.1.4 for two days now. If you find the server too fast, I can increase the upload throttling :) (right now there's a one second delay between uploads) --Darkcanuck 15:14, 6 April 2009 (UTC)

Rednaxela, bot issues are fixed, please verify. Unfortunatly, new bugs discovered. [1] :-( » Nat | Talk » 02:16, 8 April 2009 (UTC)

I think it may be awhile before a stable 1.7.x version is ready. There was never a stable 1.6.2 and 1.7 adds more systemic changes so there will be more bug hunting to come! I might add a "test" mode on the server so basic rumble checks can be done -- let me know if you have suggestions. --Darkcanuck 02:24, 8 April 2009 (UTC)

Maybe you don't know that 1.7.1 has nearly no bug left. It inherit a lot of bug from 1.7.0 that don't reported on SF, and a lot of new bug, too. But, I have hunted more than 50 bugs already (from alpha version)

The "test" mode is good ideas, but will it overload your server? I suggest, if your mysql is fast enough, try adding field stable. Stable result query WHERE `stable` = 1 and "test" result query all of them. Easy? » Nat | Talk » 03:41, 8 April 2009 (UTC)

Even when all the reported bugs are fixed, we will need to spend some time running it to make sure the results are valid. The "test" mode I was considering wouldn't actually store anything to the database, just do the basic data validation checks before throwing away the results. This way you could run a new client and monitor the results. There's already a status flag in the battle results table which could do what you suggested, but I don't know that we need to store the test results. A fairly simple improvement on this plan would be to calculate the difference between the real rumble results and those from the test client, then send this data back to the client. --Darkcanuck 04:18, 8 April 2009 (UTC)

Team Rumble result are invalid right now, that's why those melee bot going into Team Rumble result. But I think RoboRumble and MeleeRumble result are valid now. I'll test by set UPLOAD = NOT in latest 1.7, put result to 1.6.1.4 and let it upload. :-) » Nat | Talk » 04:30, 8 April 2009 (UTC)

Ergh! Sorry, please consider delete all result from Nat_1711 :-( 1.6.2 and up use Survival score but older use place count. I'm very sorry. » Nat | Talk » 04:48, 8 April 2009 (UTC)

Maybe next time don't change your client's version number? The check is there for a reason... --Darkcanuck 06:27, 8 April 2009 (UTC)

I'm not playing. All result is uploaded under new username (Nat_1711 vs. Nat_1614 or Nat). I think you cen delete with one SQL query, aren't you?

But the result from from it is very close to original score. I can't spot any difference except survival. I've a tousand of 1.7.2alpha result save im my machine wait for 1.6.1.4 to upload it :-) Just look at your code, using survival score aren't metter in one-one-one/team since it automatically calculate percent score.

I hope you plan for newer version soon. This version work twice faster than 1.6.1.4 on my machine. But load with pile of java exceptions, too. » Nat | Talk » 06:49, 8 April 2009 (UTC)

I appreciate your taking the time to test 1.7.2, but please don't upload results from 1.7.2 using a 1.6.1.4 client! If there are problems with the results, how can we separate them easily? Removing bad results from the rumble is more complicated than a single SQL query and unfortunately I haven't automated it yet: 1 - the bad result has to be flagged/deleted, 2 - pairing scores need to be recalculated, 3 - ELO/Glicko/APS rankings need to be updated at least once to smooth out the bad data (only APS can be recovered cleanly). When the open issues with 1.7.x are fixed and a new release comes out then we can look into allowing the new version. But for now, please stick to the official versions when uploading. There are over 5 million battles stored on the server, I don't want to search through all of them to find a handful of bad ones! ;) --Darkcanuck 07:15, 8 April 2009 (UTC)

I noticed the message about patching roborumble.jar, so I did, but then I get the following when uploading:

OK. Client version null is not supported by this server! Please use one of these: 1.5.4, 1.6.0, 1.6.1.4

I tried patched versions of both 1.5.4 and 1.6.1.4, but I got the same message each time. Beats me what's up with that; for now, I reverted back to the unpatched roborumble.jar (under 1.6.1.4, for what it's worth). --Deewiant 15:22, 9 April 2009 (UTC)

Sounds like the patched roborumble.jar is working but the game engine isn't returning a version number (just an empty string). Can you try a clean install (just copy over your bot jars and the files under roborumble/)? I think the engine pulls its version number from the versions.txt file, so if it's missing or has been updated then this could happen. --Darkcanuck 07:59, 10 April 2009 (UTC)

Sorry, I should have been more clear: that's exactly what I did for both 1.5.4 and 1.6.1.4 when I first ran into the problem: I grabbed the installer from SourceForge, copied over robots and roborumble/*.txt, overwrote roborumble.jar with the patched one and ran meleerumble.sh. And then I got the error again. --Deewiant 10:53, 10 April 2009 (UTC)

Thanks for the info! I think I just found the bug: in the pre-1.6.2 versions (which is where the patch comes from) there are separate methods for normal battles and melee battles. Looks like I only patched the normal one but missed melee. Expect a new set of patched versions shortly! --Darkcanuck 21:27, 10 April 2009 (UTC)

Just tested the new 1.6.1.4 patch and this problem has been fixed for melee. 1.5.4 and 1.6.0 also have been fixed. You can download the new version using the same link, although you'll probably have to clear your browser cache to get the latest version. --Darkcanuck 22:27, 10 April 2009 (UTC)

Alright, 1.5.4 works for me now, cheers. --Deewiant 10:46, 11 April 2009 (UTC)

Darkcanuck, could you please take a look at robocode 1.7.1.1 released this week? Please test it and report any bug you found, or, in another word, take a decision that is it stable for RoboRumble or not. » Nat | Talk » 06:30, 13 April 2009 (UTC)

I'm away this week but when I get back I'm planning to work on the server a bit more. Once that's done I'll take a look at the new version. And thanks to everyone who's using the patched rumble client, I think we're almost ready to disable uploads from anonymous clients! --Darkcanuck 18:32, 15 April 2009 (UTC)

There is a bug, at least in the patched 1.6.1.4 version. If you have some battle results stored and run the client with EXECUTE=NOT, then I get this message and the results are thrown away.

OK. Client version null is not supported by this server! Please use one of these: 1.5.4, 1.6.0, 1.6.1.4

I guess it pulls the version number somewhere after executing battles starts or something like that. I guess the jar should be fixed, but anyway I think the server should reply FAIL instead of OK so the results are kept in the client. --zyx 08:20, 16 April 2009 (UTC)

That's a quirk of how the version number is being pulled by Roborumble -- it's a bit odd, but I just copied how it was done in 1.7.1. Not sure how easy this is to fix but you can file it as a bug on sourceforge. On the server side, I always send an "OK" to invalid clients to prevent them from holding on to possibly bad results. For example, someone may run battles with an invalid version, see the error messages and then install a valid one on top -- if the old results are still there, they would later get uploaded with the correct version number and then corrupt the rankings... --Darkcanuck 18:55, 18 April 2009 (UTC)

Rating

If in melee, both Bot A and Bot B had "0 survival", Bot A AND Bot B get "0% survival" against each other. is it 0 because 0 survival = 0% survival against the other bot, regardless of what the other bot got? or is it because of a 0 / 0 thing? --Starrynte 00:40, 4 April 2009 (UTC)

In a melee battle, if two bots have 0 survival then when the server tries to calculate the survival % for that pairing it becomes 0 / (0+0) for bot A, same for B. The divide by zero protection simply assigns 0 scores to both, although I suppose technically they should each get 50%. --Darkcanuck 05:08, 4 April 2009 (UTC)

Team Rumble

What the heck going in team rumble? What does melee bot from? » Nat | Talk » 20:26, 5 April 2009 (UTC)

Ugh, thanks for pointing this out! That's exactly the sort of thing the patched clients will prevent: they also report the MELEE and TEAMS settings from the properties file. Now if only we can get everyone to adopt them (only 6 uploaders active this month, shouldn't be too hard?) ... --Darkcanuck 03:16, 6 April 2009 (UTC)

• (off-topic) Which rumble do you want contributor most? Now I run roborumble and meleerumble, with UPLOAD = DOWNLOAD = NOT at night (I usually close my internet at night, but I left my machine run so it don't use SERVER, but GENERAL) and when I awake, I change UPLOAD = DOWNLOAD = YES again. Should I switch to team rumble instead of roborumble? » Nat | Talk » 09:15, 6 April 2009 (UTC)

Melee Rumble

Is something wrong if each time when I run meleerumble it spews out tons of html code? --Starrynte 18:04, 9 April 2009 (UTC)

Sounds odd... can you send me a sample? (jerome at darkcanuck dot net) I don't often run a melee client but I don't remember seeing extra output. --Darkcanuck 07:53, 10 April 2009 (UTC)

Pairing

Why DrussGT 1.3.6 has 699 pairings while only 699 bots in rumble? It should have only 698 so far (it can't paired with itself) » Nat | Talk » 07:37, 15 April 2009 (UTC)

• OK, it's going down to 697 now, and loose PL score. » Nat | Talk » 08:47, 15 April 2009 (UTC)

Data in the ranking tables only updates when that bot gets a new battle result. So if there are new bots added or retired from the rumble, it may take a little while for all the existing competitors to fight one battle each and get updated. If you want to use data from the rankings table, I'd suggest waiting until that bot has at least 2000 battles and there has been no changes to the participants list for at least one day. --Darkcanuck 18:03, 15 April 2009 (UTC)

Comparison between robot

I like the new feature for comparison with old version. Can you put at the end of comparison a "total" row and maybe add sorting script like main ranking page? I hope to have a look at server's code in this day. --lestofante 11:54, 28 April 2009 (UTC)

Yeah, I love it! It was the one thing I really missed from the old server, and displaying recent versions with links is very nice. I second the "total row" idea, and listing "best" version among the links might be nice too, but I could live without either of those. I know I'm late to the party, but your RR server is really sweet, major thanks from me for all your hard work. --Voidious 13:50, 28 April 2009 (UTC)

Really good job, I used to save the page of my old bots and compare them in Excel. For the new features proposed, I like the sorting idea the best. Great work man. --zyx 14:57, 28 April 2009 (UTC)

Thanks! Sorting is already enabled, it works just like the other tables -- you may need to reload the page or clear your browser cache to update the javascript? Will a totals row really help more than the average % score and survival at the top of the page? --Darkcanuck 03:06, 29 April 2009 (UTC)

The sorting indeed works fine for me, nice. The % score and survival are not limited to the bots they have commonly faced, that's why I'd still find myself calculating the total from the table. (Especially before the new one has all its pairings, yes I'm that impatient. =)) It's no biggie for me to copy/paste into Excel for that (as I've been doing for however many years), but just FYI that's why it could be different. Honestly I feel guilty even mentioning more bells and whistles, but since you asked... --Voidious 03:28, 29 April 2009 (UTC)

So really what you want is an APS & avg. survival for common pairings only, correct? I could put that in the summary table at the top... --Darkcanuck 03:36, 29 April 2009 (UTC)

Yep, that would be the same for my purposes. Thanks dude! --Voidious 03:41, 29 April 2009 (UTC)

Try it out... ;) --Darkcanuck 03:50, 29 April 2009 (UTC)

Wow, you're quick! Awesome, thanks again. =) --Voidious 3:57 26 April 2009 (UTC)

Very nice! I've been missing this! Now, I don't want to sound ungrateful or anything, but I had an idea that would help comparisons even further: if there was an equivalent of an ELO graph that runs off the expected score and the diff, so it's easy to (graphically) see where you lost or gained points on a version, against strong or weak bots. I'm not sure if you would be able to just feed the graph software different data, or if you need to go in and make a copy which you could adapt to pull different data, but I'm fairly sure it's a feature which would see good use! --Skilgannon 15:49, 30 April 2009 (UTC)

Now you want a graph?!? I think you'll have to call ABC out of retirement to look into this -- my javascript skills are quite limited... ;) --Darkcanuck 16:17, 30 April 2009 (UTC)

Probable bugs

I've now gotten 5 different crashes as I've been running the melee battles over the last 24 hours on 2 different systems. 2 of them were out of memory failures, 1 battle thread exception, and 2 illegal awt something or anothers. The common thing I noticed was robot Justin.Mallais 10.0 running in each group. That robot also takes my system down to a crawl while running. Anything else I can add to help you out? --User:Miked0801

No, this is not a server bugs. The out of memory failures mean that you set the java heap size too low, try -Xmx512M or -Xmx1G instead of default -Xmx256M and try again. The battle thread exception should be reported on sourceforge tracker. The awt thing is sometimes happen, but I don't think it make the client crash. If it does crash, report it on the tracker, too.

In case you don't know, sing your comment with --~~~~, it will automatically link to your user page with a nice timestamps. » Nat | Talk » 15:41, 29 April 2009 (UTC)

Hey, you might like to know (if you didn't notice) that the RR client now has the option to exclude certain bots or packages (set in the ...rumble.txt file). I haven't played with it much, but I have been tempted by SlowBots in the past =), and this sounds like a good situation for it. Not that this precludes the existence of bugs to be fixed in the RR client. But on that note, I think FlemmingLarsen may handle the RR client code, while Darkcanuck just setup a new server for it to point to. --Voidious 15:44, 29 April 2009 (UTC)

Yep, I only modified the RR client so that it sends the version to the server -- bugs should be logged at sourceforge for Fnl and Pavel to look into. The default melee memory setting is definitely way too low and really needs to be at least 512M as Nat pointed out (this has been fixed in later, unstable versions). My client runs fine with this amount, but I don't use that computer for anything else... 1.6.1.4 works fine although it has the unfortunate quirk of sending tons of output to the console, including occasional awt exceptions (which don't crash the client or seem to affect results). --Darkcanuck 16:27, 29 April 2009 (UTC)

Is there a better place on teh wiki for client bug discussions then? BTW, changed my memory settings and am testing now. --Miked0801 16:34, 29 April 2009 (UTC)

RoboRumble/Reported_Problems is the best place to start if it's not clear whether you're seeing a problem with the server, client or a specific bot. There are links to this area plus the sourceforge tracker too. --Darkcanuck 16:38, 29 April 2009 (UTC)

A quick update on the AWT thing. It happens 100% of the time when I start my Internet Explorer browser while running the game in the background. It also happened when Outlook sent me a meeting reminder. But on the server side, is there anyway to make sure that all unpaired robots can take priority when being selected for random battles? I've gone nearly 800 nano battles and have yet to get my last pairing (and have only hit 1 other robot once.) I've also noticed overall that many pairings have yet to occur on bots with over 5000 battles complete in general melee. This might be a random number/selection bug, or it might be bad luck. Either way, this should probably be nudged to help out the ranking integrity. Especially when I've battled other bots over 20 times. --Miked0801 23:34, 29 April 2009 (UTC)

I've been looking at pairings more closely recently and can tell you this much:

• the server always reports missing pairings to the client on every upload (but only for the two bots in the pairing, limited to 50 pairs).
• the client doesn't actually pay attention to this data until a bot reaches the BATTLESPERBOT number (usually 2000); until that point pairings seem to be chosen randomly. This is incorrect, I noted a quirk below that causes pairing completion to take longer than expected.
• there's definitely something funny going on with melee and I'm not sure how the client puts together 10 bot matches. The server should be doing the same thing as for 1-on-1 but maybe the client doesn't use it?
• I've seen (and others have reported) the client get stuck on one pairing, running it over and over...

--Darkcanuck 00:40, 30 April 2009 (UTC)

I just peeked at the client source and it looks like melee doesn't use "smart" battles, so it's completely random... --Darkcanuck 00:46, 30 April 2009 (UTC)

Ok, I did some further digging and managed to patch my 1.6.1.4 client to use priority battles in melee, so the missing pairings should start to sort themselves out soon. I'll make it available once I'm sure there's no bugs. But I also found that the way the client stores these pairings can lead to the same pairing being run over and over again -- especially in melee. In order to work around this problem, I've updated the server so that the missing pairings are sent to the client in a somewhat randomized fashion. This should help speed up the rate at which pairings are completed in all categories.

The Survival 0/0 = 0 bug is kinda annoying as well. Every now and then a melee battle accurs with one of the melee gods and none of the nanos survive. Seeing a 0% survival freaks me out. :) --Miked0801 23:52, 30 April 2009 (UTC)

How to Enter

How do I enter? I have a decent nano I want to try. --Awesomeness 21:55, 6 May 2009 (UTC)

• include your bot on the participants page (RoboRumble -> Participants 1-v-1 or melee) and it will automatically get its battles on the running clients. See also RoboRumble -> Enter The Competition. Good luck! --GrubbmGait 22:19, 6 May 2009 (UTC)

Okay, I did... Do I just wait now? --Awesomeness 00:02, 7 May 2009 (UTC)

(edit conflict) Looks like you got it! Clients only refresh the participants list every 2hrs, so it may take at least that time for a new bot to show up in the rumble. 550 battles and climbing... with all the processing power running clients recently, Elite 1.0 should be at 2000 battles in no time! --Darkcanuck 00:41, 7 May 2009 (UTC)

Yep, your bot will get battles from those of us running a RoboRumble client. If you want to contribute battles yourself, check out the RoboRumble/Starting With RoboRumble instructions. There are a few things to note, though (that should be added to that page):

• You need to use Robocode 1.5.4, 1.6.0, or 1.6.1.4. You can grab one of those here.
• You'll need to grab the patched roborumble.jar (for the appropriate version) from this page: Darkcanuck/RRServer/Updates, and put it in the robocode/libs dir (replacing old one).
• You should edit these things in the robocode/roborumble/roborumble.txt:
  • RESULTSURL=http://darkcanuck.net/rumble/UploadedResults
  • RATINGS.URL=http://darkcanuck.net/rumble/RatingsFile
  • PARTICIPANTSURL=http://robowiki.net/w/index.php?title=RoboRumble/Participants
  • UPDATEBOTSURL=http://darkcanuck.net/rumble/RemoveOldParticipant
• (Similar updates would be needed for Melee or Teams in meleerumble.txt and teamrumble.txt, but only if you plan to run those.)

Once that's all set, just run roborumble.sh or roborumble.bat. Running a client is not required, but definitely appreciated if you're entering bots, and you won't have to wait as long to get a stable rating. =)

--Voidious 00:39, 7 May 2009 (UTC)

What's the problem?

Hey Darkcanuck, what's the problem? I can't find any problem with my client... » Nat | Talk » 08:53, 16 May 2009 (UTC)

Ok, ok. Just found that some roborumble result injected into resultsmelee.txt, weird... Fixed now. » Nat | Talk » 09:18, 16 May 2009 (UTC)

And, please unblock me soon, 4,613+ battles are waiting! (and my clients are running with UPLOAD=NOT) I've fixed all issue with my result file, anyone know how it happen? my resultsmelee.txt are injected by roborumble result and a LOT of whitespace. Actually I'm much appreciate you blocked me, or what will happen if my client reach the whitespace (around 1000 TABS characters)? » Nat | Talk » 13:39, 16 May 2009 (UTC)

Ok, but I think you should stick to the 1v1 rumble until we can figure this out -- I'm going to keep the meleerumble block active. Are you using the iterate feature? --Darkcanuck 20:10, 16 May 2009 (UTC)

Thank, but it would be better if you unblock melee and still block one-on-one because I run melee rumble as my main client (those battle are 90% melee and 10% one-on-one). Yes, I use the iterate feature (I hate initialize version check date) » Nat | Talk » 02:12, 17 May 2009 (UTC)

Well that's 4000+ possibly suspect battles... I don't feel like cleaning that up if there are more bad results. If you separate your melee and 1v1 installs and delete all saved results then we can turn this back on. --Darkcanuck 06:03, 17 May 2009 (UTC)

OK, my roborumble client is moved to my harddisk without any data transfer (blank result file) and my computer just crash around half an hour ago so I can say that no suspect battles left (lost 9000+ battles this time) But all are clean :-) » Nat | Talk » 06:14, 17 May 2009 (UTC)

Do you have separate installs (e.g other directories) for melee and one-on-one? If not, it is strongly advised not to run melee and one-on-one at the same time. --GrubbmGait 23:02, 16 May 2009 (UTC)

No, I'm not using the separated installations (not enough space in ramdrive). :-) » Nat | Talk » 02:12, 17 May 2009 (UTC)

Now I moved my one-on-one client back to hard disk, ramdrive now use for melee only. » Nat | Talk » 02:20, 17 May 2009 (UTC)

When running from the same installation, if in melee AND one-on-one the same bot is running a battle simultaneously, you get strange stuff. Same with running a client and developing at the same time in one installation. One installation should handle one thing at the time, so use separate installs although in your case this means a less convenient way. --GrubbmGait 09:26, 17 May 2009 (UTC)

Now it separated =) » Nat | Talk » 11:24, 17 May 2009 (UTC)

Well I can't really be sure, but the weird data and blanks injection sounds like a bug in the ram disk implementation to me. I haven't seen anything that could cause that in the rumble client's code nor have I heard of anyone having that issue before, but I feel that a small pointer related bug in a ram disk implementation can easily cause that behavior. --zyx 07:10, 17 May 2009 (UTC)

I don't think it is only ramdisk fault. I think it both Java and ramdisk fault. Anyway, I use separate installation (yet being synchronized) no. » Nat | Talk » 07:17, 17 May 2009 (UTC)

Have you unblocked my melee client? After cleaning the result file (accidentally actually), my client running again, now at iteration 15 and 2000+ battles waiting.

Confirmed:

• My roborumble client is at C:\roborumble while meleerumble client is at R:\roborumble (ramdisk)
• My melee result file was cleaned accidentally by a computer crash.

» Nat | Talk » 08:36, 17 May 2009 (UTC)

Iteration 34, 4500+ battles, please! (I think you are sleeping) » Nat | Talk » 11:24, 17 May 2009 (UTC)

Ok, done. :) --Darkcanuck 15:09, 17 May 2009 (UTC)

Thanks, sorry if my client upload results for Diamond 1.01/1.02 » Nat | Talk » 07:14, 18 May 2009 (UTC)

Hey DarkConuck,, My appologies... It seems my client uploaded some crap to the server... I don't know why.. I follow the directions above ( vr 1.6.1.4 / with robocode patch, and changed urls, ) and the install was meant for melee rumble only.. If you have any suggestions I'll use them, otherwise I have no prob waiting for the fool proof version . (It would be nice to one day run the roboRumble and enter a bot via the drop down menu in robocode)... Pls unblock me so I can view the rankings, and I will no longer attempt to run the melee rumble unless you have suggestions.. Thanks -Justin

No worries. I'll unblock your uploads shortly, but I fixed the bug that also blocked you from viewing the rankings -- that was unintended. I think your client was using the 1v1 participants url (that's what was posted above), but for melee you should be using http://robowiki.net/w/index.php?title=RoboRumble/Participants/Melee. This is in the meleerumble.txt file of course, which should be used by running meleerumble.bat/sh. Also important to have MELEEBOTS=10 in that file too. --Darkcanuck 22:32, 26 May 2009 (UTC)

Yes, I was using the wrong list.. :( I changed it... (MELEEBOTS=10 was ok) If you wanna Give me the go ahead I will try again if you like... (though I imagion I should open up the resultsmelee.txt and delete everything in there) right? -justin

Before restarting your client, delete all of the files in the roborumble/files and roborumble/temp directories. This will give you a fresh start. Also try running just one iteration first and check that your client is working ok before letting it run unattended. I'll try to have a look in a few hours to see how things are going. --Darkcanuck 23:34, 26 May 2009 (UTC)

And check out the pages User_talk:Jlm0924 and Talk:Mallais -- people have questions for you! --Darkcanuck 23:38, 26 May 2009 (UTC)

Hey Darkcanuck - I'm not sure if this is just spillover from the previous issue, but I figure better safe than sorry... I see some results from your client (or using your name) in the melee rumble with bots that shouldn't be there: [2] and [3], for example. --Voidious 01:53, 27 May 2009 (UTC)

It's related to the bots that Justin sent results for. My client is patched to do smart battles in melee, so the server keeps sending missing pairings for these bots (which the client naively runs). And the server no longer removes bots until at least 4hrs after a bot's last upload so the priority battles keep them in play. This loop will be broken once the bots (3, I think) reach full pairings. Normally I'd just stop my client for 4hrs or so, but I'm out of town and can't access that machine... --Darkcanuck 04:49, 27 May 2009 (UTC)

Accel/decel rules

I've almost finished my first robot to enter to the melee rumble :), but I'm wondering: does the (melee)server use the old accel/decel rules (where you can go from -1 to 1) or the new (where you can't)? --Positive 23:22, 11 Jul 2009

The RoboRumble currently only allows clients using versions 1.5.4, 1.6.0, and 1.6.1.4, so it should only be the old rule (where you can). I actually didn't realize that was changed -- I really don't like that. =( Lots of legacy bots are programmed to believe you can. --Voidious 21:24, 11 July 2009 (UTC)

Woah, what a quick response! Thanks for the info. :) I don't really like the change either (I have a cool -1, +1 strategy and a nice move simulator), but alas. --Positive 23:36, 11 Jul 2009

Are you sure the rules have changed? I thought the only changes to movement in later versions of Robocode (still unsupported in the rumble, btw) were to fix the movement quirks that Simonton had found. I don't remember decelerating through 0 being one of them. --Darkcanuck 22:26, 11 July 2009 (UTC)

Here is the discussion at the bug tracker. Fnl explains that if for example your robot is at -1.0 velocity, it can only reach 0.75 velocity the next turn (as of version 1.7.1.2). --Positive 02:45, 12 Jul 2009

Errr.... 0.75 is not 'accurate'... It's what robocode as of 1.7.1.2 does, but it's just as incorrect as before the change... Fnl says it uses a formula of (Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime), when the correct formula should be (Rules.DECELERATION * decelTime + Rules.ACCELERATION * accelTime). Change in velocity, is always equal to acceleration multiplied by time, not time squared... It looks like Fnl got his physics mixed up and looked at a formula to get distance from acceleration (d = a*t*t) instead of getting velocity change from acceleration (v = a*t) :-( --Rednaxela 01:47, 12 July 2009 (UTC)

Ooh, I see this now... Do some tests and file a bug for Fnl? --Darkcanuck 02:48, 12 July 2009 (UTC)

Robocode Developer Google Groups, I think. So Flemming can re-open that tracker instead of creating new one. I always wonder why it go from 1 to -0.75, not 0.5 since it have only half turns left, I always think that I don't have enough physics knowledge. » Nat | Talk » 02:59, 12 July 2009 (UTC)

Voidious, do you subscribe to Robocode Developer Google Groups? I think we have reached the conclusion that we worth this change, unless there are too many effects. After we changed it, Flemming and I did run a lot of test (well, mostly Flemming run, I'd run only one test). I've test Dookious with DrussGT, on both 1.6.1.4 and 1.7.1.x with new updateMovement(), and the difference is around 1-2%, which is acceptable in margin of error. I chose Dookious and DrussGT because I know that Dookious use FuturePosition library, which is the internal copy of old movement engine. And DrussGT use Skilgannon's special movement predictor which I believe should be the loosely implementation of the 'correct' movement engine.

Positive, I believe that if you create a good movement under 1.6.1.4, it will be good in 1.7.1.x version too. » Nat | Talk » 06:20, 12 July 2009 (UTC)

- - -

Hi guys, to you mind I join the discussion? I did the change in "update movement" for many reasons. The issue(s) were raised a long time ago on the old RoboWiki (the 3 caveats raised by Simonton - http://old.robowiki.net/cgi-bin/robowiki?GamePhysics/BotSpeed), and later discussed within the Robocode Developer Group (even Mathew Nelson joined the discussion). That is, if we would make the change or not. Especially with you guys in mind. The conclusion in the groups was to fix the bugs so Robocode would follow its own rules, and because lot's of robots out there counts on the rules as explained, not to the way Robocode was actually behaving. Not everybody replicates the internal code of Robocode to get the formulas correct.

The old closed bug tracker on SF created is available here: https://sourceforge.net/tracker/?func=detail&atid=419486&aid=2077512&group_id=37202

Another goal with the change was to make the internal code easier less messy and easier to understand. Regarding the impact of the change, the results are not very different (unless you can prove me wrong here). I ran lots of lots of test with RoboRumble (also Melee and TeamRumble) on my local machines (different single-code, quad-core, Linux, Windows, 32 and 64 bit etc.), and I couldn't tell the difference in rankings or score with or without the change. There was a difference, but it was in average less than 1 percent. Is it really that much of a problem? Really?

I would really love if people could try out the Betas on RoboRumble and put issues on SF as soon as they are discovered. Then the issues can be fixed or discussed before we do the real release. This way, we could avoid such issues as this one long time after the change was made and released.

Btw. I am very familiar with physics, even tough the physics in Robocode does not really follow the real physics laws. I might not have explained the details about the fix well enough.

Instead of shifting between old and new code (like you propose?), I should like you guys to tell me where the problem is in the code instead, since you are obviously the experts. The code is Open Source, so everybody is free to come with suggestions to what and where to correct things.

Here we go:

	private void updateMovement() {
		double distance = currentCommands.getDistanceRemaining();

		if (Double.isNaN(distance)) {
			distance = 0;
		}

		velocity = getNewVelocity(velocity, distance);

		double dx = velocity * sin(bodyHeading);
		double dy = velocity * cos(bodyHeading);

		x += dx;
		y += dy;

		if (dx != 0 || dy != 0) {
			updateBoundingBox();
		}

		if (distance != 0) {
			currentCommands.setDistanceRemaining(distance - velocity);
		}
	}

	/**
	 * Returns the new velocity based on the current velocity and distance to move.
	 *
	 * @param velocity the current velocity
	 * @param distance the distance to move
	 * @return the new velocity based on the current velocity and distance to move
	 */
	private double getNewVelocity(double velocity, double distance) {
		// If the distance is negative, then change it to be positive and change the sign of the input velocity and the result
		if (distance < 0) {
			return -getNewVelocity(-velocity, -distance);
		}

		double newVelocity;

		// Get the speed, which is always positive (because it is a scalar)
		final double speed = Math.abs(velocity); 

		// Check if we are decelerating, i.e. if the velocity is negative.
		// Note that if the speed is too high due to a new max. velocity, we must also decelerate.
		if (velocity < 0 || speed > currentCommands.getMaxVelocity()) {
			// If the velocity is negative, we are decelerating
			newVelocity = speed - Rules.DECELERATION;

			// Check if we are going from deceleration into acceleration
			if (newVelocity < 0) {
				// If we have decelerated to velocity = 0, then the remaining time must be used for acceleration
				double decelTime = speed / Rules.DECELERATION;
				double accelTime = (1 - decelTime);

				// New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d
				// However, the new velocity must be limited by the max. velocity
				newVelocity = Math.min(currentCommands.getMaxVelocity(),
						Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,
						distance));

				// Note: We change the sign here due to the sign check later when returning the result
				velocity *= -1;
			}
		} else {
			// Else, we are not decelerating, but might need to start doing so due to the remaining distance

			// Deceleration time (t) is calculated by: v = a * t => t = v / a
			final double decelTime = speed / Rules.DECELERATION;

			// Deceleration time (d) is calculated by: d = 1/2 a * t^2 + v0 * t + t
			// Adding the extra 't' (in the end) is special for Robocode, and v0 is the starting velocity = 0
			final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;

			// Check if we should start decelerating
			if (distance <= decelDist) {
				// If the distance < max. deceleration distance, we must decelerate so we hit a distance = 0

				// Calculate time left for deceleration to distance = 0
				double time = distance / (decelTime + 1); // 1 is added here due to the extra 't' for Robocode

				// New velocity (v) = a * t, i.e. deceleration * time, but not greater than the current speed

				if (time <= 1) {
					// When there is only one turn left (t <= 1), we set the speed to match the remaining distance
					newVelocity = Math.max(speed - Rules.DECELERATION, distance);
				} else {
					// New velocity (v) = a * t, i.e. deceleration * time
					newVelocity = time * Rules.DECELERATION;

					if (speed < newVelocity) {
						// If the speed is less that the new velocity we just calculated, then use the old speed instead
						newVelocity = speed;
					} else if (speed - newVelocity > Rules.DECELERATION) {
						// The deceleration must not exceed the max. deceleration.
						// Hence, we limit the velocity to the speed minus the max. deceleration.
						newVelocity = speed - Rules.DECELERATION;
					}
				}
			} else {
				// Else, we need to accelerate, but only to max. velocity
				newVelocity = Math.min(speed + Rules.ACCELERATION, currentCommands.getMaxVelocity());
			}
		}

		// Return the new velocity with the correct sign. We have been working with the speed, which is always positive
		return (velocity < 0) ? -newVelocity : newVelocity;
	}

What must be corrected in order to make everybody happy, following the "physic laws" and rules of Robocode? --Fnl 22:59, 12 July 2009 (UTC)

Fnl, it will take me some time to look over the code and discussions before I can give more constructive feedback. But some things I can comment on for now:

• Fixing the issues Simonton brought up seems very reasonable to me. One is a bug that I doubt anyone depends on (the setMaxVelocity / decel). For the others, I'd guess DrussGT and SilverSurfer are the only bots that might simulate the quirks (being Go-To surfers). Some Wave Surfing Challenge tests with SS (I will run some) and feedback from Skilgannon could shed some light on potential impact.
• I'm not clear on what has happened with this, but I believe changing the ability to go from velocity 1 to -1 could adversely impact a lot of bots. Even a bot as old as PrairieWolf (2002) has a movement mode that depends on it ("buzzing" between 1 and -1), and I'd guess nearly every modern wave surfer also simulates this aspect of the physics.
• One percent is a lot -- see the "huge" 1% APS gap between DrussGT and Dookious =). That said, it takes hundreds or thousands of battles to get a result accurate enough to see that 1% difference.
• I do not envy your position in these types of matters, and as always, I appreciate the effort you put into developing Robocode. Robocode's impact goes far beyond the "hardcore" Robocoders on this wiki, and I fully understand that you want to polish Robocode as best as you can for the benefit of everyone that uses it. Cheers,

--Voidious 00:01, 13 July 2009 (UTC)

1 percent is not a lot with this major change in physics, especially when it makes the game follows its own rule better. 1% is 'huge' in APS, I agree. But if you look at each battle closely, the results can swing up to 10% » Nat | Talk » 16:14, 13 July 2009 (UTC)

1% is 1% and it is a lot. You're right that individual battles have a large variance, that's why you need to run hundreds of battles to get a meaningful result. If you run enough battles to get a statistically accurate result, 1% is a lot. If you don't run enough battles, you can't draw any real conclusion from the results.

I'm not claiming there is a 1% difference in results. I'm only saying that if tests only narrowed it down to "1% or less", that's not really enough to satisfy my need for accuracy and consistency. No ill will here, I should get involved and run some tests if I care so much. And I do. And I will. =)

--Voidious 17:40, 13 July 2009 (UTC)

While I wat to argue that 1% is not a lot for this major physics change, I don't think that is an issue anymore. I think you already accept the changes now =) » Nat | Talk » 12:37, 14 July 2009 (UTC)

I've read the mailing list and bug report concerning the issue. Does the -1, +1 thing really need to be changed to fix the bugs? This is how I would code it, and I believe it should fix the bugs. I haven't actually compiled it into robocode, but the velocity routines themselves have been tested and are working. And excuse me, I'm a bad commenter :):

	private void updateMovement() {
		double distance = currentCommands.getDistanceRemaining();

		if (Double.isNaN(distance)) {
			distance = 0;
		}

		velocity = getNewVelocity(velocity, distance);

                // small tweak from original version
		if(velocity!=0)
		{
			x+=velocity * sin(bodyHeading);
			y+=velocity * cos(bodyHeading);
			updateBoundingBox();
		}

		if (distance != 0) {
			currentCommands.setDistanceRemaining(distance - velocity);
		}
	}

	static double getNewVelocity(double velocityArg, double distanceArg) 
	{	
		double velocity;
		double distance;

		// Make sure the remaining distance is always positive or zero
		// (we switch this back later)
		if(distanceArg<0)
		{
			velocity=-velocityArg;
			distance=-distanceArg;
		}
		else
		{
			velocity=velocityArg;
			distance=distanceArg;
		}

		// Get the next most positive velocity the robot can reach for next turn
		double mostPositiveReachableVelocity = VelocityToMostPositiveVelocity(velocity);
		// Get the next most negative velocity the robot can reach for next turn
		double mostNegativeReachableVelocity = VelocityToMostNegativeVelocity(velocity);


		double highestWantedVelocity = Math.min(currentCommands.getMaxVelocity(), maxSpeedToStopInDisp(distance));

		// The real next velocity is limited by what is actually reachable
		double nextVelocity = Math.min(mostPositiveReachableVelocity,Math.max(mostNegativeReachableVelocity,highestWantedVelocity ));

		// Switch return value back if needed
		if(distanceArg<0)
			nextVelocity = -nextVelocity;
	
		return nextVelocity;
	}


	static public double VelocityToMostPositiveVelocity(double velocity)
	{
		// Returns the most positive reachable velocity from the
		// specified velocity in one turn
		if(velocity>0)
		{
			double returnVelocity = velocity+Rules.ACCELERATION;
			if(returnVelocity>Rules.MAX_VELOCITY)
				return Rules.MAX_VELOCITY;
			else
				return returnVelocity;
		}
		else
		{
			double returnVelocity = velocity+Rules.DECELERATION;
			if(returnVelocity>Rules.ACCELERATION)
				return Rules.ACCELERATION;
			else
				return returnVelocity;
		}
	}
	static public double VelocityToMostNegativeVelocity(double velocity)
	{
		// Returns the most negative reachable velocity from the
		// specified velocity in one turn
		if(velocity<0)
		{
			double returnVelocity = velocity-Rules.ACCELERATION;
			if(returnVelocity<-Rules.MAX_VELOCITY)
				return -Rules.MAX_VELOCITY;
			else
				return returnVelocity;
		}
		else
		{
			double returnVelocity = velocity-Rules.DECELERATION;
			if(returnVelocity<-Rules.ACCELERATION)
				return -Rules.ACCELERATION;
			else
				return returnVelocity;
		}
	}

	static private final double[] dispStopArray = 
		{0.0000,1.0000,2.0000,2.5000,3.0000,
		3.5000,4.0000,4.3333,4.6666,5.0000,
		5.3333,5.6666,6.0000,6.2500,6.5000,
		6.7500,7.0000,7.2500,7.5000,7.7500};
	static public double maxSpeedToStopInDisp(double displacement)
	{
		// Returns the biggest velocity the robot could go to this turn,
		// still being able to stop without overshooting. (Or if 
		// remaining displacement is less than 2, returns that)
                // This routine could be improved to match up with robocode's
                // older velocity selecting rules.
		if(displacement>=0)
		{
			if(displacement>=20)
				return 8.0;
			else if(displacement<=2)
				return displacement;
			else
				return dispStopArray[(int)Math.floor(displacement)];
		}
		else
		{
			return 0;
		}
	}

I also appreciate your effort, Fnl. :) --Positive 01:48, 13 July 2009 (UTC)

Ok, I'm up to speed with the discussions and the code. I think, for how it was decided, this line:

    newVelocity = Math.min(currentCommands.getMaxVelocity(),
        Math.min(Rules.DECELERATION * decelTime * decelTime + Rules.ACCELERATION * accelTime * accelTime,
        distance));

...should be changed to:

    newVelocity = Math.min(currentCommands.getMaxVelocity(),
        Math.min(Rules.ACCELERATION * accelTime, distance));

• The deceleration already takes you to zero, so we just need to use the remaining time for acceleration, right?
• Don't need to square the accelTime (v = at).

So, as I understand it, your velocities should be, for example: -1, +0.5, -0.75, +0.625? "Legacy" issues aside, I like this solution a lot. It makes sense. I've been considering this issue a bit now, and here's how I'd lay out the impact to affected bots:

• A bot like PrairieWolf that oscillates between 1 and -1 will now oscillate between roughly 0.7 and -0.7. I'm guessing this has very minimal impact on performance (though I am curious to test / confirm).
• When Wave Surfers predict a change of direction, their predictions could be off. I believe most surfers are dealing with whole number velocities the great majority of the time. Changing direction from even velocities will not be impacted. Changing direction from odd velocities, their predictions could be off by as much as 4 pixels -- predicting a velocity 0.5 too high for 8 ticks (until they reach max velocity). Some might disagree, and of course I advocate ultimate precision in surfing, but I believe the impact here is negligible. (How many of us even do precise bot width? And I never found much to be gained there, anyway.)
• I'm still not crazy about changing Robocode's physics, and I might've opposed it if put to a vote, but I think the impact is negligible and the new solution is a good one.

Also, I've started running those SilverSurfer WSC tests on 1.6.1.4 and 1.7.3 to compare. I'll have the results today or tomorrow.

--Voidious 15:31, 13 July 2009 (UTC)

The information in Robocode (mostly the floating point value) isn't digital, means that only 0.5 change isn't impact much. If you can dodge bullets well, the missed 2 ticks with the most of 2 pixels won't make the bullet hit you. If you can't dodge it, the slippage of 2 pixels may make you dodged it, but only by luck. » Nat | Talk » 16:14, 13 July 2009 (UTC)

<Edit conflict> Thanks for taking a look Fnl. I personally think that the current code is more complicated than necessary, and as such, harder to understand. Here's a few things that should be addressed:

• The decelDist. Because robocode follows a discrete time base, it cannot be approximated with calculus. For example, say your speed is 3, your formula gives 3.75 as decelDist. However, 3 + 1 + 0 = 4, so your code would not want to decelerate in the right places. This would be the correct implementation:

       private static final double decelDistance(double velocity){
         double distance = 0;
         while(velocity > 0){
            distance += velocity;
            velocity = Math.max(0,velocity - Rules.DECELERATION);
         }
         return distance;
      }

• One of the ideas of robocode is that your bot has a continuous acceleration/deceleration over a single tick. I see what you have done is, when a bot is decelerating over 0 velocity, it takes 1/2 of the tick to decelerate and then 1/2 of the tick is left to accelerate in the other direction (the split may depend on the amount of time taken to decelerate to 0 first). But many older bots rely on being able to decelerate over the entire tick, using the 2 deceleration value instead of the 1 acceleration value, so that they can 'vibrate' from 1 to -1 back to 1 etc. While I agree that it is not correct, these are the physics of robocode, not real life =) Because of this, you can essentially remove the majority of the inside of that 'if' block, just leaving velocity *= -1;.
• I have re-written this method, and if people want I'll post it, but it seems that with a few quick fixes this one should be up to scratch =), so I don't really think that's necessary.

As an answer to Voidious, I haven't taken any of the 'quirks' into account while writing DrussGT. It is coded with the rules, as they are described on the Robocode/Game_Physics page, in mind. --Skilgannon 16:00, 13 July 2009 (UTC)

(edit conflict) In my tests, DrussGT usually performs worse. But just around 0.2% or somethings. I'm not sure since I ran only 3 35-rounds tests.

While I agree with you that this isn't real life, it still isn't correct under its own Rules. The major reason we have this fix is that we want Robocode to follows its own rule batter. Otherwise we should have the bullet velocity affected by robot velocity, the curved bullet, better bullet-bullet collision checking etc. » Nat | Talk » 16:14, 13 July 2009 (UTC)

Sorry, but 3 battles simply cannot produce a result within 0.2% accuracy. In my experience, you'd need 100 or more before the overall result stays within 0.2%. --Voidious 17:40, 13 July 2009 (UTC)

Hi guys. Thank you for the constructive feedback. I appreciate that. I see many of you have some really good pointer of what to change, and where to make the changes. Currently, I have my house full of guests and is just checking what is going on in this forum. Tomorrow evening, I will take a closer look at all the comments, and I agree that the new implementation for "update movevement" is buggy too. I intend to create some variants that you can download and test for yourselves. Afterwards, you can choose which one is the better one for the next version of Robocode. Compared to 1.6.x.x, the code has become much simpler than it was before. I am not sure that the code could be any simpler than it is now as we will brake something else (because something is missing) - even though I hope it is possible. So, tomorrow I will review all comment on this page and take action. =) --Fnl 17:43, 13 July 2009 (UTC)

I really agree that the code is a lot more simple and adaptable than 1.6 and before. When I was adapting the internal Robocode's movement engine for my movement predictor, I can't adapt the <1.6 code. I get my head mess when I'm trying to understand it. However, I can adapt the current code really easy (in fact, I did copy almost whole getNewVelocity() method) » Nat | Talk » 12:37, 14 July 2009 (UTC)

I have examined all the comments here, and is trying to figure out how to modify the existing code for getNewVelocity(). I think you are on the right track Voidious, and hence I want to implement your modifications so we could all try them out. However, I have a hard time figuring out how the modified version of getNewVelocity() will look like. If a change the part for the newVelocity, it must be in the two places in the code, where it is assigned. You have only written how you want the first one. Voidious, could you give the full version of your version of getNewVelocity() as you think it should be? This way we all will be able to follow (and discuss) the changes/ideas, and I will be able to implement it straight away. :-) --Fnl 22:28, 14 July 2009 (UTC)

Sorry, I was only closely examining the decelerating through zero issue before. I agree with Skilgannon's assessment that decelDist doesn't seem right, though I'm not sure I'm understanding this fully. Skilgannon, you say that decelDist(3) should be 4, but shouldn't it be 1, since we can update the speed before we move? In either case, I don't understand why it would be 3.75, but I'm curious if there is some voodoo at work in this code that I'm not getting yet. I'll study some more and try to figure it out. =)

And Skilgannon, no harm in posting your rewritten version, I wouldn't mind seeing it. I'll also check out Positive's version. And I'll have some 1.6.1.4 vs 1.7.1.3 WSC2K6 scores ready to examine tomorrow. Only about 180 more seasons to run. =)

--Voidious 00:23, 15 July 2009 (UTC)

• My understanding (and subsequently, DrussGT's movement simulator, which uses a decelDistance based method of deciding when to decelerate) is if we go with the velocity of 3 this tick, how far will we travel in total if we decide it's necessary to decelerate next tick. Basically, do we have freedom with to do as we please with our velocity this tick, and still be able to decelerate sufficiently in the future. If the answer is "no", then we need to decelerate or maintain velocity this tick. My statements about 4 and 3.75 assumed the DECELERATION is 2. Fnl gets 3.75 from this little bit of code:

final double decelTime = speed / Rules.DECELERATION;
final double decelDist = 0.5 * Rules.DECELERATION * decelTime * decelTime + decelTime;

ie. 3/2 = 1.5 --> 0.5*2*1.5*1.5 + 1.5 = 3.75 whereas it should be 3 + (3-2) = 4. I'll be very interested to see what the scores look like =) --Skilgannon 08:59, 15 July 2009 (UTC)

Wow, this problem really is not trivial. Here's what I came up with, I think it works and is pretty minimal:

    private void updateMovement() {
        double distance = currentCommands.getDistanceRemaining();

        if (Double.isNaN(distance)) {
            distance = 0;
        }

        velocity = getNewVelocity(velocity, distance);

        double dx = velocity * sin(bodyHeading);
        double dy = velocity * cos(bodyHeading);

        x += dx;
        y += dy;

        if (dx != 0 || dy != 0) {
            updateBoundingBox();
        }

        if (distance != 0) {
            currentCommands.setDistanceRemaining(distance - velocity);
        }
    }

    /**
     * Returns the new velocity based on the current velocity and distance to move.
     *
     * @param velocity the current velocity
     * @param distance the distance to move
     * @return the new velocity based on the current velocity and distance to move
     */
    private double getNewVelocity(double velocity, double distance) {
        // If the distance is negative, then change it to be positive and change the sign of the input velocity and the result
        if (distance < 0) {
            return -getNewVelocity(-velocity, -distance);
        }

        double newVelocity;

        // Get the speed, which is always positive (because it is a scalar)
        final double speed = Math.abs(velocity); 

        if (velocity < 0) {
            // Check if we are decelerating, i.e. if the velocity is negative.
            newVelocity = speed - Rules.DECELERATION;

            // Check if we are going from deceleration into acceleration
            if (newVelocity < 0) {
                // If we have decelerated to velocity = 0, then the remaining time must be used for acceleration
                double decelTime = speed / Rules.DECELERATION;
                double accelTime = (1 - decelTime);

                // New velocity (v) = d / t, where time = 1 (i.e. 1 turn). Hence, v = d / 1 => v = d
                // However, the new velocity must be limited by the max. velocity
                newVelocity = Math.min(Rules.ACCELERATION * accelTime, distance));

                // Note: We change the sign here due to the sign check later when returning the result
                velocity *= -1;
            }
        } else {
            // Deceleration distance (d) is calculated iteratively due to Robocode's
            // discrete time system.
            final double decelDist = decelDistance(speed);

            // Deceleration ticks is the number of ticks it will take to get to
            // zero velocity. 
            final long decelTime = Math.round( // VOIDIOUS: for rounding errors? maybe unnecessary
                Math.ceil((speed - Rules.DECELERATION) / Rules.DECELERATION));

            // The maximum distance coverable with an equivalent decelTime
            final double decelTimeMaxDist = ((decelTime + 1) / 2.0) * decelTime // sum of 1..decelTime
                * Rules.DECELERATION;
                
            if (distance <= Rules.DECELERATION) {
                // If we can cover remaining distance and then completely stop,
                // set speed = distance
                newVelocity = Math.max(speed - Rules.DECELERATION, distance);
            } else if (distance <= decelTimeMaxDist) {
                // If we can cover distance in decelTime, split any extra
                // distance (between decelDist and distance) over decelTime
                // ticks
                newVelocity = speed - Rules.DECELERATION + 
                    ((distance - decelDist) / decelTime);
            } else {
                // If we need more than decelTime ticks, try to spread the
                // extra distance over (decelTime + 1) ticks. This will just max 
                // the acceleration if it needs to (ie, if we need more ticks).
                // VOIDIOUS: I think this part would break if Rules.ACCELERATION
                //           were set above Rules.DECELERATION; we might need an 
                //           extra case or something. Doh. =(
                newVelocity = Math.min(speed + Rules.ACCELERATION,
                    (decelTime * Rules.DECELERATION) +
                        ((distance - decelTimeMaxDist) / (decelTime + 1)));
            }
        }

        // VOIDIOUS: I think it makes more sense to do this here; no need to decelerate maximally
        //           if you don't need to to accomodate a new setMaxVelocity.
        newVelocity = Math.max(speed - Rules.DECELERATION, 
            Math.min(newVelocity, currentCommands.getMaxVelocity()));
            
        // Return the new velocity with the correct sign. We have been working with the speed, which is always positive
        return (velocity < 0) ? -newVelocity : newVelocity;
    }

    private static final double decelDistance(double speed){
        double distance = 0;
        while(speed > 0){
            speed = Math.max(0,speed - Rules.DECELERATION);
            distance += speed;
        }
        return distance;
    }

Velocity is updated before the bot moves, right? =) This is a serious brain teaser! Wanted to post what I had before bed, but I'm still not satisfied with the part that would break with different accel/decel values. --Voidious 05:06, 15 July 2009 (UTC)

(maybe we should move this lengthy discussion to another page?) I've been going through the new velocity formula and have similar concerns as Skilgannon. Just running some test cases using my VelocityTest class and have found cases where the bot overshoots the requested distance (e.g. try starting velocity 0, distance 6 -- the bot ramps up to velocity 3 and will thus overshoot badly). I'll put together some tests and then maybe make a fixed version of the routine.

Regarding deceleration through 0, I have to sympathize with Fnl et al. There's nothing in the rules that says a bot can decelerate through 0 and gain some free acceleration. Deceleration takes you towards 0, acceleration takes you away from it. It's a quirk -- often called a "bug" -- that was perhaps first publicized here (near bottom) and has been exploited since. Its not a huge quirk, the advantage is minimal so fixing it should also be minimal but only tests can really confirm this.

--Darkcanuck 05:09, 15 July 2009 (UTC)

Hey Fellas. Great you're doing more research into this! I think the -1, +1 thing is not a major issue, but if the incorrect movement handling bugs can be fixed in a way that the -1, +1 thing stays valid, is there any harm? I think the version I posted is simpler to understand, and it should work effectively. The only thing that you might not agree with is the working of the maxSpeedToStopInDisp function, but that should at least centralize the problem. :) --Positive 05:53, 15 July 2009 (UTC)

I'm sorry I haven't examined yours more. There are two reasons, really:

• It does look like you're solving the problem efficiently (and I assume correctly), but I think it depends on fixing one or all of Rules.DECELERATION, Rules.ACCELERATION, and maximum velocity=8. I think we want a solution independent of those values.
• I find this quite an enjoyable brain teaser, and just wanted to figure out an answer myself. =)

--Voidious 13:26, 15 July 2009 (UTC)

The reason I don't like breaking the +-1 thing is because it makes the precise prediction significantly more complicated, and what's more it assumes that the acceleration has more than one value between 2 ticks, which to me seems to break the whole concept of a discrete time interval. For interests sake, here's the one I wrote:

    private void updateMovement() {
         double distance = currentCommands.getDistanceRemaining();
      
         if (Double.isNaN(distance)) {
            distance = 0;
         }
      
         velocity = getNewVelocity(velocity, distance);
      
         double dx = velocity * sin(bodyHeading);
         double dy = velocity * cos(bodyHeading);
      
         x += dx;
         y += dy;
      
         if (velocity != 0 ) {
            updateBoundingBox();
         }
      
         if (distance != 0) {
            currentCommands.setDistanceRemaining(distance - velocity);
         }
      }
   
   /**
    * Returns the new velocity based on the current velocity and distance to move.
    *
    * @param velocity the current velocity
    * @param distance the distance to move
    * @return the new velocity based on the current velocity and distance to move
    */
       private double getNewVelocity(double velocity, double distance) {
      
         if (distance < 0) 
            return -getNewVelocity(-velocity, -distance);
      	// If the distance is negative, then change it to be positive
      	// and change the sign of the input velocity and the result
         
         double maxVel = currentCommands.getMaxVelocity();
         if (velocity < 0)
            return Math.min(velocity + Rules.DECELERATION, maxVel);
         //we want to go in the opposite direction, so decelerate   
         	
         else{ 
         //we are going in the direction we want, test what happens if we accelerate
         
            double accel = Math.min(Rules.ACCELERATION, maxVel - velocity);
            //speed up, but not more than max velocity. decel if maxVel is less than velocity.
         	
            accel = Math.max(accel, -Rules.DECELERATION);
             //prevent excess deceleration due to bot lowering the maxVel while velocity is high
            
            if (distance > decelDistance(velocity + accel))
               return velocity + accel;
            else if(accel != 0 && distance > decelDistance(velocity))
               return velocity;
            else{
               if(distance < Rules.DECELERATION 
               //we'll be able to cover remaining distance in 1 tick and then decel to stop
               
               && velocity - distance <= Rules.DECELERATION 
               //and our velocity is low enough for us to get to that required velocity
               )
                  return Math.min(distance, maxVel);
             //choose the velocity to cover all remaining distance        
            			
               return Math.max(-maxVel, velocity -  Rules.DECELERATION);
            //velocity > 0 and we are close enough, so decelerate. 
            }
         
         }
      
      }
    /**
    * Returns the linear distance it would take to decelerate from a given positive velocity
    *
    * @param velocity the positive velocity from which to test
    * @return the linear distance required to decelerate to a standstill
    */
       private static final double decelDistance(double velocity){
         double distance = 0;
         while(velocity > 0){
            distance += velocity;
            velocity = Math.max(0,velocity - Rules.DECELERATION);
         }
         return distance;
      }  

I'm fairly sure this fixes the 0,6 test Darkcanuck is doing. Voidious, one of the problems with your decelDistance() implementation is that your decel distance assumes you decelerate before adding the distance, whereas mine checks if we can still accelerate this tick and be able to decelerate sufficiently in the future. Also, mine considers the case of continuing at the current velocity, which may be a better option, as in the 0,6 test. --Skilgannon 08:27, 15 July 2009 (UTC)

(I agree about moving this to a different or its own page. Anyone can feel free, or I'll do it in a bit.) Ah, I'm just imagining a different significance to decelDist: I imagine it as the minimum distance we would cover if we slam on the brakes. The problem with the (0, 6) case (more specifically the (2, 3) case) in mine is similar to the problem I theorize about when Rules.accel is greater than Rules.decel: I assume that if you can't cover distance in decelTime ticks, you can split the extra distance over (decelTime + 1) ticks, which of course is 1 tick and you go to speed 3. Maybe I should force decelTime to a min of 1, since if it's 0 and distance <= Rules.decel, we hit the first case and don't use it, otherwise we hit the 3rd case and need 2 ticks.

Mine would also remain at constant velocity if needed, or even speed up a bit, despite lack of a special case. I'll have to investigate that 0 to -2 acceleration... hopefully that's a simple fix.

I forgot that you'd already be familiar with this kinda stuff, since you are the Lord of Go-To. =) But I still see a problem with yours in that you restrict your decisions to max accel, constant, or max decel. Take the v=6.1, d=15 case: you want to do it in 4 ticks, and mine will (I think =)) go 6.75, 4.75, 2.75, 0.75. I think yours would go 6.1, 4.1, then be presented with (4.1, 4.8) and fail to do it in 4 ticks.

I swear there must be a known Dynamic Programming problem that reduces to this. Maybe my effort would be better spent finding it and copying the established solution. =) To be clear, we are trying to do this in the optimal number of ticks, right?

--Voidious 13:26, 15 July 2009 (UTC)

I'm about to move this discussion elsewhere... --Voidious 13:56, 15 July 2009 (UTC)

Now that everyone's ELO rating is subzero in General 1v1 =), is it maybe time to retire it altogether?

I'm all for it =) Although, doesn't the LRP depend on ELO data? Maybe shift that over to Glicko data instead? And if there was some way to make the LRP show the 'expected' option by default... that would make my day =)

I'd also support removal of ELO from the rumble, and replacing it with Glicko or Glicko2 in the places that use it (LRP).

I also agree

Yeah, ELO doesn't do much anymore. So agreed as well.

Elo is working fine, even with negative scores, but keeping both Elo and Glicko-2 is redundant. So, removing one of them is fine by me.

Luckily we still have the music . . .

FatalFlaw's uploads have suspicious APS for Tomcat:

• lxx.Tomcat 3.55 VS voidious.mini.Komarious 1.88
• lxx.Tomcat 3.55 VS "baal.nano.N 1.42
• lxx.Tomcat 3.55 VS gf.Centaur.Centaur 0.6.7

Darkcanuck, can you rollback all his uploads?

Results from kidmumu uploads don´t come close to my uploads. Is there something wrong?

I haven't had a chance to check if this could affect mn.Combat, but my #1 guess would be that perhaps it's a java version issue (i.e. kidmumu is using Java 5 and Combat requires Java 6?).

Failing that, I'd have to think that kidmumu's client may be skipping turns.

[Combat vs Corners]

[Combat vs MyFirstRobot]

[Combat vs TrackFire]

Probably a Java version issue. I´ll downgrade to 1.5 in future versions. But didn´t check other bots scores.

I'm sure there are lots of bots that require Java 6, right? We might want to have Darkcanuck rollback all his uploads until we can get kidmumu onto Java 6.

I find that until all pairings is done it's very useful to know current avarage difference in APS between two versions - after about 100 random battles this number says fairly exactly is newer version better, than older.
Darkcanuck, can you schedule to add row for columns "% Score", "% Survival" in section "+/- Difference" in bots compare page with avarage value of corresponds columns? I think, there're work for 1-2 hours maximum

I think this is already covered by the 'Common % Score (APS)' and 'Common % Survival', the lowest two lines in the top-table. At least I use it to check if my changes have a positive (or negative) result when the pairings are not complete yet.

No. May be i wrote not clear.
I mean, that i want to know average difference in pairings between 2 versions. According to my tests, this number stabilizes mach faster, than APS. And more, Common % Score does not make sense, because while there only 1 battle in every pairing it's exactly equals to APS and in another case, there may be 10 battles against Walls and 1 battle against Druss.

As far as I know, when your new version has for example 100 pairings, you will see the average APS for that 100 pairings. AND for your older version you will also see the APS for that 100 pairings. And you are right, this indicates much more reliable what your final score will be (relative to your older version) than plain APS. The one who can really answer this question is Darkcanuck.

Wow, if things is like you say, it's really what i want, thanks:)

The common %score is calculated just like APS, but only for pairings that the old and new versions have in common. That makes it easier to compare two versions when the new one is still missing many pairings, or in the case where the old bot may have pairings against a lot of retired bots (and may be missing scores vs newer bots). I think that's what you're looking for...

Yes, thank you:)

Can you turn on .htaccess browser caching for results.

#Caching
ExpiresActive on
ExpiresByType image/gif "access plus 1 year"

Other performance enhancing things you can do are: Set specific size for the images, inline or via CSS. CSS would be easier. This would speed up the page loading and be also less annoying while all the requests are going through (having default sized images deforming the table before they load). Minify the HTML/CSS/JS (less to send).

Not doing/doable for known reasons: Serve identical files from the same url. (flag images)

Just added the cache expiry directives -- let me know if that helps. The minification isn't necessary, my server already sends all files gzip'd, so the performance enhancement would be minimal at best.