http://robowiki.net/w/api.php?action=feedcontributions&user=Ncj&feedformat=atomRobowiki - User contributions [en]2024-03-29T10:18:24ZUser contributionsMediaWiki 1.34.1http://robowiki.net/w/index.php?title=Talk:RoboRumble&diff=19313Talk:RoboRumble2011-05-18T15:36:07Z<p>Ncj: Check skipped turns?</p>
<hr />
<div>== RoboRumble history ==<br />
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ<br />
<br />
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar<br />
<br />
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar<br />
<br />
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar <br />
<br />
== Subpages ==<br />
Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)<br />
<br />
== Name ==<br />
<br />
Since the new wiki supports symbols in page names, should we put this page at [[RoboRumble@Home]] instead of RoboRumble? We already have a redirect from that page to this one... --[[User:AaronR|AaronR]] 23:34, 17 November 2007 (UTC)<br />
<br />
I second this change. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:30, 28 April 2009 (UTC)<br />
<br />
== RR seems to be down ==<br />
<br />
Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 03:07, 19 September 2008 (UTC)<br />
:Are you sure? Both [http://rumble.fervir.com/rumble/Rankings?version=1&game=roborumble rumble.fervir.com] and [http://abchome.aclsi.pt:8080/ ABC's] work for me. -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 03:33, 19 September 2008 (UTC)<br />
::I fail. I meant Robocode Repository. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 05:44, 19 September 2008 (UTC)<br />
::Not a big surprise there. =P -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 13:21, 19 September 2008 (UTC)<br />
<br />
Hi! What the heck happened to RR@H again? The main roborumble has only ~60 bots again... Otherwise, I uploaded Pugio 1.2 1 week ago and has only 120 battles in nanoRumble. Situation is the same in Darcanuck's page, too. Nobody is contributing?--[[User:Robar|HUNRobar]] 12:30, 11 October 2008 (UTC)<br />
<br />
Both ABC's server and DarkCanuck's server have no full pairings yet. Once the megabots have full pairings, the minirumble will get filled completely and as last the micro- and nano-rumble. Be patient, but it probably requires a few weeks before all nanobots have 1000 battles. Remember, 640 * 640 bots means a lot of battles! Pulsar's server has another issue. I don't know what happened, but I still run (repair)battles there. --[[User:GrubbmGait|GrubbmGait]] 13:14, 11 October 2008 (UTC)<br />
<br />
I realised that in Darcanuck's server the older versions of bots are still in game. I think the competitors there should be cleaned up. For example, I don't want to generate battles for Pugio 1.0 when I wait for the results of 1.2. --[[User:Robar|HUNRobar]] 14:57, 11 October 2008 (UTC)<br />
<br />
That's a temporary thing -- I'm uploading a huge amount of data from [[User:ABC|ABC]]'s server which includes old participants. There's a big performance hit to activating/retiring participants repeatedly, so for now everyone's in the rankings until I get caught up. But don't worry, no rumble clients will actually run these bots. They'll use only the version from the participants list. In a few days you should see the old bots disappear from the rankings. --[[User:Darkcanuck|Darkcanuck]] 15:03, 11 October 2008 (UTC)<br />
<br />
Whoops edit conflict, accidentally overwrote Darkcanuck's reply with this: "What versions get battles doesn't depend on the server, it depends on the participants list that clients are configured to (which should be the old wiki's one, the one here has not been synced for a long time). The server would have nothing to do with that so you shouldn't be generating battles for Pugio 1.0 unless your client is misconfigured I believe." Anyways Darkcanuck's reply clearly explains why there are currently old versions listed :) --[[User:Rednaxela|Rednaxela]] 15:10, 11 October 2008 (UTC)<br />
<br />
Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--[[User:Robar|HUNRobar]] 17:40, 11 October 2008 (UTC)<br />
<br />
Why can't I access ABC's server? My connection get timeout before it finished loading! -[[User:Nat|Nat]] 12:42, 6 January 2009 (UTC)<br />
<br />
== Lynch the Multi-Threaders! ==<br />
<br />
A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?<br />
# On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.<br />
# On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.<br />
This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we ''could'' enforce a rule saying that no multi-threaded bot is allowed in ''the rumble''! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --[[User:Simonton|Simonton]] 02:47, 23 September 2008 (UTC)<br />
<br />
Agreed. It isn't fair on the opposition, and makes it impossible to design a bot within the CPU-constant constraints. --[[User:Skilgannon|Skilgannon]] 10:34, 23 September 2008 (UTC)<br />
<br />
I either didn't see or forgot about this section. There are already bots that use multiple threads in the rumble: [[Toad]] definitely does, possibly [[X2]] (which shares some Toad code), and probably others. Not sure how I feel about removing them at this point, just contributing some facts here... --[[User:Voidious|Voidious]] 02:20, 7 August 2009 (UTC)<br />
<br />
Well, there are java APIs that allow things like only measuring the time used in a particular thread. Robocode could start to use these in order to make this fair, AND as a '''major''' bonus it would make using Robocode on a computer with a heavily loaded CPU not cause skipped turns. The issue is... those APIs don't give the same kind of resolution, thus meaning that the only way we do it would be if we calculated something more like "How much CPU time did threads of this bot use in the last 20 ticks?", instead of "How much time did this robot take between the start and end of this turn?" which would make skipped turns behave a bit different. Personally I think that may not be such a bad thing, but I'm not really entirely sure... --[[User:Rednaxela|Rednaxela]] 02:51, 7 August 2009 (UTC)<br />
<br />
: It looks like [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 this] &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:53, 7 August 2009 (UTC)<br />
<br />
:: Hm? "ERROR This artifact is not accessible." is what that page gives --[[User:Rednaxela|Rednaxela]] 13:11, 7 August 2009 (UTC)<br />
<br />
::: Sorry, I never noticed that this is 'private' tracker... Fnl thought that he needs more precise time and mem.usage detection. I have a comment on some time measuring much like to your "How much CPU time did threads of this bot use in the last 20 ticks?". However, we didn't mention a thread at all. But I believe that Robocode allow Robots to create up to 5 threads, I'll email Fnl this. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:53, 7 August 2009 (UTC)<br />
: The [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 tracker] is public now. :-) Basically, I want to measure the CPU usage with the new features in Java 5.0 for measuring the exact CPU per thread. Hence we will (when using the TheadMXBean) know for a fact exactly how much time all threads in a robot is using in total. However, the time interval when measuring using the ThreadMXBean is big compared to what we are used to with the CPU constant currently used in Robocode. So we need a solution that can deal with this issue. I have waited with this improved feature as this will have a big impact on the scores for the robots in the RoboRumble. We have already seen how much difference the getNextVelocity() makes, so imagine the difference when we make change the concept behind the CPU constant. --[[User:FlemmingLarsen|Fnl]] 21:07, 7 August 2009 (UTC)<br />
:: Personally, I'm actually not too worried about the impact of this change. Most bots don't skip many turns at all, and the effects of a few skipped turns are often overstated. As long as the average amount of CPU allowed per tick is still similar, I can't imagine it affecting scores too much. I suppose it might have a big impact on bots that abuse the currently untracked multi-threading, but I think we can all agree that they're sort of abusing the system right now, anyway. Of course, I'd be happy to run extensive tests, too. =) --[[User:Voidious|Voidious]] 21:55, 7 August 2009 (UTC)<br />
:: I'm agreement with Voidious on this. I doubt there would be any problems caused by this so long as the correct amount of time was chosen. I would say though, that I think that this feature should be targeted at a 1.7.1.5 release, for the same reason that it's generally considered bad practice to change both a bot's movement and gun in the same rumble iteration, haha. As a side note, I wonder if while we improve the measurement method to not be affected by other things on the system, that maybe we should also improve the cpu constant calculation. For one, it should use the same ThreadMXBean methods to be accurate, but also I wonder if we could have a more realistic benchmark of what a typical bot actually does with it's time. I propose we include a small suite of some of the things a more cpu intensive bot does in order to create a more representative benchmark. I propose coding a small suite consisting of something like the following: 1) KD-Tree, 2) Nanobot-style pattern matching, 3) Array operations (searching for peak, addition of a gaussian curve to an array, multidimensional array access), 4) 'Play-It-Forward' simulation, 5) GF calculation (aka simple trig). I think I'll begin a page for comments on and code for an improved benchmark --[[User:Rednaxela|Rednaxela]] 00:00, 8 August 2009 (UTC)<br />
:: 1.7.1.5? It was there for about eight months. I think maybe 1.8 or so... &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:10, 8 August 2009 (UTC)<br />
<br />
== What Now? ==<br />
<br />
How can I submit the new versions of DrussGT and Cunobelin? Has anybody heard any news on the old wiki? Will it be recovered? Is it gone forever? --[[User:Skilgannon|Skilgannon]] 15:47, 8 December 2008 (UTC)<br />
<br />
Well on November 30th I emailed PEZ and got a reply that it's an ugly error and that he'd look into it. I haven't heard anything since but I guess I might email PEZ again. I certainly hope it won't be gone forever as I'd at least like to have a read-only version due to how much great stuff there is there that's unmigrated. --[[User:Rednaxela|Rednaxela]] 16:12, 8 December 2008 (UTC)<br />
<br />
I really hope the old wiki content still lives on. In the meantime we could agree to use this wiki's list for my server. I don't have time this week to make the proposed participant list changes, but I could lock out add/removes for all but a few select clients to make sure we all use the same list? --[[User:Darkcanuck|Darkcanuck]] 18:28, 8 December 2008 (UTC)<br />
<br />
Well, the old wiki is back! I do wonder though, should we switch to using this wiki's participants list anyway? or should that wait till some other day in the future? --[[User:Rednaxela|Rednaxela]] 18:17, 9 December 2008 (UTC)<br />
<br />
: I'd like to keep using the old wiki at least until I can code up something to validate participants on the server side. Then it would be easier to switch and not have to worry about some clients using the wrong list. --[[User:Darkcanuck|Darkcanuck]] 05:39, 10 December 2008 (UTC)<br />
<br />
Random question: How much do you think the local client would speed up if I compiled it natively? Right now, we haev a bit of a bottleneck figuring out battles andif we could speed it up by a factor or 3 or so, why not? --[[User:Miked0801|Miked0801]] 21:52, 25 May 2009 (UTC)<br />
<br />
== Nanos get little love when things get busy ==<br />
I've been waiting for nearly 4 days for my latest bot to get to 2k battles against nanos, and I'm probably gonna have to wait 3 more for it to happen. Why? Nanos, after they get to their 1 battle per bot limit, are the last bots to be updated under the current system. I understand why the system was done this way, but is there anyway we can add a time component to the battle chooser to make sure that when things heat up in the rumble, nanos get some love as well? --[[User:Miked0801|Miked0801]] 20:47, 19 June 2009 (UTC)<br />
<br />
I hear ya. Even in Mega-land, it can take a while to get to 2k battles, and I don't really trust a rating until it does (even with all pairings). There are some RR client options you could try, like excluding bots or running NanoRumble only, but the latter will just do random battles, I think. A couple of nice client side options, imo, would be mini/micro/nano while still honoring pairing priority, and ignoring pairings while running bots with under NUMBATTLES (in all applicable rumbles). I'm definitely in favor of RR contributors having control over what battles they want to run... --[[User:Voidious|Voidious]] 22:48, 19 June 2009 (UTC)<br />
<br />
Nanos get ''way'' more than their fair share of processing time. By a time a nano reaches 2000 battles in its own class, it has typically reached 5000+ battles in the main rumble. Few, if any, megabots have yet to reach that level. Not only is it unfair to folks releasing larger bots, it also takes away cpu time from other nanos. So should we abolish nanos? Of course not!<br />
<br />
I'd vote for changing the client's battle selection such that when a new bot reaches full pairings, the remainder of its 2000 battles are fought against opponents in its own size class. Those battles will still count for the higher classes, so a nano would really only need 2000 battles overall. This would mean faster results for nanos and more cpu time for everyone else, regardless of size. --[[User:Darkcanuck|Darkcanuck]] 03:19, 20 June 2009 (UTC)<br />
<br />
I second Darkcanuck's suggestion, as it seems most fair to me. :) --[[User:Rednaxela|Rednaxela]] 05:12, 20 June 2009 (UTC)<br />
<br />
And yet, some nanos love to beat up on their larger sibling... But yes, when things slow down, nanos do get a ton of extra battles, but to be fair, most nanos run much, much faster than megas so the hit isn't that bad. My main concern was waiting at the back of a line of never ending micro/mega selections. Impatients and such. If we're going to change things to minimize waits, then first completing pairings, then 2k in class, then low priority updates across other classes would be awesome. Unlike melee, just 2 or 3 battles with a mega are usually sufficient to get a strong idea of where things stand. --[[User:Miked0801|Miked0801]] 09:10, 20 June 2009 (UTC)<br />
<br />
You can also set RUNONLY=NANO, but alas then no priority battles are fought, just random ones. And I set the battlecount to 1000, so nanos will get their battles earlier. --[[User:GrubbmGait|GrubbmGait]] 10:51, 20 June 2009 (UTC)<br />
* setting RUNONLY=NANO is not a good idea. The results only count for nano, so is not counted at micro/mini/mega. Setting the battlecount lower does pay off however, except when the bigger rumbles are flooded with new versions. --[[User:GrubbmGait|GrubbmGait]] 11:00, 20 June 2009 (UTC)<br />
<br />
It would be awesome if roborumble could execute smart battles with runonly parameters. For example, run prioritary battles but only among nanos. I don't think it would be such a difficult developement. --[[User:Robar|HUNRobar]] 14:33, 20 June 2009 (UTC)<br />
<br />
: I think the RUNONLY setting needs to be fixed -- as [[GrubbmGait]] pointed out, the battles don't get uploaded to the bigger size classes, which they should. I might put together a patch for this, but first I have some wave surfing to iron out... --[[User:Darkcanuck|Darkcanuck]] 17:41, 20 June 2009 (UTC)<br />
<br />
About battlecount, one habit I have, is constantly making my battlecount set to just a little above the lowest value in the rumble. That seems to have nice results sometimes. --[[User:Rednaxela|Rednaxela]] 16:03, 20 June 2009 (UTC)<br />
<br />
All right, I think I've figured out how to implement the change I suggested, plus fix the RUNONLY problem. If enough people are ok with this, I'll put together a patched 1.6.1.4 client with the changes and send the patches to [[Fnl]] for future releases too. --[[User:Darkcanuck|Darkcanuck]] 18:21, 21 June 2009 (UTC)<br />
<br />
: Quick question: Would this only affect the 1v1 pairing order? I definitely support it there, but making your suggested change in Melee pairings would have a major impact on some bots' scores... And thanks as always for your RoboRumble efforts! --[[User:Voidious|Voidious]] 19:33, 21 June 2009 (UTC)<br />
:: Only at first. The game already does all class battles for roughly 50% of the numbers in nano now. That's why [[DustBunny]] has been slowly rising in APS - he does worse in nano only. --[[User:Miked0801|Miked0801]] 20:42, 21 June 2009 (UTC)<br />
::: Well, right now a NanoBot gets 2,000 battles against the whole field, then a bunch against MiniBots and below, then MicroBots and below, then NanoBots. With this change, it would get some amount of battles against the whole field, then all NanoBot-only battles. Depending on the bot, I think it could have an impact. Then again, that's a quirky aspect of MeleeRumble that's tough to really regulate, anyway, so maybe it's not worth worrying about. --[[User:Voidious|Voidious]] 21:51, 21 June 2009 (UTC)<br />
:: Ah, good point, I hadn't considered melee. It does use a different routine for preparing battles though, so it's possible to patch 1v1 without affecting melee. Looking at the melee routine, it does create an interesting mix of battles -- I didn't realize that there were all-nano matchups. That must skew the scores depending on the ratio of battles a nano gets with mixed sizes versus all-nano? --[[User:Darkcanuck|Darkcanuck]] 02:15, 22 June 2009 (UTC)<br />
: I don't think it is a bug, i think it was made on purpose the way it is. Alas I don't remember the reason . . . --[[User:GrubbmGait|GrubbmGait]] 21:03, 21 June 2009 (UTC)<br />
<br />
== Mobile Devices ==<br />
<br />
Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --[[User:Rednaxela|Rednaxela]] 02:01, 7 August 2009 (UTC)<br />
<br />
* Definitely crazy. --[[User:Simonton|Simonton]]<br />
<br />
I think you're crazy, but only because the iPhone OS doesn't have Java. =) I actually just looked into this the other day, lol. Was there some tech you were looking at to make it work? --[[User:Voidious|Voidious]] 02:03, 7 August 2009 (UTC)<br />
<br />
Actually, when you don't limit yourself to the app store, there is a port of [[wikipedia:JamVM|JamVM]] w/ [[wikipedia:GNU Classpath|GNU Classpath]]. There's no JIT so it won't be fast... but it'll run.. or... almost:<br />
<pre>Iteration number 0<br />
Downloading rating files ...<br />
Downloading participants list ...<br />
Downloading missing bots ...<br />
Removing old participants from server ...<br />
Preparing battles list ... Using smart battles is true<br />
Prioritary battles file not found ... <br />
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)<br />
at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)<br />
at robocode.manager.RobocodeManager.initSecurity(Unknown Source)<br />
at robocode.control.RobocodeEngine.init(Unknown Source)<br />
at robocode.control.RobocodeEngine.<init>(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)<br />
at roborumble.RoboRumbleAtHome.main(Unknown Source)<br />
Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path<br />
at java.lang.Runtime.loadLibrary(Runtime.java:763)<br />
at java.lang.System.loadLibrary(System.java:662)<br />
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)<br />
at java.lang.VMClass.forName(Native Method)<br />
at java.lang.Class.forName(Class.java:233)<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)<br />
...7 more<br />
</pre> It seems that both:<br />
# RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line<br />
# The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only<br />
Were it not for one or the other of those issues, it'd probably run just fine... Now can i fix this I wonder... --[[User:Rednaxela|Rednaxela]] 02:13, 7 August 2009 (UTC)<br />
<br />
Wow, that would be really cool. But I'm a wuss and I'm afraid to jailbreak and void my iPhone's AppleCare; I was thinking more from the perspective of writing an iPhone app myself that could do it. Good luck, though, I'm curious to hear your results! --[[User:Voidious|Voidious]] 02:17, 7 August 2009 (UTC)<br />
<br />
Aha! I got around that stupid issue! I just had to pass the VM <code>-Djava.awt.headless=true</code>... When you see rumble uploads with a user of "RednaxelaIPod", that'll be it :) --[[User:Rednaxela|Rednaxela]] 02:32, 7 August 2009 (UTC)<br />
: Ouchie, building the robot database this first time sure isn't fast... --[[User:Rednaxela|Rednaxela]] 02:39, 7 August 2009 (UTC)<br />
<br />
Sadly, while it mostly ran, it didn't quite work:<br />
<pre>java.lang.ArrayIndexOutOfBoundsException: 1<br />
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27<br />
5)<br />
at java.util.AbstractList$1.next(AbstractList.java:354)<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
java.lang.NullPointerException<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
</pre> Though if a workaround can be found for those issues (most likely bugs in the version of GNU Classpath in question. May not apply to newer versions, or a patched robocode might be able to work around it), it may work. Not sure that'll be possible though. Oh well... --[[User:Rednaxela|Rednaxela]] 03:54, 7 August 2009 (UTC)<br />
<br />
== Rumble Computers ==<br />
<br />
I'm curious, what kind of computers are people using for roborumble? [[Voidious]] and [[Simonton]] seem to really have some nice ones I think. Personally the computers I have avaliable to run rumble consist of:<br />
* Intel Core 2 Duo T5300 (1.73GHz), 2GB ram, laptop, usually avaliable<br />
* AMD Athlon XP 2000+, 512MB ram, often avaliable<br />
* AMD Athlon XP 2400+, 1GB ram, rarely avaliable<br />
I would also have my wimpy iPod were it not for one little bug preventing successful running of bots in the VM installed there. Sometimes... I'm really tempted to get a brand new shiney quad core monster for the sole purpose of storing backups, and running RoboRumble/Research :) --[[User:Rednaxela|Rednaxela]] 03:41, 16 August 2009 (UTC)<br />
<br />
I have:<br />
* MacBook 2.0 GHz Core Duo, 2 GB RAM, and I can run two clients on it safely. It's actually 3+ years old, but it holds up pretty well.<br />
* AMD 2000+, 768MB RAM (Ubuntu 8.10), which I've been running a rumble client on almost 24/7 for a while now.<br />
* Just yesterday, I ordered a MacBook Pro 2.8 GHz Core 2 Duo with 4 GB RAM. So that will more than double my total rumble power, I think. =)<br />
I wonder what [[User:Corbos|Corbos]] had, I couldn't have kept up with him if I tried when he was rumbling recently. I've also been tempted many times to spring for a quad core Linux box just for Robocode, but so far I've been able to resist... (mmm, quad core...) --[[User:Voidious|Voidious]] 03:55, 16 August 2009 (UTC)<br />
<br />
: Haha... I unfortuantely can't run two clients on my Core 2 Duo laptop... the CPU just plain gets too hot. What I really want to see though, is MXThreadBean timing in a new robocode version, which would make it safe to enable the option to allow robots to run concurrently, when in rumble... Then one could take advantage of a 8 beast when running melee rumble with only one client... --[[User:Rednaxela|Rednaxela]] 04:29, 16 August 2009 (UTC)<br />
<br />
My client runs on an old laptop -- all it does is run roborumble + meleerumble:<br />
* Intel Pentium M w/512MB ram, 100% available<br />
Occasionally I press my main machine (MacBook Pro, Core 2 Duo, 3GB) into service, but mostly I need it for work or running RoboResearch (that's what it's doing right now, in fact). It's also where the development rumble server lives, so this client is normally pointed at that anyway. Running both I was able to keep ahead of GrubbmGait for awhile until Voidious et al made our upload counts look puny by comparison.<br />
--[[User:Darkcanuck|Darkcanuck]] 04:26, 16 August 2009 (UTC)<br />
<br />
My client is a 2.66 Mhz Pentium4 (single-core) with 1GB. There was a time that I ran roborumble on a 400Mhz laptop with 128Mb using robocode 1.0.7. Btw, Darkcanuck, are you able to remove (or rename) those somewhat embarrasing contributions of GrubbmGait_15x and GrubbmGait_17x at the very low bottom. --[[User:GrubbmGait|GrubbmGait]] 11:08, 16 August 2009 (UTC)<br />
<br />
: Wow, 2.66 MHz!!?! :-D J/k. --[[User:Voidious|Voidious]] 15:04, 16 August 2009 (UTC)<br />
<br />
: It's done. I merged GrubbmGait_15x into GrubbmGait_154, and removed the lone battle from GrubbmGait_17x (the upload still shows up, merged into GrubbmGait). --[[User:Darkcanuck|Darkcanuck]] 17:38, 16 August 2009 (UTC)<br />
<br />
When I used to run it, I ran it on my Intel Centrino 2 P8400 2.26GHz with 4GB of RAM (but with 32bits OS it only sees 3GB) laptop, which I used for other works too. The time I run I only use FF to surf the web, but now I need to use Photoshop, Eclipse, LAMP and one virtual machine almost all the time so it doesn't available anymore. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 11:31, 16 August 2009 (UTC)<br />
<br />
I run my client in a Pentiun Dual Core 1.86 GHz, and I usualy run 2 clients, but right now I'm using it to test several new versions of my robot, so the rumble has to wait...--[[User:Navajo|Navajo]] 14:36, 16 August 2009 (UTC)<br />
<br />
== Lower Rank Limit? ==<br />
<br />
Wouldn't it be reasonable to remove bots that gets negative ELO Rating (i.e elvbot.ElverionBot(ELO: -191.0) & ry.Worst 1.0 (ELO: -365.3) ) ?<br />
<br />
They almost always score 0% and uses cpu-time while they contribute with near to nothing. --[[User:Rsim|Rsim]] 15:37, 16 August 2009 (UTC)<br />
<br />
== Whoops ==<br />
<br />
Err... sorry my client reactivated some old melee bots due to old data lying around, seems they crave pairings now... plus a large number of recently released melee bots... means sloooow melee right now... --[[User:Rednaxela|Rednaxela]] 05:10, 10 September 2009 (UTC)<br />
<br />
== Iteration ==<br />
<br />
I wonder if this happen to everyone or just me. When I run RoboRumble client, both 1.6.1.4 (which upload to darkcanuck's server) and 1.7.1.4 (which I use to test locally because it is faster), I found that after iteration 80 things got slower. I mean with 1.6.1.4 I can run 100 iteration in 4 hours, then another 4 hours it can run only 50-60 iterations. SO I tend to restart my client every 80 iterations. (and cool my hard disk down a little, it is around 80 degree Celcius when I run it for 150 iterations) Do anyone, especially who run RoboRumble overnight, have similar situation? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 03:10, 11 October 2009 (UTC)<br />
<br />
I've found that 1.6.1.4 still seems to have some long-term memory leakage actually. Not as bad as older version, but enough that it's still worth not using the ITERATE option actually. --[[User:Rednaxela|Rednaxela]] 03:54, 11 October 2009 (UTC)<br />
<br />
== JVM Crash ==<br />
<br />
After running the RoboRumble client (1.6.1.4) for about 12 hours, my JRE crashed. I have not been able to reproduce the problem, but I thought I'd post about here in the event it has happened to someone before. I've submitted a bug report to Sun and saved the logs [[http://www.devfluid.com/csc_club/JRE_Crash Here]]. It may not be relevant, but this happened when evaluating Krabb.sliNk.Garm 0.9u. --[[User:Christopher.Hilla|Christopher.Hilla]] 22:06, 7 February 2010 (UTC)<br />
<br />
Huh... that's a very peculiar bug. I doubt there's anything more to it other than there being a bug in the JVM though, assuming this isn't something you're able to repeat reliably. --[[User:Rednaxela|Rednaxela]] 22:48, 7 February 2010 (UTC)<br />
<br />
== Contributor's Sum ==<br />
<br />
I started contributing less than 30 days ago, yet my "All time" and Monthly sums don't match. My "All time" sum is much larger than what I've actually contributed. Even though my point tally is sort of like keeping score on "Whose Line Is It Anyway", it's worth mentioning :) --[[User:Christopher.Hilla|Christopher.Hilla]] 06:49, 9 February 2010 (UTC)<br />
<br />
: The monthly and 30-day totals are based on ''battles'', whereas the all-time list is number of ''uploads''. For a 1v1 battle between megas there is only one upload, but for smaller classes there will be one upload per size class (e.g. two nanos will generate 4 uploads). Melee is even more complicated since a full set of pairings for 10 megas will yield 45 uploads, even more if there are smaller bots in the mix. So your all-time uploads should be greater than the sum of the battles you've contributed so far. --[[User:Darkcanuck|Darkcanuck]] 07:41, 9 February 2010 (UTC)<br />
<br />
:: Thank you for the explanation. --[[User:Christopher.Hilla|Christopher.Hilla]] 19:49, 9 February 2010 (UTC)<br />
<br />
== Incomplete robot list == <br />
Hey Darkcanuck, I 've been running a few rumbles..and noticed I am missing a large number of bots " can't file specified file". Any Suggestions? Thx.. oh , I should mention Last night while Running an iteration envolving DR3.06 , Portia and 8 other bots. Something probably on my end screwwing up results for 1 battle. Not sure how, or why, but just one battle. -[[User:Jlm0924|Jlm0924]] 20:06, 27 April 2010 (UTC)<br />
<br />
== DogmanSPE ==<br />
<br />
I just ran a few tests to try and figure out the discrepancy between 1.8.0 and 1.8.2 of DrussGT, and now I can't repeat 1.8.0's results against DogmanSPE. I then decided to try a few rounds against Diamond 1.5.5, and it seems he also isn't living up to the scores he's getting on the rumble against DogmanSPE. The only thing I can think of is that it may be different versions of Robocode, as I'm doing my testing with 1.7.2b2. Any ideas? Maybe Dogman gets smart only at certain times of day? --[[User:Skilgannon|Skilgannon]] 15:06, 9 May 2010 (UTC)<br />
<br />
Eh, DogmanSPE is a major troublemaker and always has been. It sometimes doesn't crash, but when it does crash it crashes for every subsequent round of the battle. This makes it's results always unpredictable. It doesn't affect overall APS too badly because of the sheer number of bots, but it's probably the single worst offender in the rumble. Issues with DogmanSPE have [[oldwiki:RoboRumble/RankingChat|been pointed out before]]. Personally, I'm in favor of removing DogmanSPE. --[[User:Rednaxela|Rednaxela]] 15:25, 9 May 2010 (UTC)<br />
<br />
: So am I. Anyone object? --[[User:Voidious|Voidious]] 17:28, 9 May 2010 (UTC)<br />
<br />
:Done =) --[[User:Skilgannon|Skilgannon]] 19:17, 9 May 2010 (UTC)<br />
<br />
== LRP ==<br />
<br />
Perhaps we should have a section on what the LRP does. I mean most of use from the old wiki know but... Anyway in the words of Paul,<br />
<br />
<pre><br />
May seems a stupid question, but, what is the blue line, and the 4 quadrants?<br />
I can guess that on the X axis there is the expected score and on the Y the difference between expected and actual score.<br />
But what the blue line is supposed to mean? -- [[Simonech]]<br />
<br />
You are correct on the X axes and Y axes scales - the Blue line is a best-fit straight line through the data. if it has a negative<br />
gradient slopes downhill (left to right) I believe it would indicate that the movement for the bot is stronger than the gun. A<br />
positive gradient would indicate a good gun is being let down by relativley poor movement. -- [[Paul]]<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 04:55, 4 July 2010 (UTC)<br />
<br />
== Rumble use of 1.7.2.1 Beta? ==<br />
<br />
Guys, do you think that Robocode 1.7.2.1 will be good enough to replace the very old 1.6.1.4 for RoboRumble? If not, what must be done? --[[User:FlemmingLarsen|Fnl]] 22:06, 29 June 2010 (UTC)<br />
<br />
: The main problem I have with 1.7.2.1 is that objects from the data section in jars from inside zips at least do not get extracted to the cache. I also have problems with duplicate robots in the repository (mostly only ones on the development path). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 00:57, 30 June 2010 (UTC)<br />
<br />
:: Huh, I was under the impression that the data files were extracted properly still. (note, it's technically not a robotcache anymore). Also, what do you mean by duplicate robots, and is this different than older versions? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
: Well, I haven't noticed any new problems myself, but I've yet to have a chance to test very extensively, but I plan to on what is a long weekend coming up here. I'm going to clear my localhost rumble server and re-run testing with the latest version. Does anyone thing it would be good if I opened up the 1.7.2.1 testing rumble server to the world so others could speed up the process of testing it? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
:: I think it would be good. I am more than willing help you. If not due the stability of internet connection of my server I would open a testing server ages ago (well, my server located at my school in the university's infrastructure which is like twenty years old or more). Just a side note, 1.7.1.x runs at least five times faster than 1.6.1.4. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:51, 30 June 2010 (UTC)<br />
<br />
: Okay. I will wait a little with releasing 1.7.2.1 so you guys get the chance of testing it a bit more. 1.7.2.1 is "just" replacing the Jikes compiler with ECJ + some bug fixes compared to 1.7.2.0. I have started working on the 1.7.2.2 with some new features + I try to improve the speed with loading/updating the development paths, which are loaded extremely slow compared to the .jar files. :-) --[[User:FlemmingLarsen|Fnl]] 19:57, 2 July 2010 (UTC)<br />
<br />
Alright, I just moved the bots that are known to not work in 1.7 for "WontFix" reasons out of the participants list. Anybody mind? I kept them on the bottom of the pages with links to the SF ticket that's relevant. --[[User:Rednaxela|Rednaxela]] 20:46, 4 July 2010 (UTC)<br />
<br />
Okay, I now have a rumble test server facing the world on [[http://rednaxela.gotdns.com:8080/rumble/]]. It should be secured and fast enough now, I think. Feel free to run 1.7.2.1 Beta clients on it for testing! :) --[[User:Rednaxela|Rednaxela]] 21:56, 4 July 2010 (UTC)<br />
<br />
I have my roborumble and meleerumble client pointed to your server now. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 13:29, 6 July 2010 (UTC)<br />
<br />
Red, do you have any comparing method planned? The melee is almost completed, though it should need more before becoming stable. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 14:48, 12 July 2010 (UTC)<br />
<br />
My current comparing plan is:<br />
# First look for obvious outliers (things missing from high ranks, things at extreme low ranks)<br />
# Then import the 1.6.1.4 rumble and 1.7.2.1 rumble results tables into a spreadsheet, sort each by name, line them up beside eachother, create a column for rank difference and PL difference, then sort by those to find outliers.<br />
# Test any outliers. Determine if it's a bug to report, or the bot doing something that it shouldn't<br />
Currently, 1v1 rumble has two outliers at the bottom. I already reported the bug for one and it was fixed, and I think the other is breaking due to using File IO without using the proper robocode streams. About to do the spreadsheet with melee :) --[[User:Rednaxela|Rednaxela]] 02:13, 13 July 2010 (UTC)<br />
<br />
The biggest melee outliers by APS. Positive numbers mean improvement:<br />
{|<br />
|<br />
|Rank change<br />
|APS change<br />
|----<br />
|jab.DiamondStealer 5<br />
|145<br />
|20.07<br />
|----<br />
|gg.Squaraus 0.6<br />
| -72<br />
| -14.08<br />
|----<br />
|com.syncleus.robocode.Dreadnaught 0.1<br />
|49<br />
|9.40<br />
|----<br />
|stelo.Spread 0.2<br />
|62<br />
|6.34<br />
|----<br />
|bayen.nut.Squirrel 1.615<br />
|48<br />
|4.36<br />
|----<br />
|stelo.Moojuk 1.3<br />
|10<br />
|3.95<br />
|----<br />
|stelo.SoJNanoMelee 1.1<br />
| -23<br />
| -2.95<br />
|----<br />
|exauge.GateKeeper 1.1.121g<br />
|21<br />
|2.37<br />
|----<br />
|sgp.JollyNinja 3.53<br />
|18<br />
|2.12<br />
|----<br />
|lrem.micro.SpikeSoldier 0.4<br />
|19<br />
|2.00<br />
|----<br />
|sample.TrackFire 1.0<br />
| -0<br />
| -1.87<br />
|----<br />
|}<br />
I suspect DiamondStealer may have had bad results on the main rumble server, and I suspect the APS differences below 3% are probably a fluke. Maybe some of the larger are too, but I plan to test Squaraus and Dreadnaught anyway. --[[User:Rednaxela|Rednaxela]] 05:16, 13 July 2010 (UTC)<br />
<br />
Dreadnaught also had bad results in the beginning (not complient to 1.5.4 I believe) --[[User:GrubbmGait|GrubbmGait]] 08:49, 17 July 2010 (UTC)<br />
<br />
== .NET ==<br />
<br />
Is it possible to submit robots written in .NET to RoboRumble? --[[User:Dserbia|dserbia]] 15:18, 15 July 2010 (UTC)<br />
<br />
No, not at the moment. We have to make sure Robocode 1.7.x reach the really stable phase before. And I think we should wait for jni4net to reach at least beta status, for Mono support. Many of high-contributing RoboRumble clients are running under either Linux or OSX. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 15:38, 15 July 2010 (UTC)<br />
<br />
Thanks for the quick reply! --[[User:Dserbia|dserbia]] 17:21, 15 July 2010 (UTC)<br />
<br />
Personally, I'm not sure I'd ever be in favor of allowing them into the rumble. There would then be bots in the rumble that Mac/Linux users could never test against (and there are a lot of us), and it would also make us dependent on .NET users to contribute battles for those bots when we post new versions of our own. But I do sympathize - if/when more .NET Robocoders come onto the scene, things could change.<br />
<br />
Keep in mind that all of this stuff is community driven, though it may all seem very "official" to a newcomer. Anyone is free to setup a competition / tournament / rumble that includes .NET bots if they want! We've had tournament style competitions like the [[oldwiki:MiniBotChallenge|MiniBot Challenge]] and [[Twin Duel]] in the past, Robocode has APIs that make automating battles for tourneys fairly easy, and Darkcanuck posts the source to his rumble server somewhere (Nat or Rednaxela would know). And there's always [[:Category:Challenges|Challenges]] you can compete in, too.<br />
<br />
--[[User:Voidious|Voidious]] 17:38, 15 July 2010 (UTC)<br />
<br />
: I think Pavel Savara has plan for suporting jni4net, which is the core of .NET Robocode, on Mono, which can be run under Linux and Mac OS X. I don't think there is a valid reason for not supporting those when that day come. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 06:57, 16 July 2010 (UTC)<br />
<br />
: Yeah, it could work out, but there's still lots of room for issues. How stable is Mono? Will Mono add behavior discrepancies to .NET bots? Or will Java bots hit subtle behavior discepancies when battling .NET bots on Windows? (Either of those could be very hard to debug for the bot author.) Will .NET bots run much slower when running through Mono? Will that count against them in terms of CPU time/skipped turns? We've seen plenty of issues just from different JVMs / CPUs / OSes, so adding Mono and .NET to the rumble definitely requires caution. Or it may work perfectly smoothly and we'll all coexist peacefully. =) --[[User:Voidious|Voidious]] 15:18, 16 July 2010 (UTC) <br />
<br />
:: As long as one isn't doing GUI or calls to native libraries (not allowed for bots anyway), I'm pretty sure Mono is quite accurately compatible, however my concerns are around the fairness issues. x86 Java is reasonably uniform in terms of what parts of the code get optimized how well by the JVM. As I understand, Mono's performance is pretty reasonable overall, however since it's coded from scratch it's optimization characteristics are notably different I think, which makes cpu fairness somewhat tricky for having MS .Net and Mono running the same rumble. If one looks at [http://lists.ximian.com/pipermail/mono-list/2007-April/034899.html this], it's fairly old, but shows large performance differences going either way in terms of different types of operations. That exact issue only becomes larger between the JVM and .NET, so I really do think it makes sense for .NET to be kept to a separate rumble (possibly on the same server but separated like the different formats?). --[[User:Rednaxela|Rednaxela]] 19:23, 16 July 2010 (UTC)<br />
<br />
== New Rumble ==<br />
<br />
Rednaxela and I have been talking a bit, and we have put considerable thought into a new 1-vs-1 rumble. Unlike our current 1-vs-1 rumble, this would have no data saving, be single round battles on a 800x800 field. Also considering having the game 'white out' names in a battle to just numbers, so there can be no hard-coded specific bot data saving either. I personally feel this kind of 1-vs-1 competition would allow for much greater competition from non-adaptive movements, and lower the bar considerably for newer robocoders. But not too much, since obviously, Crazy would never be able to win over DrussGT.<br />
<br />
We also considered non-random starting positions (for greater fairness) and a 4 bot single round melee on the same field size.<br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 16:16, 24 July 2010 (UTC)<br />
<br />
Yeah, I think this would be a really neat thing to have. Now, I don't think it should replace the old-style rumble, but I think it would make a very interesting competition, and perhaps much less daunting for newcomers. And to clarify on what the "white out" of names, it means robot names that bots would see would just be like "1", "2", "3", or perhaps "robot 1", "robot 2", "robot 3". Now, that does require a modification to Robocode, but I think it would probably be relatively simple and quick to get implemented. (I say it should be simple because Robocode already alters names when multiple of the same bot are in a battle, so I'd imagine the same code path can be reused, so just a matter of changing it for a certain rumble flag) --[[User:Rednaxela|Rednaxela]] 16:27, 24 July 2010 (UTC)<br />
<br />
We have put togeather a seed of 60 robots, please keep in mind this is just a seed, and you can add your own robots when it gets started. This is just to round out the robots so that we can get some meaningful rankings.<br />
<pre><br />
abc.Tron 2.02<br />
ags.micro.Carpet 1.1<br />
ags.polished.PolishedRuby 1<br />
apv.Aspid 1.7<br />
apv.NanoLauLectrik 1.0<br />
apv.ScruchiPu 1.0<br />
ary.nano.AceSurf 1.2<br />
axeBots.Musashi 2.18<br />
axeBots.Okami 1.04<br />
chase.pm.Pytko 1.0<br />
cjm.Che 1.2<br />
cx.Lacrimas 1.36<br />
cx.mini.Cigaret 1.31<br />
darkcanuck.Gaff 1.50<br />
davidalves.net.DuelistMini 1.1<br />
davidalves.net.DuelistNano 1.0<br />
dummy.micro.Sparrow 2.5<br />
gh.GrubbmGrb 1.2.4<br />
gh.GrypRepetyf 0.13<br />
jam.mini.Raiko 0.43<br />
jk.micro.Toorkild 0.2.4b<br />
kawigi.robot.Girl 1.2<br />
kawigi.sbf.FloodHT 0.9.2<br />
kawigi.sbf.FloodSonnet 0.9<br />
kc.micro.Needle 0.101<br />
kc.micro.Thorn 1.252<br />
kc.mini.Vyper 0.311<br />
kc.nano.Splinter 1.2<br />
kid.Gladiator .7.2<br />
Krabb.krabby2.Krabby2 1.9o<br />
mld.Moebius 2.9.3<br />
mue.Hyperion 0.8<br />
mz.NanoDeath 2.56<br />
pe.SandboxDT 3.02<br />
pe.SandboxLump 1.52<br />
pedersen.Ugluk 1.0<br />
pez.mako.Mako 1.5<br />
pez.mini.Tityus 0.9.1<br />
pez.mini.VertiLeach 0.4.0<br />
ry.VirtualGunExperiment 1.2.0<br />
rz.Aleph 0.34<br />
rz.GlowBlowAPM 1.0<br />
sample.Walls<br />
sample.Crazy<br />
simonton.beta.LifelongObsession 0.5.1<br />
simonton.micro.GFMicro 1.0<br />
simonton.micro.WeeklongObsession 3.4.1<br />
simonton.nano.WeekendObsession_S 1.7<br />
stefw.Tigger 0.0.23<br />
synapse.Geomancy 15<br />
techdude.Carruthers 1.2.6<br />
tzu.TheArtOfWar 1.2<br />
voidious.micro.Jen 1.11<br />
vuen.Fractal 0.55<br />
wcsv.Engineer.Engineer 0.5.4<br />
whind.Strength 0.6.4<br />
wiki.BasicGFSurfer 1.02<br />
wiki.mini.Sedan 1.0<br />
wiki.nano.RaikoNano 1.1<br />
zyx.micro.Ant 1.1<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 17:36, 24 July 2010 (UTC)<br />
<br />
== 1.7.x rumble eventually... ==<br />
<br />
Hey guys... I kind of think I dropped the ball on working on getting 1.7.x to main rumble before... but I still think it would be good to eventually. Now... unlike before (where the rumble server was a little VM on my machine that I sometimes had to shut down for lack of memory), I have a more proper server I could use for rumble. I probably won't get around to setting this up till after winter holidays (have plans with family), but just wanted to ask, how much interest in this is there? Best Regards. --[[User:Rednaxela|Rednaxela]] 07:29, 21 December 2010 (UTC)<br />
<br />
I am still interested in. Right now (well, not really, since I am not actively writing robots), my movement predictor have flags for 1.6.1.4 or 1.7.1.3+ movement. Since rumble runs 1.6.1.4 but 1.7.x+ runs much faster. Also, the whole rumble would take less time to stabilised (but it would put more load to server, since client can run, as Pavel claimed, ''ten'' times faster. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 11:36, 21 December 2010 (UTC)<br />
<br />
I'm still interested. Kept meaning to ask you why the test rumble server went down but never did. Do you still have all the results, or would we start from scratch? Anyway, it would be good to be current. A lot of new people get 0 scores because they use new APIs, plus there's the performance benefits. --[[User:Voidious|Voidious]] 14:00, 21 December 2010 (UTC)<br />
<br />
: Yeah, I do still have the old data, but I'm not sure we want to use it. Presumably we'd want to test now with the very latest version, and mixing the results in this of multiple versions in this test could cloud results. --[[User:Rednaxela|Rednaxela]] 14:59, 22 December 2010 (UTC)<br />
<br />
Alright! I have a new rumble test server up and running at [http://rednaxela-robocode.dyndns.org/rumble/ http://rednaxela-robocode.dyndns.org/rumble/]. For ease of use, rumble configuration templates are linked from it's main page. Also, if you want, here's a convenient zip of all the bots currently in rumble: [http://rednaxela-robocode.dyndns.org/data/robot_archive.zip]. This one is located on a more proper type of server, rather than a virtual machine on my laptop. So... time to get testing 1.7.2.2 and prove it stable? :) --[[User:Rednaxela|Rednaxela]] 06:37, 19 January 2011 (UTC)<br />
<br />
: Hm, I thought I had this page "watched" but it looks like I've missed a lot... Is the new server running the same code and database schema as the current one? --[[User:Darkcanuck|Darkcanuck]] 06:43, 19 January 2011 (UTC)<br />
<br />
:: Yep, same code and database schema. The only changes I made were to the front html page, and changing the accepted version of robocode to 1.7.2.2. --[[User:Rednaxela|Rednaxela]] 06:57, 19 January 2011 (UTC)<br />
: I found my old laptop, I will set it to run, I might tweak the CPU constant up a little too, since it is a older/slower machine. (I will just set it in my closet, away from hustle and bustle). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 09:32, 19 January 2011 (UTC)<br />
<br />
: Nice! I'll start running my clients against this again. Thanks Rednaxela! Btw, the superpack .zip is gone from [[RoboRumble/Starting With RoboRumble]]. I'll make a new one with the above archive unless you could just repost the old one. --[[User:Voidious|Voidious]] 14:47, 19 January 2011 (UTC)<br />
<br />
:: It turns out both my laptops puked at some point while I was out (one locked up while loading rankings, the other I forgot to make a loop and iterate was NOT). Not sure if you still have to do iterate not, and make a script loop, but I did. Only my main system had kept running the rumble. But I restarted both of those now. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:36, 20 January 2011 (UTC)<br />
<br />
::: As far as I know, all the memory leaks have been fixed. I had my client run over the whole day and the memory use plateaued nicely with no issues whatsoever. --[[User:Rednaxela|Rednaxela]] 02:39, 20 January 2011 (UTC)<br />
:::: Ah well, I will switch them to use ITERATE then. Thanks. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:59, 20 January 2011 (UTC)<br />
<br />
Is there anything that we're waiting on for the switch to the 1.7 rumble rankings? I'd love to help make this upgrade happen. [[User:Ncj|Ncj]] 16:45, 4 April 2011 (UTC)<br />
<br />
I know Rednaxela was investigating some of the outliers from the test server's rankings. I'm not sure there was really anything "stop ship" though. I think the rankings look pretty good. Rednaxela, what do you think? --[[User:Voidious|Voidious]] 20:38, 4 April 2011 (UTC)<br />
<br />
Well, here's the "Table of Anomalous Results" I made when the 1.7.2.2 rumble first stabilized:<br />
<br />
{| border="1" cellpadding="2" style="border-collapse: collapse; color: black; font-size: xx-small" class="sortable"<br />
|class="unsortable"| ||Old Rank||Old %||New Rank||New %||Rank Diff||% Diff||class="unsortable"| ||ABS % Diff||ABS Rank Diff||Explanation<br />
|-<br />
| CharlieN.Omega.Omega 1.03||319||55.29||774||9.19||-455||-46.1||||46.1||455||[http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405]<br />
|-<br />
| NDH.GuessFactor 1.0||787||0.42||578||39.54||209||39.12||||39.12||209||uses post-1.6.1.4 functions<br />
|-<br />
| jeremyreeder.Vincent 2011.12.09||788||0||645||33.68||143||33.68||||33.68||143||uses post-1.6.1.4 functions<br />
|-<br />
| Krabb.krabby2.Krabby2 1.9o||71||73.63||528||43.12||-457||-30.51||||30.51||457<br />
|-<br />
| gg.Squaraus 0.6||714||26.3||786||4.62||-72||-21.68||||21.68||72||[http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405]<br />
|-<br />
| elvbot.ElverionBot 0.3||785||0.72||751||19.75||34||19.03||||19.03||34||uses post-1.6.1.4 functions<br />
|-<br />
| TJ.Exupery 1.39||403||50.02||174||63.3||229||13.28||||13.28||229||<br />
|-<br />
| zh.UnderDog 0.0.2||782||4.31||762||14.11||20||9.8||||9.8||20||1 on 5 exception in TacticalAdvisor in 1.6.1.4<br />
|-<br />
| reaper.Reaper 1.1||357||53.1||194||62.6||163||9.5||||9.5||163||crashes on some clients in 1.6.14 but not 1.7?<br />
|-<br />
| sm.Devil 7.3||517||44.13||351||53.45||166||9.32||||9.32||166||crashes on some clients in 1.6.14 but not 1.7?<br />
|-<br />
| xiongan.Xiongan 1.1||709||27.05||614||36.22||95||9.17||||9.17||95||<br />
|-<br />
| ag.Gir 0.99||762||13.25||739||22.26||23||9.01||||9.01||23||<br />
|}<br />
The case of "CharlieN.Omega.Omega 1.03" was [http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405], and has been fixed in 1.7.3.0 Beta. Unfortunately I've yet to investigate the other results.<br />
<br />
Some of positive results I suspect may have been from using some Robocode 1.7 features perhaps (i.e. some new events). The case of Krabby2 I in particular mean to investigate because that result looks quite odd. Some other positive changes like Devil seem strange to me, because Devil predates Robocode 1.7 by a huge margin, yet seems to do better than in 1.6 by a notable margin. I've yet to be able to figure that out either. Anyone have any theories or can look into these cases?<br />
<br />
Anyway, presuming these issues can be worked out, what do people think of moving straight to 1.7.3.0 perhaps? The difference relative to 1.7.2.2 is small so I don't see it as that high risk, and if it turns out there were issues, then we're no worse off than if we had spent the same effort to test 1.7.3.0. Thoughts?<br />
<br />
--[[User:Rednaxela|Rednaxela]] 04:45, 5 April 2011 (UTC)<br />
<br />
SmallDevil crashes on my clients (dunno about others), so his 1.6 score is probably just wrong. I'm probably OK with moving to 1.7.3.0, but I'd prefer to just go with 1.7.2.2 since that's the one we've actually spent so much time testing. The difference being small could support either decision. =) 1.7.3.0 is still beta, too. --[[User:Voidious|Voidious]] 12:44, 5 April 2011 (UTC)<br />
<br />
Well, of course some testing of 1.7.3.0 needs to be done, but that should be possible to complete before it's out of beta. I think it's changes from 1.7.2.2 are definitely seem small enough to me that it's not like we need to do a full rumble run again. --[[User:Rednaxela|Rednaxela]] 13:23, 5 April 2011 (UTC)<br />
<br />
The three bots 'NDH.Guessfactor', 'jeremyreeder.Vincent' and elvbot.ElverionBot' all use post-1.6.1.4 functions, no further investigation needed for them. SmallDevil indeed occasionally crashes, why it does not do that on 1.7.2.2 I don't know. I believe the same goes for 'reaper.Reaper'. Friday I will have some time to check other differences. Is there a possibility to check all '2100-0' scores on the server for a specific bot? A bad client on the moment of submission has a permanent influence now. On the old server (years ago) these bad results faded away with each new battle (0.7*0.7*0.7 etc). --[[User:GrubbmGait|GrubbmGait]] 18:35, 6 April 2011 (UTC)<br />
<br />
: I suspect [[SmallDevil]] just crashes due to some corrupt saved data, tho I haven't investigated it. I've seen the same with other bots, like [[TheBrainPi]]. I wiped my robotcache today so I'll watch out for SmallDevil battles from me with any new bot releases. --[[User:Voidious|Voidious]] 00:30, 7 April 2011 (UTC)<br />
<br />
Interesting. Tomorrow I think I'll be able to look into these more, especially Krabby2 I think. --[[User:Rednaxela|Rednaxela]] 05:00, 7 April 2011 (UTC)<br />
<br />
For reaper.Reaper and sm.Devil just check their scores against ad.last.Bottom. There is the possibility that these bots still could crash in 1.7, as it only happens occasionally.<br />
Is there a way to reject/ignore 21xx-0 scores (if other scores are available) and scores way outside the normal range? That would be like an aspirine for the ranking. See example below. --[[User:GrubbmGait|GrubbmGait]] 14:18, 7 April 2011 (UTC)<br />
<br />
BATTLE DETAILS FOR "reaper.Reaper 1.1" VS "abud.ThirdRobo 1.0" IN GAME "roborumble"<br />
<pre><br />
|% Score |% Survival |score |bullet dmg. |survival |score |bullet dmg. |survival |Battle Time |Submitted by <br />
| | reaper.Reaper 1.1 | abud.ThirdRobo 1.0 |<br />
|90.622 |100.000 |5991 |3233 |35 |620 | 614 | 0 |2010-05-31 12:57:18:835 |cberendt@178.63.10.12 ver.1.6.1.4 <br />
|90.927 |100.000 |5963 |3215 |35 |595 | 590 | 0 |2010-02-09 07:49:56:713 |Miked0801@207.170.253.83 ver.1.6.1.4 <br />
|90.044 |100.000 |5960 |3209 |35 |659 | 657 | 0 |2010-01-06 02:27:33:942 |darkcanuck@24.85.46.67 ver.1.6.1.4 <br />
|89.834 |100.000 |5956 |3200 |35 |674 | 667 | 0 |2009-01-15 16:51:12:182 |darkcanuck_154@24.85.45.250 ver.1 <br />
|90.435 |100.000 |5928 |3187 |35 |627 | 622 | 0 |2008-09-10 15:49:11:187 |ABC@import ver.1 <br />
|88.993 | 97.143 |5862 |3179 |34 |725 | 643 | 1 |2008-09-21 12:06:41:943 |ABC@import ver.1 <br />
|0.000 | 0.000 | 0 |0 | 0 |2103 | 0 |35 |2010-11-09 13:21:30:209 |Voidious@76.15.102.168 ver.1.6.1.4 <br />
|0.000 | 0.000 | 0 |0 | 0 |2101 | 0 |35 |2010-07-04 13:50:23:859 |Voidious@76.15.102.168 ver.1.6.1.4 <br />
|0.000 | 0.000 | 0 |0 | 0 |2101 | 0 |35 |2009-10-13 23:34:34:50 |Voidious@173.50.167.108 ver.1.6.1.4 <br />
|0.016 | 0.000 | 1 |0 | 0 |6179 |3395 |35 |2008-10-29 04:30:08:727 |darkcanuck@24.85.45.250 ver.1<br />
</pre><br />
<br />
== Client on Google Apps Engine ==<br />
<br />
I wonder, since the latest release of Google Apps Engine (1.5.0), Google add support for Backend, which allow process to run as long as you like. I think it is possible to port the RoboRumble@Home client to run on these environment; that would speed up the process. But I think we need to check if this is applicable with Google Apps Engine TOS and throttle the client enough so it doesn't use more than its free quota limit ;-) Just an idea! --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 01:42, 11 May 2011 (UTC)<br />
<br />
Well, I'm pretty sure that even if you can run a process as long as you like, they don't guarantee a constant amount of available CPU, which is important for robocode. Of course, if in the future, robocode switches to using the less granular APIs that track actual cpu time used by given threads, then this would probably work. It's not really the same, but as a note, you can already run robocode on Amazon's EC2, which does guarantee a level of CPU allocation. Chase-san briefly tried this once in the past.--[[User:Rednaxela|Rednaxela]] 02:51, 11 May 2011 (UTC)<br />
<br />
But, of course, unless you already host something on EC2, the EC2 isn't "free" ;-) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:19, 11 May 2011 (UTC)<br />
<br />
I've been running two instances of the client on the cheapest server offered by linode ($20/mo). I'd run more, as it's quad core, but it only has 500MB of RAM and is thus memory bound. I keep the box around in case I need to pretend my traffic is coming from the US, but for a dedicated RoboRumble box would EC2 end up being cheaper? [[User:Ncj|Ncj]] 16:52, 17 May 2011 (UTC)<br />
<br />
: As an aside, I'd only recommend running one client with 500 megs of RAM, as I think other people use and test with 512. I remember the default was 512 in robocode.sh but still 256 in roborumble.sh at one point - not sure if that's been fixed. Pretty cool you do that, though! --[[User:Voidious|Voidious]] 21:44, 17 May 2011 (UTC)<br />
<br />
: Aside from agreeing with Voidious about wanting 500mb per client, I'd question whether the CPU allocation on linode is stable. Those are virtual machines shared with other instances, and while there are "four cores" that it has access to, it's not as if it's exclusive access. I'd be very concerned that your clients are causing bots to skip turns whenever other instances on the machine get busy. --[[User:Rednaxela|Rednaxela]] 00:29, 18 May 2011 (UTC)<br />
<br />
:: If Linode CPU's allocation isn't stable, then isn't the EC2. They are based on the same virtualization technology, Xen. I'd be more concerned if it is KVM or OpenVZ virtualization system. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 14:29, 18 May 2011 (UTC)<br />
<br />
:: Is there a way for me to check this? Somehow compare the % of skipped turns on my client to someone else's? [[User:Ncj|Ncj]] 15:36, 18 May 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:RoboRumble&diff=19301Talk:RoboRumble2011-05-17T16:52:43Z<p>Ncj: Using linode</p>
<hr />
<div>== RoboRumble history ==<br />
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ<br />
<br />
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar<br />
<br />
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar<br />
<br />
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar <br />
<br />
== Subpages ==<br />
Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)<br />
<br />
== Name ==<br />
<br />
Since the new wiki supports symbols in page names, should we put this page at [[RoboRumble@Home]] instead of RoboRumble? We already have a redirect from that page to this one... --[[User:AaronR|AaronR]] 23:34, 17 November 2007 (UTC)<br />
<br />
I second this change. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:30, 28 April 2009 (UTC)<br />
<br />
== RR seems to be down ==<br />
<br />
Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 03:07, 19 September 2008 (UTC)<br />
:Are you sure? Both [http://rumble.fervir.com/rumble/Rankings?version=1&game=roborumble rumble.fervir.com] and [http://abchome.aclsi.pt:8080/ ABC's] work for me. -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 03:33, 19 September 2008 (UTC)<br />
::I fail. I meant Robocode Repository. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 05:44, 19 September 2008 (UTC)<br />
::Not a big surprise there. =P -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 13:21, 19 September 2008 (UTC)<br />
<br />
Hi! What the heck happened to RR@H again? The main roborumble has only ~60 bots again... Otherwise, I uploaded Pugio 1.2 1 week ago and has only 120 battles in nanoRumble. Situation is the same in Darcanuck's page, too. Nobody is contributing?--[[User:Robar|HUNRobar]] 12:30, 11 October 2008 (UTC)<br />
<br />
Both ABC's server and DarkCanuck's server have no full pairings yet. Once the megabots have full pairings, the minirumble will get filled completely and as last the micro- and nano-rumble. Be patient, but it probably requires a few weeks before all nanobots have 1000 battles. Remember, 640 * 640 bots means a lot of battles! Pulsar's server has another issue. I don't know what happened, but I still run (repair)battles there. --[[User:GrubbmGait|GrubbmGait]] 13:14, 11 October 2008 (UTC)<br />
<br />
I realised that in Darcanuck's server the older versions of bots are still in game. I think the competitors there should be cleaned up. For example, I don't want to generate battles for Pugio 1.0 when I wait for the results of 1.2. --[[User:Robar|HUNRobar]] 14:57, 11 October 2008 (UTC)<br />
<br />
That's a temporary thing -- I'm uploading a huge amount of data from [[User:ABC|ABC]]'s server which includes old participants. There's a big performance hit to activating/retiring participants repeatedly, so for now everyone's in the rankings until I get caught up. But don't worry, no rumble clients will actually run these bots. They'll use only the version from the participants list. In a few days you should see the old bots disappear from the rankings. --[[User:Darkcanuck|Darkcanuck]] 15:03, 11 October 2008 (UTC)<br />
<br />
Whoops edit conflict, accidentally overwrote Darkcanuck's reply with this: "What versions get battles doesn't depend on the server, it depends on the participants list that clients are configured to (which should be the old wiki's one, the one here has not been synced for a long time). The server would have nothing to do with that so you shouldn't be generating battles for Pugio 1.0 unless your client is misconfigured I believe." Anyways Darkcanuck's reply clearly explains why there are currently old versions listed :) --[[User:Rednaxela|Rednaxela]] 15:10, 11 October 2008 (UTC)<br />
<br />
Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--[[User:Robar|HUNRobar]] 17:40, 11 October 2008 (UTC)<br />
<br />
Why can't I access ABC's server? My connection get timeout before it finished loading! -[[User:Nat|Nat]] 12:42, 6 January 2009 (UTC)<br />
<br />
== Lynch the Multi-Threaders! ==<br />
<br />
A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?<br />
# On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.<br />
# On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.<br />
This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we ''could'' enforce a rule saying that no multi-threaded bot is allowed in ''the rumble''! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --[[User:Simonton|Simonton]] 02:47, 23 September 2008 (UTC)<br />
<br />
Agreed. It isn't fair on the opposition, and makes it impossible to design a bot within the CPU-constant constraints. --[[User:Skilgannon|Skilgannon]] 10:34, 23 September 2008 (UTC)<br />
<br />
I either didn't see or forgot about this section. There are already bots that use multiple threads in the rumble: [[Toad]] definitely does, possibly [[X2]] (which shares some Toad code), and probably others. Not sure how I feel about removing them at this point, just contributing some facts here... --[[User:Voidious|Voidious]] 02:20, 7 August 2009 (UTC)<br />
<br />
Well, there are java APIs that allow things like only measuring the time used in a particular thread. Robocode could start to use these in order to make this fair, AND as a '''major''' bonus it would make using Robocode on a computer with a heavily loaded CPU not cause skipped turns. The issue is... those APIs don't give the same kind of resolution, thus meaning that the only way we do it would be if we calculated something more like "How much CPU time did threads of this bot use in the last 20 ticks?", instead of "How much time did this robot take between the start and end of this turn?" which would make skipped turns behave a bit different. Personally I think that may not be such a bad thing, but I'm not really entirely sure... --[[User:Rednaxela|Rednaxela]] 02:51, 7 August 2009 (UTC)<br />
<br />
: It looks like [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 this] &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:53, 7 August 2009 (UTC)<br />
<br />
:: Hm? "ERROR This artifact is not accessible." is what that page gives --[[User:Rednaxela|Rednaxela]] 13:11, 7 August 2009 (UTC)<br />
<br />
::: Sorry, I never noticed that this is 'private' tracker... Fnl thought that he needs more precise time and mem.usage detection. I have a comment on some time measuring much like to your "How much CPU time did threads of this bot use in the last 20 ticks?". However, we didn't mention a thread at all. But I believe that Robocode allow Robots to create up to 5 threads, I'll email Fnl this. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:53, 7 August 2009 (UTC)<br />
: The [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 tracker] is public now. :-) Basically, I want to measure the CPU usage with the new features in Java 5.0 for measuring the exact CPU per thread. Hence we will (when using the TheadMXBean) know for a fact exactly how much time all threads in a robot is using in total. However, the time interval when measuring using the ThreadMXBean is big compared to what we are used to with the CPU constant currently used in Robocode. So we need a solution that can deal with this issue. I have waited with this improved feature as this will have a big impact on the scores for the robots in the RoboRumble. We have already seen how much difference the getNextVelocity() makes, so imagine the difference when we make change the concept behind the CPU constant. --[[User:FlemmingLarsen|Fnl]] 21:07, 7 August 2009 (UTC)<br />
:: Personally, I'm actually not too worried about the impact of this change. Most bots don't skip many turns at all, and the effects of a few skipped turns are often overstated. As long as the average amount of CPU allowed per tick is still similar, I can't imagine it affecting scores too much. I suppose it might have a big impact on bots that abuse the currently untracked multi-threading, but I think we can all agree that they're sort of abusing the system right now, anyway. Of course, I'd be happy to run extensive tests, too. =) --[[User:Voidious|Voidious]] 21:55, 7 August 2009 (UTC)<br />
:: I'm agreement with Voidious on this. I doubt there would be any problems caused by this so long as the correct amount of time was chosen. I would say though, that I think that this feature should be targeted at a 1.7.1.5 release, for the same reason that it's generally considered bad practice to change both a bot's movement and gun in the same rumble iteration, haha. As a side note, I wonder if while we improve the measurement method to not be affected by other things on the system, that maybe we should also improve the cpu constant calculation. For one, it should use the same ThreadMXBean methods to be accurate, but also I wonder if we could have a more realistic benchmark of what a typical bot actually does with it's time. I propose we include a small suite of some of the things a more cpu intensive bot does in order to create a more representative benchmark. I propose coding a small suite consisting of something like the following: 1) KD-Tree, 2) Nanobot-style pattern matching, 3) Array operations (searching for peak, addition of a gaussian curve to an array, multidimensional array access), 4) 'Play-It-Forward' simulation, 5) GF calculation (aka simple trig). I think I'll begin a page for comments on and code for an improved benchmark --[[User:Rednaxela|Rednaxela]] 00:00, 8 August 2009 (UTC)<br />
:: 1.7.1.5? It was there for about eight months. I think maybe 1.8 or so... &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:10, 8 August 2009 (UTC)<br />
<br />
== What Now? ==<br />
<br />
How can I submit the new versions of DrussGT and Cunobelin? Has anybody heard any news on the old wiki? Will it be recovered? Is it gone forever? --[[User:Skilgannon|Skilgannon]] 15:47, 8 December 2008 (UTC)<br />
<br />
Well on November 30th I emailed PEZ and got a reply that it's an ugly error and that he'd look into it. I haven't heard anything since but I guess I might email PEZ again. I certainly hope it won't be gone forever as I'd at least like to have a read-only version due to how much great stuff there is there that's unmigrated. --[[User:Rednaxela|Rednaxela]] 16:12, 8 December 2008 (UTC)<br />
<br />
I really hope the old wiki content still lives on. In the meantime we could agree to use this wiki's list for my server. I don't have time this week to make the proposed participant list changes, but I could lock out add/removes for all but a few select clients to make sure we all use the same list? --[[User:Darkcanuck|Darkcanuck]] 18:28, 8 December 2008 (UTC)<br />
<br />
Well, the old wiki is back! I do wonder though, should we switch to using this wiki's participants list anyway? or should that wait till some other day in the future? --[[User:Rednaxela|Rednaxela]] 18:17, 9 December 2008 (UTC)<br />
<br />
: I'd like to keep using the old wiki at least until I can code up something to validate participants on the server side. Then it would be easier to switch and not have to worry about some clients using the wrong list. --[[User:Darkcanuck|Darkcanuck]] 05:39, 10 December 2008 (UTC)<br />
<br />
Random question: How much do you think the local client would speed up if I compiled it natively? Right now, we haev a bit of a bottleneck figuring out battles andif we could speed it up by a factor or 3 or so, why not? --[[User:Miked0801|Miked0801]] 21:52, 25 May 2009 (UTC)<br />
<br />
== Nanos get little love when things get busy ==<br />
I've been waiting for nearly 4 days for my latest bot to get to 2k battles against nanos, and I'm probably gonna have to wait 3 more for it to happen. Why? Nanos, after they get to their 1 battle per bot limit, are the last bots to be updated under the current system. I understand why the system was done this way, but is there anyway we can add a time component to the battle chooser to make sure that when things heat up in the rumble, nanos get some love as well? --[[User:Miked0801|Miked0801]] 20:47, 19 June 2009 (UTC)<br />
<br />
I hear ya. Even in Mega-land, it can take a while to get to 2k battles, and I don't really trust a rating until it does (even with all pairings). There are some RR client options you could try, like excluding bots or running NanoRumble only, but the latter will just do random battles, I think. A couple of nice client side options, imo, would be mini/micro/nano while still honoring pairing priority, and ignoring pairings while running bots with under NUMBATTLES (in all applicable rumbles). I'm definitely in favor of RR contributors having control over what battles they want to run... --[[User:Voidious|Voidious]] 22:48, 19 June 2009 (UTC)<br />
<br />
Nanos get ''way'' more than their fair share of processing time. By a time a nano reaches 2000 battles in its own class, it has typically reached 5000+ battles in the main rumble. Few, if any, megabots have yet to reach that level. Not only is it unfair to folks releasing larger bots, it also takes away cpu time from other nanos. So should we abolish nanos? Of course not!<br />
<br />
I'd vote for changing the client's battle selection such that when a new bot reaches full pairings, the remainder of its 2000 battles are fought against opponents in its own size class. Those battles will still count for the higher classes, so a nano would really only need 2000 battles overall. This would mean faster results for nanos and more cpu time for everyone else, regardless of size. --[[User:Darkcanuck|Darkcanuck]] 03:19, 20 June 2009 (UTC)<br />
<br />
I second Darkcanuck's suggestion, as it seems most fair to me. :) --[[User:Rednaxela|Rednaxela]] 05:12, 20 June 2009 (UTC)<br />
<br />
And yet, some nanos love to beat up on their larger sibling... But yes, when things slow down, nanos do get a ton of extra battles, but to be fair, most nanos run much, much faster than megas so the hit isn't that bad. My main concern was waiting at the back of a line of never ending micro/mega selections. Impatients and such. If we're going to change things to minimize waits, then first completing pairings, then 2k in class, then low priority updates across other classes would be awesome. Unlike melee, just 2 or 3 battles with a mega are usually sufficient to get a strong idea of where things stand. --[[User:Miked0801|Miked0801]] 09:10, 20 June 2009 (UTC)<br />
<br />
You can also set RUNONLY=NANO, but alas then no priority battles are fought, just random ones. And I set the battlecount to 1000, so nanos will get their battles earlier. --[[User:GrubbmGait|GrubbmGait]] 10:51, 20 June 2009 (UTC)<br />
* setting RUNONLY=NANO is not a good idea. The results only count for nano, so is not counted at micro/mini/mega. Setting the battlecount lower does pay off however, except when the bigger rumbles are flooded with new versions. --[[User:GrubbmGait|GrubbmGait]] 11:00, 20 June 2009 (UTC)<br />
<br />
It would be awesome if roborumble could execute smart battles with runonly parameters. For example, run prioritary battles but only among nanos. I don't think it would be such a difficult developement. --[[User:Robar|HUNRobar]] 14:33, 20 June 2009 (UTC)<br />
<br />
: I think the RUNONLY setting needs to be fixed -- as [[GrubbmGait]] pointed out, the battles don't get uploaded to the bigger size classes, which they should. I might put together a patch for this, but first I have some wave surfing to iron out... --[[User:Darkcanuck|Darkcanuck]] 17:41, 20 June 2009 (UTC)<br />
<br />
About battlecount, one habit I have, is constantly making my battlecount set to just a little above the lowest value in the rumble. That seems to have nice results sometimes. --[[User:Rednaxela|Rednaxela]] 16:03, 20 June 2009 (UTC)<br />
<br />
All right, I think I've figured out how to implement the change I suggested, plus fix the RUNONLY problem. If enough people are ok with this, I'll put together a patched 1.6.1.4 client with the changes and send the patches to [[Fnl]] for future releases too. --[[User:Darkcanuck|Darkcanuck]] 18:21, 21 June 2009 (UTC)<br />
<br />
: Quick question: Would this only affect the 1v1 pairing order? I definitely support it there, but making your suggested change in Melee pairings would have a major impact on some bots' scores... And thanks as always for your RoboRumble efforts! --[[User:Voidious|Voidious]] 19:33, 21 June 2009 (UTC)<br />
:: Only at first. The game already does all class battles for roughly 50% of the numbers in nano now. That's why [[DustBunny]] has been slowly rising in APS - he does worse in nano only. --[[User:Miked0801|Miked0801]] 20:42, 21 June 2009 (UTC)<br />
::: Well, right now a NanoBot gets 2,000 battles against the whole field, then a bunch against MiniBots and below, then MicroBots and below, then NanoBots. With this change, it would get some amount of battles against the whole field, then all NanoBot-only battles. Depending on the bot, I think it could have an impact. Then again, that's a quirky aspect of MeleeRumble that's tough to really regulate, anyway, so maybe it's not worth worrying about. --[[User:Voidious|Voidious]] 21:51, 21 June 2009 (UTC)<br />
:: Ah, good point, I hadn't considered melee. It does use a different routine for preparing battles though, so it's possible to patch 1v1 without affecting melee. Looking at the melee routine, it does create an interesting mix of battles -- I didn't realize that there were all-nano matchups. That must skew the scores depending on the ratio of battles a nano gets with mixed sizes versus all-nano? --[[User:Darkcanuck|Darkcanuck]] 02:15, 22 June 2009 (UTC)<br />
: I don't think it is a bug, i think it was made on purpose the way it is. Alas I don't remember the reason . . . --[[User:GrubbmGait|GrubbmGait]] 21:03, 21 June 2009 (UTC)<br />
<br />
== Mobile Devices ==<br />
<br />
Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --[[User:Rednaxela|Rednaxela]] 02:01, 7 August 2009 (UTC)<br />
<br />
* Definitely crazy. --[[User:Simonton|Simonton]]<br />
<br />
I think you're crazy, but only because the iPhone OS doesn't have Java. =) I actually just looked into this the other day, lol. Was there some tech you were looking at to make it work? --[[User:Voidious|Voidious]] 02:03, 7 August 2009 (UTC)<br />
<br />
Actually, when you don't limit yourself to the app store, there is a port of [[wikipedia:JamVM|JamVM]] w/ [[wikipedia:GNU Classpath|GNU Classpath]]. There's no JIT so it won't be fast... but it'll run.. or... almost:<br />
<pre>Iteration number 0<br />
Downloading rating files ...<br />
Downloading participants list ...<br />
Downloading missing bots ...<br />
Removing old participants from server ...<br />
Preparing battles list ... Using smart battles is true<br />
Prioritary battles file not found ... <br />
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)<br />
at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)<br />
at robocode.manager.RobocodeManager.initSecurity(Unknown Source)<br />
at robocode.control.RobocodeEngine.init(Unknown Source)<br />
at robocode.control.RobocodeEngine.<init>(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)<br />
at roborumble.RoboRumbleAtHome.main(Unknown Source)<br />
Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path<br />
at java.lang.Runtime.loadLibrary(Runtime.java:763)<br />
at java.lang.System.loadLibrary(System.java:662)<br />
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)<br />
at java.lang.VMClass.forName(Native Method)<br />
at java.lang.Class.forName(Class.java:233)<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)<br />
...7 more<br />
</pre> It seems that both:<br />
# RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line<br />
# The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only<br />
Were it not for one or the other of those issues, it'd probably run just fine... Now can i fix this I wonder... --[[User:Rednaxela|Rednaxela]] 02:13, 7 August 2009 (UTC)<br />
<br />
Wow, that would be really cool. But I'm a wuss and I'm afraid to jailbreak and void my iPhone's AppleCare; I was thinking more from the perspective of writing an iPhone app myself that could do it. Good luck, though, I'm curious to hear your results! --[[User:Voidious|Voidious]] 02:17, 7 August 2009 (UTC)<br />
<br />
Aha! I got around that stupid issue! I just had to pass the VM <code>-Djava.awt.headless=true</code>... When you see rumble uploads with a user of "RednaxelaIPod", that'll be it :) --[[User:Rednaxela|Rednaxela]] 02:32, 7 August 2009 (UTC)<br />
: Ouchie, building the robot database this first time sure isn't fast... --[[User:Rednaxela|Rednaxela]] 02:39, 7 August 2009 (UTC)<br />
<br />
Sadly, while it mostly ran, it didn't quite work:<br />
<pre>java.lang.ArrayIndexOutOfBoundsException: 1<br />
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27<br />
5)<br />
at java.util.AbstractList$1.next(AbstractList.java:354)<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
java.lang.NullPointerException<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
</pre> Though if a workaround can be found for those issues (most likely bugs in the version of GNU Classpath in question. May not apply to newer versions, or a patched robocode might be able to work around it), it may work. Not sure that'll be possible though. Oh well... --[[User:Rednaxela|Rednaxela]] 03:54, 7 August 2009 (UTC)<br />
<br />
== Rumble Computers ==<br />
<br />
I'm curious, what kind of computers are people using for roborumble? [[Voidious]] and [[Simonton]] seem to really have some nice ones I think. Personally the computers I have avaliable to run rumble consist of:<br />
* Intel Core 2 Duo T5300 (1.73GHz), 2GB ram, laptop, usually avaliable<br />
* AMD Athlon XP 2000+, 512MB ram, often avaliable<br />
* AMD Athlon XP 2400+, 1GB ram, rarely avaliable<br />
I would also have my wimpy iPod were it not for one little bug preventing successful running of bots in the VM installed there. Sometimes... I'm really tempted to get a brand new shiney quad core monster for the sole purpose of storing backups, and running RoboRumble/Research :) --[[User:Rednaxela|Rednaxela]] 03:41, 16 August 2009 (UTC)<br />
<br />
I have:<br />
* MacBook 2.0 GHz Core Duo, 2 GB RAM, and I can run two clients on it safely. It's actually 3+ years old, but it holds up pretty well.<br />
* AMD 2000+, 768MB RAM (Ubuntu 8.10), which I've been running a rumble client on almost 24/7 for a while now.<br />
* Just yesterday, I ordered a MacBook Pro 2.8 GHz Core 2 Duo with 4 GB RAM. So that will more than double my total rumble power, I think. =)<br />
I wonder what [[User:Corbos|Corbos]] had, I couldn't have kept up with him if I tried when he was rumbling recently. I've also been tempted many times to spring for a quad core Linux box just for Robocode, but so far I've been able to resist... (mmm, quad core...) --[[User:Voidious|Voidious]] 03:55, 16 August 2009 (UTC)<br />
<br />
: Haha... I unfortuantely can't run two clients on my Core 2 Duo laptop... the CPU just plain gets too hot. What I really want to see though, is MXThreadBean timing in a new robocode version, which would make it safe to enable the option to allow robots to run concurrently, when in rumble... Then one could take advantage of a 8 beast when running melee rumble with only one client... --[[User:Rednaxela|Rednaxela]] 04:29, 16 August 2009 (UTC)<br />
<br />
My client runs on an old laptop -- all it does is run roborumble + meleerumble:<br />
* Intel Pentium M w/512MB ram, 100% available<br />
Occasionally I press my main machine (MacBook Pro, Core 2 Duo, 3GB) into service, but mostly I need it for work or running RoboResearch (that's what it's doing right now, in fact). It's also where the development rumble server lives, so this client is normally pointed at that anyway. Running both I was able to keep ahead of GrubbmGait for awhile until Voidious et al made our upload counts look puny by comparison.<br />
--[[User:Darkcanuck|Darkcanuck]] 04:26, 16 August 2009 (UTC)<br />
<br />
My client is a 2.66 Mhz Pentium4 (single-core) with 1GB. There was a time that I ran roborumble on a 400Mhz laptop with 128Mb using robocode 1.0.7. Btw, Darkcanuck, are you able to remove (or rename) those somewhat embarrasing contributions of GrubbmGait_15x and GrubbmGait_17x at the very low bottom. --[[User:GrubbmGait|GrubbmGait]] 11:08, 16 August 2009 (UTC)<br />
<br />
: Wow, 2.66 MHz!!?! :-D J/k. --[[User:Voidious|Voidious]] 15:04, 16 August 2009 (UTC)<br />
<br />
: It's done. I merged GrubbmGait_15x into GrubbmGait_154, and removed the lone battle from GrubbmGait_17x (the upload still shows up, merged into GrubbmGait). --[[User:Darkcanuck|Darkcanuck]] 17:38, 16 August 2009 (UTC)<br />
<br />
When I used to run it, I ran it on my Intel Centrino 2 P8400 2.26GHz with 4GB of RAM (but with 32bits OS it only sees 3GB) laptop, which I used for other works too. The time I run I only use FF to surf the web, but now I need to use Photoshop, Eclipse, LAMP and one virtual machine almost all the time so it doesn't available anymore. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 11:31, 16 August 2009 (UTC)<br />
<br />
I run my client in a Pentiun Dual Core 1.86 GHz, and I usualy run 2 clients, but right now I'm using it to test several new versions of my robot, so the rumble has to wait...--[[User:Navajo|Navajo]] 14:36, 16 August 2009 (UTC)<br />
<br />
== Lower Rank Limit? ==<br />
<br />
Wouldn't it be reasonable to remove bots that gets negative ELO Rating (i.e elvbot.ElverionBot(ELO: -191.0) & ry.Worst 1.0 (ELO: -365.3) ) ?<br />
<br />
They almost always score 0% and uses cpu-time while they contribute with near to nothing. --[[User:Rsim|Rsim]] 15:37, 16 August 2009 (UTC)<br />
<br />
== Whoops ==<br />
<br />
Err... sorry my client reactivated some old melee bots due to old data lying around, seems they crave pairings now... plus a large number of recently released melee bots... means sloooow melee right now... --[[User:Rednaxela|Rednaxela]] 05:10, 10 September 2009 (UTC)<br />
<br />
== Iteration ==<br />
<br />
I wonder if this happen to everyone or just me. When I run RoboRumble client, both 1.6.1.4 (which upload to darkcanuck's server) and 1.7.1.4 (which I use to test locally because it is faster), I found that after iteration 80 things got slower. I mean with 1.6.1.4 I can run 100 iteration in 4 hours, then another 4 hours it can run only 50-60 iterations. SO I tend to restart my client every 80 iterations. (and cool my hard disk down a little, it is around 80 degree Celcius when I run it for 150 iterations) Do anyone, especially who run RoboRumble overnight, have similar situation? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 03:10, 11 October 2009 (UTC)<br />
<br />
I've found that 1.6.1.4 still seems to have some long-term memory leakage actually. Not as bad as older version, but enough that it's still worth not using the ITERATE option actually. --[[User:Rednaxela|Rednaxela]] 03:54, 11 October 2009 (UTC)<br />
<br />
== JVM Crash ==<br />
<br />
After running the RoboRumble client (1.6.1.4) for about 12 hours, my JRE crashed. I have not been able to reproduce the problem, but I thought I'd post about here in the event it has happened to someone before. I've submitted a bug report to Sun and saved the logs [[http://www.devfluid.com/csc_club/JRE_Crash Here]]. It may not be relevant, but this happened when evaluating Krabb.sliNk.Garm 0.9u. --[[User:Christopher.Hilla|Christopher.Hilla]] 22:06, 7 February 2010 (UTC)<br />
<br />
Huh... that's a very peculiar bug. I doubt there's anything more to it other than there being a bug in the JVM though, assuming this isn't something you're able to repeat reliably. --[[User:Rednaxela|Rednaxela]] 22:48, 7 February 2010 (UTC)<br />
<br />
== Contributor's Sum ==<br />
<br />
I started contributing less than 30 days ago, yet my "All time" and Monthly sums don't match. My "All time" sum is much larger than what I've actually contributed. Even though my point tally is sort of like keeping score on "Whose Line Is It Anyway", it's worth mentioning :) --[[User:Christopher.Hilla|Christopher.Hilla]] 06:49, 9 February 2010 (UTC)<br />
<br />
: The monthly and 30-day totals are based on ''battles'', whereas the all-time list is number of ''uploads''. For a 1v1 battle between megas there is only one upload, but for smaller classes there will be one upload per size class (e.g. two nanos will generate 4 uploads). Melee is even more complicated since a full set of pairings for 10 megas will yield 45 uploads, even more if there are smaller bots in the mix. So your all-time uploads should be greater than the sum of the battles you've contributed so far. --[[User:Darkcanuck|Darkcanuck]] 07:41, 9 February 2010 (UTC)<br />
<br />
:: Thank you for the explanation. --[[User:Christopher.Hilla|Christopher.Hilla]] 19:49, 9 February 2010 (UTC)<br />
<br />
== Incomplete robot list == <br />
Hey Darkcanuck, I 've been running a few rumbles..and noticed I am missing a large number of bots " can't file specified file". Any Suggestions? Thx.. oh , I should mention Last night while Running an iteration envolving DR3.06 , Portia and 8 other bots. Something probably on my end screwwing up results for 1 battle. Not sure how, or why, but just one battle. -[[User:Jlm0924|Jlm0924]] 20:06, 27 April 2010 (UTC)<br />
<br />
== DogmanSPE ==<br />
<br />
I just ran a few tests to try and figure out the discrepancy between 1.8.0 and 1.8.2 of DrussGT, and now I can't repeat 1.8.0's results against DogmanSPE. I then decided to try a few rounds against Diamond 1.5.5, and it seems he also isn't living up to the scores he's getting on the rumble against DogmanSPE. The only thing I can think of is that it may be different versions of Robocode, as I'm doing my testing with 1.7.2b2. Any ideas? Maybe Dogman gets smart only at certain times of day? --[[User:Skilgannon|Skilgannon]] 15:06, 9 May 2010 (UTC)<br />
<br />
Eh, DogmanSPE is a major troublemaker and always has been. It sometimes doesn't crash, but when it does crash it crashes for every subsequent round of the battle. This makes it's results always unpredictable. It doesn't affect overall APS too badly because of the sheer number of bots, but it's probably the single worst offender in the rumble. Issues with DogmanSPE have [[oldwiki:RoboRumble/RankingChat|been pointed out before]]. Personally, I'm in favor of removing DogmanSPE. --[[User:Rednaxela|Rednaxela]] 15:25, 9 May 2010 (UTC)<br />
<br />
: So am I. Anyone object? --[[User:Voidious|Voidious]] 17:28, 9 May 2010 (UTC)<br />
<br />
:Done =) --[[User:Skilgannon|Skilgannon]] 19:17, 9 May 2010 (UTC)<br />
<br />
== LRP ==<br />
<br />
Perhaps we should have a section on what the LRP does. I mean most of use from the old wiki know but... Anyway in the words of Paul,<br />
<br />
<pre><br />
May seems a stupid question, but, what is the blue line, and the 4 quadrants?<br />
I can guess that on the X axis there is the expected score and on the Y the difference between expected and actual score.<br />
But what the blue line is supposed to mean? -- [[Simonech]]<br />
<br />
You are correct on the X axes and Y axes scales - the Blue line is a best-fit straight line through the data. if it has a negative<br />
gradient slopes downhill (left to right) I believe it would indicate that the movement for the bot is stronger than the gun. A<br />
positive gradient would indicate a good gun is being let down by relativley poor movement. -- [[Paul]]<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 04:55, 4 July 2010 (UTC)<br />
<br />
== Rumble use of 1.7.2.1 Beta? ==<br />
<br />
Guys, do you think that Robocode 1.7.2.1 will be good enough to replace the very old 1.6.1.4 for RoboRumble? If not, what must be done? --[[User:FlemmingLarsen|Fnl]] 22:06, 29 June 2010 (UTC)<br />
<br />
: The main problem I have with 1.7.2.1 is that objects from the data section in jars from inside zips at least do not get extracted to the cache. I also have problems with duplicate robots in the repository (mostly only ones on the development path). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 00:57, 30 June 2010 (UTC)<br />
<br />
:: Huh, I was under the impression that the data files were extracted properly still. (note, it's technically not a robotcache anymore). Also, what do you mean by duplicate robots, and is this different than older versions? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
: Well, I haven't noticed any new problems myself, but I've yet to have a chance to test very extensively, but I plan to on what is a long weekend coming up here. I'm going to clear my localhost rumble server and re-run testing with the latest version. Does anyone thing it would be good if I opened up the 1.7.2.1 testing rumble server to the world so others could speed up the process of testing it? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
:: I think it would be good. I am more than willing help you. If not due the stability of internet connection of my server I would open a testing server ages ago (well, my server located at my school in the university's infrastructure which is like twenty years old or more). Just a side note, 1.7.1.x runs at least five times faster than 1.6.1.4. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:51, 30 June 2010 (UTC)<br />
<br />
: Okay. I will wait a little with releasing 1.7.2.1 so you guys get the chance of testing it a bit more. 1.7.2.1 is "just" replacing the Jikes compiler with ECJ + some bug fixes compared to 1.7.2.0. I have started working on the 1.7.2.2 with some new features + I try to improve the speed with loading/updating the development paths, which are loaded extremely slow compared to the .jar files. :-) --[[User:FlemmingLarsen|Fnl]] 19:57, 2 July 2010 (UTC)<br />
<br />
Alright, I just moved the bots that are known to not work in 1.7 for "WontFix" reasons out of the participants list. Anybody mind? I kept them on the bottom of the pages with links to the SF ticket that's relevant. --[[User:Rednaxela|Rednaxela]] 20:46, 4 July 2010 (UTC)<br />
<br />
Okay, I now have a rumble test server facing the world on [[http://rednaxela.gotdns.com:8080/rumble/]]. It should be secured and fast enough now, I think. Feel free to run 1.7.2.1 Beta clients on it for testing! :) --[[User:Rednaxela|Rednaxela]] 21:56, 4 July 2010 (UTC)<br />
<br />
I have my roborumble and meleerumble client pointed to your server now. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 13:29, 6 July 2010 (UTC)<br />
<br />
Red, do you have any comparing method planned? The melee is almost completed, though it should need more before becoming stable. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 14:48, 12 July 2010 (UTC)<br />
<br />
My current comparing plan is:<br />
# First look for obvious outliers (things missing from high ranks, things at extreme low ranks)<br />
# Then import the 1.6.1.4 rumble and 1.7.2.1 rumble results tables into a spreadsheet, sort each by name, line them up beside eachother, create a column for rank difference and PL difference, then sort by those to find outliers.<br />
# Test any outliers. Determine if it's a bug to report, or the bot doing something that it shouldn't<br />
Currently, 1v1 rumble has two outliers at the bottom. I already reported the bug for one and it was fixed, and I think the other is breaking due to using File IO without using the proper robocode streams. About to do the spreadsheet with melee :) --[[User:Rednaxela|Rednaxela]] 02:13, 13 July 2010 (UTC)<br />
<br />
The biggest melee outliers by APS. Positive numbers mean improvement:<br />
{|<br />
|<br />
|Rank change<br />
|APS change<br />
|----<br />
|jab.DiamondStealer 5<br />
|145<br />
|20.07<br />
|----<br />
|gg.Squaraus 0.6<br />
| -72<br />
| -14.08<br />
|----<br />
|com.syncleus.robocode.Dreadnaught 0.1<br />
|49<br />
|9.40<br />
|----<br />
|stelo.Spread 0.2<br />
|62<br />
|6.34<br />
|----<br />
|bayen.nut.Squirrel 1.615<br />
|48<br />
|4.36<br />
|----<br />
|stelo.Moojuk 1.3<br />
|10<br />
|3.95<br />
|----<br />
|stelo.SoJNanoMelee 1.1<br />
| -23<br />
| -2.95<br />
|----<br />
|exauge.GateKeeper 1.1.121g<br />
|21<br />
|2.37<br />
|----<br />
|sgp.JollyNinja 3.53<br />
|18<br />
|2.12<br />
|----<br />
|lrem.micro.SpikeSoldier 0.4<br />
|19<br />
|2.00<br />
|----<br />
|sample.TrackFire 1.0<br />
| -0<br />
| -1.87<br />
|----<br />
|}<br />
I suspect DiamondStealer may have had bad results on the main rumble server, and I suspect the APS differences below 3% are probably a fluke. Maybe some of the larger are too, but I plan to test Squaraus and Dreadnaught anyway. --[[User:Rednaxela|Rednaxela]] 05:16, 13 July 2010 (UTC)<br />
<br />
Dreadnaught also had bad results in the beginning (not complient to 1.5.4 I believe) --[[User:GrubbmGait|GrubbmGait]] 08:49, 17 July 2010 (UTC)<br />
<br />
== .NET ==<br />
<br />
Is it possible to submit robots written in .NET to RoboRumble? --[[User:Dserbia|dserbia]] 15:18, 15 July 2010 (UTC)<br />
<br />
No, not at the moment. We have to make sure Robocode 1.7.x reach the really stable phase before. And I think we should wait for jni4net to reach at least beta status, for Mono support. Many of high-contributing RoboRumble clients are running under either Linux or OSX. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 15:38, 15 July 2010 (UTC)<br />
<br />
Thanks for the quick reply! --[[User:Dserbia|dserbia]] 17:21, 15 July 2010 (UTC)<br />
<br />
Personally, I'm not sure I'd ever be in favor of allowing them into the rumble. There would then be bots in the rumble that Mac/Linux users could never test against (and there are a lot of us), and it would also make us dependent on .NET users to contribute battles for those bots when we post new versions of our own. But I do sympathize - if/when more .NET Robocoders come onto the scene, things could change.<br />
<br />
Keep in mind that all of this stuff is community driven, though it may all seem very "official" to a newcomer. Anyone is free to setup a competition / tournament / rumble that includes .NET bots if they want! We've had tournament style competitions like the [[oldwiki:MiniBotChallenge|MiniBot Challenge]] and [[Twin Duel]] in the past, Robocode has APIs that make automating battles for tourneys fairly easy, and Darkcanuck posts the source to his rumble server somewhere (Nat or Rednaxela would know). And there's always [[:Category:Challenges|Challenges]] you can compete in, too.<br />
<br />
--[[User:Voidious|Voidious]] 17:38, 15 July 2010 (UTC)<br />
<br />
: I think Pavel Savara has plan for suporting jni4net, which is the core of .NET Robocode, on Mono, which can be run under Linux and Mac OS X. I don't think there is a valid reason for not supporting those when that day come. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 06:57, 16 July 2010 (UTC)<br />
<br />
: Yeah, it could work out, but there's still lots of room for issues. How stable is Mono? Will Mono add behavior discrepancies to .NET bots? Or will Java bots hit subtle behavior discepancies when battling .NET bots on Windows? (Either of those could be very hard to debug for the bot author.) Will .NET bots run much slower when running through Mono? Will that count against them in terms of CPU time/skipped turns? We've seen plenty of issues just from different JVMs / CPUs / OSes, so adding Mono and .NET to the rumble definitely requires caution. Or it may work perfectly smoothly and we'll all coexist peacefully. =) --[[User:Voidious|Voidious]] 15:18, 16 July 2010 (UTC) <br />
<br />
:: As long as one isn't doing GUI or calls to native libraries (not allowed for bots anyway), I'm pretty sure Mono is quite accurately compatible, however my concerns are around the fairness issues. x86 Java is reasonably uniform in terms of what parts of the code get optimized how well by the JVM. As I understand, Mono's performance is pretty reasonable overall, however since it's coded from scratch it's optimization characteristics are notably different I think, which makes cpu fairness somewhat tricky for having MS .Net and Mono running the same rumble. If one looks at [http://lists.ximian.com/pipermail/mono-list/2007-April/034899.html this], it's fairly old, but shows large performance differences going either way in terms of different types of operations. That exact issue only becomes larger between the JVM and .NET, so I really do think it makes sense for .NET to be kept to a separate rumble (possibly on the same server but separated like the different formats?). --[[User:Rednaxela|Rednaxela]] 19:23, 16 July 2010 (UTC)<br />
<br />
== New Rumble ==<br />
<br />
Rednaxela and I have been talking a bit, and we have put considerable thought into a new 1-vs-1 rumble. Unlike our current 1-vs-1 rumble, this would have no data saving, be single round battles on a 800x800 field. Also considering having the game 'white out' names in a battle to just numbers, so there can be no hard-coded specific bot data saving either. I personally feel this kind of 1-vs-1 competition would allow for much greater competition from non-adaptive movements, and lower the bar considerably for newer robocoders. But not too much, since obviously, Crazy would never be able to win over DrussGT.<br />
<br />
We also considered non-random starting positions (for greater fairness) and a 4 bot single round melee on the same field size.<br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 16:16, 24 July 2010 (UTC)<br />
<br />
Yeah, I think this would be a really neat thing to have. Now, I don't think it should replace the old-style rumble, but I think it would make a very interesting competition, and perhaps much less daunting for newcomers. And to clarify on what the "white out" of names, it means robot names that bots would see would just be like "1", "2", "3", or perhaps "robot 1", "robot 2", "robot 3". Now, that does require a modification to Robocode, but I think it would probably be relatively simple and quick to get implemented. (I say it should be simple because Robocode already alters names when multiple of the same bot are in a battle, so I'd imagine the same code path can be reused, so just a matter of changing it for a certain rumble flag) --[[User:Rednaxela|Rednaxela]] 16:27, 24 July 2010 (UTC)<br />
<br />
We have put togeather a seed of 60 robots, please keep in mind this is just a seed, and you can add your own robots when it gets started. This is just to round out the robots so that we can get some meaningful rankings.<br />
<pre><br />
abc.Tron 2.02<br />
ags.micro.Carpet 1.1<br />
ags.polished.PolishedRuby 1<br />
apv.Aspid 1.7<br />
apv.NanoLauLectrik 1.0<br />
apv.ScruchiPu 1.0<br />
ary.nano.AceSurf 1.2<br />
axeBots.Musashi 2.18<br />
axeBots.Okami 1.04<br />
chase.pm.Pytko 1.0<br />
cjm.Che 1.2<br />
cx.Lacrimas 1.36<br />
cx.mini.Cigaret 1.31<br />
darkcanuck.Gaff 1.50<br />
davidalves.net.DuelistMini 1.1<br />
davidalves.net.DuelistNano 1.0<br />
dummy.micro.Sparrow 2.5<br />
gh.GrubbmGrb 1.2.4<br />
gh.GrypRepetyf 0.13<br />
jam.mini.Raiko 0.43<br />
jk.micro.Toorkild 0.2.4b<br />
kawigi.robot.Girl 1.2<br />
kawigi.sbf.FloodHT 0.9.2<br />
kawigi.sbf.FloodSonnet 0.9<br />
kc.micro.Needle 0.101<br />
kc.micro.Thorn 1.252<br />
kc.mini.Vyper 0.311<br />
kc.nano.Splinter 1.2<br />
kid.Gladiator .7.2<br />
Krabb.krabby2.Krabby2 1.9o<br />
mld.Moebius 2.9.3<br />
mue.Hyperion 0.8<br />
mz.NanoDeath 2.56<br />
pe.SandboxDT 3.02<br />
pe.SandboxLump 1.52<br />
pedersen.Ugluk 1.0<br />
pez.mako.Mako 1.5<br />
pez.mini.Tityus 0.9.1<br />
pez.mini.VertiLeach 0.4.0<br />
ry.VirtualGunExperiment 1.2.0<br />
rz.Aleph 0.34<br />
rz.GlowBlowAPM 1.0<br />
sample.Walls<br />
sample.Crazy<br />
simonton.beta.LifelongObsession 0.5.1<br />
simonton.micro.GFMicro 1.0<br />
simonton.micro.WeeklongObsession 3.4.1<br />
simonton.nano.WeekendObsession_S 1.7<br />
stefw.Tigger 0.0.23<br />
synapse.Geomancy 15<br />
techdude.Carruthers 1.2.6<br />
tzu.TheArtOfWar 1.2<br />
voidious.micro.Jen 1.11<br />
vuen.Fractal 0.55<br />
wcsv.Engineer.Engineer 0.5.4<br />
whind.Strength 0.6.4<br />
wiki.BasicGFSurfer 1.02<br />
wiki.mini.Sedan 1.0<br />
wiki.nano.RaikoNano 1.1<br />
zyx.micro.Ant 1.1<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 17:36, 24 July 2010 (UTC)<br />
<br />
== 1.7.x rumble eventually... ==<br />
<br />
Hey guys... I kind of think I dropped the ball on working on getting 1.7.x to main rumble before... but I still think it would be good to eventually. Now... unlike before (where the rumble server was a little VM on my machine that I sometimes had to shut down for lack of memory), I have a more proper server I could use for rumble. I probably won't get around to setting this up till after winter holidays (have plans with family), but just wanted to ask, how much interest in this is there? Best Regards. --[[User:Rednaxela|Rednaxela]] 07:29, 21 December 2010 (UTC)<br />
<br />
I am still interested in. Right now (well, not really, since I am not actively writing robots), my movement predictor have flags for 1.6.1.4 or 1.7.1.3+ movement. Since rumble runs 1.6.1.4 but 1.7.x+ runs much faster. Also, the whole rumble would take less time to stabilised (but it would put more load to server, since client can run, as Pavel claimed, ''ten'' times faster. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 11:36, 21 December 2010 (UTC)<br />
<br />
I'm still interested. Kept meaning to ask you why the test rumble server went down but never did. Do you still have all the results, or would we start from scratch? Anyway, it would be good to be current. A lot of new people get 0 scores because they use new APIs, plus there's the performance benefits. --[[User:Voidious|Voidious]] 14:00, 21 December 2010 (UTC)<br />
<br />
: Yeah, I do still have the old data, but I'm not sure we want to use it. Presumably we'd want to test now with the very latest version, and mixing the results in this of multiple versions in this test could cloud results. --[[User:Rednaxela|Rednaxela]] 14:59, 22 December 2010 (UTC)<br />
<br />
Alright! I have a new rumble test server up and running at [http://rednaxela-robocode.dyndns.org/rumble/ http://rednaxela-robocode.dyndns.org/rumble/]. For ease of use, rumble configuration templates are linked from it's main page. Also, if you want, here's a convenient zip of all the bots currently in rumble: [http://rednaxela-robocode.dyndns.org/data/robot_archive.zip]. This one is located on a more proper type of server, rather than a virtual machine on my laptop. So... time to get testing 1.7.2.2 and prove it stable? :) --[[User:Rednaxela|Rednaxela]] 06:37, 19 January 2011 (UTC)<br />
<br />
: Hm, I thought I had this page "watched" but it looks like I've missed a lot... Is the new server running the same code and database schema as the current one? --[[User:Darkcanuck|Darkcanuck]] 06:43, 19 January 2011 (UTC)<br />
<br />
:: Yep, same code and database schema. The only changes I made were to the front html page, and changing the accepted version of robocode to 1.7.2.2. --[[User:Rednaxela|Rednaxela]] 06:57, 19 January 2011 (UTC)<br />
: I found my old laptop, I will set it to run, I might tweak the CPU constant up a little too, since it is a older/slower machine. (I will just set it in my closet, away from hustle and bustle). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 09:32, 19 January 2011 (UTC)<br />
<br />
: Nice! I'll start running my clients against this again. Thanks Rednaxela! Btw, the superpack .zip is gone from [[RoboRumble/Starting With RoboRumble]]. I'll make a new one with the above archive unless you could just repost the old one. --[[User:Voidious|Voidious]] 14:47, 19 January 2011 (UTC)<br />
<br />
:: It turns out both my laptops puked at some point while I was out (one locked up while loading rankings, the other I forgot to make a loop and iterate was NOT). Not sure if you still have to do iterate not, and make a script loop, but I did. Only my main system had kept running the rumble. But I restarted both of those now. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:36, 20 January 2011 (UTC)<br />
<br />
::: As far as I know, all the memory leaks have been fixed. I had my client run over the whole day and the memory use plateaued nicely with no issues whatsoever. --[[User:Rednaxela|Rednaxela]] 02:39, 20 January 2011 (UTC)<br />
:::: Ah well, I will switch them to use ITERATE then. Thanks. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:59, 20 January 2011 (UTC)<br />
<br />
Is there anything that we're waiting on for the switch to the 1.7 rumble rankings? I'd love to help make this upgrade happen. [[User:Ncj|Ncj]] 16:45, 4 April 2011 (UTC)<br />
<br />
I know Rednaxela was investigating some of the outliers from the test server's rankings. I'm not sure there was really anything "stop ship" though. I think the rankings look pretty good. Rednaxela, what do you think? --[[User:Voidious|Voidious]] 20:38, 4 April 2011 (UTC)<br />
<br />
Well, here's the "Table of Anomalous Results" I made when the 1.7.2.2 rumble first stabilized:<br />
<br />
{| border="1" cellpadding="2" style="border-collapse: collapse; color: black; font-size: xx-small" class="sortable"<br />
|class="unsortable"| ||Old Rank||Old %||New Rank||New %||Rank Diff||% Diff||class="unsortable"| ||ABS % Diff||ABS Rank Diff||Explanation<br />
|-<br />
| CharlieN.Omega.Omega 1.03||319||55.29||774||9.19||-455||-46.1||||46.1||455||[http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405]<br />
|-<br />
| NDH.GuessFactor 1.0||787||0.42||578||39.54||209||39.12||||39.12||209||uses post-1.6.1.4 functions<br />
|-<br />
| jeremyreeder.Vincent 2011.12.09||788||0||645||33.68||143||33.68||||33.68||143||uses post-1.6.1.4 functions<br />
|-<br />
| Krabb.krabby2.Krabby2 1.9o||71||73.63||528||43.12||-457||-30.51||||30.51||457<br />
|-<br />
| gg.Squaraus 0.6||714||26.3||786||4.62||-72||-21.68||||21.68||72||[http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405]<br />
|-<br />
| elvbot.ElverionBot 0.3||785||0.72||751||19.75||34||19.03||||19.03||34||uses post-1.6.1.4 functions<br />
|-<br />
| TJ.Exupery 1.39||403||50.02||174||63.3||229||13.28||||13.28||229||<br />
|-<br />
| zh.UnderDog 0.0.2||782||4.31||762||14.11||20||9.8||||9.8||20||1 on 5 exception in TacticalAdvisor in 1.6.1.4<br />
|-<br />
| reaper.Reaper 1.1||357||53.1||194||62.6||163||9.5||||9.5||163||crashes on some clients in 1.6.14 but not 1.7?<br />
|-<br />
| sm.Devil 7.3||517||44.13||351||53.45||166||9.32||||9.32||166||crashes on some clients in 1.6.14 but not 1.7?<br />
|-<br />
| xiongan.Xiongan 1.1||709||27.05||614||36.22||95||9.17||||9.17||95||<br />
|-<br />
| ag.Gir 0.99||762||13.25||739||22.26||23||9.01||||9.01||23||<br />
|}<br />
The case of "CharlieN.Omega.Omega 1.03" was [http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405], and has been fixed in 1.7.3.0 Beta. Unfortunately I've yet to investigate the other results.<br />
<br />
Some of positive results I suspect may have been from using some Robocode 1.7 features perhaps (i.e. some new events). The case of Krabby2 I in particular mean to investigate because that result looks quite odd. Some other positive changes like Devil seem strange to me, because Devil predates Robocode 1.7 by a huge margin, yet seems to do better than in 1.6 by a notable margin. I've yet to be able to figure that out either. Anyone have any theories or can look into these cases?<br />
<br />
Anyway, presuming these issues can be worked out, what do people think of moving straight to 1.7.3.0 perhaps? The difference relative to 1.7.2.2 is small so I don't see it as that high risk, and if it turns out there were issues, then we're no worse off than if we had spent the same effort to test 1.7.3.0. Thoughts?<br />
<br />
--[[User:Rednaxela|Rednaxela]] 04:45, 5 April 2011 (UTC)<br />
<br />
SmallDevil crashes on my clients (dunno about others), so his 1.6 score is probably just wrong. I'm probably OK with moving to 1.7.3.0, but I'd prefer to just go with 1.7.2.2 since that's the one we've actually spent so much time testing. The difference being small could support either decision. =) 1.7.3.0 is still beta, too. --[[User:Voidious|Voidious]] 12:44, 5 April 2011 (UTC)<br />
<br />
Well, of course some testing of 1.7.3.0 needs to be done, but that should be possible to complete before it's out of beta. I think it's changes from 1.7.2.2 are definitely seem small enough to me that it's not like we need to do a full rumble run again. --[[User:Rednaxela|Rednaxela]] 13:23, 5 April 2011 (UTC)<br />
<br />
The three bots 'NDH.Guessfactor', 'jeremyreeder.Vincent' and elvbot.ElverionBot' all use post-1.6.1.4 functions, no further investigation needed for them. SmallDevil indeed occasionally crashes, why it does not do that on 1.7.2.2 I don't know. I believe the same goes for 'reaper.Reaper'. Friday I will have some time to check other differences. Is there a possibility to check all '2100-0' scores on the server for a specific bot? A bad client on the moment of submission has a permanent influence now. On the old server (years ago) these bad results faded away with each new battle (0.7*0.7*0.7 etc). --[[User:GrubbmGait|GrubbmGait]] 18:35, 6 April 2011 (UTC)<br />
<br />
: I suspect [[SmallDevil]] just crashes due to some corrupt saved data, tho I haven't investigated it. I've seen the same with other bots, like [[TheBrainPi]]. I wiped my robotcache today so I'll watch out for SmallDevil battles from me with any new bot releases. --[[User:Voidious|Voidious]] 00:30, 7 April 2011 (UTC)<br />
<br />
Interesting. Tomorrow I think I'll be able to look into these more, especially Krabby2 I think. --[[User:Rednaxela|Rednaxela]] 05:00, 7 April 2011 (UTC)<br />
<br />
For reaper.Reaper and sm.Devil just check their scores against ad.last.Bottom. There is the possibility that these bots still could crash in 1.7, as it only happens occasionally.<br />
Is there a way to reject/ignore 21xx-0 scores (if other scores are available) and scores way outside the normal range? That would be like an aspirine for the ranking. See example below. --[[User:GrubbmGait|GrubbmGait]] 14:18, 7 April 2011 (UTC)<br />
<br />
BATTLE DETAILS FOR "reaper.Reaper 1.1" VS "abud.ThirdRobo 1.0" IN GAME "roborumble"<br />
<pre><br />
|% Score |% Survival |score |bullet dmg. |survival |score |bullet dmg. |survival |Battle Time |Submitted by <br />
| | reaper.Reaper 1.1 | abud.ThirdRobo 1.0 |<br />
|90.622 |100.000 |5991 |3233 |35 |620 | 614 | 0 |2010-05-31 12:57:18:835 |cberendt@178.63.10.12 ver.1.6.1.4 <br />
|90.927 |100.000 |5963 |3215 |35 |595 | 590 | 0 |2010-02-09 07:49:56:713 |Miked0801@207.170.253.83 ver.1.6.1.4 <br />
|90.044 |100.000 |5960 |3209 |35 |659 | 657 | 0 |2010-01-06 02:27:33:942 |darkcanuck@24.85.46.67 ver.1.6.1.4 <br />
|89.834 |100.000 |5956 |3200 |35 |674 | 667 | 0 |2009-01-15 16:51:12:182 |darkcanuck_154@24.85.45.250 ver.1 <br />
|90.435 |100.000 |5928 |3187 |35 |627 | 622 | 0 |2008-09-10 15:49:11:187 |ABC@import ver.1 <br />
|88.993 | 97.143 |5862 |3179 |34 |725 | 643 | 1 |2008-09-21 12:06:41:943 |ABC@import ver.1 <br />
|0.000 | 0.000 | 0 |0 | 0 |2103 | 0 |35 |2010-11-09 13:21:30:209 |Voidious@76.15.102.168 ver.1.6.1.4 <br />
|0.000 | 0.000 | 0 |0 | 0 |2101 | 0 |35 |2010-07-04 13:50:23:859 |Voidious@76.15.102.168 ver.1.6.1.4 <br />
|0.000 | 0.000 | 0 |0 | 0 |2101 | 0 |35 |2009-10-13 23:34:34:50 |Voidious@173.50.167.108 ver.1.6.1.4 <br />
|0.016 | 0.000 | 1 |0 | 0 |6179 |3395 |35 |2008-10-29 04:30:08:727 |darkcanuck@24.85.45.250 ver.1<br />
</pre><br />
<br />
== Client on Google Apps Engine ==<br />
<br />
I wonder, since the latest release of Google Apps Engine (1.5.0), Google add support for Backend, which allow process to run as long as you like. I think it is possible to port the RoboRumble@Home client to run on these environment; that would speed up the process. But I think we need to check if this is applicable with Google Apps Engine TOS and throttle the client enough so it doesn't use more than its free quota limit ;-) Just an idea! --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 01:42, 11 May 2011 (UTC)<br />
<br />
Well, I'm pretty sure that even if you can run a process as long as you like, they don't guarantee a constant amount of available CPU, which is important for robocode. Of course, if in the future, robocode switches to using the less granular APIs that track actual cpu time used by given threads, then this would probably work. It's not really the same, but as a note, you can already run robocode on Amazon's EC2, which does guarantee a level of CPU allocation. Chase-san briefly tried this once in the past.--[[User:Rednaxela|Rednaxela]] 02:51, 11 May 2011 (UTC)<br />
<br />
But, of course, unless you already host something on EC2, the EC2 isn't "free" ;-) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:19, 11 May 2011 (UTC)<br />
<br />
I've been running two instances of the client on the cheapest server offered by linode ($20/mo). I'd run more, as it's quad core, but it only has 500MB of RAM and is thus memory bound. I keep the box around in case I need to pretend my traffic is coming from the US, but for a dedicated RoboRumble box would EC2 end up being cheaper? [[User:Ncj|Ncj]] 16:52, 17 May 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:RoboRumble&diff=19058Talk:RoboRumble2011-04-06T22:34:27Z<p>Ncj: Added 'explanation' column to table of anomalous results so we can see what's left to do</p>
<hr />
<div>== RoboRumble history ==<br />
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ<br />
<br />
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar<br />
<br />
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar<br />
<br />
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar <br />
<br />
== Subpages ==<br />
Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)<br />
<br />
== Name ==<br />
<br />
Since the new wiki supports symbols in page names, should we put this page at [[RoboRumble@Home]] instead of RoboRumble? We already have a redirect from that page to this one... --[[User:AaronR|AaronR]] 23:34, 17 November 2007 (UTC)<br />
<br />
I second this change. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:30, 28 April 2009 (UTC)<br />
<br />
== RR seems to be down ==<br />
<br />
Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 03:07, 19 September 2008 (UTC)<br />
:Are you sure? Both [http://rumble.fervir.com/rumble/Rankings?version=1&game=roborumble rumble.fervir.com] and [http://abchome.aclsi.pt:8080/ ABC's] work for me. -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 03:33, 19 September 2008 (UTC)<br />
::I fail. I meant Robocode Repository. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 05:44, 19 September 2008 (UTC)<br />
::Not a big surprise there. =P -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 13:21, 19 September 2008 (UTC)<br />
<br />
Hi! What the heck happened to RR@H again? The main roborumble has only ~60 bots again... Otherwise, I uploaded Pugio 1.2 1 week ago and has only 120 battles in nanoRumble. Situation is the same in Darcanuck's page, too. Nobody is contributing?--[[User:Robar|HUNRobar]] 12:30, 11 October 2008 (UTC)<br />
<br />
Both ABC's server and DarkCanuck's server have no full pairings yet. Once the megabots have full pairings, the minirumble will get filled completely and as last the micro- and nano-rumble. Be patient, but it probably requires a few weeks before all nanobots have 1000 battles. Remember, 640 * 640 bots means a lot of battles! Pulsar's server has another issue. I don't know what happened, but I still run (repair)battles there. --[[User:GrubbmGait|GrubbmGait]] 13:14, 11 October 2008 (UTC)<br />
<br />
I realised that in Darcanuck's server the older versions of bots are still in game. I think the competitors there should be cleaned up. For example, I don't want to generate battles for Pugio 1.0 when I wait for the results of 1.2. --[[User:Robar|HUNRobar]] 14:57, 11 October 2008 (UTC)<br />
<br />
That's a temporary thing -- I'm uploading a huge amount of data from [[User:ABC|ABC]]'s server which includes old participants. There's a big performance hit to activating/retiring participants repeatedly, so for now everyone's in the rankings until I get caught up. But don't worry, no rumble clients will actually run these bots. They'll use only the version from the participants list. In a few days you should see the old bots disappear from the rankings. --[[User:Darkcanuck|Darkcanuck]] 15:03, 11 October 2008 (UTC)<br />
<br />
Whoops edit conflict, accidentally overwrote Darkcanuck's reply with this: "What versions get battles doesn't depend on the server, it depends on the participants list that clients are configured to (which should be the old wiki's one, the one here has not been synced for a long time). The server would have nothing to do with that so you shouldn't be generating battles for Pugio 1.0 unless your client is misconfigured I believe." Anyways Darkcanuck's reply clearly explains why there are currently old versions listed :) --[[User:Rednaxela|Rednaxela]] 15:10, 11 October 2008 (UTC)<br />
<br />
Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--[[User:Robar|HUNRobar]] 17:40, 11 October 2008 (UTC)<br />
<br />
Why can't I access ABC's server? My connection get timeout before it finished loading! -[[User:Nat|Nat]] 12:42, 6 January 2009 (UTC)<br />
<br />
== Lynch the Multi-Threaders! ==<br />
<br />
A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?<br />
# On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.<br />
# On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.<br />
This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we ''could'' enforce a rule saying that no multi-threaded bot is allowed in ''the rumble''! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --[[User:Simonton|Simonton]] 02:47, 23 September 2008 (UTC)<br />
<br />
Agreed. It isn't fair on the opposition, and makes it impossible to design a bot within the CPU-constant constraints. --[[User:Skilgannon|Skilgannon]] 10:34, 23 September 2008 (UTC)<br />
<br />
I either didn't see or forgot about this section. There are already bots that use multiple threads in the rumble: [[Toad]] definitely does, possibly [[X2]] (which shares some Toad code), and probably others. Not sure how I feel about removing them at this point, just contributing some facts here... --[[User:Voidious|Voidious]] 02:20, 7 August 2009 (UTC)<br />
<br />
Well, there are java APIs that allow things like only measuring the time used in a particular thread. Robocode could start to use these in order to make this fair, AND as a '''major''' bonus it would make using Robocode on a computer with a heavily loaded CPU not cause skipped turns. The issue is... those APIs don't give the same kind of resolution, thus meaning that the only way we do it would be if we calculated something more like "How much CPU time did threads of this bot use in the last 20 ticks?", instead of "How much time did this robot take between the start and end of this turn?" which would make skipped turns behave a bit different. Personally I think that may not be such a bad thing, but I'm not really entirely sure... --[[User:Rednaxela|Rednaxela]] 02:51, 7 August 2009 (UTC)<br />
<br />
: It looks like [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 this] &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:53, 7 August 2009 (UTC)<br />
<br />
:: Hm? "ERROR This artifact is not accessible." is what that page gives --[[User:Rednaxela|Rednaxela]] 13:11, 7 August 2009 (UTC)<br />
<br />
::: Sorry, I never noticed that this is 'private' tracker... Fnl thought that he needs more precise time and mem.usage detection. I have a comment on some time measuring much like to your "How much CPU time did threads of this bot use in the last 20 ticks?". However, we didn't mention a thread at all. But I believe that Robocode allow Robots to create up to 5 threads, I'll email Fnl this. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:53, 7 August 2009 (UTC)<br />
: The [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 tracker] is public now. :-) Basically, I want to measure the CPU usage with the new features in Java 5.0 for measuring the exact CPU per thread. Hence we will (when using the TheadMXBean) know for a fact exactly how much time all threads in a robot is using in total. However, the time interval when measuring using the ThreadMXBean is big compared to what we are used to with the CPU constant currently used in Robocode. So we need a solution that can deal with this issue. I have waited with this improved feature as this will have a big impact on the scores for the robots in the RoboRumble. We have already seen how much difference the getNextVelocity() makes, so imagine the difference when we make change the concept behind the CPU constant. --[[User:FlemmingLarsen|Fnl]] 21:07, 7 August 2009 (UTC)<br />
:: Personally, I'm actually not too worried about the impact of this change. Most bots don't skip many turns at all, and the effects of a few skipped turns are often overstated. As long as the average amount of CPU allowed per tick is still similar, I can't imagine it affecting scores too much. I suppose it might have a big impact on bots that abuse the currently untracked multi-threading, but I think we can all agree that they're sort of abusing the system right now, anyway. Of course, I'd be happy to run extensive tests, too. =) --[[User:Voidious|Voidious]] 21:55, 7 August 2009 (UTC)<br />
:: I'm agreement with Voidious on this. I doubt there would be any problems caused by this so long as the correct amount of time was chosen. I would say though, that I think that this feature should be targeted at a 1.7.1.5 release, for the same reason that it's generally considered bad practice to change both a bot's movement and gun in the same rumble iteration, haha. As a side note, I wonder if while we improve the measurement method to not be affected by other things on the system, that maybe we should also improve the cpu constant calculation. For one, it should use the same ThreadMXBean methods to be accurate, but also I wonder if we could have a more realistic benchmark of what a typical bot actually does with it's time. I propose we include a small suite of some of the things a more cpu intensive bot does in order to create a more representative benchmark. I propose coding a small suite consisting of something like the following: 1) KD-Tree, 2) Nanobot-style pattern matching, 3) Array operations (searching for peak, addition of a gaussian curve to an array, multidimensional array access), 4) 'Play-It-Forward' simulation, 5) GF calculation (aka simple trig). I think I'll begin a page for comments on and code for an improved benchmark --[[User:Rednaxela|Rednaxela]] 00:00, 8 August 2009 (UTC)<br />
:: 1.7.1.5? It was there for about eight months. I think maybe 1.8 or so... &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:10, 8 August 2009 (UTC)<br />
<br />
== What Now? ==<br />
<br />
How can I submit the new versions of DrussGT and Cunobelin? Has anybody heard any news on the old wiki? Will it be recovered? Is it gone forever? --[[User:Skilgannon|Skilgannon]] 15:47, 8 December 2008 (UTC)<br />
<br />
Well on November 30th I emailed PEZ and got a reply that it's an ugly error and that he'd look into it. I haven't heard anything since but I guess I might email PEZ again. I certainly hope it won't be gone forever as I'd at least like to have a read-only version due to how much great stuff there is there that's unmigrated. --[[User:Rednaxela|Rednaxela]] 16:12, 8 December 2008 (UTC)<br />
<br />
I really hope the old wiki content still lives on. In the meantime we could agree to use this wiki's list for my server. I don't have time this week to make the proposed participant list changes, but I could lock out add/removes for all but a few select clients to make sure we all use the same list? --[[User:Darkcanuck|Darkcanuck]] 18:28, 8 December 2008 (UTC)<br />
<br />
Well, the old wiki is back! I do wonder though, should we switch to using this wiki's participants list anyway? or should that wait till some other day in the future? --[[User:Rednaxela|Rednaxela]] 18:17, 9 December 2008 (UTC)<br />
<br />
: I'd like to keep using the old wiki at least until I can code up something to validate participants on the server side. Then it would be easier to switch and not have to worry about some clients using the wrong list. --[[User:Darkcanuck|Darkcanuck]] 05:39, 10 December 2008 (UTC)<br />
<br />
Random question: How much do you think the local client would speed up if I compiled it natively? Right now, we haev a bit of a bottleneck figuring out battles andif we could speed it up by a factor or 3 or so, why not? --[[User:Miked0801|Miked0801]] 21:52, 25 May 2009 (UTC)<br />
<br />
== Nanos get little love when things get busy ==<br />
I've been waiting for nearly 4 days for my latest bot to get to 2k battles against nanos, and I'm probably gonna have to wait 3 more for it to happen. Why? Nanos, after they get to their 1 battle per bot limit, are the last bots to be updated under the current system. I understand why the system was done this way, but is there anyway we can add a time component to the battle chooser to make sure that when things heat up in the rumble, nanos get some love as well? --[[User:Miked0801|Miked0801]] 20:47, 19 June 2009 (UTC)<br />
<br />
I hear ya. Even in Mega-land, it can take a while to get to 2k battles, and I don't really trust a rating until it does (even with all pairings). There are some RR client options you could try, like excluding bots or running NanoRumble only, but the latter will just do random battles, I think. A couple of nice client side options, imo, would be mini/micro/nano while still honoring pairing priority, and ignoring pairings while running bots with under NUMBATTLES (in all applicable rumbles). I'm definitely in favor of RR contributors having control over what battles they want to run... --[[User:Voidious|Voidious]] 22:48, 19 June 2009 (UTC)<br />
<br />
Nanos get ''way'' more than their fair share of processing time. By a time a nano reaches 2000 battles in its own class, it has typically reached 5000+ battles in the main rumble. Few, if any, megabots have yet to reach that level. Not only is it unfair to folks releasing larger bots, it also takes away cpu time from other nanos. So should we abolish nanos? Of course not!<br />
<br />
I'd vote for changing the client's battle selection such that when a new bot reaches full pairings, the remainder of its 2000 battles are fought against opponents in its own size class. Those battles will still count for the higher classes, so a nano would really only need 2000 battles overall. This would mean faster results for nanos and more cpu time for everyone else, regardless of size. --[[User:Darkcanuck|Darkcanuck]] 03:19, 20 June 2009 (UTC)<br />
<br />
I second Darkcanuck's suggestion, as it seems most fair to me. :) --[[User:Rednaxela|Rednaxela]] 05:12, 20 June 2009 (UTC)<br />
<br />
And yet, some nanos love to beat up on their larger sibling... But yes, when things slow down, nanos do get a ton of extra battles, but to be fair, most nanos run much, much faster than megas so the hit isn't that bad. My main concern was waiting at the back of a line of never ending micro/mega selections. Impatients and such. If we're going to change things to minimize waits, then first completing pairings, then 2k in class, then low priority updates across other classes would be awesome. Unlike melee, just 2 or 3 battles with a mega are usually sufficient to get a strong idea of where things stand. --[[User:Miked0801|Miked0801]] 09:10, 20 June 2009 (UTC)<br />
<br />
You can also set RUNONLY=NANO, but alas then no priority battles are fought, just random ones. And I set the battlecount to 1000, so nanos will get their battles earlier. --[[User:GrubbmGait|GrubbmGait]] 10:51, 20 June 2009 (UTC)<br />
* setting RUNONLY=NANO is not a good idea. The results only count for nano, so is not counted at micro/mini/mega. Setting the battlecount lower does pay off however, except when the bigger rumbles are flooded with new versions. --[[User:GrubbmGait|GrubbmGait]] 11:00, 20 June 2009 (UTC)<br />
<br />
It would be awesome if roborumble could execute smart battles with runonly parameters. For example, run prioritary battles but only among nanos. I don't think it would be such a difficult developement. --[[User:Robar|HUNRobar]] 14:33, 20 June 2009 (UTC)<br />
<br />
: I think the RUNONLY setting needs to be fixed -- as [[GrubbmGait]] pointed out, the battles don't get uploaded to the bigger size classes, which they should. I might put together a patch for this, but first I have some wave surfing to iron out... --[[User:Darkcanuck|Darkcanuck]] 17:41, 20 June 2009 (UTC)<br />
<br />
About battlecount, one habit I have, is constantly making my battlecount set to just a little above the lowest value in the rumble. That seems to have nice results sometimes. --[[User:Rednaxela|Rednaxela]] 16:03, 20 June 2009 (UTC)<br />
<br />
All right, I think I've figured out how to implement the change I suggested, plus fix the RUNONLY problem. If enough people are ok with this, I'll put together a patched 1.6.1.4 client with the changes and send the patches to [[Fnl]] for future releases too. --[[User:Darkcanuck|Darkcanuck]] 18:21, 21 June 2009 (UTC)<br />
<br />
: Quick question: Would this only affect the 1v1 pairing order? I definitely support it there, but making your suggested change in Melee pairings would have a major impact on some bots' scores... And thanks as always for your RoboRumble efforts! --[[User:Voidious|Voidious]] 19:33, 21 June 2009 (UTC)<br />
:: Only at first. The game already does all class battles for roughly 50% of the numbers in nano now. That's why [[DustBunny]] has been slowly rising in APS - he does worse in nano only. --[[User:Miked0801|Miked0801]] 20:42, 21 June 2009 (UTC)<br />
::: Well, right now a NanoBot gets 2,000 battles against the whole field, then a bunch against MiniBots and below, then MicroBots and below, then NanoBots. With this change, it would get some amount of battles against the whole field, then all NanoBot-only battles. Depending on the bot, I think it could have an impact. Then again, that's a quirky aspect of MeleeRumble that's tough to really regulate, anyway, so maybe it's not worth worrying about. --[[User:Voidious|Voidious]] 21:51, 21 June 2009 (UTC)<br />
:: Ah, good point, I hadn't considered melee. It does use a different routine for preparing battles though, so it's possible to patch 1v1 without affecting melee. Looking at the melee routine, it does create an interesting mix of battles -- I didn't realize that there were all-nano matchups. That must skew the scores depending on the ratio of battles a nano gets with mixed sizes versus all-nano? --[[User:Darkcanuck|Darkcanuck]] 02:15, 22 June 2009 (UTC)<br />
: I don't think it is a bug, i think it was made on purpose the way it is. Alas I don't remember the reason . . . --[[User:GrubbmGait|GrubbmGait]] 21:03, 21 June 2009 (UTC)<br />
<br />
== Mobile Devices ==<br />
<br />
Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --[[User:Rednaxela|Rednaxela]] 02:01, 7 August 2009 (UTC)<br />
<br />
* Definitely crazy. --[[User:Simonton|Simonton]]<br />
<br />
I think you're crazy, but only because the iPhone OS doesn't have Java. =) I actually just looked into this the other day, lol. Was there some tech you were looking at to make it work? --[[User:Voidious|Voidious]] 02:03, 7 August 2009 (UTC)<br />
<br />
Actually, when you don't limit yourself to the app store, there is a port of [[wikipedia:JamVM|JamVM]] w/ [[wikipedia:GNU Classpath|GNU Classpath]]. There's no JIT so it won't be fast... but it'll run.. or... almost:<br />
<pre>Iteration number 0<br />
Downloading rating files ...<br />
Downloading participants list ...<br />
Downloading missing bots ...<br />
Removing old participants from server ...<br />
Preparing battles list ... Using smart battles is true<br />
Prioritary battles file not found ... <br />
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)<br />
at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)<br />
at robocode.manager.RobocodeManager.initSecurity(Unknown Source)<br />
at robocode.control.RobocodeEngine.init(Unknown Source)<br />
at robocode.control.RobocodeEngine.<init>(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)<br />
at roborumble.RoboRumbleAtHome.main(Unknown Source)<br />
Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path<br />
at java.lang.Runtime.loadLibrary(Runtime.java:763)<br />
at java.lang.System.loadLibrary(System.java:662)<br />
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)<br />
at java.lang.VMClass.forName(Native Method)<br />
at java.lang.Class.forName(Class.java:233)<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)<br />
...7 more<br />
</pre> It seems that both:<br />
# RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line<br />
# The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only<br />
Were it not for one or the other of those issues, it'd probably run just fine... Now can i fix this I wonder... --[[User:Rednaxela|Rednaxela]] 02:13, 7 August 2009 (UTC)<br />
<br />
Wow, that would be really cool. But I'm a wuss and I'm afraid to jailbreak and void my iPhone's AppleCare; I was thinking more from the perspective of writing an iPhone app myself that could do it. Good luck, though, I'm curious to hear your results! --[[User:Voidious|Voidious]] 02:17, 7 August 2009 (UTC)<br />
<br />
Aha! I got around that stupid issue! I just had to pass the VM <code>-Djava.awt.headless=true</code>... When you see rumble uploads with a user of "RednaxelaIPod", that'll be it :) --[[User:Rednaxela|Rednaxela]] 02:32, 7 August 2009 (UTC)<br />
: Ouchie, building the robot database this first time sure isn't fast... --[[User:Rednaxela|Rednaxela]] 02:39, 7 August 2009 (UTC)<br />
<br />
Sadly, while it mostly ran, it didn't quite work:<br />
<pre>java.lang.ArrayIndexOutOfBoundsException: 1<br />
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27<br />
5)<br />
at java.util.AbstractList$1.next(AbstractList.java:354)<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
java.lang.NullPointerException<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
</pre> Though if a workaround can be found for those issues (most likely bugs in the version of GNU Classpath in question. May not apply to newer versions, or a patched robocode might be able to work around it), it may work. Not sure that'll be possible though. Oh well... --[[User:Rednaxela|Rednaxela]] 03:54, 7 August 2009 (UTC)<br />
<br />
== Rumble Computers ==<br />
<br />
I'm curious, what kind of computers are people using for roborumble? [[Voidious]] and [[Simonton]] seem to really have some nice ones I think. Personally the computers I have avaliable to run rumble consist of:<br />
* Intel Core 2 Duo T5300 (1.73GHz), 2GB ram, laptop, usually avaliable<br />
* AMD Athlon XP 2000+, 512MB ram, often avaliable<br />
* AMD Athlon XP 2400+, 1GB ram, rarely avaliable<br />
I would also have my wimpy iPod were it not for one little bug preventing successful running of bots in the VM installed there. Sometimes... I'm really tempted to get a brand new shiney quad core monster for the sole purpose of storing backups, and running RoboRumble/Research :) --[[User:Rednaxela|Rednaxela]] 03:41, 16 August 2009 (UTC)<br />
<br />
I have:<br />
* MacBook 2.0 GHz Core Duo, 2 GB RAM, and I can run two clients on it safely. It's actually 3+ years old, but it holds up pretty well.<br />
* AMD 2000+, 768MB RAM (Ubuntu 8.10), which I've been running a rumble client on almost 24/7 for a while now.<br />
* Just yesterday, I ordered a MacBook Pro 2.8 GHz Core 2 Duo with 4 GB RAM. So that will more than double my total rumble power, I think. =)<br />
I wonder what [[User:Corbos|Corbos]] had, I couldn't have kept up with him if I tried when he was rumbling recently. I've also been tempted many times to spring for a quad core Linux box just for Robocode, but so far I've been able to resist... (mmm, quad core...) --[[User:Voidious|Voidious]] 03:55, 16 August 2009 (UTC)<br />
<br />
: Haha... I unfortuantely can't run two clients on my Core 2 Duo laptop... the CPU just plain gets too hot. What I really want to see though, is MXThreadBean timing in a new robocode version, which would make it safe to enable the option to allow robots to run concurrently, when in rumble... Then one could take advantage of a 8 beast when running melee rumble with only one client... --[[User:Rednaxela|Rednaxela]] 04:29, 16 August 2009 (UTC)<br />
<br />
My client runs on an old laptop -- all it does is run roborumble + meleerumble:<br />
* Intel Pentium M w/512MB ram, 100% available<br />
Occasionally I press my main machine (MacBook Pro, Core 2 Duo, 3GB) into service, but mostly I need it for work or running RoboResearch (that's what it's doing right now, in fact). It's also where the development rumble server lives, so this client is normally pointed at that anyway. Running both I was able to keep ahead of GrubbmGait for awhile until Voidious et al made our upload counts look puny by comparison.<br />
--[[User:Darkcanuck|Darkcanuck]] 04:26, 16 August 2009 (UTC)<br />
<br />
My client is a 2.66 Mhz Pentium4 (single-core) with 1GB. There was a time that I ran roborumble on a 400Mhz laptop with 128Mb using robocode 1.0.7. Btw, Darkcanuck, are you able to remove (or rename) those somewhat embarrasing contributions of GrubbmGait_15x and GrubbmGait_17x at the very low bottom. --[[User:GrubbmGait|GrubbmGait]] 11:08, 16 August 2009 (UTC)<br />
<br />
: Wow, 2.66 MHz!!?! :-D J/k. --[[User:Voidious|Voidious]] 15:04, 16 August 2009 (UTC)<br />
<br />
: It's done. I merged GrubbmGait_15x into GrubbmGait_154, and removed the lone battle from GrubbmGait_17x (the upload still shows up, merged into GrubbmGait). --[[User:Darkcanuck|Darkcanuck]] 17:38, 16 August 2009 (UTC)<br />
<br />
When I used to run it, I ran it on my Intel Centrino 2 P8400 2.26GHz with 4GB of RAM (but with 32bits OS it only sees 3GB) laptop, which I used for other works too. The time I run I only use FF to surf the web, but now I need to use Photoshop, Eclipse, LAMP and one virtual machine almost all the time so it doesn't available anymore. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 11:31, 16 August 2009 (UTC)<br />
<br />
I run my client in a Pentiun Dual Core 1.86 GHz, and I usualy run 2 clients, but right now I'm using it to test several new versions of my robot, so the rumble has to wait...--[[User:Navajo|Navajo]] 14:36, 16 August 2009 (UTC)<br />
<br />
== Lower Rank Limit? ==<br />
<br />
Wouldn't it be reasonable to remove bots that gets negative ELO Rating (i.e elvbot.ElverionBot(ELO: -191.0) & ry.Worst 1.0 (ELO: -365.3) ) ?<br />
<br />
They almost always score 0% and uses cpu-time while they contribute with near to nothing. --[[User:Rsim|Rsim]] 15:37, 16 August 2009 (UTC)<br />
<br />
== Whoops ==<br />
<br />
Err... sorry my client reactivated some old melee bots due to old data lying around, seems they crave pairings now... plus a large number of recently released melee bots... means sloooow melee right now... --[[User:Rednaxela|Rednaxela]] 05:10, 10 September 2009 (UTC)<br />
<br />
== Iteration ==<br />
<br />
I wonder if this happen to everyone or just me. When I run RoboRumble client, both 1.6.1.4 (which upload to darkcanuck's server) and 1.7.1.4 (which I use to test locally because it is faster), I found that after iteration 80 things got slower. I mean with 1.6.1.4 I can run 100 iteration in 4 hours, then another 4 hours it can run only 50-60 iterations. SO I tend to restart my client every 80 iterations. (and cool my hard disk down a little, it is around 80 degree Celcius when I run it for 150 iterations) Do anyone, especially who run RoboRumble overnight, have similar situation? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 03:10, 11 October 2009 (UTC)<br />
<br />
I've found that 1.6.1.4 still seems to have some long-term memory leakage actually. Not as bad as older version, but enough that it's still worth not using the ITERATE option actually. --[[User:Rednaxela|Rednaxela]] 03:54, 11 October 2009 (UTC)<br />
<br />
== JVM Crash ==<br />
<br />
After running the RoboRumble client (1.6.1.4) for about 12 hours, my JRE crashed. I have not been able to reproduce the problem, but I thought I'd post about here in the event it has happened to someone before. I've submitted a bug report to Sun and saved the logs [[http://www.devfluid.com/csc_club/JRE_Crash Here]]. It may not be relevant, but this happened when evaluating Krabb.sliNk.Garm 0.9u. --[[User:Christopher.Hilla|Christopher.Hilla]] 22:06, 7 February 2010 (UTC)<br />
<br />
Huh... that's a very peculiar bug. I doubt there's anything more to it other than there being a bug in the JVM though, assuming this isn't something you're able to repeat reliably. --[[User:Rednaxela|Rednaxela]] 22:48, 7 February 2010 (UTC)<br />
<br />
== Contributor's Sum ==<br />
<br />
I started contributing less than 30 days ago, yet my "All time" and Monthly sums don't match. My "All time" sum is much larger than what I've actually contributed. Even though my point tally is sort of like keeping score on "Whose Line Is It Anyway", it's worth mentioning :) --[[User:Christopher.Hilla|Christopher.Hilla]] 06:49, 9 February 2010 (UTC)<br />
<br />
: The monthly and 30-day totals are based on ''battles'', whereas the all-time list is number of ''uploads''. For a 1v1 battle between megas there is only one upload, but for smaller classes there will be one upload per size class (e.g. two nanos will generate 4 uploads). Melee is even more complicated since a full set of pairings for 10 megas will yield 45 uploads, even more if there are smaller bots in the mix. So your all-time uploads should be greater than the sum of the battles you've contributed so far. --[[User:Darkcanuck|Darkcanuck]] 07:41, 9 February 2010 (UTC)<br />
<br />
:: Thank you for the explanation. --[[User:Christopher.Hilla|Christopher.Hilla]] 19:49, 9 February 2010 (UTC)<br />
<br />
== Incomplete robot list == <br />
Hey Darkcanuck, I 've been running a few rumbles..and noticed I am missing a large number of bots " can't file specified file". Any Suggestions? Thx.. oh , I should mention Last night while Running an iteration envolving DR3.06 , Portia and 8 other bots. Something probably on my end screwwing up results for 1 battle. Not sure how, or why, but just one battle. -[[User:Jlm0924|Jlm0924]] 20:06, 27 April 2010 (UTC)<br />
<br />
== DogmanSPE ==<br />
<br />
I just ran a few tests to try and figure out the discrepancy between 1.8.0 and 1.8.2 of DrussGT, and now I can't repeat 1.8.0's results against DogmanSPE. I then decided to try a few rounds against Diamond 1.5.5, and it seems he also isn't living up to the scores he's getting on the rumble against DogmanSPE. The only thing I can think of is that it may be different versions of Robocode, as I'm doing my testing with 1.7.2b2. Any ideas? Maybe Dogman gets smart only at certain times of day? --[[User:Skilgannon|Skilgannon]] 15:06, 9 May 2010 (UTC)<br />
<br />
Eh, DogmanSPE is a major troublemaker and always has been. It sometimes doesn't crash, but when it does crash it crashes for every subsequent round of the battle. This makes it's results always unpredictable. It doesn't affect overall APS too badly because of the sheer number of bots, but it's probably the single worst offender in the rumble. Issues with DogmanSPE have [[oldwiki:RoboRumble/RankingChat|been pointed out before]]. Personally, I'm in favor of removing DogmanSPE. --[[User:Rednaxela|Rednaxela]] 15:25, 9 May 2010 (UTC)<br />
<br />
: So am I. Anyone object? --[[User:Voidious|Voidious]] 17:28, 9 May 2010 (UTC)<br />
<br />
:Done =) --[[User:Skilgannon|Skilgannon]] 19:17, 9 May 2010 (UTC)<br />
<br />
== LRP ==<br />
<br />
Perhaps we should have a section on what the LRP does. I mean most of use from the old wiki know but... Anyway in the words of Paul,<br />
<br />
<pre><br />
May seems a stupid question, but, what is the blue line, and the 4 quadrants?<br />
I can guess that on the X axis there is the expected score and on the Y the difference between expected and actual score.<br />
But what the blue line is supposed to mean? -- [[Simonech]]<br />
<br />
You are correct on the X axes and Y axes scales - the Blue line is a best-fit straight line through the data. if it has a negative<br />
gradient slopes downhill (left to right) I believe it would indicate that the movement for the bot is stronger than the gun. A<br />
positive gradient would indicate a good gun is being let down by relativley poor movement. -- [[Paul]]<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 04:55, 4 July 2010 (UTC)<br />
<br />
== Rumble use of 1.7.2.1 Beta? ==<br />
<br />
Guys, do you think that Robocode 1.7.2.1 will be good enough to replace the very old 1.6.1.4 for RoboRumble? If not, what must be done? --[[User:FlemmingLarsen|Fnl]] 22:06, 29 June 2010 (UTC)<br />
<br />
: The main problem I have with 1.7.2.1 is that objects from the data section in jars from inside zips at least do not get extracted to the cache. I also have problems with duplicate robots in the repository (mostly only ones on the development path). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 00:57, 30 June 2010 (UTC)<br />
<br />
:: Huh, I was under the impression that the data files were extracted properly still. (note, it's technically not a robotcache anymore). Also, what do you mean by duplicate robots, and is this different than older versions? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
: Well, I haven't noticed any new problems myself, but I've yet to have a chance to test very extensively, but I plan to on what is a long weekend coming up here. I'm going to clear my localhost rumble server and re-run testing with the latest version. Does anyone thing it would be good if I opened up the 1.7.2.1 testing rumble server to the world so others could speed up the process of testing it? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
:: I think it would be good. I am more than willing help you. If not due the stability of internet connection of my server I would open a testing server ages ago (well, my server located at my school in the university's infrastructure which is like twenty years old or more). Just a side note, 1.7.1.x runs at least five times faster than 1.6.1.4. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:51, 30 June 2010 (UTC)<br />
<br />
: Okay. I will wait a little with releasing 1.7.2.1 so you guys get the chance of testing it a bit more. 1.7.2.1 is "just" replacing the Jikes compiler with ECJ + some bug fixes compared to 1.7.2.0. I have started working on the 1.7.2.2 with some new features + I try to improve the speed with loading/updating the development paths, which are loaded extremely slow compared to the .jar files. :-) --[[User:FlemmingLarsen|Fnl]] 19:57, 2 July 2010 (UTC)<br />
<br />
Alright, I just moved the bots that are known to not work in 1.7 for "WontFix" reasons out of the participants list. Anybody mind? I kept them on the bottom of the pages with links to the SF ticket that's relevant. --[[User:Rednaxela|Rednaxela]] 20:46, 4 July 2010 (UTC)<br />
<br />
Okay, I now have a rumble test server facing the world on [[http://rednaxela.gotdns.com:8080/rumble/]]. It should be secured and fast enough now, I think. Feel free to run 1.7.2.1 Beta clients on it for testing! :) --[[User:Rednaxela|Rednaxela]] 21:56, 4 July 2010 (UTC)<br />
<br />
I have my roborumble and meleerumble client pointed to your server now. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 13:29, 6 July 2010 (UTC)<br />
<br />
Red, do you have any comparing method planned? The melee is almost completed, though it should need more before becoming stable. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 14:48, 12 July 2010 (UTC)<br />
<br />
My current comparing plan is:<br />
# First look for obvious outliers (things missing from high ranks, things at extreme low ranks)<br />
# Then import the 1.6.1.4 rumble and 1.7.2.1 rumble results tables into a spreadsheet, sort each by name, line them up beside eachother, create a column for rank difference and PL difference, then sort by those to find outliers.<br />
# Test any outliers. Determine if it's a bug to report, or the bot doing something that it shouldn't<br />
Currently, 1v1 rumble has two outliers at the bottom. I already reported the bug for one and it was fixed, and I think the other is breaking due to using File IO without using the proper robocode streams. About to do the spreadsheet with melee :) --[[User:Rednaxela|Rednaxela]] 02:13, 13 July 2010 (UTC)<br />
<br />
The biggest melee outliers by APS. Positive numbers mean improvement:<br />
{|<br />
|<br />
|Rank change<br />
|APS change<br />
|----<br />
|jab.DiamondStealer 5<br />
|145<br />
|20.07<br />
|----<br />
|gg.Squaraus 0.6<br />
| -72<br />
| -14.08<br />
|----<br />
|com.syncleus.robocode.Dreadnaught 0.1<br />
|49<br />
|9.40<br />
|----<br />
|stelo.Spread 0.2<br />
|62<br />
|6.34<br />
|----<br />
|bayen.nut.Squirrel 1.615<br />
|48<br />
|4.36<br />
|----<br />
|stelo.Moojuk 1.3<br />
|10<br />
|3.95<br />
|----<br />
|stelo.SoJNanoMelee 1.1<br />
| -23<br />
| -2.95<br />
|----<br />
|exauge.GateKeeper 1.1.121g<br />
|21<br />
|2.37<br />
|----<br />
|sgp.JollyNinja 3.53<br />
|18<br />
|2.12<br />
|----<br />
|lrem.micro.SpikeSoldier 0.4<br />
|19<br />
|2.00<br />
|----<br />
|sample.TrackFire 1.0<br />
| -0<br />
| -1.87<br />
|----<br />
|}<br />
I suspect DiamondStealer may have had bad results on the main rumble server, and I suspect the APS differences below 3% are probably a fluke. Maybe some of the larger are too, but I plan to test Squaraus and Dreadnaught anyway. --[[User:Rednaxela|Rednaxela]] 05:16, 13 July 2010 (UTC)<br />
<br />
Dreadnaught also had bad results in the beginning (not complient to 1.5.4 I believe) --[[User:GrubbmGait|GrubbmGait]] 08:49, 17 July 2010 (UTC)<br />
<br />
== .NET ==<br />
<br />
Is it possible to submit robots written in .NET to RoboRumble? --[[User:Dserbia|dserbia]] 15:18, 15 July 2010 (UTC)<br />
<br />
No, not at the moment. We have to make sure Robocode 1.7.x reach the really stable phase before. And I think we should wait for jni4net to reach at least beta status, for Mono support. Many of high-contributing RoboRumble clients are running under either Linux or OSX. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 15:38, 15 July 2010 (UTC)<br />
<br />
Thanks for the quick reply! --[[User:Dserbia|dserbia]] 17:21, 15 July 2010 (UTC)<br />
<br />
Personally, I'm not sure I'd ever be in favor of allowing them into the rumble. There would then be bots in the rumble that Mac/Linux users could never test against (and there are a lot of us), and it would also make us dependent on .NET users to contribute battles for those bots when we post new versions of our own. But I do sympathize - if/when more .NET Robocoders come onto the scene, things could change.<br />
<br />
Keep in mind that all of this stuff is community driven, though it may all seem very "official" to a newcomer. Anyone is free to setup a competition / tournament / rumble that includes .NET bots if they want! We've had tournament style competitions like the [[oldwiki:MiniBotChallenge|MiniBot Challenge]] and [[Twin Duel]] in the past, Robocode has APIs that make automating battles for tourneys fairly easy, and Darkcanuck posts the source to his rumble server somewhere (Nat or Rednaxela would know). And there's always [[:Category:Challenges|Challenges]] you can compete in, too.<br />
<br />
--[[User:Voidious|Voidious]] 17:38, 15 July 2010 (UTC)<br />
<br />
: I think Pavel Savara has plan for suporting jni4net, which is the core of .NET Robocode, on Mono, which can be run under Linux and Mac OS X. I don't think there is a valid reason for not supporting those when that day come. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 06:57, 16 July 2010 (UTC)<br />
<br />
: Yeah, it could work out, but there's still lots of room for issues. How stable is Mono? Will Mono add behavior discrepancies to .NET bots? Or will Java bots hit subtle behavior discepancies when battling .NET bots on Windows? (Either of those could be very hard to debug for the bot author.) Will .NET bots run much slower when running through Mono? Will that count against them in terms of CPU time/skipped turns? We've seen plenty of issues just from different JVMs / CPUs / OSes, so adding Mono and .NET to the rumble definitely requires caution. Or it may work perfectly smoothly and we'll all coexist peacefully. =) --[[User:Voidious|Voidious]] 15:18, 16 July 2010 (UTC) <br />
<br />
:: As long as one isn't doing GUI or calls to native libraries (not allowed for bots anyway), I'm pretty sure Mono is quite accurately compatible, however my concerns are around the fairness issues. x86 Java is reasonably uniform in terms of what parts of the code get optimized how well by the JVM. As I understand, Mono's performance is pretty reasonable overall, however since it's coded from scratch it's optimization characteristics are notably different I think, which makes cpu fairness somewhat tricky for having MS .Net and Mono running the same rumble. If one looks at [http://lists.ximian.com/pipermail/mono-list/2007-April/034899.html this], it's fairly old, but shows large performance differences going either way in terms of different types of operations. That exact issue only becomes larger between the JVM and .NET, so I really do think it makes sense for .NET to be kept to a separate rumble (possibly on the same server but separated like the different formats?). --[[User:Rednaxela|Rednaxela]] 19:23, 16 July 2010 (UTC)<br />
<br />
== New Rumble ==<br />
<br />
Rednaxela and I have been talking a bit, and we have put considerable thought into a new 1-vs-1 rumble. Unlike our current 1-vs-1 rumble, this would have no data saving, be single round battles on a 800x800 field. Also considering having the game 'white out' names in a battle to just numbers, so there can be no hard-coded specific bot data saving either. I personally feel this kind of 1-vs-1 competition would allow for much greater competition from non-adaptive movements, and lower the bar considerably for newer robocoders. But not too much, since obviously, Crazy would never be able to win over DrussGT.<br />
<br />
We also considered non-random starting positions (for greater fairness) and a 4 bot single round melee on the same field size.<br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 16:16, 24 July 2010 (UTC)<br />
<br />
Yeah, I think this would be a really neat thing to have. Now, I don't think it should replace the old-style rumble, but I think it would make a very interesting competition, and perhaps much less daunting for newcomers. And to clarify on what the "white out" of names, it means robot names that bots would see would just be like "1", "2", "3", or perhaps "robot 1", "robot 2", "robot 3". Now, that does require a modification to Robocode, but I think it would probably be relatively simple and quick to get implemented. (I say it should be simple because Robocode already alters names when multiple of the same bot are in a battle, so I'd imagine the same code path can be reused, so just a matter of changing it for a certain rumble flag) --[[User:Rednaxela|Rednaxela]] 16:27, 24 July 2010 (UTC)<br />
<br />
We have put togeather a seed of 60 robots, please keep in mind this is just a seed, and you can add your own robots when it gets started. This is just to round out the robots so that we can get some meaningful rankings.<br />
<pre><br />
abc.Tron 2.02<br />
ags.micro.Carpet 1.1<br />
ags.polished.PolishedRuby 1<br />
apv.Aspid 1.7<br />
apv.NanoLauLectrik 1.0<br />
apv.ScruchiPu 1.0<br />
ary.nano.AceSurf 1.2<br />
axeBots.Musashi 2.18<br />
axeBots.Okami 1.04<br />
chase.pm.Pytko 1.0<br />
cjm.Che 1.2<br />
cx.Lacrimas 1.36<br />
cx.mini.Cigaret 1.31<br />
darkcanuck.Gaff 1.50<br />
davidalves.net.DuelistMini 1.1<br />
davidalves.net.DuelistNano 1.0<br />
dummy.micro.Sparrow 2.5<br />
gh.GrubbmGrb 1.2.4<br />
gh.GrypRepetyf 0.13<br />
jam.mini.Raiko 0.43<br />
jk.micro.Toorkild 0.2.4b<br />
kawigi.robot.Girl 1.2<br />
kawigi.sbf.FloodHT 0.9.2<br />
kawigi.sbf.FloodSonnet 0.9<br />
kc.micro.Needle 0.101<br />
kc.micro.Thorn 1.252<br />
kc.mini.Vyper 0.311<br />
kc.nano.Splinter 1.2<br />
kid.Gladiator .7.2<br />
Krabb.krabby2.Krabby2 1.9o<br />
mld.Moebius 2.9.3<br />
mue.Hyperion 0.8<br />
mz.NanoDeath 2.56<br />
pe.SandboxDT 3.02<br />
pe.SandboxLump 1.52<br />
pedersen.Ugluk 1.0<br />
pez.mako.Mako 1.5<br />
pez.mini.Tityus 0.9.1<br />
pez.mini.VertiLeach 0.4.0<br />
ry.VirtualGunExperiment 1.2.0<br />
rz.Aleph 0.34<br />
rz.GlowBlowAPM 1.0<br />
sample.Walls<br />
sample.Crazy<br />
simonton.beta.LifelongObsession 0.5.1<br />
simonton.micro.GFMicro 1.0<br />
simonton.micro.WeeklongObsession 3.4.1<br />
simonton.nano.WeekendObsession_S 1.7<br />
stefw.Tigger 0.0.23<br />
synapse.Geomancy 15<br />
techdude.Carruthers 1.2.6<br />
tzu.TheArtOfWar 1.2<br />
voidious.micro.Jen 1.11<br />
vuen.Fractal 0.55<br />
wcsv.Engineer.Engineer 0.5.4<br />
whind.Strength 0.6.4<br />
wiki.BasicGFSurfer 1.02<br />
wiki.mini.Sedan 1.0<br />
wiki.nano.RaikoNano 1.1<br />
zyx.micro.Ant 1.1<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 17:36, 24 July 2010 (UTC)<br />
<br />
== 1.7.x rumble eventually... ==<br />
<br />
Hey guys... I kind of think I dropped the ball on working on getting 1.7.x to main rumble before... but I still think it would be good to eventually. Now... unlike before (where the rumble server was a little VM on my machine that I sometimes had to shut down for lack of memory), I have a more proper server I could use for rumble. I probably won't get around to setting this up till after winter holidays (have plans with family), but just wanted to ask, how much interest in this is there? Best Regards. --[[User:Rednaxela|Rednaxela]] 07:29, 21 December 2010 (UTC)<br />
<br />
I am still interested in. Right now (well, not really, since I am not actively writing robots), my movement predictor have flags for 1.6.1.4 or 1.7.1.3+ movement. Since rumble runs 1.6.1.4 but 1.7.x+ runs much faster. Also, the whole rumble would take less time to stabilised (but it would put more load to server, since client can run, as Pavel claimed, ''ten'' times faster. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 11:36, 21 December 2010 (UTC)<br />
<br />
I'm still interested. Kept meaning to ask you why the test rumble server went down but never did. Do you still have all the results, or would we start from scratch? Anyway, it would be good to be current. A lot of new people get 0 scores because they use new APIs, plus there's the performance benefits. --[[User:Voidious|Voidious]] 14:00, 21 December 2010 (UTC)<br />
<br />
: Yeah, I do still have the old data, but I'm not sure we want to use it. Presumably we'd want to test now with the very latest version, and mixing the results in this of multiple versions in this test could cloud results. --[[User:Rednaxela|Rednaxela]] 14:59, 22 December 2010 (UTC)<br />
<br />
Alright! I have a new rumble test server up and running at [http://rednaxela-robocode.dyndns.org/rumble/ http://rednaxela-robocode.dyndns.org/rumble/]. For ease of use, rumble configuration templates are linked from it's main page. Also, if you want, here's a convenient zip of all the bots currently in rumble: [http://rednaxela-robocode.dyndns.org/data/robot_archive.zip]. This one is located on a more proper type of server, rather than a virtual machine on my laptop. So... time to get testing 1.7.2.2 and prove it stable? :) --[[User:Rednaxela|Rednaxela]] 06:37, 19 January 2011 (UTC)<br />
<br />
: Hm, I thought I had this page "watched" but it looks like I've missed a lot... Is the new server running the same code and database schema as the current one? --[[User:Darkcanuck|Darkcanuck]] 06:43, 19 January 2011 (UTC)<br />
<br />
:: Yep, same code and database schema. The only changes I made were to the front html page, and changing the accepted version of robocode to 1.7.2.2. --[[User:Rednaxela|Rednaxela]] 06:57, 19 January 2011 (UTC)<br />
: I found my old laptop, I will set it to run, I might tweak the CPU constant up a little too, since it is a older/slower machine. (I will just set it in my closet, away from hustle and bustle). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 09:32, 19 January 2011 (UTC)<br />
<br />
: Nice! I'll start running my clients against this again. Thanks Rednaxela! Btw, the superpack .zip is gone from [[RoboRumble/Starting With RoboRumble]]. I'll make a new one with the above archive unless you could just repost the old one. --[[User:Voidious|Voidious]] 14:47, 19 January 2011 (UTC)<br />
<br />
:: It turns out both my laptops puked at some point while I was out (one locked up while loading rankings, the other I forgot to make a loop and iterate was NOT). Not sure if you still have to do iterate not, and make a script loop, but I did. Only my main system had kept running the rumble. But I restarted both of those now. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:36, 20 January 2011 (UTC)<br />
<br />
::: As far as I know, all the memory leaks have been fixed. I had my client run over the whole day and the memory use plateaued nicely with no issues whatsoever. --[[User:Rednaxela|Rednaxela]] 02:39, 20 January 2011 (UTC)<br />
:::: Ah well, I will switch them to use ITERATE then. Thanks. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:59, 20 January 2011 (UTC)<br />
<br />
Is there anything that we're waiting on for the switch to the 1.7 rumble rankings? I'd love to help make this upgrade happen. [[User:Ncj|Ncj]] 16:45, 4 April 2011 (UTC)<br />
<br />
I know Rednaxela was investigating some of the outliers from the test server's rankings. I'm not sure there was really anything "stop ship" though. I think the rankings look pretty good. Rednaxela, what do you think? --[[User:Voidious|Voidious]] 20:38, 4 April 2011 (UTC)<br />
<br />
Well, here's the "Table of Anomalous Results" I made when the 1.7.2.2 rumble first stabilized:<br />
<br />
{| border="1" cellpadding="2" style="border-collapse: collapse; color: black; font-size: xx-small" class="sortable"<br />
|class="unsortable"| ||Old Rank||Old %||New Rank||New %||Rank Diff||% Diff||class="unsortable"| ||ABS % Diff||ABS Rank Diff||Explanation<br />
|-<br />
| CharlieN.Omega.Omega 1.03||319||55.29||774||9.19||-455||-46.1||||46.1||455||[http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405]<br />
|-<br />
| NDH.GuessFactor 1.0||787||0.42||578||39.54||209||39.12||||39.12||209||uses post-1.6.1.4 functions<br />
|-<br />
| jeremyreeder.Vincent 2011.12.09||788||0||645||33.68||143||33.68||||33.68||143||uses post-1.6.1.4 functions<br />
|-<br />
| Krabb.krabby2.Krabby2 1.9o||71||73.63||528||43.12||-457||-30.51||||30.51||457<br />
|-<br />
| gg.Squaraus 0.6||714||26.3||786||4.62||-72||-21.68||||21.68||72||<br />
|-<br />
| elvbot.ElverionBot 0.3||785||0.72||751||19.75||34||19.03||||19.03||34||uses post-1.6.1.4 functions<br />
|-<br />
| TJ.Exupery 1.39||403||50.02||174||63.3||229||13.28||||13.28||229||<br />
|-<br />
| zh.UnderDog 0.0.2||782||4.31||762||14.11||20||9.8||||9.8||20||<br />
|-<br />
| reaper.Reaper 1.1||357||53.1||194||62.6||163||9.5||||9.5||163||crashes on some clients in 1.6.14 but not 1.7?<br />
|-<br />
| sm.Devil 7.3||517||44.13||351||53.45||166||9.32||||9.32||166||crashes on some clients in 1.6.14 but not 1.7?<br />
|-<br />
| xiongan.Xiongan 1.1||709||27.05||614||36.22||95||9.17||||9.17||95||<br />
|-<br />
| ag.Gir 0.99||762||13.25||739||22.26||23||9.01||||9.01||23||<br />
|}<br />
The case of "CharlieN.Omega.Omega 1.03" was [http://sourceforge.net/tracker/?func=detail&aid=3207405&group_id=37202&atid=419486 tracker item 3207405], and has been fixed in 1.7.3.0 Beta. Unfortunately I've yet to investigate the other results.<br />
<br />
Some of positive results I suspect may have been from using some Robocode 1.7 features perhaps (i.e. some new events). The case of Krabby2 I in particular mean to investigate because that result looks quite odd. Some other positive changes like Devil seem strange to me, because Devil predates Robocode 1.7 by a huge margin, yet seems to do better than in 1.6 by a notable margin. I've yet to be able to figure that out either. Anyone have any theories or can look into these cases?<br />
<br />
Anyway, presuming these issues can be worked out, what do people think of moving straight to 1.7.3.0 perhaps? The difference relative to 1.7.2.2 is small so I don't see it as that high risk, and if it turns out there were issues, then we're no worse off than if we had spent the same effort to test 1.7.3.0. Thoughts?<br />
<br />
--[[User:Rednaxela|Rednaxela]] 04:45, 5 April 2011 (UTC)<br />
<br />
SmallDevil crashes on my clients (dunno about others), so his 1.6 score is probably just wrong. I'm probably OK with moving to 1.7.3.0, but I'd prefer to just go with 1.7.2.2 since that's the one we've actually spent so much time testing. The difference being small could support either decision. =) 1.7.3.0 is still beta, too. --[[User:Voidious|Voidious]] 12:44, 5 April 2011 (UTC)<br />
<br />
Well, of course some testing of 1.7.3.0 needs to be done, but that should be possible to complete before it's out of beta. I think it's changes from 1.7.2.2 are definitely seem small enough to me that it's not like we need to do a full rumble run again. --[[User:Rednaxela|Rednaxela]] 13:23, 5 April 2011 (UTC)<br />
<br />
The three bots 'NDH.Guessfactor', 'jeremyreeder.Vincent' and elvbot.ElverionBot' all use post-1.6.1.4 functions, no further investigation needed for them. SmallDevil indeed occasionally crashes, why it does not do that on 1.7.2.2 I don't know. I believe the same goes for 'reaper.Reaper'. Friday I will have some time to check other differences. Is there a possibility to check all '2100-0' scores on the server for a specific bot? A bad client on the moment of submission has a permanent influence now. On the old server (years ago) these bad results faded away with each new battle (0.7*0.7*0.7 etc). --[[User:GrubbmGait|GrubbmGait]] 18:35, 6 April 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:RoboRumble&diff=19031Talk:RoboRumble2011-04-04T16:45:18Z<p>Ncj: What's necessary before rumble upgrade to 1.7?</p>
<hr />
<div>== RoboRumble history ==<br />
April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ<br />
<br />
October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar<br />
<br />
October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar<br />
<br />
February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar<br />
<br />
March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar <br />
<br />
== Subpages ==<br />
Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)<br />
<br />
== Name ==<br />
<br />
Since the new wiki supports symbols in page names, should we put this page at [[RoboRumble@Home]] instead of RoboRumble? We already have a redirect from that page to this one... --[[User:AaronR|AaronR]] 23:34, 17 November 2007 (UTC)<br />
<br />
I second this change. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 02:30, 28 April 2009 (UTC)<br />
<br />
== RR seems to be down ==<br />
<br />
Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 03:07, 19 September 2008 (UTC)<br />
:Are you sure? Both [http://rumble.fervir.com/rumble/Rankings?version=1&game=roborumble rumble.fervir.com] and [http://abchome.aclsi.pt:8080/ ABC's] work for me. -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 03:33, 19 September 2008 (UTC)<br />
::I fail. I meant Robocode Repository. -- [[User:Synapse|<font style="font-size:0.8em;font-variant:small-caps;">Synapse</font>]] 05:44, 19 September 2008 (UTC)<br />
::Not a big surprise there. =P -- [[User:Nfwu|<font color="#3B9C9C">Ketsu</font>]][[User Talk:Nfwu|<font color="#F87217">Nfwu</font>]] 13:21, 19 September 2008 (UTC)<br />
<br />
Hi! What the heck happened to RR@H again? The main roborumble has only ~60 bots again... Otherwise, I uploaded Pugio 1.2 1 week ago and has only 120 battles in nanoRumble. Situation is the same in Darcanuck's page, too. Nobody is contributing?--[[User:Robar|HUNRobar]] 12:30, 11 October 2008 (UTC)<br />
<br />
Both ABC's server and DarkCanuck's server have no full pairings yet. Once the megabots have full pairings, the minirumble will get filled completely and as last the micro- and nano-rumble. Be patient, but it probably requires a few weeks before all nanobots have 1000 battles. Remember, 640 * 640 bots means a lot of battles! Pulsar's server has another issue. I don't know what happened, but I still run (repair)battles there. --[[User:GrubbmGait|GrubbmGait]] 13:14, 11 October 2008 (UTC)<br />
<br />
I realised that in Darcanuck's server the older versions of bots are still in game. I think the competitors there should be cleaned up. For example, I don't want to generate battles for Pugio 1.0 when I wait for the results of 1.2. --[[User:Robar|HUNRobar]] 14:57, 11 October 2008 (UTC)<br />
<br />
That's a temporary thing -- I'm uploading a huge amount of data from [[User:ABC|ABC]]'s server which includes old participants. There's a big performance hit to activating/retiring participants repeatedly, so for now everyone's in the rankings until I get caught up. But don't worry, no rumble clients will actually run these bots. They'll use only the version from the participants list. In a few days you should see the old bots disappear from the rankings. --[[User:Darkcanuck|Darkcanuck]] 15:03, 11 October 2008 (UTC)<br />
<br />
Whoops edit conflict, accidentally overwrote Darkcanuck's reply with this: "What versions get battles doesn't depend on the server, it depends on the participants list that clients are configured to (which should be the old wiki's one, the one here has not been synced for a long time). The server would have nothing to do with that so you shouldn't be generating battles for Pugio 1.0 unless your client is misconfigured I believe." Anyways Darkcanuck's reply clearly explains why there are currently old versions listed :) --[[User:Rednaxela|Rednaxela]] 15:10, 11 October 2008 (UTC)<br />
<br />
Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--[[User:Robar|HUNRobar]] 17:40, 11 October 2008 (UTC)<br />
<br />
Why can't I access ABC's server? My connection get timeout before it finished loading! -[[User:Nat|Nat]] 12:42, 6 January 2009 (UTC)<br />
<br />
== Lynch the Multi-Threaders! ==<br />
<br />
A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?<br />
# On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.<br />
# On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.<br />
This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we ''could'' enforce a rule saying that no multi-threaded bot is allowed in ''the rumble''! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --[[User:Simonton|Simonton]] 02:47, 23 September 2008 (UTC)<br />
<br />
Agreed. It isn't fair on the opposition, and makes it impossible to design a bot within the CPU-constant constraints. --[[User:Skilgannon|Skilgannon]] 10:34, 23 September 2008 (UTC)<br />
<br />
I either didn't see or forgot about this section. There are already bots that use multiple threads in the rumble: [[Toad]] definitely does, possibly [[X2]] (which shares some Toad code), and probably others. Not sure how I feel about removing them at this point, just contributing some facts here... --[[User:Voidious|Voidious]] 02:20, 7 August 2009 (UTC)<br />
<br />
Well, there are java APIs that allow things like only measuring the time used in a particular thread. Robocode could start to use these in order to make this fair, AND as a '''major''' bonus it would make using Robocode on a computer with a heavily loaded CPU not cause skipped turns. The issue is... those APIs don't give the same kind of resolution, thus meaning that the only way we do it would be if we calculated something more like "How much CPU time did threads of this bot use in the last 20 ticks?", instead of "How much time did this robot take between the start and end of this turn?" which would make skipped turns behave a bit different. Personally I think that may not be such a bad thing, but I'm not really entirely sure... --[[User:Rednaxela|Rednaxela]] 02:51, 7 August 2009 (UTC)<br />
<br />
: It looks like [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 this] &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 12:53, 7 August 2009 (UTC)<br />
<br />
:: Hm? "ERROR This artifact is not accessible." is what that page gives --[[User:Rednaxela|Rednaxela]] 13:11, 7 August 2009 (UTC)<br />
<br />
::: Sorry, I never noticed that this is 'private' tracker... Fnl thought that he needs more precise time and mem.usage detection. I have a comment on some time measuring much like to your "How much CPU time did threads of this bot use in the last 20 ticks?". However, we didn't mention a thread at all. But I believe that Robocode allow Robots to create up to 5 threads, I'll email Fnl this. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 13:53, 7 August 2009 (UTC)<br />
: The [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 tracker] is public now. :-) Basically, I want to measure the CPU usage with the new features in Java 5.0 for measuring the exact CPU per thread. Hence we will (when using the TheadMXBean) know for a fact exactly how much time all threads in a robot is using in total. However, the time interval when measuring using the ThreadMXBean is big compared to what we are used to with the CPU constant currently used in Robocode. So we need a solution that can deal with this issue. I have waited with this improved feature as this will have a big impact on the scores for the robots in the RoboRumble. We have already seen how much difference the getNextVelocity() makes, so imagine the difference when we make change the concept behind the CPU constant. --[[User:FlemmingLarsen|Fnl]] 21:07, 7 August 2009 (UTC)<br />
:: Personally, I'm actually not too worried about the impact of this change. Most bots don't skip many turns at all, and the effects of a few skipped turns are often overstated. As long as the average amount of CPU allowed per tick is still similar, I can't imagine it affecting scores too much. I suppose it might have a big impact on bots that abuse the currently untracked multi-threading, but I think we can all agree that they're sort of abusing the system right now, anyway. Of course, I'd be happy to run extensive tests, too. =) --[[User:Voidious|Voidious]] 21:55, 7 August 2009 (UTC)<br />
:: I'm agreement with Voidious on this. I doubt there would be any problems caused by this so long as the correct amount of time was chosen. I would say though, that I think that this feature should be targeted at a 1.7.1.5 release, for the same reason that it's generally considered bad practice to change both a bot's movement and gun in the same rumble iteration, haha. As a side note, I wonder if while we improve the measurement method to not be affected by other things on the system, that maybe we should also improve the cpu constant calculation. For one, it should use the same ThreadMXBean methods to be accurate, but also I wonder if we could have a more realistic benchmark of what a typical bot actually does with it's time. I propose we include a small suite of some of the things a more cpu intensive bot does in order to create a more representative benchmark. I propose coding a small suite consisting of something like the following: 1) KD-Tree, 2) Nanobot-style pattern matching, 3) Array operations (searching for peak, addition of a gaussian curve to an array, multidimensional array access), 4) 'Play-It-Forward' simulation, 5) GF calculation (aka simple trig). I think I'll begin a page for comments on and code for an improved benchmark --[[User:Rednaxela|Rednaxela]] 00:00, 8 August 2009 (UTC)<br />
:: 1.7.1.5? It was there for about eight months. I think maybe 1.8 or so... &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 06:10, 8 August 2009 (UTC)<br />
<br />
== What Now? ==<br />
<br />
How can I submit the new versions of DrussGT and Cunobelin? Has anybody heard any news on the old wiki? Will it be recovered? Is it gone forever? --[[User:Skilgannon|Skilgannon]] 15:47, 8 December 2008 (UTC)<br />
<br />
Well on November 30th I emailed PEZ and got a reply that it's an ugly error and that he'd look into it. I haven't heard anything since but I guess I might email PEZ again. I certainly hope it won't be gone forever as I'd at least like to have a read-only version due to how much great stuff there is there that's unmigrated. --[[User:Rednaxela|Rednaxela]] 16:12, 8 December 2008 (UTC)<br />
<br />
I really hope the old wiki content still lives on. In the meantime we could agree to use this wiki's list for my server. I don't have time this week to make the proposed participant list changes, but I could lock out add/removes for all but a few select clients to make sure we all use the same list? --[[User:Darkcanuck|Darkcanuck]] 18:28, 8 December 2008 (UTC)<br />
<br />
Well, the old wiki is back! I do wonder though, should we switch to using this wiki's participants list anyway? or should that wait till some other day in the future? --[[User:Rednaxela|Rednaxela]] 18:17, 9 December 2008 (UTC)<br />
<br />
: I'd like to keep using the old wiki at least until I can code up something to validate participants on the server side. Then it would be easier to switch and not have to worry about some clients using the wrong list. --[[User:Darkcanuck|Darkcanuck]] 05:39, 10 December 2008 (UTC)<br />
<br />
Random question: How much do you think the local client would speed up if I compiled it natively? Right now, we haev a bit of a bottleneck figuring out battles andif we could speed it up by a factor or 3 or so, why not? --[[User:Miked0801|Miked0801]] 21:52, 25 May 2009 (UTC)<br />
<br />
== Nanos get little love when things get busy ==<br />
I've been waiting for nearly 4 days for my latest bot to get to 2k battles against nanos, and I'm probably gonna have to wait 3 more for it to happen. Why? Nanos, after they get to their 1 battle per bot limit, are the last bots to be updated under the current system. I understand why the system was done this way, but is there anyway we can add a time component to the battle chooser to make sure that when things heat up in the rumble, nanos get some love as well? --[[User:Miked0801|Miked0801]] 20:47, 19 June 2009 (UTC)<br />
<br />
I hear ya. Even in Mega-land, it can take a while to get to 2k battles, and I don't really trust a rating until it does (even with all pairings). There are some RR client options you could try, like excluding bots or running NanoRumble only, but the latter will just do random battles, I think. A couple of nice client side options, imo, would be mini/micro/nano while still honoring pairing priority, and ignoring pairings while running bots with under NUMBATTLES (in all applicable rumbles). I'm definitely in favor of RR contributors having control over what battles they want to run... --[[User:Voidious|Voidious]] 22:48, 19 June 2009 (UTC)<br />
<br />
Nanos get ''way'' more than their fair share of processing time. By a time a nano reaches 2000 battles in its own class, it has typically reached 5000+ battles in the main rumble. Few, if any, megabots have yet to reach that level. Not only is it unfair to folks releasing larger bots, it also takes away cpu time from other nanos. So should we abolish nanos? Of course not!<br />
<br />
I'd vote for changing the client's battle selection such that when a new bot reaches full pairings, the remainder of its 2000 battles are fought against opponents in its own size class. Those battles will still count for the higher classes, so a nano would really only need 2000 battles overall. This would mean faster results for nanos and more cpu time for everyone else, regardless of size. --[[User:Darkcanuck|Darkcanuck]] 03:19, 20 June 2009 (UTC)<br />
<br />
I second Darkcanuck's suggestion, as it seems most fair to me. :) --[[User:Rednaxela|Rednaxela]] 05:12, 20 June 2009 (UTC)<br />
<br />
And yet, some nanos love to beat up on their larger sibling... But yes, when things slow down, nanos do get a ton of extra battles, but to be fair, most nanos run much, much faster than megas so the hit isn't that bad. My main concern was waiting at the back of a line of never ending micro/mega selections. Impatients and such. If we're going to change things to minimize waits, then first completing pairings, then 2k in class, then low priority updates across other classes would be awesome. Unlike melee, just 2 or 3 battles with a mega are usually sufficient to get a strong idea of where things stand. --[[User:Miked0801|Miked0801]] 09:10, 20 June 2009 (UTC)<br />
<br />
You can also set RUNONLY=NANO, but alas then no priority battles are fought, just random ones. And I set the battlecount to 1000, so nanos will get their battles earlier. --[[User:GrubbmGait|GrubbmGait]] 10:51, 20 June 2009 (UTC)<br />
* setting RUNONLY=NANO is not a good idea. The results only count for nano, so is not counted at micro/mini/mega. Setting the battlecount lower does pay off however, except when the bigger rumbles are flooded with new versions. --[[User:GrubbmGait|GrubbmGait]] 11:00, 20 June 2009 (UTC)<br />
<br />
It would be awesome if roborumble could execute smart battles with runonly parameters. For example, run prioritary battles but only among nanos. I don't think it would be such a difficult developement. --[[User:Robar|HUNRobar]] 14:33, 20 June 2009 (UTC)<br />
<br />
: I think the RUNONLY setting needs to be fixed -- as [[GrubbmGait]] pointed out, the battles don't get uploaded to the bigger size classes, which they should. I might put together a patch for this, but first I have some wave surfing to iron out... --[[User:Darkcanuck|Darkcanuck]] 17:41, 20 June 2009 (UTC)<br />
<br />
About battlecount, one habit I have, is constantly making my battlecount set to just a little above the lowest value in the rumble. That seems to have nice results sometimes. --[[User:Rednaxela|Rednaxela]] 16:03, 20 June 2009 (UTC)<br />
<br />
All right, I think I've figured out how to implement the change I suggested, plus fix the RUNONLY problem. If enough people are ok with this, I'll put together a patched 1.6.1.4 client with the changes and send the patches to [[Fnl]] for future releases too. --[[User:Darkcanuck|Darkcanuck]] 18:21, 21 June 2009 (UTC)<br />
<br />
: Quick question: Would this only affect the 1v1 pairing order? I definitely support it there, but making your suggested change in Melee pairings would have a major impact on some bots' scores... And thanks as always for your RoboRumble efforts! --[[User:Voidious|Voidious]] 19:33, 21 June 2009 (UTC)<br />
:: Only at first. The game already does all class battles for roughly 50% of the numbers in nano now. That's why [[DustBunny]] has been slowly rising in APS - he does worse in nano only. --[[User:Miked0801|Miked0801]] 20:42, 21 June 2009 (UTC)<br />
::: Well, right now a NanoBot gets 2,000 battles against the whole field, then a bunch against MiniBots and below, then MicroBots and below, then NanoBots. With this change, it would get some amount of battles against the whole field, then all NanoBot-only battles. Depending on the bot, I think it could have an impact. Then again, that's a quirky aspect of MeleeRumble that's tough to really regulate, anyway, so maybe it's not worth worrying about. --[[User:Voidious|Voidious]] 21:51, 21 June 2009 (UTC)<br />
:: Ah, good point, I hadn't considered melee. It does use a different routine for preparing battles though, so it's possible to patch 1v1 without affecting melee. Looking at the melee routine, it does create an interesting mix of battles -- I didn't realize that there were all-nano matchups. That must skew the scores depending on the ratio of battles a nano gets with mixed sizes versus all-nano? --[[User:Darkcanuck|Darkcanuck]] 02:15, 22 June 2009 (UTC)<br />
: I don't think it is a bug, i think it was made on purpose the way it is. Alas I don't remember the reason . . . --[[User:GrubbmGait|GrubbmGait]] 21:03, 21 June 2009 (UTC)<br />
<br />
== Mobile Devices ==<br />
<br />
Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --[[User:Rednaxela|Rednaxela]] 02:01, 7 August 2009 (UTC)<br />
<br />
* Definitely crazy. --[[User:Simonton|Simonton]]<br />
<br />
I think you're crazy, but only because the iPhone OS doesn't have Java. =) I actually just looked into this the other day, lol. Was there some tech you were looking at to make it work? --[[User:Voidious|Voidious]] 02:03, 7 August 2009 (UTC)<br />
<br />
Actually, when you don't limit yourself to the app store, there is a port of [[wikipedia:JamVM|JamVM]] w/ [[wikipedia:GNU Classpath|GNU Classpath]]. There's no JIT so it won't be fast... but it'll run.. or... almost:<br />
<pre>Iteration number 0<br />
Downloading rating files ...<br />
Downloading participants list ...<br />
Downloading missing bots ...<br />
Removing old participants from server ...<br />
Preparing battles list ... Using smart battles is true<br />
Prioritary battles file not found ... <br />
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)<br />
at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)<br />
at robocode.manager.RobocodeManager.initSecurity(Unknown Source)<br />
at robocode.control.RobocodeEngine.init(Unknown Source)<br />
at robocode.control.RobocodeEngine.<init>(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)<br />
at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)<br />
at roborumble.RoboRumbleAtHome.main(Unknown Source)<br />
Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path<br />
at java.lang.Runtime.loadLibrary(Runtime.java:763)<br />
at java.lang.System.loadLibrary(System.java:662)<br />
at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)<br />
at java.lang.VMClass.forName(Native Method)<br />
at java.lang.Class.forName(Class.java:233)<br />
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)<br />
...7 more<br />
</pre> It seems that both:<br />
# RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line<br />
# The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only<br />
Were it not for one or the other of those issues, it'd probably run just fine... Now can i fix this I wonder... --[[User:Rednaxela|Rednaxela]] 02:13, 7 August 2009 (UTC)<br />
<br />
Wow, that would be really cool. But I'm a wuss and I'm afraid to jailbreak and void my iPhone's AppleCare; I was thinking more from the perspective of writing an iPhone app myself that could do it. Good luck, though, I'm curious to hear your results! --[[User:Voidious|Voidious]] 02:17, 7 August 2009 (UTC)<br />
<br />
Aha! I got around that stupid issue! I just had to pass the VM <code>-Djava.awt.headless=true</code>... When you see rumble uploads with a user of "RednaxelaIPod", that'll be it :) --[[User:Rednaxela|Rednaxela]] 02:32, 7 August 2009 (UTC)<br />
: Ouchie, building the robot database this first time sure isn't fast... --[[User:Rednaxela|Rednaxela]] 02:39, 7 August 2009 (UTC)<br />
<br />
Sadly, while it mostly ran, it didn't quite work:<br />
<pre>java.lang.ArrayIndexOutOfBoundsException: 1<br />
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27<br />
5)<br />
at java.util.AbstractList$1.next(AbstractList.java:354)<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
java.lang.NullPointerException<br />
at robocode.battle.Battle.updateBullets(Unknown Source)<br />
at robocode.battle.Battle.runTurn(Unknown Source)<br />
at robocode.battle.Battle.runRound(Unknown Source)<br />
at robocode.battle.Battle.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
<br />
...<br />
<br />
Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.setEnergy(Unknown Source)<br />
at robocode.peer.RobotPeer.run(Unknown Source)<br />
at java.lang.Thread.run(Thread.java:743)<br />
</pre> Though if a workaround can be found for those issues (most likely bugs in the version of GNU Classpath in question. May not apply to newer versions, or a patched robocode might be able to work around it), it may work. Not sure that'll be possible though. Oh well... --[[User:Rednaxela|Rednaxela]] 03:54, 7 August 2009 (UTC)<br />
<br />
== Rumble Computers ==<br />
<br />
I'm curious, what kind of computers are people using for roborumble? [[Voidious]] and [[Simonton]] seem to really have some nice ones I think. Personally the computers I have avaliable to run rumble consist of:<br />
* Intel Core 2 Duo T5300 (1.73GHz), 2GB ram, laptop, usually avaliable<br />
* AMD Athlon XP 2000+, 512MB ram, often avaliable<br />
* AMD Athlon XP 2400+, 1GB ram, rarely avaliable<br />
I would also have my wimpy iPod were it not for one little bug preventing successful running of bots in the VM installed there. Sometimes... I'm really tempted to get a brand new shiney quad core monster for the sole purpose of storing backups, and running RoboRumble/Research :) --[[User:Rednaxela|Rednaxela]] 03:41, 16 August 2009 (UTC)<br />
<br />
I have:<br />
* MacBook 2.0 GHz Core Duo, 2 GB RAM, and I can run two clients on it safely. It's actually 3+ years old, but it holds up pretty well.<br />
* AMD 2000+, 768MB RAM (Ubuntu 8.10), which I've been running a rumble client on almost 24/7 for a while now.<br />
* Just yesterday, I ordered a MacBook Pro 2.8 GHz Core 2 Duo with 4 GB RAM. So that will more than double my total rumble power, I think. =)<br />
I wonder what [[User:Corbos|Corbos]] had, I couldn't have kept up with him if I tried when he was rumbling recently. I've also been tempted many times to spring for a quad core Linux box just for Robocode, but so far I've been able to resist... (mmm, quad core...) --[[User:Voidious|Voidious]] 03:55, 16 August 2009 (UTC)<br />
<br />
: Haha... I unfortuantely can't run two clients on my Core 2 Duo laptop... the CPU just plain gets too hot. What I really want to see though, is MXThreadBean timing in a new robocode version, which would make it safe to enable the option to allow robots to run concurrently, when in rumble... Then one could take advantage of a 8 beast when running melee rumble with only one client... --[[User:Rednaxela|Rednaxela]] 04:29, 16 August 2009 (UTC)<br />
<br />
My client runs on an old laptop -- all it does is run roborumble + meleerumble:<br />
* Intel Pentium M w/512MB ram, 100% available<br />
Occasionally I press my main machine (MacBook Pro, Core 2 Duo, 3GB) into service, but mostly I need it for work or running RoboResearch (that's what it's doing right now, in fact). It's also where the development rumble server lives, so this client is normally pointed at that anyway. Running both I was able to keep ahead of GrubbmGait for awhile until Voidious et al made our upload counts look puny by comparison.<br />
--[[User:Darkcanuck|Darkcanuck]] 04:26, 16 August 2009 (UTC)<br />
<br />
My client is a 2.66 Mhz Pentium4 (single-core) with 1GB. There was a time that I ran roborumble on a 400Mhz laptop with 128Mb using robocode 1.0.7. Btw, Darkcanuck, are you able to remove (or rename) those somewhat embarrasing contributions of GrubbmGait_15x and GrubbmGait_17x at the very low bottom. --[[User:GrubbmGait|GrubbmGait]] 11:08, 16 August 2009 (UTC)<br />
<br />
: Wow, 2.66 MHz!!?! :-D J/k. --[[User:Voidious|Voidious]] 15:04, 16 August 2009 (UTC)<br />
<br />
: It's done. I merged GrubbmGait_15x into GrubbmGait_154, and removed the lone battle from GrubbmGait_17x (the upload still shows up, merged into GrubbmGait). --[[User:Darkcanuck|Darkcanuck]] 17:38, 16 August 2009 (UTC)<br />
<br />
When I used to run it, I ran it on my Intel Centrino 2 P8400 2.26GHz with 4GB of RAM (but with 32bits OS it only sees 3GB) laptop, which I used for other works too. The time I run I only use FF to surf the web, but now I need to use Photoshop, Eclipse, LAMP and one virtual machine almost all the time so it doesn't available anymore. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 11:31, 16 August 2009 (UTC)<br />
<br />
I run my client in a Pentiun Dual Core 1.86 GHz, and I usualy run 2 clients, but right now I'm using it to test several new versions of my robot, so the rumble has to wait...--[[User:Navajo|Navajo]] 14:36, 16 August 2009 (UTC)<br />
<br />
== Lower Rank Limit? ==<br />
<br />
Wouldn't it be reasonable to remove bots that gets negative ELO Rating (i.e elvbot.ElverionBot(ELO: -191.0) & ry.Worst 1.0 (ELO: -365.3) ) ?<br />
<br />
They almost always score 0% and uses cpu-time while they contribute with near to nothing. --[[User:Rsim|Rsim]] 15:37, 16 August 2009 (UTC)<br />
<br />
== Whoops ==<br />
<br />
Err... sorry my client reactivated some old melee bots due to old data lying around, seems they crave pairings now... plus a large number of recently released melee bots... means sloooow melee right now... --[[User:Rednaxela|Rednaxela]] 05:10, 10 September 2009 (UTC)<br />
<br />
== Iteration ==<br />
<br />
I wonder if this happen to everyone or just me. When I run RoboRumble client, both 1.6.1.4 (which upload to darkcanuck's server) and 1.7.1.4 (which I use to test locally because it is faster), I found that after iteration 80 things got slower. I mean with 1.6.1.4 I can run 100 iteration in 4 hours, then another 4 hours it can run only 50-60 iterations. SO I tend to restart my client every 80 iterations. (and cool my hard disk down a little, it is around 80 degree Celcius when I run it for 150 iterations) Do anyone, especially who run RoboRumble overnight, have similar situation? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 03:10, 11 October 2009 (UTC)<br />
<br />
I've found that 1.6.1.4 still seems to have some long-term memory leakage actually. Not as bad as older version, but enough that it's still worth not using the ITERATE option actually. --[[User:Rednaxela|Rednaxela]] 03:54, 11 October 2009 (UTC)<br />
<br />
== JVM Crash ==<br />
<br />
After running the RoboRumble client (1.6.1.4) for about 12 hours, my JRE crashed. I have not been able to reproduce the problem, but I thought I'd post about here in the event it has happened to someone before. I've submitted a bug report to Sun and saved the logs [[http://www.devfluid.com/csc_club/JRE_Crash Here]]. It may not be relevant, but this happened when evaluating Krabb.sliNk.Garm 0.9u. --[[User:Christopher.Hilla|Christopher.Hilla]] 22:06, 7 February 2010 (UTC)<br />
<br />
Huh... that's a very peculiar bug. I doubt there's anything more to it other than there being a bug in the JVM though, assuming this isn't something you're able to repeat reliably. --[[User:Rednaxela|Rednaxela]] 22:48, 7 February 2010 (UTC)<br />
<br />
== Contributor's Sum ==<br />
<br />
I started contributing less than 30 days ago, yet my "All time" and Monthly sums don't match. My "All time" sum is much larger than what I've actually contributed. Even though my point tally is sort of like keeping score on "Whose Line Is It Anyway", it's worth mentioning :) --[[User:Christopher.Hilla|Christopher.Hilla]] 06:49, 9 February 2010 (UTC)<br />
<br />
: The monthly and 30-day totals are based on ''battles'', whereas the all-time list is number of ''uploads''. For a 1v1 battle between megas there is only one upload, but for smaller classes there will be one upload per size class (e.g. two nanos will generate 4 uploads). Melee is even more complicated since a full set of pairings for 10 megas will yield 45 uploads, even more if there are smaller bots in the mix. So your all-time uploads should be greater than the sum of the battles you've contributed so far. --[[User:Darkcanuck|Darkcanuck]] 07:41, 9 February 2010 (UTC)<br />
<br />
:: Thank you for the explanation. --[[User:Christopher.Hilla|Christopher.Hilla]] 19:49, 9 February 2010 (UTC)<br />
<br />
== Incomplete robot list == <br />
Hey Darkcanuck, I 've been running a few rumbles..and noticed I am missing a large number of bots " can't file specified file". Any Suggestions? Thx.. oh , I should mention Last night while Running an iteration envolving DR3.06 , Portia and 8 other bots. Something probably on my end screwwing up results for 1 battle. Not sure how, or why, but just one battle. -[[User:Jlm0924|Jlm0924]] 20:06, 27 April 2010 (UTC)<br />
<br />
== DogmanSPE ==<br />
<br />
I just ran a few tests to try and figure out the discrepancy between 1.8.0 and 1.8.2 of DrussGT, and now I can't repeat 1.8.0's results against DogmanSPE. I then decided to try a few rounds against Diamond 1.5.5, and it seems he also isn't living up to the scores he's getting on the rumble against DogmanSPE. The only thing I can think of is that it may be different versions of Robocode, as I'm doing my testing with 1.7.2b2. Any ideas? Maybe Dogman gets smart only at certain times of day? --[[User:Skilgannon|Skilgannon]] 15:06, 9 May 2010 (UTC)<br />
<br />
Eh, DogmanSPE is a major troublemaker and always has been. It sometimes doesn't crash, but when it does crash it crashes for every subsequent round of the battle. This makes it's results always unpredictable. It doesn't affect overall APS too badly because of the sheer number of bots, but it's probably the single worst offender in the rumble. Issues with DogmanSPE have [[oldwiki:RoboRumble/RankingChat|been pointed out before]]. Personally, I'm in favor of removing DogmanSPE. --[[User:Rednaxela|Rednaxela]] 15:25, 9 May 2010 (UTC)<br />
<br />
: So am I. Anyone object? --[[User:Voidious|Voidious]] 17:28, 9 May 2010 (UTC)<br />
<br />
:Done =) --[[User:Skilgannon|Skilgannon]] 19:17, 9 May 2010 (UTC)<br />
<br />
== LRP ==<br />
<br />
Perhaps we should have a section on what the LRP does. I mean most of use from the old wiki know but... Anyway in the words of Paul,<br />
<br />
<pre><br />
May seems a stupid question, but, what is the blue line, and the 4 quadrants?<br />
I can guess that on the X axis there is the expected score and on the Y the difference between expected and actual score.<br />
But what the blue line is supposed to mean? -- [[Simonech]]<br />
<br />
You are correct on the X axes and Y axes scales - the Blue line is a best-fit straight line through the data. if it has a negative<br />
gradient slopes downhill (left to right) I believe it would indicate that the movement for the bot is stronger than the gun. A<br />
positive gradient would indicate a good gun is being let down by relativley poor movement. -- [[Paul]]<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 04:55, 4 July 2010 (UTC)<br />
<br />
== Rumble use of 1.7.2.1 Beta? ==<br />
<br />
Guys, do you think that Robocode 1.7.2.1 will be good enough to replace the very old 1.6.1.4 for RoboRumble? If not, what must be done? --[[User:FlemmingLarsen|Fnl]] 22:06, 29 June 2010 (UTC)<br />
<br />
: The main problem I have with 1.7.2.1 is that objects from the data section in jars from inside zips at least do not get extracted to the cache. I also have problems with duplicate robots in the repository (mostly only ones on the development path). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 00:57, 30 June 2010 (UTC)<br />
<br />
:: Huh, I was under the impression that the data files were extracted properly still. (note, it's technically not a robotcache anymore). Also, what do you mean by duplicate robots, and is this different than older versions? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
: Well, I haven't noticed any new problems myself, but I've yet to have a chance to test very extensively, but I plan to on what is a long weekend coming up here. I'm going to clear my localhost rumble server and re-run testing with the latest version. Does anyone thing it would be good if I opened up the 1.7.2.1 testing rumble server to the world so others could speed up the process of testing it? --[[User:Rednaxela|Rednaxela]] 05:30, 30 June 2010 (UTC)<br />
<br />
:: I think it would be good. I am more than willing help you. If not due the stability of internet connection of my server I would open a testing server ages ago (well, my server located at my school in the university's infrastructure which is like twenty years old or more). Just a side note, 1.7.1.x runs at least five times faster than 1.6.1.4. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 12:51, 30 June 2010 (UTC)<br />
<br />
: Okay. I will wait a little with releasing 1.7.2.1 so you guys get the chance of testing it a bit more. 1.7.2.1 is "just" replacing the Jikes compiler with ECJ + some bug fixes compared to 1.7.2.0. I have started working on the 1.7.2.2 with some new features + I try to improve the speed with loading/updating the development paths, which are loaded extremely slow compared to the .jar files. :-) --[[User:FlemmingLarsen|Fnl]] 19:57, 2 July 2010 (UTC)<br />
<br />
Alright, I just moved the bots that are known to not work in 1.7 for "WontFix" reasons out of the participants list. Anybody mind? I kept them on the bottom of the pages with links to the SF ticket that's relevant. --[[User:Rednaxela|Rednaxela]] 20:46, 4 July 2010 (UTC)<br />
<br />
Okay, I now have a rumble test server facing the world on [[http://rednaxela.gotdns.com:8080/rumble/]]. It should be secured and fast enough now, I think. Feel free to run 1.7.2.1 Beta clients on it for testing! :) --[[User:Rednaxela|Rednaxela]] 21:56, 4 July 2010 (UTC)<br />
<br />
I have my roborumble and meleerumble client pointed to your server now. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 13:29, 6 July 2010 (UTC)<br />
<br />
Red, do you have any comparing method planned? The melee is almost completed, though it should need more before becoming stable. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 14:48, 12 July 2010 (UTC)<br />
<br />
My current comparing plan is:<br />
# First look for obvious outliers (things missing from high ranks, things at extreme low ranks)<br />
# Then import the 1.6.1.4 rumble and 1.7.2.1 rumble results tables into a spreadsheet, sort each by name, line them up beside eachother, create a column for rank difference and PL difference, then sort by those to find outliers.<br />
# Test any outliers. Determine if it's a bug to report, or the bot doing something that it shouldn't<br />
Currently, 1v1 rumble has two outliers at the bottom. I already reported the bug for one and it was fixed, and I think the other is breaking due to using File IO without using the proper robocode streams. About to do the spreadsheet with melee :) --[[User:Rednaxela|Rednaxela]] 02:13, 13 July 2010 (UTC)<br />
<br />
The biggest melee outliers by APS. Positive numbers mean improvement:<br />
{|<br />
|<br />
|Rank change<br />
|APS change<br />
|----<br />
|jab.DiamondStealer 5<br />
|145<br />
|20.07<br />
|----<br />
|gg.Squaraus 0.6<br />
| -72<br />
| -14.08<br />
|----<br />
|com.syncleus.robocode.Dreadnaught 0.1<br />
|49<br />
|9.40<br />
|----<br />
|stelo.Spread 0.2<br />
|62<br />
|6.34<br />
|----<br />
|bayen.nut.Squirrel 1.615<br />
|48<br />
|4.36<br />
|----<br />
|stelo.Moojuk 1.3<br />
|10<br />
|3.95<br />
|----<br />
|stelo.SoJNanoMelee 1.1<br />
| -23<br />
| -2.95<br />
|----<br />
|exauge.GateKeeper 1.1.121g<br />
|21<br />
|2.37<br />
|----<br />
|sgp.JollyNinja 3.53<br />
|18<br />
|2.12<br />
|----<br />
|lrem.micro.SpikeSoldier 0.4<br />
|19<br />
|2.00<br />
|----<br />
|sample.TrackFire 1.0<br />
| -0<br />
| -1.87<br />
|----<br />
|}<br />
I suspect DiamondStealer may have had bad results on the main rumble server, and I suspect the APS differences below 3% are probably a fluke. Maybe some of the larger are too, but I plan to test Squaraus and Dreadnaught anyway. --[[User:Rednaxela|Rednaxela]] 05:16, 13 July 2010 (UTC)<br />
<br />
Dreadnaught also had bad results in the beginning (not complient to 1.5.4 I believe) --[[User:GrubbmGait|GrubbmGait]] 08:49, 17 July 2010 (UTC)<br />
<br />
== .NET ==<br />
<br />
Is it possible to submit robots written in .NET to RoboRumble? --[[User:Dserbia|dserbia]] 15:18, 15 July 2010 (UTC)<br />
<br />
No, not at the moment. We have to make sure Robocode 1.7.x reach the really stable phase before. And I think we should wait for jni4net to reach at least beta status, for Mono support. Many of high-contributing RoboRumble clients are running under either Linux or OSX. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 15:38, 15 July 2010 (UTC)<br />
<br />
Thanks for the quick reply! --[[User:Dserbia|dserbia]] 17:21, 15 July 2010 (UTC)<br />
<br />
Personally, I'm not sure I'd ever be in favor of allowing them into the rumble. There would then be bots in the rumble that Mac/Linux users could never test against (and there are a lot of us), and it would also make us dependent on .NET users to contribute battles for those bots when we post new versions of our own. But I do sympathize - if/when more .NET Robocoders come onto the scene, things could change.<br />
<br />
Keep in mind that all of this stuff is community driven, though it may all seem very "official" to a newcomer. Anyone is free to setup a competition / tournament / rumble that includes .NET bots if they want! We've had tournament style competitions like the [[oldwiki:MiniBotChallenge|MiniBot Challenge]] and [[Twin Duel]] in the past, Robocode has APIs that make automating battles for tourneys fairly easy, and Darkcanuck posts the source to his rumble server somewhere (Nat or Rednaxela would know). And there's always [[:Category:Challenges|Challenges]] you can compete in, too.<br />
<br />
--[[User:Voidious|Voidious]] 17:38, 15 July 2010 (UTC)<br />
<br />
: I think Pavel Savara has plan for suporting jni4net, which is the core of .NET Robocode, on Mono, which can be run under Linux and Mac OS X. I don't think there is a valid reason for not supporting those when that day come. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 06:57, 16 July 2010 (UTC)<br />
<br />
: Yeah, it could work out, but there's still lots of room for issues. How stable is Mono? Will Mono add behavior discrepancies to .NET bots? Or will Java bots hit subtle behavior discepancies when battling .NET bots on Windows? (Either of those could be very hard to debug for the bot author.) Will .NET bots run much slower when running through Mono? Will that count against them in terms of CPU time/skipped turns? We've seen plenty of issues just from different JVMs / CPUs / OSes, so adding Mono and .NET to the rumble definitely requires caution. Or it may work perfectly smoothly and we'll all coexist peacefully. =) --[[User:Voidious|Voidious]] 15:18, 16 July 2010 (UTC) <br />
<br />
:: As long as one isn't doing GUI or calls to native libraries (not allowed for bots anyway), I'm pretty sure Mono is quite accurately compatible, however my concerns are around the fairness issues. x86 Java is reasonably uniform in terms of what parts of the code get optimized how well by the JVM. As I understand, Mono's performance is pretty reasonable overall, however since it's coded from scratch it's optimization characteristics are notably different I think, which makes cpu fairness somewhat tricky for having MS .Net and Mono running the same rumble. If one looks at [http://lists.ximian.com/pipermail/mono-list/2007-April/034899.html this], it's fairly old, but shows large performance differences going either way in terms of different types of operations. That exact issue only becomes larger between the JVM and .NET, so I really do think it makes sense for .NET to be kept to a separate rumble (possibly on the same server but separated like the different formats?). --[[User:Rednaxela|Rednaxela]] 19:23, 16 July 2010 (UTC)<br />
<br />
== New Rumble ==<br />
<br />
Rednaxela and I have been talking a bit, and we have put considerable thought into a new 1-vs-1 rumble. Unlike our current 1-vs-1 rumble, this would have no data saving, be single round battles on a 800x800 field. Also considering having the game 'white out' names in a battle to just numbers, so there can be no hard-coded specific bot data saving either. I personally feel this kind of 1-vs-1 competition would allow for much greater competition from non-adaptive movements, and lower the bar considerably for newer robocoders. But not too much, since obviously, Crazy would never be able to win over DrussGT.<br />
<br />
We also considered non-random starting positions (for greater fairness) and a 4 bot single round melee on the same field size.<br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 16:16, 24 July 2010 (UTC)<br />
<br />
Yeah, I think this would be a really neat thing to have. Now, I don't think it should replace the old-style rumble, but I think it would make a very interesting competition, and perhaps much less daunting for newcomers. And to clarify on what the "white out" of names, it means robot names that bots would see would just be like "1", "2", "3", or perhaps "robot 1", "robot 2", "robot 3". Now, that does require a modification to Robocode, but I think it would probably be relatively simple and quick to get implemented. (I say it should be simple because Robocode already alters names when multiple of the same bot are in a battle, so I'd imagine the same code path can be reused, so just a matter of changing it for a certain rumble flag) --[[User:Rednaxela|Rednaxela]] 16:27, 24 July 2010 (UTC)<br />
<br />
We have put togeather a seed of 60 robots, please keep in mind this is just a seed, and you can add your own robots when it gets started. This is just to round out the robots so that we can get some meaningful rankings.<br />
<pre><br />
abc.Tron 2.02<br />
ags.micro.Carpet 1.1<br />
ags.polished.PolishedRuby 1<br />
apv.Aspid 1.7<br />
apv.NanoLauLectrik 1.0<br />
apv.ScruchiPu 1.0<br />
ary.nano.AceSurf 1.2<br />
axeBots.Musashi 2.18<br />
axeBots.Okami 1.04<br />
chase.pm.Pytko 1.0<br />
cjm.Che 1.2<br />
cx.Lacrimas 1.36<br />
cx.mini.Cigaret 1.31<br />
darkcanuck.Gaff 1.50<br />
davidalves.net.DuelistMini 1.1<br />
davidalves.net.DuelistNano 1.0<br />
dummy.micro.Sparrow 2.5<br />
gh.GrubbmGrb 1.2.4<br />
gh.GrypRepetyf 0.13<br />
jam.mini.Raiko 0.43<br />
jk.micro.Toorkild 0.2.4b<br />
kawigi.robot.Girl 1.2<br />
kawigi.sbf.FloodHT 0.9.2<br />
kawigi.sbf.FloodSonnet 0.9<br />
kc.micro.Needle 0.101<br />
kc.micro.Thorn 1.252<br />
kc.mini.Vyper 0.311<br />
kc.nano.Splinter 1.2<br />
kid.Gladiator .7.2<br />
Krabb.krabby2.Krabby2 1.9o<br />
mld.Moebius 2.9.3<br />
mue.Hyperion 0.8<br />
mz.NanoDeath 2.56<br />
pe.SandboxDT 3.02<br />
pe.SandboxLump 1.52<br />
pedersen.Ugluk 1.0<br />
pez.mako.Mako 1.5<br />
pez.mini.Tityus 0.9.1<br />
pez.mini.VertiLeach 0.4.0<br />
ry.VirtualGunExperiment 1.2.0<br />
rz.Aleph 0.34<br />
rz.GlowBlowAPM 1.0<br />
sample.Walls<br />
sample.Crazy<br />
simonton.beta.LifelongObsession 0.5.1<br />
simonton.micro.GFMicro 1.0<br />
simonton.micro.WeeklongObsession 3.4.1<br />
simonton.nano.WeekendObsession_S 1.7<br />
stefw.Tigger 0.0.23<br />
synapse.Geomancy 15<br />
techdude.Carruthers 1.2.6<br />
tzu.TheArtOfWar 1.2<br />
voidious.micro.Jen 1.11<br />
vuen.Fractal 0.55<br />
wcsv.Engineer.Engineer 0.5.4<br />
whind.Strength 0.6.4<br />
wiki.BasicGFSurfer 1.02<br />
wiki.mini.Sedan 1.0<br />
wiki.nano.RaikoNano 1.1<br />
zyx.micro.Ant 1.1<br />
</pre><br />
<br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 17:36, 24 July 2010 (UTC)<br />
<br />
== 1.7.x rumble eventually... ==<br />
<br />
Hey guys... I kind of think I dropped the ball on working on getting 1.7.x to main rumble before... but I still think it would be good to eventually. Now... unlike before (where the rumble server was a little VM on my machine that I sometimes had to shut down for lack of memory), I have a more proper server I could use for rumble. I probably won't get around to setting this up till after winter holidays (have plans with family), but just wanted to ask, how much interest in this is there? Best Regards. --[[User:Rednaxela|Rednaxela]] 07:29, 21 December 2010 (UTC)<br />
<br />
I am still interested in. Right now (well, not really, since I am not actively writing robots), my movement predictor have flags for 1.6.1.4 or 1.7.1.3+ movement. Since rumble runs 1.6.1.4 but 1.7.x+ runs much faster. Also, the whole rumble would take less time to stabilised (but it would put more load to server, since client can run, as Pavel claimed, ''ten'' times faster. --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 11:36, 21 December 2010 (UTC)<br />
<br />
I'm still interested. Kept meaning to ask you why the test rumble server went down but never did. Do you still have all the results, or would we start from scratch? Anyway, it would be good to be current. A lot of new people get 0 scores because they use new APIs, plus there's the performance benefits. --[[User:Voidious|Voidious]] 14:00, 21 December 2010 (UTC)<br />
<br />
: Yeah, I do still have the old data, but I'm not sure we want to use it. Presumably we'd want to test now with the very latest version, and mixing the results in this of multiple versions in this test could cloud results. --[[User:Rednaxela|Rednaxela]] 14:59, 22 December 2010 (UTC)<br />
<br />
Alright! I have a new rumble test server up and running at [http://rednaxela-robocode.dyndns.org/rumble/ http://rednaxela-robocode.dyndns.org/rumble/]. For ease of use, rumble configuration templates are linked from it's main page. Also, if you want, here's a convenient zip of all the bots currently in rumble: [http://rednaxela-robocode.dyndns.org/data/robot_archive.zip]. This one is located on a more proper type of server, rather than a virtual machine on my laptop. So... time to get testing 1.7.2.2 and prove it stable? :) --[[User:Rednaxela|Rednaxela]] 06:37, 19 January 2011 (UTC)<br />
<br />
: Hm, I thought I had this page "watched" but it looks like I've missed a lot... Is the new server running the same code and database schema as the current one? --[[User:Darkcanuck|Darkcanuck]] 06:43, 19 January 2011 (UTC)<br />
<br />
:: Yep, same code and database schema. The only changes I made were to the front html page, and changing the accepted version of robocode to 1.7.2.2. --[[User:Rednaxela|Rednaxela]] 06:57, 19 January 2011 (UTC)<br />
: I found my old laptop, I will set it to run, I might tweak the CPU constant up a little too, since it is a older/slower machine. (I will just set it in my closet, away from hustle and bustle). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 09:32, 19 January 2011 (UTC)<br />
<br />
: Nice! I'll start running my clients against this again. Thanks Rednaxela! Btw, the superpack .zip is gone from [[RoboRumble/Starting With RoboRumble]]. I'll make a new one with the above archive unless you could just repost the old one. --[[User:Voidious|Voidious]] 14:47, 19 January 2011 (UTC)<br />
<br />
:: It turns out both my laptops puked at some point while I was out (one locked up while loading rankings, the other I forgot to make a loop and iterate was NOT). Not sure if you still have to do iterate not, and make a script loop, but I did. Only my main system had kept running the rumble. But I restarted both of those now. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:36, 20 January 2011 (UTC)<br />
<br />
::: As far as I know, all the memory leaks have been fixed. I had my client run over the whole day and the memory use plateaued nicely with no issues whatsoever. --[[User:Rednaxela|Rednaxela]] 02:39, 20 January 2011 (UTC)<br />
:::: Ah well, I will switch them to use ITERATE then. Thanks. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:59, 20 January 2011 (UTC)<br />
<br />
Is there anything that we're waiting on for the switch to the 1.7 rumble rankings? I'd love to help make this upgrade happen. [[User:Ncj|Ncj]] 16:45, 4 April 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:Targeting_Challenge_(original)&diff=18934Talk:Targeting Challenge (original)2011-03-29T02:45:20Z<p>Ncj: Point to targeting challenge 2k7</p>
<hr />
<div>The download link doesn't work. Is that intentional / can it be fixed? --[[User:Ceasar|Ceasar]] 02:21, 29 March 2011 (UTC)<br />
<br />
I don't think it's intentional, and it looks like it can't be recovered from the file host. Have you considered trying a newer targeting challenge such as [[Targeting Challenge 2K7]]? --[[User:Ncj|Ncj]] 02:45, 29 March 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:Shark_Challenge&diff=18622Talk:Shark Challenge2011-02-27T22:46:16Z<p>Ncj: Migrated talk for Shark Challenge</p>
<hr />
<div>== From old wiki ==<br />
I think that to make challenge II really relevant Shark must be equipped with the same [[Energy Management]] as [[RaikoMicro]]. -- [[PEZ]]</div>Ncjhttp://robowiki.net/w/index.php?title=Shark_Challenge&diff=18621Shark Challenge2011-02-27T22:41:44Z<p>Ncj: Migrated Shark Challenge from old wiki</p>
<hr />
<div>Here is the robot to use for each of the two Shark Challenges:<br />
[http://davidalves.net/robocode/robots/wiki.challenge.Shark_1.0.jar]<br />
<br />
== Shark Challenge I: Targeting ==<br />
<br />
It's very easy to beat Shark. [[MyFirstRobot]] beats Shark, for example. However, it's not easy to beat Shark by a large margin. Show off your your % score vs. Shark in a 1000 battle here:<br />
<br />
Note: Shark uses the movement from RaikoMicro 1.44 and a very simple random gun. <br />
{| border="1"<br />
|align="left"|'''Author'''<br />
|align="left"|'''Robot'''<br />
|align="left"|'''% score'''<br />
|'''Comments'''<br />
|-<br />
|align="left"|[[PEZ]]<br />
|align="left"|[[CassiusClay]] 1.9.9.20<br />
|align="left"|76.027%<br />
|-<br />
|-<br />
|align="left"|[[wcsv]]<br />
|align="left"|[[Stampede2]] 1.1<br />
|align="left"|74.312%<br />
|My experimental bot.<br />
|-<br />
|[[David Alves]]<br />
|[[David Alves/YALT|YALT]] 1.722<br />
|align="left"|73.228%<br />
|-<br />
|-<br />
|align="left"|[[iiley]]<br />
|align="left"|[[Pear]] 0.5<br />
|align="left"|72.337%<br />
|skipped 22534 times:(<br />
|-<br />
|align="left"|[[Pulsar]]<br />
|align="left"|[[PulsarMax]] 0.5.20<br />
|align="left"|71.218%<br />
|-<br />
|-<br />
|align="left"|[[UnderDark]]<br />
|align="left"|[[UnderDark3]] 2.3.24<br />
|align="left"|69.338%<br />
|Extends Robot<br />
|-<br />
|align="left"|[[Mat Nelson]]<br />
|align="left"|[[TrackFire]]<br />
|align="left"|68.549%<br />
|-<br />
|-<br />
|align="left"|[[Mat Nelson]]<br />
|align="left"|[[MyFirstRobot]]<br />
|align="left"|53.463%<br />
|-<br />
|}<br />
<br />
<br />
----<br />
== Shark Challenge II: Surfing ==<br />
<br />
Your score in Shark Challenge I is a measure of how good your aim is. Since Shark's aim is random, your score should be about the same amount whether you use your most advanced Surfing or don't move at all. So here's SharkChallenge II to test your movement.<br />
<br />
Shark uses the movement from RaikoMicro 1.44, completely untouched. Therefore, the difference between RaikoMicro's score against you and Shark's score against you is completely due to the difference in their guns. A surfer should be able to surf RaikoMicro's bullets and therefore lower RaikoMicro's bullet damage. A truly amazing surfer might even be able to exploit the predictability of RaikoMicro's gun to make it hit less often than a random gun would. Can you?<br />
<br />
Your Shark Challenge II score is (Shark 1.0's bullet damage against you) - (RaikoMicro 1.44's bullet damage against you). 1000 rounds each, 800x600.<br />
<br />
Note: Higher is better, but I'm not sure that positive scores are possible.<br />
<br />
{| border="1"<br />
|align="left"|'''Author'''<br />
|align="left"|'''Robot'''<br />
|'''Shark\'s Bullet Damage'''<br />
|'''RM\'s Bullet Damage'''<br />
|'''Score'''<br />
|-<br />
|align="left"|[[PEZ]]<br />
|align="left"|CassiusClay 1.9.9.20<br />
|align="center"|23973<br />
|align="center"|31088<br />
|align="right"|-7115<br />
|}<br />
<br />
== See also ==<br />
<br />
{{Navbox challenges}}<br />
<br />
[[Category:Bot Challenges]]<br />
[[Category:Movement Challenges]]<br />
[[Category:Uncontrolled Testing Environments Challenges]]</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:MoxieBot&diff=18400Talk:MoxieBot2011-02-07T05:03:34Z<p>Ncj: Added some ramblings about strategy in response to GrubbmGait</p>
<hr />
<div>Very neat - I like how you refer to the [[Bullet Shadow]] idea. The notion (in a vague form =)) has crossed my mind as something an elite wave surfer might want to try in a really tight spot (like in a corner + 2 bullets in the air), since not getting hit is so much more important than hitting the enemy when you're vastly outscoring them and trying to optimize <% total score>. Best of luck with MoxieBot! I might have to add some bullet shielding detection if you start beating [[Diamond]]. =) --[[User:Voidious|Voidious]] 06:22, 4 February 2011 (UTC)<br />
: Don't worry about me...Worry about if DrussGT starts using it! :) [[User:Ncj|Ncj]] 04:27, 5 February 2011 (UTC)<br />
<br />
I also really like the sound of this. I'm actually wondering about incorporating this into DrussGT. I'd check whether there is anywhere I can get with a coverage of >95%, and if their bullet power is > 0.1, and if so take that option for this wave. I'm also wondering if you can increase your coverage by waiting to fire until a bit later, or whether the earlier you fire the better your coverage is sort of thing. By mixing this idea with imaginary waves I think the coverage might be able to be increased substantially. Anyways, nice work on this bot =) --[[User:Skilgannon|Skilgannon]] 08:50, 4 February 2011 (UTC)<br />
: Thanks! There are definitely situations where you can get that kind of coverage if the enemy is far away and you get to move in a straight line at top speed. In the simple case where you move in a straight line to the point at which the wave will break, then I think that firing earlier will get you the largest shadow: The angle at which you need to fire will be the same no matter when you fire. This means the angle between your intersecting bullet and the enemy bullet is constant regardless of time, as will be the component of your bullet's movement perpendicular to the enemy bullet's movement. The angular width of the bullet shadow is a function of this perpendicular component and the distance from the wave origin of the bullet intersection. As the perpendicular component is constant, the only way to get a larger angular width is to intersect the wave earlier, which means firing as soon as possible. Of course, the point you intend to move to is under your control...Actually, this gave me some ideas for selecting a better location than I do now. [[User:Ncj|Ncj]] 04:24, 5 February 2011 (UTC)<br />
<br />
I've been thinking of colliding bullets also lately, but from a slightly other perspective. If bullets collide, you know where the enemies bullit was heading, so you could move there indeed. Not specifically because that is a safe spot, although a nice side-effect, but as a sort of 'smoke curtain' to influence the gunnery of your opponent. He would register this spot as a peak, while normally you wouldn't had moved there in the first place. I feel like having a card in my sleeve, while wearing a t-shirt. --[[User:GrubbmGait|GrubbmGait]] 00:56, 5 February 2011 (UTC)<br />
: Ok, I've seen Moxiebot in action now, and it is far more effective than I imagined. It is also very hard to counteract on it, not like BulletCatcher that is easily fooled. Congratulations on successfully implementing this idea! --[[User:GrubbmGait|GrubbmGait]] 17:04, 6 February 2011 (UTC)<br />
:: Thanks. I consider MoxieBot to be fighting from a position of weakness when it comes to bullet dodging and accuracy, as other bots have had years of refinement. My hope is that bullet shielding can be part of a successful mixed strategy which forces opponents who would otherwise have both better guns and movement into situations where MoxieBot gains a temporary upper hand. It seems to me that the counter to a bot using Bullet Shielding exclusively is to just close in, making your shots more effective, with RamBots at the extreme. However, when an enemy moves closer, their movement becomes more predictable, so they become even even easier to hit in turn. If MoxieBot can take advantage of this, it might be able to shoot at the enemy with a good hit probability for a few turns, or decide to get closer and perhaps even ram. If the enemy uses low power bullets, in order to counteract the strategy, MoxieBot can choose to fire high power bullets with the intention of hitting the enemy. Even though MoxieBot might be hit more frequently, MoxieBot might be able to output a higher raw damage per second, and win that way. If the enemy switches back to normal shooting and wave surfing at distance, than MoxieBot can go back to bullet shielding. [[User:Ncj|Ncj]] 05:03, 7 February 2011 (UTC)<br />
Very nice. For a while I've been thinking about integrating [[Bullet Shadow|Bullet Shadows]] into a surfing movement, but this is the first time I've seen a bot with some particularly nice use of them. Also, I like the term "Bullet Shadow", I never had a good term for it before. Some thoughts:<br />
* Perhaps it would make sense to only have it move to positions with large shadows, instead of occasionally going to small shadow locations?<br />
* Looking at results [http://rednaxela-robocode.dyndns.org/rumble/RatingsDetails?game=roborumble&name=ncj.MoxieBot%201.0 here], it seems like my bot [[Midboss]] does particularly well against this. I'm pretty sure it's because of Midboss' rather smart bulletpower selection. Perhaps [[MoxieBot]] should fall back to another strategy when the enemy is firing small bullets?<br />
* Very impressive looking in battle! :)<br />
--[[User:Rednaxela|Rednaxela]] 01:09, 5 February 2011 (UTC)<br />
: Thanks for the kind words and suggestions. I've spent some time today looking at the rumble results, so I have quite a bit to respond with:<br />
:* First, Midboss really crushes MoxieBot! I agree that I need some kind of better movement, but it's hard for me to determine whether to try improve the bullet shadowing or the dodging. In order for MoxieBot to win (assuming the enemy is firing bullets of power > .5), the enemy needs to either miss or have their bullet intercepted > 88% of the time. In other words P(bullet aimed wrong) + P(bullet aimed right)*P(bullet intercepted | bullet aimed right) > 88%. Unfortunately, strategies that increase the bullet shadow generally make it easy to figure out where the bot will be, but random movement means that the bullet shadows are often poor. Right now, both dodging and bullet interception hover around 60% against many bots, which works out to be right around the % needed. A long term goal is to improve one of them substantially, and keep the other percent above 50%. Out of curiosity do you know what kind of dodge % a random movement algorithm with a flat profile should get?<br />
:* I took a long look at Midboss to try to figure out what it's doing, as compared to some of the other top bots. My initial guess was the same as yours; that Midboss used a lot of low power bullets, which raise the threshold above the 88% miss needed for the higher powers. However, the effect only really becomes significant below a power of .5, and Midboss used a power around 1.5 most of the time. Additionally, other bots fire low power bullets too, often even more frequently than Midboss, but not all share in the success. The biggest difference in behavior seems to be that Midboss hangs around the middle of the battlefield, whereas other bots like to hug the walls. On average Midboss shoots from around 400 pixels, wheras the wall huggers shoot from around 550 pixels. I believe that this increases the accuracy of your bot a few percent, dropping the overall measured P(miss or intercepted) to 82%, well below the 88% MoxieBot needs, which ultimately means that MoxieBot goes down in flames. I hope this made some kind of sense!<br />
:--[[User:Ncj|Ncj]] 08:58, 5 February 2011 (UTC)<br />
:: Well, a distance of 400 is a reasonably popular distance for many bots. As far as why Midboss does better against it than ones that always shoot below firepower 0.5, I still suspect it's bulletpower selection plays a part. To fill you in on what it's doing, it simulates/estimates the exact scoring of the battle, given:<br />
::* current energy of both robots<br />
::* current hitrate of both robots (normalized for distance)<br />
::* current firepower the enemy seems to be using<br />
::* bullet damage thus far (factors into win/loss bonus)<br />
::* for a wide variety of possible bulletpower values for itself to use<br />
:: This means that against MoxieBot, it'll choose low bulletpower when it figures it needs to in order to survive a particular round. The time it was using higher bulletpower, was because it's algorithm expected it to be likely enough to survive the round, that doing more damage is worth the risk. Does it seem to you that might explain it?<br />
:: --[[User:Rednaxela|Rednaxela]] 17:44, 5 February 2011 (UTC)<br />
::: In order to try to understand what's going on, I've narrowed my analysis down to two bots. I collected hit, miss, or interception data about the same number of bullets as fired from DrussGT and from Midboss. Here's a page I whipped up [http://dl.dropbox.com/u/162056/comparison.html showing the comparison]. It looks to me like Midboss is very confident it's going to win the round...Is this the bullet power distribution you expected? I'm sorry if the data is hard to read (as it's missing labels), but I'm literally moments away from going on vacation and wanted to put this up. When looking at the graphs showing P(miss or interception), it's useful to remember that MoxieBot needs the probability to be higher than .88 in order for a win. Thanks for prompting me to look deeper in to my bot's behavior, and hopefully when I get back I'll get to give Midboss a run for it's money :) [[User:Ncj|Ncj]] 04:54, 7 February 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:MoxieBot&diff=18393Talk:MoxieBot2011-02-07T04:54:52Z<p>Ncj: Added comparison data between Midboss and Druss</p>
<hr />
<div>Very neat - I like how you refer to the [[Bullet Shadow]] idea. The notion (in a vague form =)) has crossed my mind as something an elite wave surfer might want to try in a really tight spot (like in a corner + 2 bullets in the air), since not getting hit is so much more important than hitting the enemy when you're vastly outscoring them and trying to optimize <% total score>. Best of luck with MoxieBot! I might have to add some bullet shielding detection if you start beating [[Diamond]]. =) --[[User:Voidious|Voidious]] 06:22, 4 February 2011 (UTC)<br />
: Don't worry about me...Worry about if DrussGT starts using it! :) [[User:Ncj|Ncj]] 04:27, 5 February 2011 (UTC)<br />
<br />
I also really like the sound of this. I'm actually wondering about incorporating this into DrussGT. I'd check whether there is anywhere I can get with a coverage of >95%, and if their bullet power is > 0.1, and if so take that option for this wave. I'm also wondering if you can increase your coverage by waiting to fire until a bit later, or whether the earlier you fire the better your coverage is sort of thing. By mixing this idea with imaginary waves I think the coverage might be able to be increased substantially. Anyways, nice work on this bot =) --[[User:Skilgannon|Skilgannon]] 08:50, 4 February 2011 (UTC)<br />
: Thanks! There are definitely situations where you can get that kind of coverage if the enemy is far away and you get to move in a straight line at top speed. In the simple case where you move in a straight line to the point at which the wave will break, then I think that firing earlier will get you the largest shadow: The angle at which you need to fire will be the same no matter when you fire. This means the angle between your intersecting bullet and the enemy bullet is constant regardless of time, as will be the component of your bullet's movement perpendicular to the enemy bullet's movement. The angular width of the bullet shadow is a function of this perpendicular component and the distance from the wave origin of the bullet intersection. As the perpendicular component is constant, the only way to get a larger angular width is to intersect the wave earlier, which means firing as soon as possible. Of course, the point you intend to move to is under your control...Actually, this gave me some ideas for selecting a better location than I do now. [[User:Ncj|Ncj]] 04:24, 5 February 2011 (UTC)<br />
<br />
I've been thinking of colliding bullets also lately, but from a slightly other perspective. If bullets collide, you know where the enemies bullit was heading, so you could move there indeed. Not specifically because that is a safe spot, although a nice side-effect, but as a sort of 'smoke curtain' to influence the gunnery of your opponent. He would register this spot as a peak, while normally you wouldn't had moved there in the first place. I feel like having a card in my sleeve, while wearing a t-shirt. --[[User:GrubbmGait|GrubbmGait]] 00:56, 5 February 2011 (UTC)<br />
: Ok, I've seen Moxiebot in action now, and it is far more effective than I imagined. It is also very hard to counteract on it, not like BulletCatcher that is easily fooled. Congratulations on successfully implementing this idea! --[[User:GrubbmGait|GrubbmGait]] 17:04, 6 February 2011 (UTC)<br />
<br />
Very nice. For a while I've been thinking about integrating [[Bullet Shadow|Bullet Shadows]] into a surfing movement, but this is the first time I've seen a bot with some particularly nice use of them. Also, I like the term "Bullet Shadow", I never had a good term for it before. Some thoughts:<br />
* Perhaps it would make sense to only have it move to positions with large shadows, instead of occasionally going to small shadow locations?<br />
* Looking at results [http://rednaxela-robocode.dyndns.org/rumble/RatingsDetails?game=roborumble&name=ncj.MoxieBot%201.0 here], it seems like my bot [[Midboss]] does particularly well against this. I'm pretty sure it's because of Midboss' rather smart bulletpower selection. Perhaps [[MoxieBot]] should fall back to another strategy when the enemy is firing small bullets?<br />
* Very impressive looking in battle! :)<br />
--[[User:Rednaxela|Rednaxela]] 01:09, 5 February 2011 (UTC)<br />
: Thanks for the kind words and suggestions. I've spent some time today looking at the rumble results, so I have quite a bit to respond with:<br />
:* First, Midboss really crushes MoxieBot! I agree that I need some kind of better movement, but it's hard for me to determine whether to try improve the bullet shadowing or the dodging. In order for MoxieBot to win (assuming the enemy is firing bullets of power > .5), the enemy needs to either miss or have their bullet intercepted > 88% of the time. In other words P(bullet aimed wrong) + P(bullet aimed right)*P(bullet intercepted | bullet aimed right) > 88%. Unfortunately, strategies that increase the bullet shadow generally make it easy to figure out where the bot will be, but random movement means that the bullet shadows are often poor. Right now, both dodging and bullet interception hover around 60% against many bots, which works out to be right around the % needed. A long term goal is to improve one of them substantially, and keep the other percent above 50%. Out of curiosity do you know what kind of dodge % a random movement algorithm with a flat profile should get?<br />
:* I took a long look at Midboss to try to figure out what it's doing, as compared to some of the other top bots. My initial guess was the same as yours; that Midboss used a lot of low power bullets, which raise the threshold above the 88% miss needed for the higher powers. However, the effect only really becomes significant below a power of .5, and Midboss used a power around 1.5 most of the time. Additionally, other bots fire low power bullets too, often even more frequently than Midboss, but not all share in the success. The biggest difference in behavior seems to be that Midboss hangs around the middle of the battlefield, whereas other bots like to hug the walls. On average Midboss shoots from around 400 pixels, wheras the wall huggers shoot from around 550 pixels. I believe that this increases the accuracy of your bot a few percent, dropping the overall measured P(miss or intercepted) to 82%, well below the 88% MoxieBot needs, which ultimately means that MoxieBot goes down in flames. I hope this made some kind of sense!<br />
:--[[User:Ncj|Ncj]] 08:58, 5 February 2011 (UTC)<br />
:: Well, a distance of 400 is a reasonably popular distance for many bots. As far as why Midboss does better against it than ones that always shoot below firepower 0.5, I still suspect it's bulletpower selection plays a part. To fill you in on what it's doing, it simulates/estimates the exact scoring of the battle, given:<br />
::* current energy of both robots<br />
::* current hitrate of both robots (normalized for distance)<br />
::* current firepower the enemy seems to be using<br />
::* bullet damage thus far (factors into win/loss bonus)<br />
::* for a wide variety of possible bulletpower values for itself to use<br />
:: This means that against MoxieBot, it'll choose low bulletpower when it figures it needs to in order to survive a particular round. The time it was using higher bulletpower, was because it's algorithm expected it to be likely enough to survive the round, that doing more damage is worth the risk. Does it seem to you that might explain it?<br />
:: --[[User:Rednaxela|Rednaxela]] 17:44, 5 February 2011 (UTC)<br />
::: In order to try to understand what's going on, I've narrowed my analysis down to two bots. I collected hit, miss, or interception data about the same number of bullets as fired from DrussGT and from Midboss. Here's a page I whipped up [http://dl.dropbox.com/u/162056/comparison.html showing the comparison]. It looks to me like Midboss is very confident it's going to win the round...Is this the bullet power distribution you expected? I'm sorry if the data is hard to read (as it's missing labels), but I'm literally moments away from going on vacation and wanted to put this up. When looking at the graphs showing P(miss or interception), it's useful to remember that MoxieBot needs the probability to be higher than .88 in order for a win. Thanks for prompting me to look deeper in to my bot's behavior, and hopefully when I get back I'll get to give Midboss a run for it's money :) [[User:Ncj|Ncj]] 04:54, 7 February 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:MoxieBot&diff=18377Talk:MoxieBot2011-02-05T08:58:54Z<p>Ncj: Response to Rednaxela</p>
<hr />
<div>Very neat - I like how you refer to the [[Bullet Shadow]] idea. The notion (in a vague form =)) has crossed my mind as something an elite wave surfer might want to try in a really tight spot (like in a corner + 2 bullets in the air), since not getting hit is so much more important than hitting the enemy when you're vastly outscoring them and trying to optimize <% total score>. Best of luck with MoxieBot! I might have to add some bullet shielding detection if you start beating [[Diamond]]. =) --[[User:Voidious|Voidious]] 06:22, 4 February 2011 (UTC)<br />
: Don't worry about me...Worry about if DrussGT starts using it! :) [[User:Ncj|Ncj]] 04:27, 5 February 2011 (UTC)<br />
<br />
I also really like the sound of this. I'm actually wondering about incorporating this into DrussGT. I'd check whether there is anywhere I can get with a coverage of >95%, and if their bullet power is > 0.1, and if so take that option for this wave. I'm also wondering if you can increase your coverage by waiting to fire until a bit later, or whether the earlier you fire the better your coverage is sort of thing. By mixing this idea with imaginary waves I think the coverage might be able to be increased substantially. Anyways, nice work on this bot =) --[[User:Skilgannon|Skilgannon]] 08:50, 4 February 2011 (UTC)<br />
: Thanks! There are definitely situations where you can get that kind of coverage if the enemy is far away and you get to move in a straight line at top speed. In the simple case where you move in a straight line to the point at which the wave will break, then I think that firing earlier will get you the largest shadow: The angle at which you need to fire will be the same no matter when you fire. This means the angle between your intersecting bullet and the enemy bullet is constant regardless of time, as will be the component of your bullet's movement perpendicular to the enemy bullet's movement. The angular width of the bullet shadow is a function of this perpendicular component and the distance from the wave origin of the bullet intersection. As the perpendicular component is constant, the only way to get a larger angular width is to intersect the wave earlier, which means firing as soon as possible. Of course, the point you intend to move to is under your control...Actually, this gave me some ideas for selecting a better location than I do now. [[User:Ncj|Ncj]] 04:24, 5 February 2011 (UTC)<br />
<br />
I've been thinking of this also lately, but from a slightly other perspective. If bullets collide, you know where the enemies bullit was heading, so you could move there indeed. Not specifically because that is a safe spot, although a nice side-effect, but as a sort of 'smoke curtain' to influence the gunnery of your opponent. He would register this spot as a peak, while normally you wouldn't had moved there in the first place. I feel like having a card in my sleeve, while wearing a t-shirt. --[[User:GrubbmGait|GrubbmGait]] 00:56, 5 February 2011 (UTC)<br />
<br />
Very nice. For a while I've been thinking about integrating [[Bullet Shadow|Bullet Shadows]] into a surfing movement, but this is the first time I've seen a bot with some particularly nice use of them. Also, I like the term "Bullet Shadow", I never had a good term for it before. Some thoughts:<br />
* Perhaps it would make sense to only have it move to positions with large shadows, instead of occasionally going to small shadow locations?<br />
* Looking at results [http://rednaxela-robocode.dyndns.org/rumble/RatingsDetails?game=roborumble&name=ncj.MoxieBot%201.0 here], it seems like my bot [[Midboss]] does particularly well against this. I'm pretty sure it's because of Midboss' rather smart bulletpower selection. Perhaps [[MoxieBot]] should fall back to another strategy when the enemy is firing small bullets?<br />
* Very impressive looking in battle! :)<br />
--[[User:Rednaxela|Rednaxela]] 01:09, 5 February 2011 (UTC)<br />
: Thanks for the kind words and suggestions. I've spent some time today looking at the rumble results, so I have quite a bit to respond with:<br />
:* First, Midboss really crushes MoxieBot! I agree that I need some kind of better movement, but it's hard for me to determine whether to try improve the bullet shadowing or the dodging. In order for MoxieBot to win (assuming the enemy is firing bullets of power > .5), the enemy needs to either miss or have their bullet intercepted > 88% of the time. In other words P(bullet aimed wrong) + P(bullet aimed right)*P(bullet intercepted | bullet aimed right) > 88%. Unfortunately, strategies that increase the bullet shadow generally make it easy to figure out where the bot will be, but random movement means that the bullet shadows are often poor. Right now, both dodging and bullet interception hover around 60% against many bots, which works out to be right around the % needed. A long term goal is to improve one of them substantially, and keep the other percent above 50%. Out of curiosity do you know what kind of dodge % a random movement algorithm with a flat profile should get?<br />
:* I took a long look at Midboss to try to figure out what it's doing, as compared to some of the other top bots. My initial guess was the same as yours; that Midboss used a lot of low power bullets, which raise the threshold above the 88% miss needed for the higher powers. However, the effect only really becomes significant below a power of .5, and Midboss used a power around 1.5 most of the time. Additionally, other bots fire low power bullets too, often even more frequently than Midboss, but not all share in the success. The biggest difference in behavior seems to be that Midboss hangs around the middle of the battlefield, whereas other bots like to hug the walls. On average Midboss shoots from around 400 pixels, wheras the wall huggers shoot from around 550 pixels. I believe that this increases the accuracy of your bot a few percent, dropping the overall measured P(miss or intercepted) to 82%, well below the 88% MoxieBot needs, which ultimately means that MoxieBot goes down in flames. I hope this made some kind of sense!<br />
:--[[User:Ncj|Ncj]] 08:58, 5 February 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18376MoxieBot2011-02-05T05:36:47Z<p>Ncj: Added rumble results for v1</p>
<hr />
<div>{{Infobox Robot<br />
| bgcolour = #505050<br />
| altimage = [[File:MoxieBotImage.png]]<br />
| author = [[User:Ncj|ncj]]<br />
| extends = [[AdvancedRobot]]<br />
| released = Feb 3, 2011<br />
| current_version = 1.0<br />
| license = Attribution<br />
| download_link = http://www.robocoderepository.com/BotDetail.jsp?id=4003<br />
| isOneOneOne = true<br />
}}<br />
== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[User:Ncj|ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
MoxieBot fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003 Download MoxieBot]<br />
<br />
; How competitive is it?<br />
My goal is to get at least 50% survival against all bots in the rumble. It should be able to do this against bots with standard strategies. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
v1.0 - APS(36.01%) Survival(66.84%), Pairings with <50% survival: ~250<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with [[Bullet_Shielding]]. <br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's statistics against standard guess factor targeting bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work on improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot that I'd like to implement counters for. I'd also like to incorporate shooting at the enemy into the bot's arsenal, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:MoxieBot&diff=18375Talk:MoxieBot2011-02-05T04:27:29Z<p>Ncj: Response to Voidious</p>
<hr />
<div>Very neat - I like how you refer to the [[Bullet Shadow]] idea. The notion (in a vague form =)) has crossed my mind as something an elite wave surfer might want to try in a really tight spot (like in a corner + 2 bullets in the air), since not getting hit is so much more important than hitting the enemy when you're vastly outscoring them and trying to optimize <% total score>. Best of luck with MoxieBot! I might have to add some bullet shielding detection if you start beating [[Diamond]]. =) --[[User:Voidious|Voidious]] 06:22, 4 February 2011 (UTC)<br />
: Don't worry about me...Worry about if DrussGT starts using it! :) [[User:Ncj|Ncj]] 04:27, 5 February 2011 (UTC)<br />
<br />
I also really like the sound of this. I'm actually wondering about incorporating this into DrussGT. I'd check whether there is anywhere I can get with a coverage of >95%, and if their bullet power is > 0.1, and if so take that option for this wave. I'm also wondering if you can increase your coverage by waiting to fire until a bit later, or whether the earlier you fire the better your coverage is sort of thing. By mixing this idea with imaginary waves I think the coverage might be able to be increased substantially. Anyways, nice work on this bot =) --[[User:Skilgannon|Skilgannon]] 08:50, 4 February 2011 (UTC)<br />
: Thanks! There are definitely situations where you can get that kind of coverage if the enemy is far away and you get to move in a straight line at top speed. In the simple case where you move in a straight line to the point at which the wave will break, then I think that firing earlier will get you the largest shadow: The angle at which you need to fire will be the same no matter when you fire. This means the angle between your intersecting bullet and the enemy bullet is constant regardless of time, as will be the component of your bullet's movement perpendicular to the enemy bullet's movement. The angular width of the bullet shadow is a function of this perpendicular component and the distance from the wave origin of the bullet intersection. As the perpendicular component is constant, the only way to get a larger angular width is to intersect the wave earlier, which means firing as soon as possible. Of course, the point you intend to move to is under your control...Actually, this gave me some ideas for selecting a better location than I do now. [[User:Ncj|Ncj]] 04:24, 5 February 2011 (UTC)<br />
<br />
I've been thinking of this also lately, but from a slightly other perspective. If bullets collide, you know where the enemies bullit was heading, so you could move there indeed. Not specifically because that is a safe spot, although a nice side-effect, but as a sort of 'smoke curtain' to influence the gunnery of your opponent. He would register this spot as a peak, while normally you wouldn't had moved there in the first place. I feel like having a card in my sleeve, while wearing a t-shirt. --[[User:GrubbmGait|GrubbmGait]] 00:56, 5 February 2011 (UTC)<br />
<br />
Very nice. For a while I've been thinking about integrating [[Bullet Shadow|Bullet Shadows]] into a surfing movement, but this is the first time I've seen a bot with some particularly nice use of them. Also, I like the term "Bullet Shadow", I never had a good term for it before. Some thoughts:<br />
* Perhaps it would make sense to only have it move to positions with large shadows, instead of occasionally going to small shadow locations?<br />
* Looking at results [http://rednaxela-robocode.dyndns.org/rumble/RatingsDetails?game=roborumble&name=ncj.MoxieBot%201.0 here], it seems like my bot [[Midboss]] does particularly well against this. I'm pretty sure it's because of Midboss' rather smart bulletpower selection. Perhaps [[MoxieBot]] should fall back to another strategy when the enemy is firing small bullets?<br />
* Very impressive looking in battle! :)<br />
--[[User:Rednaxela|Rednaxela]] 01:09, 5 February 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:MoxieBot&diff=18374Talk:MoxieBot2011-02-05T04:24:09Z<p>Ncj: Response to Skilgannon</p>
<hr />
<div>Very neat - I like how you refer to the [[Bullet Shadow]] idea. The notion (in a vague form =)) has crossed my mind as something an elite wave surfer might want to try in a really tight spot (like in a corner + 2 bullets in the air), since not getting hit is so much more important than hitting the enemy when you're vastly outscoring them and trying to optimize <% total score>. Best of luck with MoxieBot! I might have to add some bullet shielding detection if you start beating [[Diamond]]. =) --[[User:Voidious|Voidious]] 06:22, 4 February 2011 (UTC)<br />
<br />
I also really like the sound of this. I'm actually wondering about incorporating this into DrussGT. I'd check whether there is anywhere I can get with a coverage of >95%, and if their bullet power is > 0.1, and if so take that option for this wave. I'm also wondering if you can increase your coverage by waiting to fire until a bit later, or whether the earlier you fire the better your coverage is sort of thing. By mixing this idea with imaginary waves I think the coverage might be able to be increased substantially. Anyways, nice work on this bot =) --[[User:Skilgannon|Skilgannon]] 08:50, 4 February 2011 (UTC)<br />
: Thanks! There are definitely situations where you can get that kind of coverage if the enemy is far away and you get to move in a straight line at top speed. In the simple case where you move in a straight line to the point at which the wave will break, then I think that firing earlier will get you the largest shadow: The angle at which you need to fire will be the same no matter when you fire. This means the angle between your intersecting bullet and the enemy bullet is constant regardless of time, as will be the component of your bullet's movement perpendicular to the enemy bullet's movement. The angular width of the bullet shadow is a function of this perpendicular component and the distance from the wave origin of the bullet intersection. As the perpendicular component is constant, the only way to get a larger angular width is to intersect the wave earlier, which means firing as soon as possible. Of course, the point you intend to move to is under your control...Actually, this gave me some ideas for selecting a better location than I do now. [[User:Ncj|Ncj]] 04:24, 5 February 2011 (UTC)<br />
<br />
I've been thinking of this also lately, but from a slightly other perspective. If bullets collide, you know where the enemies bullit was heading, so you could move there indeed. Not specifically because that is a safe spot, although a nice side-effect, but as a sort of 'smoke curtain' to influence the gunnery of your opponent. He would register this spot as a peak, while normally you wouldn't had moved there in the first place. I feel like having a card in my sleeve, while wearing a t-shirt. --[[User:GrubbmGait|GrubbmGait]] 00:56, 5 February 2011 (UTC)<br />
<br />
Very nice. For a while I've been thinking about integrating [[Bullet Shadow|Bullet Shadows]] into a surfing movement, but this is the first time I've seen a bot with some particularly nice use of them. Also, I like the term "Bullet Shadow", I never had a good term for it before. Some thoughts:<br />
* Perhaps it would make sense to only have it move to positions with large shadows, instead of occasionally going to small shadow locations?<br />
* Looking at results [http://rednaxela-robocode.dyndns.org/rumble/RatingsDetails?game=roborumble&name=ncj.MoxieBot%201.0 here], it seems like my bot [[Midboss]] does particularly well against this. I'm pretty sure it's because of Midboss' rather smart bulletpower selection. Perhaps [[MoxieBot]] should fall back to another strategy when the enemy is firing small bullets?<br />
* Very impressive looking in battle! :)<br />
--[[User:Rednaxela|Rednaxela]] 01:09, 5 February 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18370MoxieBot2011-02-04T17:19:31Z<p>Ncj: Switched image to uploaded file.</p>
<hr />
<div>{{Infobox Robot<br />
| bgcolour = #505050<br />
| altimage = [[File:MoxieBotImage.png]]<br />
| author = [[User:Ncj|ncj]]<br />
| extends = [[AdvancedRobot]]<br />
| released = Feb 3, 2011<br />
| current_version = 1.0<br />
| license = Attribution<br />
| download_link = http://www.robocoderepository.com/BotDetail.jsp?id=4003<br />
| isOneOneOne = true<br />
}}<br />
== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[User:Ncj|ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
MoxieBot fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003 Download MoxieBot]<br />
<br />
; How competitive is it?<br />
It was just entered into the [[RoboRumble]], but my goal was to get at least 50% survival against all bots currently in the rumble. We'll see. It should be able to do this against bots with standard strategies. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with [[Bullet_Shielding]]. <br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's statistics against standard guess factor targeting bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work on improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot that I'd like to implement counters for. I'd also like to incorporate shooting at the enemy into the bot's arsenal, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=File:MoxieBotImage.png&diff=18369File:MoxieBotImage.png2011-02-04T17:17:47Z<p>Ncj: </p>
<hr />
<div></div>Ncjhttp://robowiki.net/w/index.php?title=Bullet_Shadow&diff=18368Bullet Shadow2011-02-04T17:15:19Z<p>Ncj: Created page with 'When you fire a bullet which intersects an enemy Wave, you will know for certain that the enemy bullet is not in the wave section which was intersected. If it were in that se…'</p>
<hr />
<div>When you fire a bullet which intersects an enemy [[Wave]], you will know for certain that the enemy bullet is not in the wave section which was intersected. If it were in that section, then the two bullets would have collided and exploded. As the enemy wave travels outward, this safe region will trace out a region of the battle field as if your bullet cast a shadow of safety outward.</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:Bullet_Shielding&diff=18363Talk:Bullet Shielding2011-02-04T05:58:40Z<p>Ncj: /* No practical need to adjust the bullet power */</p>
<hr />
<div>{{CreditForOldWikiArticle<br />
| oldpage=BulletShielding<br />
| author=[[User:Vuen|Vuen]]<br />
}}<br />
<br />
== Discussion from Old Wiki ==<br />
I was just reading this, and thought of an idea: Instead of theming Firing/Movement? on bullet collisions like this, why not use this technique to enhance the existing methods of WaveSurfing? Basically, track movement of your own bullets, and check what "umbrellas" exist, and set the danger factor to 0 where it is covered by an "umbrella". A robot using this would be able to take advantage of these zero-danger locations while still using good movement when it can't get to these zero danger locations. You don't even to make the firing algorithm optimized for creating as much BulletShielding as possible, just just look at what lucky BulletShielding happens to exist. Perhaps this could be combined with firing that is designed to create more BulletShielding, but even without that you could use this to make WaveSurfing just a little bit smarter. -- [[User:Rednaxela|Rednalexa]]<br />
<br />
:I've tried this recently, and in practice the width of these umbrellas are rather narrow. I'm still working with the idea though. I spent a couple hours earlier today looking at the logistics of creating deliberate safe(r) areas. More work ahead of me. -- [[User:Martin|Martin]]<br />
<br />
::Well, even if the umbrellas are very narrow, it could still reduce the overall danger (both actual and calculated) across the width of the robot. Even if it wouldn't change the lowest danger location for the robot very often, every avoided bullet counts. Best of luck tring to implement this type of thing. I might give it a try once my WaveSurfing is working well enough to be worth looking for these smaller optimizations. -- [[User:Rednaxela|Rednalexa]]<br />
<br />
::I've tried this too, no success. I thought this could be a nice secret weapon, but it hat no impact on the score ;( But the idea of BulletShielding is fascinating, I tried it every once in a while :) --[[User:Krabb|Krabb]]<br />
<br />
:::Interesting. Well, despite the past failures people have had with this, I'll probably give it a try some day just for fun. I think that somebody will manage to get this to add a tiny tiny fraction of score. Maybe 0.01 extra score in the RoboRumble will be achievable some day with this? :) -- [[User:Rednaxela|Rednalexa]]<br />
<br />
== Multiple bullets? ==<br />
Is it possible for more than 2 bullets to collide? And if so, how do the mechanics of that work? --[[User:Starrynte|Starrynte]] 04:29, 23 April 2010 (UTC)<br />
<br />
I actually have no idea. Both may be removed from consideration as soon as the collision is detected, but I dunno. I imagine you could easily tell from looking at the Robocode source. Or of course you could code up some bots that fire intersecting bullets and see what happens. =) --[[User:Voidious|Voidious]] 20:52, 23 April 2010 (UTC)<br />
<br />
Voidious is correct and incorrect. Each bullet can only hit once, either other bullets, robots or wall. So if more than two bullets collide, each bullet will be paired with other bullets and the odd one is left. This happen randomly, so it is completely unpredictable which pair will collide. No, it can be easily tell from Robocode source. It is quite complicated and very modular. =) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 05:24, 24 April 2010 (UTC)<br />
<br />
==Parametric equations?==<br />
How do I use "parametric equations"? Could someone explain this to me? For example, what kind of equations would I use the "center" the intersection point? <br />
<br />
--[[User:Urgood2|-- Josh S]] 11:18, 26 April 2010 (UTC)<br />
<br />
== No practical need to adjust the bullet power ==<br />
In [[MoxieBot]], I found that the bullet shadows are usually smaller than the width of my bot, and that the increased shadow size given by 'centering' the collision didn't make up for the additional energy loss from firing a bullet of power greater than ".1".<br />
[[User:Ncj|Ncj]] 05:58, 4 February 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=Talk:Bullet_Shielding&diff=18362Talk:Bullet Shielding2011-02-04T05:56:33Z<p>Ncj: </p>
<hr />
<div>{{CreditForOldWikiArticle<br />
| oldpage=BulletShielding<br />
| author=[[User:Vuen|Vuen]]<br />
}}<br />
<br />
== Discussion from Old Wiki ==<br />
I was just reading this, and thought of an idea: Instead of theming Firing/Movement? on bullet collisions like this, why not use this technique to enhance the existing methods of WaveSurfing? Basically, track movement of your own bullets, and check what "umbrellas" exist, and set the danger factor to 0 where it is covered by an "umbrella". A robot using this would be able to take advantage of these zero-danger locations while still using good movement when it can't get to these zero danger locations. You don't even to make the firing algorithm optimized for creating as much BulletShielding as possible, just just look at what lucky BulletShielding happens to exist. Perhaps this could be combined with firing that is designed to create more BulletShielding, but even without that you could use this to make WaveSurfing just a little bit smarter. -- [[User:Rednaxela|Rednalexa]]<br />
<br />
:I've tried this recently, and in practice the width of these umbrellas are rather narrow. I'm still working with the idea though. I spent a couple hours earlier today looking at the logistics of creating deliberate safe(r) areas. More work ahead of me. -- [[User:Martin|Martin]]<br />
<br />
::Well, even if the umbrellas are very narrow, it could still reduce the overall danger (both actual and calculated) across the width of the robot. Even if it wouldn't change the lowest danger location for the robot very often, every avoided bullet counts. Best of luck tring to implement this type of thing. I might give it a try once my WaveSurfing is working well enough to be worth looking for these smaller optimizations. -- [[User:Rednaxela|Rednalexa]]<br />
<br />
::I've tried this too, no success. I thought this could be a nice secret weapon, but it hat no impact on the score ;( But the idea of BulletShielding is fascinating, I tried it every once in a while :) --[[User:Krabb|Krabb]]<br />
<br />
:::Interesting. Well, despite the past failures people have had with this, I'll probably give it a try some day just for fun. I think that somebody will manage to get this to add a tiny tiny fraction of score. Maybe 0.01 extra score in the RoboRumble will be achievable some day with this? :) -- [[User:Rednaxela|Rednalexa]]<br />
<br />
== Multiple bullets? ==<br />
Is it possible for more than 2 bullets to collide? And if so, how do the mechanics of that work? --[[User:Starrynte|Starrynte]] 04:29, 23 April 2010 (UTC)<br />
<br />
I actually have no idea. Both may be removed from consideration as soon as the collision is detected, but I dunno. I imagine you could easily tell from looking at the Robocode source. Or of course you could code up some bots that fire intersecting bullets and see what happens. =) --[[User:Voidious|Voidious]] 20:52, 23 April 2010 (UTC)<br />
<br />
Voidious is correct and incorrect. Each bullet can only hit once, either other bullets, robots or wall. So if more than two bullets collide, each bullet will be paired with other bullets and the odd one is left. This happen randomly, so it is completely unpredictable which pair will collide. No, it can be easily tell from Robocode source. It is quite complicated and very modular. =) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 05:24, 24 April 2010 (UTC)<br />
<br />
==Parametric equations?==<br />
How do I use "parametric equations"? Could someone explain this to me? For example, what kind of equations would I use the "center" the intersection point? <br />
<br />
--[[User:Urgood2|-- Josh S]] 11:18, 26 April 2010 (UTC)<br />
<br />
== No practical need to adjust the bullet power ==<br />
In [[MoxieBot]], I found that the bullet shadows are usually smaller than the width of my bot, and that the increased shadow size given by 'centering' the collision didn't make up for the additional energy loss from firing a bullet of power greater than ".1".</div>Ncjhttp://robowiki.net/w/index.php?title=User:Ncj&diff=18361User:Ncj2011-02-04T05:42:12Z<p>Ncj: </p>
<hr />
<div>Hello!<br />
<br />
I'm a programmer by trade, and I've been playing with Robocode on and off for a couple of years. From the beginning, the wiki is what really drew me in. At first I didn't want to build my own robot, but I spent hours reading everything on this site to learn how the best bots were able to dance around, magically avoiding bullets.<br />
<br />
I finally have a bot in the works that's doing well in my own tests. I'm trying to build a [[Bullet_Shielding]] bot; my first goal is to get at least a 50% win record against every bot in the rumble, though I'm sure those nice results won't last long. I'm making this page to motivate myself to actually release the thing instead of tweaking forever and ever.<br />
<br />
Here's the bot: [[MoxieBot]]<br />
<br />
Robots!</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18360MoxieBot2011-02-04T05:41:43Z<p>Ncj: </p>
<hr />
<div>{{Infobox Robot<br />
| bgcolour = #505050<br />
| altimage = http://dl.dropbox.com/u/162056/2011-02-03T17.52.12.858.png<br />
| author = [[User:Ncj|ncj]]<br />
| extends = [[AdvancedRobot]]<br />
| released = Feb 3, 2011<br />
| current_version = 1.0<br />
| license = Attribution<br />
| download_link = http://www.robocoderepository.com/BotDetail.jsp?id=4003<br />
| isOneOneOne = true<br />
}}<br />
== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[User:Ncj|ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
MoxieBot fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003 Download MoxieBot]<br />
<br />
; How competitive is it?<br />
It was just entered into the [[RoboRumble]], but my goal was to get at least 50% survival against all bots currently in the rumble. We'll see. It should be able to do this against bots with standard strategies. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with [[Bullet_Shielding]]. <br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's statistics against standard guess factor targeting bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work on improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot that I'd like to implement counters for. I'd also like to incorporate shooting at the enemy into the bot's arsenal, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18359MoxieBot2011-02-04T05:39:42Z<p>Ncj: Linked to BulletShielding</p>
<hr />
<div>{{Infobox Robot<br />
| bgcolour = #505050<br />
| altimage = http://dl.dropbox.com/u/162056/2011-02-03T17.52.12.858.png<br />
| author = [[User:Ncj|ncj]]<br />
| extends = [[AdvancedRobot]]<br />
| released = Feb 3, 2011<br />
| current_version = 1.0<br />
| license = Attribution<br />
| download_link = http://www.robocoderepository.com/BotDetail.jsp?id=4003<br />
| isOneOneOne = true<br />
}}<br />
== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[User:Ncj|ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
MoxieBot fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003 Download MoxieBot]<br />
<br />
; How competitive is it?<br />
It was just entered into the [[RoboRumble]], but my goal was to get at least 50% survival against all bots currently in the rumble. We'll see. It should be able to do this against bots with standard strategies. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with [[BulletShielding]]. <br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's statistics against standard guess factor targeting bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work on improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot that I'd like to implement counters for. I'd also like to incorporate shooting at the enemy into the bot's arsenal, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=User:Ncj&diff=18358User:Ncj2011-02-04T05:37:37Z<p>Ncj: Ha! Finally found the bullet shielding page.</p>
<hr />
<div>Hello!<br />
<br />
I'm a programmer by trade, and I've been playing with Robocode on and off for a couple of years. From the beginning, the wiki is what really drew me in. At first I didn't want to build my own robot, but I spent hours reading everything on this site to learn how the best bots were able to dance around, magically avoiding bullets.<br />
<br />
I finally have a bot in the works that's doing well in my own tests. I'm trying to build a [[BulletShielding]] bot; my first goal is to get at least a 50% win record against every bot in the rumble, though I'm sure those nice results won't last long. I'm making this page to motivate myself to actually release the thing instead of tweaking forever and ever.<br />
<br />
Here's the bot: [[MoxieBot]]<br />
<br />
Robots!</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18357MoxieBot2011-02-04T01:16:09Z<p>Ncj: /* Background Information */</p>
<hr />
<div>{{Infobox Robot<br />
| bgcolour = #505050<br />
| altimage = http://dl.dropbox.com/u/162056/2011-02-03T17.52.12.858.png<br />
| author = [[User:Ncj|ncj]]<br />
| extends = [[AdvancedRobot]]<br />
| released = Feb 3, 2011<br />
| current_version = 1.0<br />
| license = Attribution<br />
| download_link = http://www.robocoderepository.com/BotDetail.jsp?id=4003<br />
| isOneOneOne = true<br />
}}<br />
== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[User:Ncj|ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
MoxieBot fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003 Download MoxieBot]<br />
<br />
; How competitive is it?<br />
It was just entered into the [[RoboRumble]], but my goal was to get at least 50% survival against all bots currently in the rumble. We'll see. It should be able to do this handily against the standard guess factor targeting bots, even the better ones. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with its own shots.<br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's statistics against standard guess factor targeting bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work on improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot that I'd like to implement counters for. I'd also like to incorporate shooting at the enemy into the bot's arsenal, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=User:Ncj&diff=18356User:Ncj2011-02-04T00:56:42Z<p>Ncj: </p>
<hr />
<div>Hello!<br />
<br />
I'm a programmer by trade, and I've been playing with Robocode on and off for a couple of years. From the beginning, the wiki is what really drew me in. At first I didn't want to build my own robot, but I spent hours reading everything on this site to learn how the best bots were able to dance around, magically avoiding bullets.<br />
<br />
I finally have a bot in the works that's doing well in my own tests. I'm trying out what I think is a new strategy; my first goal is to get at least a 50% win record against every bot in the rumble, though I'm sure those nice results won't last long. I'm making this page to motivate myself to actually release the thing instead of tweaking forever and ever.<br />
<br />
Here's the bot: [[MoxieBot]]<br />
<br />
Robots!</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18355MoxieBot2011-02-04T00:48:53Z<p>Ncj: Minor fixes</p>
<hr />
<div>== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[User:Ncj|ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
MoxieBot fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003 Download MoxieBot]<br />
<br />
; How competitive is it?<br />
It was just entered into the [[RoboRumble]], but my goal was to get at least 50% survival against all bots currently in the rumble. We'll see. It should be able to do this handily against the standard guess factor targeting bots, even the better ones. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with its own shots.<br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's statistics against standard guess factor targeting bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work on improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot that I'd like to implement counters for. I'd also like to incorporate shooting at the enemy into the bot's arsenal, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=MoxieBot&diff=18354MoxieBot2011-02-04T00:40:59Z<p>Ncj: Added a page for MoxieBot</p>
<hr />
<div>== Background Information ==<br />
<br />
; Bot Name<br />
MoxieBot<br />
<br />
; Author<br />
[[ncj]]<br />
<br />
; Extends<br />
[[AdvancedRobot]]<br />
<br />
; What's special about it?<br />
It fires .1 power bullets that are aimed to intercept enemy bullets. It wins by simply running the opponent out of energy, which works surprisingly well.<br />
<br />
; Great, I want to try it. Where can I download it?<br />
[http://www.robocoderepository.com/BotDetail.jsp?id=4003]<br />
<br />
; How competitive is it?<br />
It was just entered into the [[RoboRumble]], but my goal was to get at least 50% survival against all bots currently in the rumble. We'll see. It should be able to do this handily against the standard guess factor targeting bots, even the better ones. However, unless it wins all battles against a given bot, it will probably lose by score.<br />
<br />
== Strategy ==<br />
<br />
; How does it [[Movement|move]]?<br />
It tries to move somewhat perpendicular to the incoming wave. Selection of the particular location to move to is random, weighted by how much of a [[BulletShadow]] that position offers. <br />
<br />
; How does it fire?<br />
Every time the enemy fires, the bot selects a new position to move to, and fires a bullet that will intercept the enemy bullet it if it fired at the selected position. This means that there is a chance for the enemy to 'miss' even if it fired at MoxieBot's future position. I'd like to apologize for the long battles this can engender.<br />
<br />
; How does it [[Dodging Bullets|dodge bullets]]?<br />
It moves in a somewhat random pattern, while shadowing future positions with its own shots.<br />
<br />
; How does the [[melee]] strategy differ from [[One-on-one]] strategy?<br />
n/a<br />
<br />
; How does it select a target to attack/avoid in [[melee]]?<br />
n/a<br />
<br />
; What does it save between rounds and matches?<br />
Nothing.<br />
<br />
== Additional Information ==<br />
<br />
; Where did you get the name?<br />
I wanted to name the bot Patience, given that the bot just waits out the enemy, but that name was already being used. I looked at a list of synonyms, and Moxie stood out. The development name was 'NextBot', so I put the two together and got MoxieBot.<br />
<br />
; Can I use your code?<br />
Yes, if you tell me you used it and attribute it to me. There's a license file in the git repository, which is located here:<br />
git://github.com/bluemoo/robots.git<br />
<br />
; What's next for your robot?<br />
I just threw together a mediocre movement strategy, but that's first on the list of improvements. The bot still hits walls and moves in odd snake-like patterns! <br />
<br />
After movement, I intend to put some logic in to handle bots that use non-standard strategies, as will be revealed by the RoboRumble.<br />
<br />
The bot's current statistics against higher ranked bots looks something like this:<br />
P(interception | enemy bullet aimed at my position) = 62%<br />
P(enemy bullet aimed incorrectly) = 64%<br />
P(enemy shot will miss me) = 86%<br />
<br />
I will generally work improving these percentages, and perhaps implement a rudimentary firing strategy. There are also several simple things that the enemy can currently do to beat MoxieBot. I'd also like to incorporate shooting at the enemy into the bot's arsenal of tricks, in order to eventually be able to win according to score.<br />
<br />
; Does it have any [[White Whale]]s?<br />
Pretty much anything non-standard. Ram-bots will destroy it, as the bot has no real offensive capabilities. Any bot that fires .1 power bullets should win, at the moment.<br />
<br />
; What other robot(s) is it based on?<br />
I learned how to think correctly about the battles by reading this wiki. I found Albert's [[FuturePosition]] code to be invaluable, and use most of it directly. There's also a bot out there called BulletCatcher that I found during my implementation. While MoxieBot is bot based off of it, I like to think they are distantly related.<br />
<br />
[[Category:Templates|Bots]]</div>Ncjhttp://robowiki.net/w/index.php?title=RoboRumble/Participants&diff=18353RoboRumble/Participants2011-02-04T00:02:19Z<p>Ncj: Added MoxieBot to the roborumble</p>
<hr />
<div>{{:RoboRumble/Navigation}}<br />
<br />
----<br />
Just add your bot name ('''as appears in the Robocode selector after packaging''', so including versionnumber) and the RobocodeRepository id number separated by "," (there must be no space after the comma).<br> <br />
Please, make sure your bot is not in the list before adding it, and delete the old version if you are adding a new one.<br />
<br><br />
The list is in '''alphabetical''' order. Add your bot in the right slot.<br />
<br />
----<br />
<pre><br />
ab.DengerousRoBatra 1.3,http://www.robocoderepository.com/BotFiles/3664/ab.DengerousRoBatra_1.3.jar<br />
abc.Shadow 3.83c,http://robocode.aclsi.pt/abc.Shadow_3.83c.jar<br />
abc.tron3.Tron 3.11,http://www.robocoderepository.com/BotFiles/2205/abc.tron3.Tron_3.11.jar<br />
abc.Tron 2.02,http://www.robocoderepository.com/BotFiles/241/abc.Tron_2.02.jar<br />
abud.ThirdRobo 1.0,http://www.robocoderepository.com/BotFiles/2479/abud.ThirdRobo_1.0.jar<br />
ad.last.Bottom 1.0,http://www.robocoderepository.com/BotFiles/1876/ad.last.Bottom_1.0.jar<br />
ad.Quest 0.10,http://www.robocoderepository.com/BotFiles/1846/ad.Quest_0.10.jar<br />
adt.Ar1 2.1,http://www.robocoderepository.com/BotFiles/2254/adt.Ar1_2.1.jar<br />
adt.Ar2 1.0,http://www.robocoderepository.com/BotFiles/2303/adt.Ar2_1.0.jar<br />
ag.Gir 0.99,http://www.robocoderepository.com/BotFiles/3065/ag.Gir_0.99.jar<br />
agd.Mooserwirt2 2.7,http://www.glyndavies.org/robocode/agd.Mooserwirt2.jar<br />
ags.Glacier 0.2.7,http://rednaxela-robocode.dyndns.org/data/robots/ags.Glacier_0.2.7.jar<br />
ags.micro.Carpet 1.1,http://rednaxela-robocode.dyndns.org/data/robots/ags.micro.Carpet_1.1.jar<br />
ags.Midboss 1s,http://rednaxela-robocode.dyndns.org/data/robots/ags.Midboss_1s.jar<br />
ags.polished.PolishedRuby 1,http://rednaxela-robocode.dyndns.org/data/robots/ags.polished.PolishedRuby_1.jar<br />
ags.rougedc.RougeDC willow,http://rednaxela-robocode.dyndns.org/data/robots/ags.rougedc.RougeDC_willow.jar<br />
ahf.Acero 1.0,http://www.robocoderepository.com/BotFiles/2151/ahf.Acero_1.0.jar<br />
ahf.NanoAndrew .4,http://www.robocoderepository.com/BotFiles/2002/ahf.NanoAndrew_.4.jar<br />
ahf.r2d2.R2d2 0.86,http://www.robocoderepository.com/BotFiles/2035/ahf.r2d2.R2d2_0.86.jar<br />
ahr.ice.Ice 1.0,http://robocoderepository.com/BotFiles/3966/ahr.ice.Ice_1.0.jar<br />
ahr.ice.Ice 1.0.1,http://robocoderepository.com/BotFiles/3978/ahr.ice.Ice_1.0.1.jar<br />
AIR.iRobot 1.0,http://www.robocoderepository.com/BotFiles/3205/AIR.iRobot_1.0.jar<br />
ak.Fermat 2.0,http://www.robocoderepository.com/BotFiles/799/ak.Fermat_2.0.jar<br />
alex.Diabolo5 1.1,http://darkcanuck.net/rumble/robots/alex.Diabolo5_1.1.jar<br />
alk.lap.LoudAndProud 2.23,http://www.robocoderepository.com/BotFiles/3601/alk.lap.LoudAndProud_2.23.jar<br />
altglass.Exterminans2oo8 alpha0328,http://d-gfx.kognetwork.ch/robocode/altglass.Exterminans2oo8_alpha0328.jar<br />
altglass.Exterminans2oo8 Build0411,http://d-gfx.kognetwork.ch/robocode/altglass.Exterminans2oo8_Build0411.jar<br />
am.Miedzix 2.0,http://www.robocoderepository.com/BotFiles/3383/am.Miedzix_2.0.jar<br />
am.Miedzix 3.0,http://darkcanuck.net/rumble/robots/am.Miedzix_3.0.jar<br />
amarok.Rookie 1.1,http://www.robocoderepository.com/BotFiles/422/amarok.Rookie_1.1.jar<br />
amk.ChumbaMini 0.2,http://www.robocoderepository.com/BotFiles/2655/amk.ChumbaMini_0.2.jar<br />
amk.ChumbaWumba 0.3,http://www.robocoderepository.com/BotFiles/2646/amk.ChumbaWumba_0.3.jar<br />
amk.jointstrike.JointStrike 0.2,http://www.robocoderepository.com/BotFiles/2597/amk.jointstrike.JointStrike_0.2.jar<br />
amk.ShizzleStiX.ShizzleStiX 0.6,http://www.robocoderepository.com/BotFiles/2603/amk.ShizzleStiX.ShizzleStiX_0.6.jar<br />
amk.superstrike.SuperStrike 0.3,http://www.robocoderepository.com/BotFiles/2600/amk.superstrike.SuperStrike_0.3.jar<br />
amk.Punbot.Punbot 0.01,http://www.robocoderepository.com/BotFiles/2604/amk.Punbot.Punbot_0.01.jar<br />
ao.T100 0.9,http://www.robocoderepository.com/BotFiles/3385/ao.T100_0.9.jar<br />
ap.Frederick 1.1,http://darkcanuck.net/rumble/robots/ap.Frederick_1.1.jar<br />
apollokidd.ApolloKidd 0.9,http://www.robocoderepository.com/BotFiles/321/apollokidd.ApolloKidd_0.9.jar<br />
apv.Aspid 1.7,http://www.robocoderepository.com/BotFiles/1412/apv.Aspid_1.7.jar<br />
apv.AspidReloaded 0.6,http://www.robocoderepository.com/BotFiles/1985/apv.AspidReloaded_0.6.jar<br />
apv.LauLectrik 1.2,http://www.robocoderepository.com/BotFiles/1300/apv.LauLectrik_1.2.jar<br />
apv.MicroAspid 1.8,http://www.robocoderepository.com/BotFiles/2519/apv.MicroAspid_1.8.jar<br />
apv.NanoLauLectrik 1.0,http://www.robocoderepository.com/BotFiles/1399/apv.NanoLauLectrik_1.0.jar<br />
apv.NanoLauLectrikTheCannibal 1.1,http://www.robocoderepository.com/BotFiles/2147/apv.NanoLauLectrikTheCannibal_1.1.jar<br />
apv.ScruchiPu 1.0,http://www.robocoderepository.com/BotFiles/1367/apv.ScruchiPu_1.0.jar<br />
apv.test.Virus 0.6.1,http://www.robocoderepository.com/BotFiles/2645/apv.test.Virus_0.6.1.jar<br />
apv.TheBrainPi 0.5fix,http://darkcanuck.net/rumble/robots/apv.TheBrainPi_0.5fix.jar<br />
ar.horizon.Horizon 1.2.2,http://www.robocoderepository.com/BotFiles/3286/ar.horizon.Horizon_1.2.2.jar<br />
ar.QuantumChromodynamics 1.2.1,http://www.robocoderepository.com/BotFiles/3220/ar.QuantumChromodynamics_1.2.1.jar<br />
ar.TheoryOfEverything 1.2.1,http://www.robocoderepository.com/BotFiles/3221/ar.TheoryOfEverything_1.2.1.jar<br />
ara.Shera 0.88,http://www.robocoderepository.com/BotFiles/1050/ara.Shera_0.88.jar<br />
areb.Union 1.06,http://www.robocoderepository.com/BotFiles/2893/areb.Union_1.06.jar<br />
arthord.micro.Apoptygma 0.4,http://www.robocoderepository.com/BotFiles/1688/arthord.micro.Apoptygma_0.4.jar<br />
arthord.micro.Muffin 0.6.1,http://www.robocoderepository.com/BotFiles/1963/arthord.micro.Muffin_0.6.1.jar<br />
arthord.KostyaTszyu Beta2,http://www.robocoderepository.com/BotFiles/2322/arthord.KostyaTszyu_Beta2.jar<br />
arthord.MannyPacquiao Delta2,http://scoutery.awardspace.com/arthord.MannyPacquiao_Delta2.jar<br />
arthord.NanoSatan Mu,http://www.robocoderepository.com/BotFiles/2157/arthord.NanoSatan_Mu.jar<br />
arthord.NanoSatanMelee Beta,http://www.robocoderepository.com/BotFiles/2088/arthord.NanoSatanMelee_Beta.jar<br />
ary.micro.Weak 1.2,http://www.robocoderepository.com/BotFiles/3433/ary.micro.Weak_1.2.jar<br />
ary.mini.Nimi 1.0,http://www.robocoderepository.com/BotFiles/3397/ary.mini.Nimi_1.0.jar<br />
ary.nano.AceSurf 1.2,http://www.robocoderepository.com/BotFiles/3352/ary.nano.AceSurf_1.2.jar<br />
ary.nano.ColorNanoP 1.1,http://www.robocoderepository.com/BotFiles/3629/ary.nano.ColorNanoP_1.1.jar<br />
ary.Crisis 1.0,http://www.robocoderepository.com/BotFiles/3495/ary.Crisis_1.0.jar<br />
ary.Help 1.0,http://darkcanuck.net/rumble/robots/ary.Help_1.0.jar<br />
ary.FourWD 1.3d,http://darkcanuck.net/rumble/robots/ary.FourWD_1.3d.jar<br />
ary.SMG 1.01,http://ary-robocode.110mb.com/ary.SMG_1.01.jar<br />
as.xbots 1.0,http://darkcanuck.net/rumble/robots/as.xbots_1.0.jar<br />
asd.Cthulhu 1.2,http://darkcanuck.net/rumble/robots/asd.Cthulhu_1.2.jar<br />
asm.Statistas 0.1,http://www.robocoderepository.com/BotFiles/1989/asm.Statistas_0.1.jar<br />
awesomeness.Elite 1.0,http://robocoderepository.com/BotFiles/3597/awesomeness.Elite.jar<br />
awl.Locutus 1.0,3844<br />
axeBots.HataMoto 3.09,http://www.robocoderepository.com/BotFiles/1655/axeBots.HataMoto_3.09.jar<br />
axeBots.Musashi 2.18,http://www.robocoderepository.com/BotFiles/1759/axeBots.Musashi_2.18.jar<br />
axeBots.Okami 1.04,http://www.robocoderepository.com/BotFiles/2016/axeBots.Okami_1.04.jar<br />
axeBots.SilverSurfer 2.53.33fix,http://rednaxela-robocode.dyndns.org/data/robots/axeBots.SilverSurfer_2.53.33fix.jar<br />
baal.nano.N 1.42,http://webpages.charter.net/eleeleth/Robots/baal.nano.N_1.42.jar<br />
banshee.mini.Nexus6 0.2.0,http://www.robocoderepository.com/BotFiles/3467/banshee.mini.Nexus6_0.2.0.jar<br />
banshee.micro.Nexus6 0.3.0,http://www.robocoderepository.com/BotFiles/3473/banshee.micro.Nexus6_0.3.0.jar<br />
bayen.nano.Squirrel 0.2,http://www.freewebs.com/bayen/files/bayen.nano.Squirrel_0.2.jar<br />
bayen.nut.Squirrel 1.621,http://darkcanuck.net/rumble/robots/bayen.nut.Squirrel_1.621.jar<br />
bayen.UbaMicro 1.4,http://www.robocoderepository.com/BotFiles/2830/bayen.UbaMicro_1.4.jar<br />
bayen.UbaRamLT 1.0,http://www.robocoderepository.com/BotFiles/2868/bayen.UbaRamLT_1.0.jar<br />
bbo.RamboT 0.3,http://www.robocoderepository.com/BotFiles/2210/bbo.RamboT_0.3.jar<br />
bbo.TheRoof 1.4.3,http://www.robocoderepository.com/BotFiles/2179/bbo.TheRoof_1.4.3.jar<br />
Bemo.Sweet30 1.6.1,http://www.stg-volleyball.de/images/Bemo.Sweet30_1.6.1.jar<br />
benhorner.PureAggression 0.2.6,http://www.robocoderepository.com/BotFiles/3421/benhorner.PureAggression_0.2.6.jar<br />
bh.PencilRain 0.01,http://www.robocoderepository.com/BotFiles/3670/bh.PencilRain-0.01.jar<br />
bigpete.Stewie 1.0,http://www.robocoderepository.com/BotFiles/2927/bigpete.Stewie_1.0.jar<br />
bing2.Melody 1.3.1,http://www.ccs.neu.edu/home/bing/robocode/bing2.Melody_1.3.1.jar<br />
bjl.LoneDragon 0.5,http://www.robocoderepository.com/BotFiles/1929/bjl.LoneDragon_0.5.jar<br />
bndl.LostLion 1.2,http://www.robocoderepository.com/BotFiles/1033/bndl.LostLion_1.2.jar<br />
bons.NanoStalker 1.2,http://www.robocoderepository.com/BotFiles/1179/bons.NanoStalker_1.2.jar<br />
bp.Kuma 1.0,http://www.robocoderepository.com/BotFiles/3238/bp.Kuma_1.0.jar<br />
braaropolis.Abot 1.0,http://darkcanuck.net/rumble/robots/braaropolis.Abot_1.0.jar<br />
brainfade.Fallen 0.63,http://www.robocoderepository.com/BotFiles/2250/brainfade.Fallen_0.63.jar<br />
brainfade.melee.Dusk 0.44,http://www.robocoderepository.com/BotFiles/2518/brainfade.melee.Dusk_0.44.jar<br />
buba.Archivist 0.1,http://www.robocoderepository.com/BotFiles/3899/buba.Archivist_0.1.jar<br />
buba.Buba 0.3,http://www.robocoderepository.com/BotFiles/3896/buba.Buba_0.3.jar<br />
bvh.fnr.Fenrir 0.36l,http://www.robocoderepository.com/BotFiles/1428/bvh.fnr.Fenrir_0.36l.jar<br />
bvh.frg.Friga 0.112dev,http://darkcanuck.net/rumble/robots/bvh.frg.Friga_0.112dev.jar<br />
bvh.fry.Freya 0.82,http://darkcanuck.net/rumble/robots/bvh.fry.Freya_0.82.jar<br />
bvh.hdr.Hodur 0.4,http://www.robocoderepository.com/BotFiles/1954/bvh.hdr.Hodur_0.4.jar<br />
bvh.loki.Loki 0.5,http://www.robocoderepository.com/BotFiles/885/bvh.loki.Loki_0.5.jar<br />
bvh.micro.Freya 0.3,http://www.robocoderepository.com/BotFiles/2815/bvh.micro.Freya_0.3.jar<br />
bvh.micro.Svadilfari 0.2,http://www.robocoderepository.com/BotFiles/1086/bvh.micro.Svadilfari_0.2.jar<br />
bvh.mini.Fenrir 0.39,http://www.robocoderepository.com/BotFiles/1429/bvh.mini.Fenrir_0.39.jar<br />
bvh.mini.Freya 0.55,http://darkcanuck.net/rumble/robots/bvh.mini.Freya_0.55.jar<br />
bvh.mini.Mjolnir 0.3,http://www.robocoderepository.com/BotFiles/2220/bvh.mini.Mjolnir_0.3.jar<br />
bvh.mini.Wodan 0.50,http://www.robocoderepository.com/BotFiles/2064/bvh.mini.Wodan_0.50.jar<br />
bvh.tyr.Tyr 1.74,http://www.robocoderepository.com/BotFiles/886/bvh.tyr.Tyr_1.74.jar<br />
bzdp.BoxCar 2.0,http://www.robocoderepository.com/BotFiles/3703/bzdp.BoxCar_2.0.jar<br />
bzdp.Pansy 2.1,http://www.robocoderepository.com/BotFiles/3726/bzdp.Pansy_2.1.jar<br />
caimano.Furia_Ceca 0.22,http://www.robocoderepository.com/BotFiles/1843/caimano.Furia_Ceca_0.22.jar<br />
cbot.agile.Nibbler 0.2,http://www.robocoderepository.com/BotFiles/1537/cbot.agile.Nibbler_0.2.jar<br />
cbot.cbot.CBot 0.8,http://www.robocoderepository.com/BotFiles/1375/cbot.cbot.CBot_0.8.jar<br />
cf.mini.Chiva 1.0,http://www.robocoderepository.com/BotFiles/2331/cf.mini.Chiva_1.0.jar<br />
cf.OldMan.OldManXP 0.1,http://www.robocoderepository.com/BotFiles/1968/cf.OldMan.OldManXP_0.1.jar<br />
cf.proto.Shiva 2.2,http://www.robocoderepository.com/BotFiles/2409/cf.proto.Shiva_2.2.jar<br />
cf.star.Star2 1.23,http://www.robocoderepository.com/BotFiles/2255/cf.star.Star2_1.23.jar<br />
ch.rhj.rbc.RHJ1 1.0,http://www.robocoderepository.com/BotFiles/1879/ch.rhj.rbc.RHJ1_1.0.jar<br />
CharlieN.Omega.Omega 1.03,http://www.robocoderepository.com/BotFiles/3503/CharlieN.Omega.Omega_1.03.jar<br />
chase.c.Wristwatch 1.0,http://www.csdgn.org/files/bots/chase.c.Wristwatch_1.0.jar<br />
chase.pm.Pytko 1.0,http://www.csdgn.org/files/bots/chase.pm.Pytko_1.0.jar<br />
chase.s2.Genesis 1.1,http://www.csdgn.org/files/bots/chase.s2.Genesis_1.1.jar<br />
chase.s2.Seraphim 2.0.9,http://www.csdgn.org/files/bots/chase.s2.Seraphim_2.0.9.jar<br />
chickenfuego.UrChicken2 1.0,http://www.robocoderepository.com/BotFiles/3422/chickenfuego.UrChicken2_1.0.jar<br />
cjk.Merkava 0.1.1,http://www.robocoderepository.com/BotFiles/2637/cjk.Merkava_0.1.1.jar<br />
cjk.Merkava 0.2.0,http://www.robocoderepository.com/BotFiles/2640/cjk.Merkava_0.2.0.jar<br />
cjk.Merkava 0.3.0,http://darkcanuck.net/rumble/robots/cjk.Merkava_0.3.0.jar<br />
cjm.chalk.Chalk 2.6.Be,http://scatterbright.com/robots/cjm.chalk.Chalk_2.6.Be.jar<br />
cjm.Charo 1.1,http://scatterbright.com/robots/cjm.Charo_1.1.jar<br />
cjm.Che 1.2,http://www.robocoderepository.com/BotFiles/2703/cjm.Che_1.2.jar<br />
cjm.Chomsky 1.5,http://scatterbright.com/robots/cjm.Chomsky_1.5.jar<br />
codemojo.nano.Woot 1.0,http://darkcanuck.net/rumble/robots/codemojo.nano.Woot_1.0.jar<br />
cs.ExclusionNano 1.1,http://www.csdgn.org/files/bots/cs.ExclusionNano_1.1.jar<br />
csm.NthGeneration 0.04,http://www.robocoderepository.com/BotFiles/1214/csm.NthGeneration_0.04.jar<br />
csp.Eagle 3.30,http://www.robocoderepository.com/BotFiles/2436/csp.Eagle_3.30.jar<br />
css.Delitioner 0.11,http://darkcanuck.net/rumble/robots/css.Delitioner_0.11.jar<br />
cx.BlestPain 1.41,http://www.robocoderepository.com/BotFiles/1671/cx.BlestPain_1.41.jar<br />
cx.CigaretBH 1.03,http://www.robocoderepository.com/BotFiles/1414/cx.CigaretBH_1.03.jar<br />
cx.Lacrimas 1.36,http://www.robocoderepository.com/BotFiles/1820/cx.Lacrimas_1.36.jar<br />
cx.micro.Blur 0.2,http://www.robocoderepository.com/BotFiles/2447/cx.micro.Blur_0.2.jar<br />
cx.micro.Smoke 0.96,http://www.robocoderepository.com/BotFiles/1037/cx.micro.Smoke_0.96.jar<br />
cx.micro.Spark 0.6,http://www.robocoderepository.com/BotFiles/1320/cx.micro.Spark_0.6.jar<br />
cx.mini.BlackSwans 0.60,http://www.robocoderepository.com/BotFiles/1158/cx.mini.BlackSwans_0.60.jar<br />
cx.mini.Cigaret 1.31,http://www.robocoderepository.com/BotFiles/1152/cx.mini.Cigaret_1.31.jar<br />
cx.mini.Nimrod 0.55,http://www.robocoderepository.com/BotFiles/1236/cx.mini.Nimrod_0.55.jar<br />
cx.nano.Smog 2.6,http://www.robocoderepository.com/BotFiles/1036/cx.nano.Smog_2.6.jar<br />
cx.Princess 1.0,http://www.robocoderepository.com/BotFiles/1343/cx.Princess_1.0.jar<br />
da.NewBGank 1.4,http://www.robocoderepository.com/BotFiles/3312/da.NewBGank_1.4.jar<br />
dam.MogBot 2.9,http://www.robocoderepository.com/BotFiles/555/dam.MogBot_2.9.jar<br />
dans.Cinnamon 1.2,http://www.robocoderepository.com/BotFiles/1976/dans.Cinnamon_1.2.jar<br />
darkcanuck.Gaff 1.50,http://darkcanuck.net/rumble/robots/darkcanuck.Gaff_1.50.jar<br />
darkcanuck.Holden 1.13a,http://darkcanuck.net/rumble/robots/darkcanuck.Holden_1.13a.jar<br />
darkcanuck.Pris 0.88,http://darkcanuck.net/rumble/robots/darkcanuck.Pris_0.88.jar<br />
davidalves.Firebird 0.25,http://davidalves.net/robocode/robots/davidalves.Firebird_0.25.jar<br />
davidalves.Phoenix 1.02,http://davidalves.net/robocode/robots/davidalves.Phoenix_1.02.jar<br />
davidalves.PhoenixOS 1.1,http://davidalves.net/robocode/robots/davidalves.PhoenixOS_1.1.jar<br />
davidalves.net.Duelist 0.1.6src,http://www.robocoderepository.com/BotFiles/1000/davidalves.net.Duelist_0.1.6src.jar<br />
davidalves.net.DuelistMicro 1.22,http://www.robocoderepository.com/BotFiles/1144/davidalves.net.DuelistMicro_1.22.jar<br />
davidalves.net.DuelistMicroMkII 1.1,http://www.robocoderepository.com/BotFiles/1281/davidalves.net.DuelistMicroMkII_1.1.jar<br />
davidalves.net.DuelistMini 1.1,http://www.robocoderepository.com/BotFiles/1181/davidalves.net.DuelistMini_1.1.jar<br />
davidalves.net.DuelistNano 1.0,http://www.robocoderepository.com/BotFiles/1272/davidalves.net.DuelistNano_1.0.jar<br />
dcs.Eater_of_Worlds 1.1.3-A,http://www.robocoderepository.com/BotFiles/2578/dcs.Eater_of_Worlds_1.1.3-A.jar<br />
dcs.Eater_of_Worlds_Mini 1.0,http://www.robocoderepository.com/BotFiles/2850/dcs.Eater_of_Worlds_Mini_1.0.jar<br />
dcs.PM.Eater_of_Worlds_PM 1.2,http://www.robocoderepository.com/BotFiles/2856/dcs.PM.Eater_of_Worlds_PM_1.2.jar<br />
de.erdega.robocode.Polyphemos 0.4,http://darkcanuck.net/rumble/robots/de.erdega.robocode.Polyphemos_0.4.jar<br />
deewiant.Anomaly 0.2,http://www.iki.fi/~deewiant/files/deewiant.Anomaly_0.2.jar<br />
deith.Czolgzilla 0.11,http://www.robocoderepository.com/BotFiles/3256/deith.Czolgzilla_0.11.jar<br />
demetrix.ForceMajeure 0.75,http://ever-rage.narod.ru/robowiki/demetrix.ForceMajeure_0.75.jar<br />
demetrix.nano.Neutrino 0.27,http://ever-rage.narod.ru/robowiki/demetrix.nano.Neutrino_0.27.jar<br />
demetrix.nano.SledgeHammer 0.22,http://ever-rage.narod.ru/robowiki/demetrix.nano.SledgeHammer_0.22.jar<br />
deo.CloudBot 1.3,http://robocoderepository.com/BotFiles/3644/deo.CloudBot_1.3.jar<br />
deo.FlowerBot 1.0,http://robocoderepository.com/BotFiles/3683/deo.FlowerBot_1.0.jar<br />
deo.virtual.RainbowBot 1.0,http://robocoderepository.com/BotFiles/3694/deo.virtual.RainbowBot_1.0.jar<br />
dft.Calliope 5.6,http://www.robocoderepository.com/BotFiles/237/dft.Calliope_5.6.jar<br />
dft.Cyanide 1.90,http://darkcanuck.net/rumble/robots/dft.Cyanide_1.90.jar<br />
dft.Cyprus 3.0,http://www.robocoderepository.com/BotFiles/377/dft.Cyprus_3.0.jar<br />
dft.Freddie 1.32,http://darkcanuck.net/rumble/robots/dft.Freddie_1.32.jar<br />
dft.Guppy 1.0,http://darkcanuck.net/rumble/robots/dft.Guppy_1.0.jar<br />
dft.Immortal 1.40,http://darkcanuck.net/rumble/robots/dft.Immortal_1.40.jar<br />
dft.Krazy 1.5,http://www.robocoderepository.com/BotFiles/2099/dft.Krazy_1.5.jar<br />
dft.Virgin 1.25,http://www.robocoderepository.com/BotFiles/1447/dft.Virgin_1.25.jar<br />
dggp.haiku.gpBot_0 1.1,http://www.robocoderepository.com/BotFiles/3154/dggp.haiku.gpBot_0_1.1.jar<br />
dittman.BlindSquirl Retired,http://home.comcast.net/~kokyunage/robocode/ugluk/dittman.BlindSquirl_Retired.jar<br />
djc.Aardvark 0.3.6,http://www.robocoderepository.com/BotFiles/652/djc.Aardvark_0.3.6.jar<br />
djdjdj.NanoSkunk10 1.0,http://davidjoerg.com/robocode/djdjdj.NanoSkunk10_1.0.jar<br />
dk.stable.Gorgatron 1.1,http://www.robocoderepository.com/BotFiles/2112/dk.stable.Gorgatron_1.1.jar<br />
dks.MicroDanMK2 1.0,http://darkcanuck.net/rumble/robots/dks.MicroDanMK2_1.0.jar<br />
DM.Capriite 3.7.2,http://www.robocoderepository.com/BotFiles/2989/DM.Capriite_3.7.2.jar<br />
DM.Chicken 4.0,http://www.robocoderepository.com/BotFiles/3020/DM.Chicken_4.0.jar<br />
DM.Mijit .3,http://www.robocoderepository.com/BotFiles/3043/DM.Mijit_.3.jar<br />
dmp.micro.Aurora 1.41,http://www.robocoderepository.com/BotFiles/853/dmp.micro.Aurora_1.41.jar<br />
dmp.nano.Eve 3.41,http://www.robocoderepository.com/BotFiles/842/dmp.nano.Eve_3.41.jar<br />
donjezza.Jezza 1.0,http://www.robocoderepository.com/BotFiles/3385/donjezza.Jezza_1.0.jar<br />
donjezza.Muncho 1.0,http://www.robocoderepository.com/BotFiles/3384/donjezza.Muncho_1.0.jar<br />
drd.Dreadknoght 0.9,http://www.robocoderepository.com/BotFiles/3835/drd.Dreadknoght_0.9.jar<br />
drm.CobraBora 1.12,http://www.robocoderepository.com/BotFiles/1146/drm.CobraBora_1.12.jar<br />
drm.Magazine 0.39,http://www.robocoderepository.com/BotFiles/989/drm.Magazine_0.39.jar<br />
ds.OoV4 0.3b,http://www.robocoderepository.com/BotFiles/2851/ds.OoV4_0.3b.jar<br />
dsw.StaticD 1.0,http://darkcanuck.net/rumble/robots/dsw.StaticD_1.0.jar<br />
dsx724.VSAB_EP3a 1.0,http://darkcanuck.net/rumble/robots/dsx724.VSAB_EP3a_1.0.jar<br />
dsx724.VSAB_EP3_ATR 1.1,http://www.robocoderepository.com/BotFiles/3432/dsx724.VSAB_EP3_ATR_1.1.jar<br />
dukie.Ambassador 1.0,http://www.robocoderepository.com/BotFiles/2845/dukie.Ambassador_1.0.jar<br />
dummy.micro.HummingBird 2.14,http://www.robocoderepository.com/BotFiles/369/dummy.micro.HummingBird_2.14.jar<br />
dummy.micro.Sparrow 2.5,http://www.robocoderepository.com/BotFiles/484/dummy.micro.Sparrow_2.5.jar<br />
dummy.mini.Parakeet 2.40,http://www.robocoderepository.com/BotFiles/400/dummy.mini.Parakeet_2.40.jar<br />
dvogon.GangBang 1.0,http://www.robocoderepository.com/BotFiles/3193/dvogon.GangBang_1.0.jar<br />
dy.LevelOne 2.0,http://www.robocoderepository.com/BotFiles/3452/dy.LevelOne_2.0.jar<br />
dz.Caedo 1.4,http://www.robocoderepository.com/BotFiles/1044/dz.Caedo_1.4.jar<br />
dz.GalbaMicro 0.11,http://www.robocoderepository.com/BotFiles/2482/dz.GalbaMicro_0.11.jar<br />
dz.GalbaMini 0.121,http://darkcanuck.net/rumble/robots/dz.GalbaMini_0.121.jar<br />
dz.MostlyHarmlessNano 2.1,http://www.robocoderepository.com/BotFiles/2166/dz.MostlyHarmlessNano_2.1.jar<br />
dz.OthoMicro 0.12,http://www.robocoderepository.com/BotFiles/2198/dz.OthoMicro_0.12.jar<br />
dz.OthoMini 0.15,http://www.robocoderepository.com/BotFiles/2221/dz.OthoMini_0.15.jar<br />
eat.HumblePieLite 1.0,http://www.robocoderepository.com/BotFiles/1088/eat.HumblePieLite_1.0.jar<br />
ebo.Sparse 0.02,http://www.4geeks.de/files/ebo.Sparse_0.02.jar<br />
ebo.Tahoe 1.1.79,http://www.4geeks.de/files/ebo.Tahoe_1.1.79.jar<br />
el.Attackr 0.1,http://darkcanuck.net/rumble/robots/el.Attackr_0.1.jar<br />
el.JumpShoot 0.2,http://www.robocoderepository.com/BotFiles/3360/el.JumpShoot_0.2.jar<br />
el33t.EL33tGangstarr2 2.0,http://www.robocoderepository.com/BotFiles/2069/el33t.EL33tGangstarr2_2.0.jar<br />
eld.Hmm 1.0,http://darkcanuck.net/rumble/robots/eld.Hmm_1.0.jar<br />
element.Earth 1.1,http://www.robocoderepository.com/BotFiles/3587/element.Earth_1.1.jar<br />
elloco.Flower 0.1r1,http://www.robocoderepository.com/BotFiles/3242/elloco.Flower_0.1r1.jar<br />
elloco.Kabuto 0.2r,http://www.robocoderepository.com/BotFiles/3229/elloco.Kabuto_0.2r.jar<br />
elvbot.ElverionBot 0.3,http://www.robocoderepository.com/BotFiles/3541/elvbot.ElverionBot_0.3.jar<br />
emp.Yngwie 1.11,http://www.robocoderepository.com/BotFiles/1928/emp.Yngwie_1.11.jar<br />
erdnis.Rover 0.3,http://www.free-games-fun.com/erdnis.Rover_0.3.jar<br />
eskimo.micro.Echo 0.1,http://robocoderepository.com/BotFiles/3969/eskimo.micro.Echo_0.1.jar<br />
et.Predator 1.8,http://www.robocoderepository.com/BotFiles/668/et.Predator_1.8.jar<br />
ethdsy.Malacka 2.4,http://www.robocoderepository.com/BotFiles/1159/ethdsy.Malacka_2.4.jar<br />
evd.X1 0.01,http://www.robocoderepository.com/BotFiles/3503/evd.X1_0.01.jar<br />
exauge.GateKeeper 1.1.121g,http://www.robocoderepository.com/BotFiles/3928/exauge.GateKeeper_1.1.121g.jar<br />
exauge.LemonDrop 1.6.130,http://www.robocoderepository.com/BotFiles/3911/exauge.LemonDrop_1.6.130.jar<br />
exauge.Leopard 1.1.019,http://www.robocoderepository.com/BotFiles/3917/exauge.Leopard_1.1.019.jar<br />
fala.robocode.FalaRobot 1.0,http://www.robocoderepository.com/BotFiles/3474/fala.robocode.FalaRobot_1.0.jar<br />
fcr.First 1.0,http://www.robocoderepository.com/BotFiles/3362/fcr.First_1.0.jar<br />
Fenix.FenixTrack 1.0,http://www.robocoderepository.com/BotFiles/1627/Fenix.FenixTrack_1.0.jar<br />
florent.FloatingTadpole 1.2.6,http://www.robocoderepository.com/BotFiles/2675/florent.FloatingTadpole_1.2.6.jar<br />
florent.small.LittleAngel 1.8,http://www.robocoderepository.com/BotFiles/2917/florent.small.LittleAngel_1.8.jar<br />
florent.test.Toad 0.14t,http://wesley3.free.fr/florent.test.Toad_0.14t.jar<br />
florent.XSeries.X2 0.17,http://wesley3.free.fr/florent.XSeries.X2_0.17.jar<br />
fm.claire 1.7,http://www.robocoderepository.com/BotFiles/2251/fm.claire_1.7.jar<br />
fm.mammillarias 1.3,http://www.robocoderepository.com/BotFiles/2238/fm.mammillarias_1.3.jar<br />
fnc.bandit.Bandit 5.2.0,http://www.robocoderepository.com/BotFiles/2155/fnc.bandit.Bandit_5.2.0.jar<br />
fnc.bandit2002.Bandit2002 4.0.2,http://www.robocoderepository.com/BotFiles/2202/fnc.bandit2002.Bandit2002_4.0.2.jar<br />
frag.FragBot 1.0,http://darkcanuck.net/rumble/robots/frag.FragBot_1.0.jar<br />
franzor.Lizt 1.3.1,http://pages.prodigy.net/franz1/house/franzor.Lizt_1.3.1.jar<br />
fromHell.CHCl3 0.0.1,http://fromhell.schreiende-stille.de/fromHell.CHCl3_0.0.1.jar<br />
fullsail.LaxativeTeaTwo 1.0,http://www.robocoderepository.com/BotFiles/3403/fullsail.LaxativeTeaTwo_1.0.jar<br />
fullsail.TimbotNoPrediction 1.0,http://darkcanuck.net/rumble/robots/fullsail.TimbotNoPrediction_1.0.jar<br />
fullsail.SweetTea 1.1,http://darkcanuck.net/rumble/robots/fullsail.SweetTea_1.1.jar<br />
fushi.PvP1.PvP1 2004-02-16,http://www.robocoderepository.com/BotFiles/2023/fushi.PvP1.PvP1_2004-02-16.jar<br />
fw.Number1 1.0b,http://www.dijitari.com/void/robocode/fw.Number1_1.0b.jar<br />
gadsky.Gadsky 1.01,http://www.robocoderepository.com/BotFiles/3595/gadsky.Gadsky_1.01.jar<br />
geep.mini.GPBotA 1.0,http://www.robocoderepository.com/BotFiles/2361/geep.mini.GPBotA_1.0.jar<br />
geep.mini.GPBotB 1.1,http://www.robocoderepository.com/BotFiles/2363/geep.mini.GPBotB_1.1.jar<br />
germ.TheMind .2,http://www.robocoderepository.com/BotFiles/2525/germ.TheMind_.2.jar<br />
gg.Squaraus 0.6,http://www.robocoderepository.com/BotFiles/1788/gg.Squaraus_0.6.jar<br />
gg.Wolverine 2.0,http://darkcanuck.net/rumble/robots/gg.Wolverine_2.0.jar<br />
gh.GresSuffurd 0.2.26,http://home.versatel.nl/gheijenk/robocode/jarfiles/gh.GresSuffurd_0.2.26.jar<br />
gh.GrubbmGrb 1.2.4,http://home.versatel.nl/gheijenk/robocode/jarfiles/gh.GrubbmGrb_1.2.4.jar<br />
gh.GrypRepetyf 0.13,http://www.robocoderepository.com/BotFiles/2650/gh.GrypRepetyf_0.13.jar<br />
gh.micro.Grinnik 0.7,http://www.robocoderepository.com/BotFiles/3208/gh.micro.Grinnik_0.7.jar<br />
gh.micro.GrubbmThree 0.9,http://www.robocoderepository.com/BotFiles/2444/gh.micro.GrubbmThree_0.9.jar<br />
gh.mini.Gruwel 0.9,http://www.robocoderepository.com/BotFiles/2511/gh.mini.Gruwel_0.9.jar<br />
gh.nano.Grofvuil 0.2,http://www.robocoderepository.com/BotFiles/2553/gh.nano.Grofvuil_0.2.jar<br />
gimp.GimpBot 0.1,http://www.robocoderepository.com/BotFiles/2434/gimp.GimpBot_0.1.jar<br />
gio.RealGioBot 1.0,http://www.robocoderepository.com/BotFiles/2521/gio.RealGioBot_1.0.jar<br />
gjr.Cephalosporin 0.2,http://www.robocoderepository.com/BotFiles/2240/gjr.Cephalosporin_0.2.jar<br />
gm.GaetanoA 2.15,http://www.robocoderepository.com/BotFiles/2188/gm.GaetanoA_2.15.jar<br />
goblin.Bender 2.4,http://www.robocoderepository.com/BotFiles/1871/goblin.Bender_2.4.jar<br />
grybgoofy.GoofyBot 0.10,http://www.robocoderepository.com/BotFiles/2196/grybgoofy.GoofyBot_0.10.jar<br />
gu.MicroScoob 1.3,http://www.robocoderepository.com/BotFiles/2086/gu.MicroScoob_1.3.jar<br />
gwah.GBotMarkIV 1.0,http://www.horula.ca/roborumble/participants/download.php?file=18<br />
gwah.GerryBotMkII 1.5.1,http://www.horula.ca/roborumble/participants/download.php?file=17<br />
hamilton.Hamilton 1.0,http://www.robocoderepository.com/BotFiles/1408/hamilton.Hamilton_1.0.jar<br />
hapiel.Spiral 0.1,http://robocoderepository.com/BotFiles/3997/hapiel.Spiral_0.1.jar<br />
hirataatsushi.Neo 1.6,http://www.robocoderepository.com/BotFiles/1081/hirataatsushi.Neo_1.6.jar<br />
hirataatsushi.Trinity 0.003,http://www.robocoderepository.com/BotFiles/1145/hirataatsushi.Trinity_0.003.jar<br />
homerbots.h1 1.0,http://www.robocoderepository.com/BotFiles/2999/homerbots.h1_1.0.jar<br />
hp.Athena 0.1,http://www.robocoderepository.com/BotFiles/3415/hp.Athena_0.1.jar<br />
hvilela.HVilela 0.9,http://henrique.vilela.googlepages.com/hvilela.HVilela_0.9.jar<br />
ins.MobyNano 0.8,http://www.robocoderepository.com/BotFiles/939/ins.MobyNano_0.8.jar<br />
intruder.PrairieWolf 2.61,http://darkcanuck.net/rumble/robots/intruder.PrairieWolf_2.61.jar<br />
ivor.prophet.Prophet 0.01,http://www.ivan.php5.sk/ivor.prophet.Prophet_0.01.jar<br />
jaara.LambdaBot 1.1,http://www.robocoderepository.com/BotFiles/3514/jaara.LambdaBot_1.1.jar<br />
jab.avk.ManuelGallegus 0.6,http://darkcanuck.net/rumble/robots/jab.avk.ManuelGallegus_0.6.jar<br />
jab.DiamondStealer 5,http://darkcanuck.net/rumble/robots/jab.DiamondStealers_5.jar<br />
jab.micro.Sanguijuela 0.8,http://darkcanuck.net/rumble/robots/jab.micro.Sanguijuela_0.8.jar<br />
janm.Jammy 1.0,http://www.robocoderepository.com/BotFiles/3543/janm.Jammy_1.0.jar<br />
jam.micro.RaikoMicro 1.44,http://www.robocoderepository.com/BotFiles/1983/jam.micro.RaikoMicro_1.44.jar<br />
jam.mini.Raiko 0.43,http://www.robocoderepository.com/BotFiles/1922/jam.mini.Raiko_0.43.jar<br />
jam.RaikoMX 0.32,http://www.robocoderepository.com/BotFiles/1961/jam.RaikoMX_0.32.jar<br />
japs.Serenity 1.0,http://www.robocoderepository.com/BotFiles/2217/japs.Serenity_1.0.jar<br />
japs.Sjonniebot 0.9.1,http://www.robocoderepository.com/BotFiles/2203/japs.Sjonniebot_0.9.1.jar<br />
jasolo.Sonda 0.55,http://www.robocoderepository.com/BotFiles/1534/jasolo.Sonda_0.55.jar<br />
jaw.Mouse 0.11,http://www.robocoderepository.com/BotFiles/2472/jaw.Mouse_0.11.jar<br />
jaw.KarenCain 0.11,http://www.robocoderepository.com/BotFiles/2474/jaw.KarenCain_0.11.jar<br />
jaybot.adv.bots.JayBot 2.0,http://darkcanuck.net/rumble/robots/jaybot.adv.bots.JayBot_2.0.jar<br />
jaybot.bots.Oddball 4.0,http://darkcanuck.net/rumble/robots/jaybot.bots.Oddball_4.0.jar<br />
jbot.Rabbit2 1.1,http://darkcanuck.net/rumble/robots/jbot.Rabbit2_1.1.jar<br />
jcs.AutoBot 4.2.1,http://www.robocoderepository.com/BotFiles/2616/jcs.AutoBot_4.2.1.jar<br />
jcs.Decepticon 2.5.3,http://www.robocoderepository.com/BotFiles/2620/jcs.Decepticon_2.5.3.jar<br />
jcs.Megatron 1.2,http://www.robocoderepository.com/BotFiles/2632/jcs.Megatron_1.2.jar<br />
jcs.Seth 1.8,http://darkcanuck.net/rumble/robots/jcs.Seth_1.8.jar<br />
jcw.ArcherOne 1.0,http://darkcanuck.net/rumble/robots/jcw.ArcherOne_1.0.jar<br />
jekl.DarkHallow .90.9,http://www.robocoderepository.com/BotFiles/2296/jekl.DarkHallow_.90.9.jar<br />
jekl.Jekyl .70,http://www.robocoderepository.com/BotFiles/1837/jekl.Jekyl_.70.jar<br />
jekl.mini.BlackPearl .91,http://www.robocoderepository.com/BotFiles/1875/jekl.mini.BlackPearl_.91.jar<br />
jep.nano.Hawkwing 0.4.1,http://www.robocoderepository.com/BotFiles/1561/jep.nano.Hawkwing_0.4.1.jar<br />
jep.nano.Hotspur 0.1,http://www.robocoderepository.com/BotFiles/1877/jep.nano.Hotspur_0.1.jar<br />
jep.Terrible 0.4.1,http://www.robocoderepository.com/BotFiles/1536/jep.Terrible_0.4.1.jar<br />
jeremyreeder.Vincent 2011.12.09,http://www.robocoderepository.com/BotFiles/3993/jeremyreeder.Vincent_2011.12.09.jar<br />
jf.Dodger 1.1,http://keenehs.dyndns.org:90/rumble/robots/jf.Dodger_1.1.jar<br />
jf.Dodger 1.3,http://keenehs.dyndns.org:90/rumble/robots/jf.Dodger_1.3.jar<br />
jgap.JGAP12584 1.0,http://www.robocoderepository.com/BotFiles/3383/jgap.JGAP12584_1.0.jar<br />
jgap.JGAP130166 1.0,http://www.robocoderepository.com/BotFiles/3371/jgap.JGAP130166_1.0.jar<br />
jgap.JGAP23423 1.0,http://www.robocoderepository.com/BotFiles/3378/jgap.JGAP23423_1.0.jar<br />
jgap.JGAP6139 1.0,http://www.robocoderepository.com/BotFiles/3372/jgap.JGAP6139_1.0.jar<br />
jgap.JGAP7247_2 1.0,http://www.robocoderepository.com/BotFiles/3382/jgap.JGAP7247_2_1.0.jar<br />
jgap.JGAP7958 1.0,http://www.robocoderepository.com/BotFiles/3373/jgap.JGAP7958_1.0.jar<br />
jje.BagPuss 1.2,http://darkcanuck.net/rumble/robots/jje.BagPuss_1.2.jar<br />
jk.mega.DrussGT 1.8.16b,http://www.minifly.rchomepage.com/robocode/jk.mega.DrussGT_1.8.16b.jar<br />
jk.micro.Toorkild 0.2.4b,http://www.minifly.rchomepage.com/robocode/jk.micro.Toorkild_0.2.4b.jar<br />
jk.mini.CunobelinDC 0.6,https://sites.google.com/site/jkflying/jk.mini.CunobelinDC_0.6.jar<br />
jk.precise.Wintermute 0.7,http://www.minifly.rchomepage.com/robocode/jk.precise.Wintermute_0.7.jar<br />
jmcd.BeoWulf 2.8,http://www.robocoderepository.com/BotFiles/1377/jmcd.BeoWulf_2.8.jar<br />
joe.ADinosaur 1.0,http://www.robocoderepository.com/BotFiles/2822/joe.ADinosaur_1.0.jar<br />
josago.Jorgito 0.10,http://www.robocoderepository.com/BotFiles/4000/josago.Jorgito_0.10.jar<br />
jp.Perpy 16.0,http://www.robocoderepository.com/BotFiles/3001/jp.Perpy_16.0.jar<br />
jp.SineWall 1.0,http://www.robocoderepository.com/BotFiles/2968/jp.SineWall_1.0.jar<br />
jrm.Test0 1.0,http://www.robocoderepository.com/BotFiles/3636/jrm.Test0_1.0.jar<br />
js.PinBall 1.6,http://www.robocoderepository.com/BotFiles/684/js.PinBall_1.6.jar<br />
jsal.Jsalbot 1.0,http://jeremybubs.googlepages.com/jsal.Jsalbot_1.0.jar<br />
jt.SpearmintCT Alpha,http://www.robocoderepository.com/BotFiles/2164/jt.SpearmintCT_Alpha.jar<br />
justin.DemonicRage 3.20,http://sites.google.com/site/justinsitehere/file-cabinet/justin.DemonicRage_3.20.jar<br />
jw.Booring 1.11,http://www.robocoderepository.com/BotFiles/1250/jw.Booring_1.11.jar<br />
jwst.DAD.DarkAndDarker 1.1,http://darkcanuck.net/rumble/robots/jwst.DAD.DarkAndDarker_1.1.jar<br />
kanishk.Fr0z3n 1.1,http://darkcanuck.net/rumble/robots/kanishk.Fr0z3n_1.1.jar<br />
kano.gamma.KanoGamma 1.8,http://www.robocoderepository.com/BotFiles/1098/kano.gamma.KanoGamma_1.8.jar<br />
kawam.kmBot9 1.0,http://www.robocoderepository.com/BotFiles/967/kawam.kmBot9_1.0.jar<br />
kawigi.f.FhqwhgadsMicro 1.0,http://www.robocoderepository.com/BotFiles/1673/kawigi.f.FhqwhgadsMicro_1.0.jar<br />
kawigi.micro.Shiz 1.1,http://www.robocoderepository.com/BotFiles/2007/kawigi.micro.Shiz_1.1.jar<br />
kawigi.mini.Coriantumr 1.1,http://www.robocoderepository.com/BotFiles/1988/kawigi.mini.Coriantumr_1.1.jar<br />
kawigi.mini.Fhqwhgads 1.1,http://www.robocoderepository.com/BotFiles/1604/kawigi.mini.Fhqwhgads_1.1.jar<br />
kawigi.nano.FunkyChicken 1.1,http://www.robocoderepository.com/BotFiles/1512/kawigi.nano.FunkyChicken_1.1.jar<br />
kawigi.nano.ThnikkaBot 0.9,http://www.robocoderepository.com/BotFiles/2059/kawigi.nano.ThnikkaBot_0.9.jar<br />
kawigi.robot.Girl 1.2,http://www.robocoderepository.com/BotFiles/2124/kawigi.robot.Girl_1.2.jar<br />
kawigi.sbf.Barracuda 1.0,http://www.robocoderepository.com/BotFiles/1535/kawigi.sbf.Barracuda_1.0.jar<br />
kawigi.sbf.FloodHT 0.9.2,http://www.robocoderepository.com/BotFiles/1552/kawigi.sbf.FloodHT_0.9.2.jar<br />
kawigi.sbf.FloodMicro 1.5,http://www.robocoderepository.com/BotFiles/1381/kawigi.sbf.FloodMicro_1.5.jar<br />
kawigi.sbf.FloodMini 1.4,http://www.robocoderepository.com/BotFiles/1462/kawigi.sbf.FloodMini_1.4.jar<br />
kawigi.sbf.FloodNano 1.2,http://www.robocoderepository.com/BotFiles/1421/kawigi.sbf.FloodNano_1.2.jar<br />
kawigi.sbf.FloodSonnet 0.9,http://www.robocoderepository.com/BotFiles/1779/kawigi.sbf.FloodSonnet_0.9.jar<br />
kawigi.sbf.Teancum 1.3,http://www.robocoderepository.com/BotFiles/1470/kawigi.sbf.Teancum_1.3.jar<br />
kawigi.spare.SpareParts 0.7.6nosnd,http://www.robocoderepository.com/BotFiles/1335/kawigi.spare.SpareParts_0.7.6nosnd.jar<br />
kc.micro.Needle 0.101,http://www.robocoderepository.com/BotFiles/3379/kc.micro.Needle_0.101.jar<br />
kc.micro.Thorn 1.252,http://sites.google.com/site/kevcsite/robocode/kc.micro.Thorn_1.252.jar<br />
kc.micro.WaveShark 0.31,http://www.robocoderepository.com/BotFiles/3822/kc.micro.WaveShark_0.31.jar<br />
kc.mini.Vyper 0.311,http://darkcanuck.net/rumble/robots/kc.mini.Vyper_0.311.jar<br />
kc.nano.Splinter 1.2,http://darkcanuck.net/rumble/robots/kc.nano.Splinter_1.2.jar<br />
kc.serpent.Hydra 0.21,http://darkcanuck.net/rumble/robots/kc.serpent.Hydra_0.21.jar<br />
kc.serpent.WaveSerpent 2.11,http://sites.google.com/site/kevcsite/robocode/kc.serpent.WaveSerpent_2.11.jar<br />
kcn.percept.PerceptBot 2.3,http://www.robocoderepository.com/BotFiles/1075/kcn.percept.PerceptBot_2.3.jar<br />
kcn.unnamed.Unnamed 1.21,http://www.robocoderepository.com/BotFiles/1969/kcn.unnamed.Unnamed_1.21.jar<br />
kenran.mega.Pantheist 1.1,http://sites.google.com/site/kenranbots/robocode/kenran.mega.Pantheist_1.1.jar<br />
kid.Gladiator .7.2,http://darkcanuck.net/rumble/robots/kid.Gladiator_.7.2.jar<br />
kid.Toa .0.5,http://rednaxela-robocode.dyndns.org/data/robot_archive/kid.Toa_.0.5.jar<br />
KiraNL.Chupacabra 0.5,http://sandbox-project.nl/robocode/KiraNL.Chupacabra_0.5.jar<br />
KiraNL.ChupaLite 0.4,http://sandbox-project.nl/robocode/KiraNL.ChupaLite_0.4.jar<br />
KiraNL.SpaceKees 0.1,http://sandbox-project.nl/robocode/KiraNL.SpaceKees_0.1.jar<br />
kinsen.melee.Angsaichmophobia 1.8c,http://sites.google.com/site/dcvqksyb/robocode/kinsen.melee.Angsaichmophobia_1.8c.jar<br />
kinsen.nano.Hoplomachy 1.6,http://sites.google.com/site/dcvqksyb/robocode/kinsen.nano.Hoplomachy_1.6.jar<br />
kinsen.nano.Quarrelet 1.0,http://sites.google.com/site/dcvqksyb/robocode/kinsen.nano.Quarrelet_1.0.jar<br />
kinsen.nano.Senticous 1.0,http://sites.google.com/site/dcvqksyb/robocode/kinsen.nano.Senticous_1.0.jar<br />
kjc.etc.Dharok 1.0,http://www.robocoderepository.com/BotFiles/3293/kjc.etc.Dharok_1.0.jar<br />
kjc.MailManX 2.0,http://www.robocoderepository.com/BotFiles/3288/kjc.MailManX_2.0.jar<br />
kjc.Karaykan 1.0,http://www.robocoderepository.com/BotFiles/3289/kjc.Karaykan_1.0.jar<br />
klein.GottesKrieger 1.1,http://www.robocoderepository.com/BotFiles/3258/klein.GottesKrieger_1.1.jar<br />
Krabb.fe4r.Fe4r 0.4,http://www.robocoderepository.com/BotFiles/2766/Krabb.fe4r.Fe4r_0.4.jar<br />
Krabb.sliNk.Garm 0.9u,http://designnj.de/roboking/Krabb.sliNk.Garm_0.9u.jar<br />
Krabb.krabby.Krabby 1.18b,http://darkcanuck.net/rumble/robots/Krabb.krabby.Krabby_1.18b.jar<br />
Krabb.krabby2.Krabby2 1.9o,http://darkcanuck.net/rumble/robots/Krabb.krabby2.Krabby2_1.9o.jar<br />
krillr.mini.JointStrike 2.0.0,http://darkcanuck.net/rumble/robots/krillr.mini.JointStrike_2.0.0.jar<br />
krillr.mega.Psyche 0.0.3,http://darkcanuck.net/rumble/robots/krillr.mega.Psyche_0.0.3.jar<br />
krzysiek.robbo2.Robbo 1.0.0,http://darkcanuck.net/rumble/robots/krzysiek.robbo2.Robbo_1.0.0.jar<br />
kurios.DOSexe .9a,http://www.kuriosly.com/roborumble/kurios.DOSexe_.9a.jar<br />
kurios.DOSexe .9b,http://www.kuriosly.com/roborumble/kurios.DOSexe_.9b.jar<br />
kvk.HebusLeTroll 0.41,http://www.robocoderepository.com/BotFiles/2125/kvk.HebusLeTroll_0.41.jar<br />
labg.Cataclysm 2.05,http://www.robocoderepository.com/BotFiles/2399/labg.Cataclysm_2.05.jar<br />
lancel.Lynx 1.09,http://www.robocoderepository.com/BotFiles/3992/lancel.Lynx_1.09.jar<br />
lazarecki.mega.PinkerStinker 0.7,http://www.robocoderepository.com/BotFiles/3838/lazarecki.mega.PinkerStinker_0.7.jar<br />
leb.ShootAnArrow 0.1,http://www.robocoderepository.com/BotFiles/2648/leb.ShootAnArrow_0.1.jar<br />
lechu.Ala 0.0.4,http://www.robocoderepository.com/BotFiles/3497/lechu.Ala_0.0.4.jar<br />
lechu.Lechu 1.1,http://www.robocoderepository.com/BotFiles/3480/lechu.Lechu_1.1.jar<br />
lion.Kresnanano 1.0,http://www.robocoderepository.com/BotFiles/2295/lion.Kresnanano_1.0.jar<br />
lk.nano.Avesnar 1.1,http://www.robocoderepository.com/BotFiles/1597/lk.nano.Avesnar_1.1.jar<br />
lorneswork.Predator 1.0,http://www.robocoderepository.com/BotFiles/2609/lorneswork.Predator_1.0.jar<br />
lrem.Spectre 0.4.4,http://www.robocoderepository.com/BotFiles/2253/lrem.Spectre_0.4.4.jar<br />
lrem.magic.TormentedAngel Antiquitie,http://maxnet.org.pl/~lrem/lrem.magic.TormentedAngel_Antiquitie.jar<br />
lrem.micro.MoggFanatic 0.2,http://www.robocoderepository.com/BotFiles/2639/lrem.micro.MoggFanatic_0.2.jar<br />
lrem.micro.FalseProphet Alpha,http://www.robocoderepository.com/BotFiles/2415/lrem.micro.FalseProphet_Alpha.jar<br />
lrem.quickhack.QuickHack 1.0,http://www.robocoderepository.com/BotFiles/2555/lrem.quickhack.QuickHack_1.0.jar<br />
lunchie.Lunchbox 0.93,http://darkcanuck.net/rumble/robots/lunchie.Lunchbox_0.93.jar<br />
lw.LuthersTest 0.1,http://darkcanuck.net/rumble/robots/lw.LuthersTest_0.1.jar<br />
m3thos.Eva00 1.1,http://darkcanuck.net/rumble/robots/m3thos.Eva00_1.1.jar<br />
m3thos.Eva02 0.7.1,http://darkcanuck.net/rumble/robots/m3thos.Eva02_0.7.1.jar<br />
m3thos.mini.Eva01 0.5.5,http://darkcanuck.net/rumble/robots/m3thos.mini.Eva01_0.5.5.jar<br />
madmath.Cow 0.1.1,http://www.robocoderepository.com/BotFiles/3476/madmath.Cow_0.1.1.jar<br />
marcinek.TopGun 1.3,http://www.robocoderepository.com/BotFiles/3458/marcinek.TopGun_1.3.jar<br />
marksteam.Phoenix 1.0,http://www.robocoderepository.com/BotFiles/2749/marksteam.Phoenix_1.0.jar<br />
matt.advanced.Katana 1.0,http://www.robocoderepository.com/BotFiles/2498/matt.advanced.Katana_1.0.jar<br />
matt.BlueMind 0.8.00,http://www.robocoderepository.com/BotFiles/2685/matt.BlueMind_0.8.00.jar<br />
matt.UnderDark3 2.4.34,http://www.robocoderepository.com/BotFiles/2485/matt.UnderDark3_2.4.34.jar<br />
matt.UnderDark4 0.4.00,http://www.robocoderepository.com/BotFiles/2644/matt.UnderDark4_0.4.00.jar<br />
mbh.Mbh 0.1,http://www.robocoderepository.com/BotFiles/3365/mbh.Mbh_0.1.jar<br />
mbro.BelajarBot 0.0.3,http://www.robocoderepository.com/BotFiles/2471/mbro.BelajarBot_0.0.3.jar<br />
mbro.Detektor3 0.1.1,http://www.robocoderepository.com/BotFiles/2478/mbro.Detektor3_0.1.1.jar<br />
mc.Messapia 0.1.8,http://www.robocoderepository.com/BotFiles/2223/mc.Messapia_0.1.8.jar<br />
mcb.Audace 1.3,http://www.robocoderepository.com/BotFiles/3424/mcb.Audace_1.3.jar<br />
md.November 1.0,http://www.robocoderepository.com/BotFiles/1004/md.November_1.0.jar<br />
md.Pasta 1.1,http://www.robocoderepository.com/BotFiles/1014/md.Pasta_1.1.jar<br />
md.VelociRaptor 1.3,http://www.robocoderepository.com/BotFiles/232/md.VelociRaptor_1.3.jar<br />
mdouet.BotKicker 2.0,http://www.robocoderepository.com/BotFiles/1478/mdouet.BotKicker_2.0.jar<br />
metal.small.MCool 1.21,http://www.robocoderepository.com/BotFiles/1698/metal.small.MCool_1.21.jar<br />
metal.small.dna2.MCoolDNA 1.5,http://www.robocoderepository.com/BotFiles/2354/metal.small.dna2.MCoolDNA_1.5.jar<br />
mk.Alpha 0.2.1,http://darkcanuck.net/rumble/robots/mk.Alpha_0.2.1.jar<br />
mladjo.AIR 0.7,http://www.robocoderepository.com/BotFiles/3187/mladjo.AIR_0.7.jar<br />
mladjo.GnuKlub 0.1,http://darkcanuck.net/rumble/robots/mladjo.GnuKlub_0.1.jar<br />
mladjo.Grrrrr 0.9,http://www.robocoderepository.com/BotFiles/3189/mladjo.Grrrrr_0.9.jar<br />
mladjo.iRobot 0.3,http://www.robocoderepository.com/BotFiles/3149/mladjo.iRobot_0.3.jar<br />
mladjo.Startko 1.0,http://www.robocoderepository.com/BotFiles/3186/mladjo.Startko_1.0.jar<br />
mld.DustBunny 3.8,http://www.robocoderepository.com/BotFiles/3650/mld.DustBunny_3.8.jar<br />
mld.Infinity 2.2,http://www.robocoderepository.com/BotFiles/3591/mld.Infinity_2.2.jar<br />
mld.LittleBlackBook 1.69c,http://www.robocoderepository.com/BotFiles/3873/mld.LittleBlackBook_1.69c.jar<br />
mld.Moebius 2.9.3,http://www.robocoderepository.com/BotFiles/3634/mld.Moebius_2.9.3.jar<br />
mld.Wisdom 1.0,http://www.robocoderepository.com/BotFiles/3640/mld.Wisdom_1.0.jar<br />
mmb.Roskilde 0.5,http://www.robocoderepository.com/BotFiles/3965/mmb.Roskilde_0.5.jar<br />
mme.NikeEnhanced 2.0,http://www.robocoderepository.com/BotFiles/2828/mme.NikeEnhanced_2.0.jar<br />
mn.Combat 1.0,http://www.robocoderepository.com/BotFiles/2351/mn.Combat_1.0.jar<br />
mn.WarMachine 1.1,http://www.robocoderepository.com/BotFiles/2574/mn.WarMachine_1.1.jar<br />
mnt.AHEB 0.6a,http://www.robocoderepository.com/BotFiles/2417/mnt.AHEB_0.6a.jar<br />
mnt.SurferBot 0.2.5,http://www.robocoderepository.com/BotFiles/2433/mnt.SurferBot_0.2.5.jar<br />
morbid.MorbidPriest 1.0,http://www.robocoderepository.com/BotFiles/1758/morbid.MorbidPriest_1.0.jar<br />
mrm.MightyMoose .2,http://darkcanuck.net/rumble/robots/mrm.MightyMoose_.2.jar<br />
ms.Ares 0.19,http://www.robocoderepository.com/BotFiles/730/ms.Ares_0.19.jar<br />
mue.Ascendant 1.2.27,http://mue.sonar-echo.de/robocode/mue.Ascendant_1.2.27.jar<br />
mue.Hyperion 0.8,http://www.robocoderepository.com/BotFiles/2224/mue.Hyperion_0.8.jar<br />
muf.CrazyKitten 0.9,http://www.robocoderepository.com/BotFiles/1946/muf.CrazyKitten_0.9.jar<br />
mwj.A1176183 1.0,http://robocode.rleach.id.au/mwj.A1176183_1.0.jar<br />
myl.micro.Avipes 1.00,http://www.robocoderepository.com/BotFiles/1347/myl.micro.Avipes_1.00.jar<br />
myl.micro.NekoNinja 1.30,http://www.robocoderepository.com/BotFiles/944/myl.micro.NekoNinja_1.30.jar<br />
myl.micro.Predator 1.50,http://www.robocoderepository.com/BotFiles/1097/myl.micro.Predator_1.50.jar<br />
myl.micro.Troodon 1.10,http://www.robocoderepository.com/BotFiles/1226/myl.micro.Troodon_1.10.jar<br />
myl.nano.Graviton 1.10,http://www.robocoderepository.com/BotFiles/770/myl.nano.Graviton_1.10.jar<br />
myl.nano.Kakuru 1.20,http://www.robocoderepository.com/BotFiles/1330/myl.nano.Kakuru_1.20.jar<br />
myl.nano.KomoriNinja 1.1,http://www.robocoderepository.com/BotFiles/978/myl.nano.KomoriNinja_1.1.jar<br />
mym.EdgeStalker 1.0,http://www.robocoderepository.com/BotFiles/3956/mym.EdgeStalker_1.0.jar<br />
mz.Adept 2.65,http://www.robocoderepository.com/BotFiles/2090/mz.Adept_2.65.jar<br />
mz.AdeptBSB 1.03,http://www.robocoderepository.com/BotFiles/2113/mz.AdeptBSB_1.03.jar<br />
mz.Movement 1.8,http://www.robocoderepository.com/BotFiles/2145/mz.Movement_1.8.jar<br />
mz.NanoDeath 2.56,http://www.robocoderepository.com/BotFiles/2010/mz.NanoDeath_2.56.jar<br />
mz.NanoGod 2.02,http://www.robocoderepository.com/BotFiles/1996/mz.NanoGod_2.02.jar<br />
nammyung.ModelT 0.23,http://www.robocoderepository.com/BotFiles/969/nammyung.ModelT_0.23.jar<br />
nanoskank.NanoSkank 1.0,http://darkcanuck.net/rumble/robots/nanoskank.NanoSkank_1.0.jar<br />
nat.BlackHole 2.0gamma,http://nat.robothai.net/robots/nat.BlackHole_2.0gamma.jar<br />
nat.micro.NP 1.34,http://nat.robothai.net/robots/nat.micro.NP_1.34.jar<br />
nat.micro.Reepicheep 0.1a,http://nat.robothai.net/robots/nat.micro.Reepicheep_0.1a.jar<br />
nat.nano.Ocnirp 1.73,http://nat.robothai.net/robots/nat.nano.Ocnirp_1.73.jar<br />
nat.nano.OcnirpPM 1.0,http://nat.robothai.net/robots/nat.nano.OcnirpPM_1.0.jar<br />
nat.nano.OcnirpSNG 1.0b,http://nat.robothai.net/robots/nat.nano.OcnirpSNG_1.0b.jar<br />
nat.Samekh 0.4,http://nat.robothai.net/robots/nat.Samekh_0.4.jar<br />
ncj.MoxieBot 1.0,http://www.robocoderepository.com/BotFiles/4003/ncj.MoxieBot_1.0.jar<br />
ndn.DyslexicMonkey 1.1,http://www.robocoderepository.com/BotFiles/1141/ndn.DyslexicMonkey_1.1.jar<br />
NDH.GuessFactor 1.0, http://www.robocoderepository.com/BotFiles/3949/NDH.GuessFactor_1.0.jar<br />
ne.Chimera 1.2,http://www.robocoderepository.com/BotFiles/3276/ne.Chimera_1.2.jar<br />
nexus.One 1.0,http://darkcanuck.net/rumble/robots/nexus.One_1.0.jar<br />
nexus.Prototype 1.0,http://darkcanuck.net/rumble/robots/nexus.Prototype_1.0.jar<br />
nic.Nicator 2.4,http://www.robocoderepository.com/BotFiles/193/nic.Nicator_2.4.jar<br />
nic.SnippetBot 1.0,http://www.robocoderepository.com/BotFiles/286/nic.SnippetBot_1.0.jar<br />
nkn.mini.Jskr0 0.1,http://www.robocoderepository.com/BotFiles/3852/nkn.mini.Jskr0_0.1.jar<br />
NG.LegatusLegionis 1.0,http://www.robocoderepository.com/BotFiles/3888/NG.LegatusLegionis_1.0.jar<br />
NG.LegatusLegionis 1.1,http://www.robocoderepository.com/BotFiles/3889/NG.LegatusLegionis_1.1.jar<br />
non.mega.NaN 0.1,http://www.robocoderepository.com/BotFiles/1960/non.mega.NaN_0.1.jar<br />
non.mega.NoName 0.0,http://www.robocoderepository.com/BotFiles/1957/non.mega.NoName_0.0.jar<br />
Noran.BitchingElk 0.054,http://www.robocoderepository.com/BotFiles/1855/Noran.BitchingElk_0.054.jar<br />
Noran.RandomTargeting 0.02,http://www.robocoderepository.com/BotFiles/1849/Noran.RandomTargeting_0.02.jar<br />
nova.Snow 1.0,http://www.robocoderepository.com/BotFiles/3623/nova.Snow_1.0.jar<br />
ntc.Cannon 1.12test,http://www.robocoderepository.com/BotFiles/3815/ntc.Cannon_1.12test.jar<br />
ntc.Evader 1.2,http://www.robocoderepository.com/BotFiles/3355/ntc.Evader_1.2.jar<br />
ntc.Knowledge 1.1,http://www.robocoderepository.com/BotFiles/3354/ntc.Knowledge_1.1.jar<br />
ntc.Lasers.Lasers 0.9,http://www.robocoderepository.com/BotFiles/3359/ntc.Lasers.Lasers_0.9.jar<br />
ntc.Plains 0.9,http://www.robocoderepository.com/BotFiles/3381/ntc.Plains_0.9.jar<br />
ntc.Swim 0.9,http://www.robocoderepository.com/BotFiles/3820/ntc.Swim_0.9.jar<br />
ntw.Sighup 1.5,http://darkcanuck.net/rumble/robots/ntw.Sighup_1.5.jar<br />
ntw.Sigsys 1.6,http://darkcanuck.net/rumble/robots/ntw.Sigsys_1.6.jar<br />
nz.jdc.micro.HedgehogGF 1.3,http://www.robocoderepository.com/BotFiles/3626/nz.jdc.micro.HedgehogGF_1.3.jar<br />
nz.jdc.micro.HedgehogP 1.2,http://www.robocoderepository.com/BotFiles/3622/nz.jdc.micro.HedgehogP_1.2.jar<br />
nz.jdc.nano.NeophytePattern 1.0,http://www.robocoderepository.com/BotFiles/3578/nz.jdc.nano.NeophytePattern_1.0.jar<br />
nz.jdc.nano.NeophytePRAL 1.2,http://www.robocoderepository.com/BotFiles/3568/nz.jdc.nano.NeophytePRAL_1.2.jar<br />
nz.jdc.nano.NeophyteSRAL 1.2,http://www.robocoderepository.com/BotFiles/3567/nz.jdc.nano.NeophyteSRAL_1.2.jar<br />
oa.weak.BotherBot 0.1,http://www.robocoderepository.com/BotFiles/2956/oa.weak.BotherBot_0.1.jar<br />
oa.weak.FlyMk1 0.1,http://www.robocoderepository.com/BotFiles/2958/oa.weak.FlyMk1_0.1.jar<br />
ola.Puffin 1.0,http://www.robocoderepository.com/BotFiles/3380/ola.Puffin_1.0.jar<br />
oog.Caligula 1.0,http://www.robocoderepository.com/BotFiles/3957/oog.Caligula_1.0.jar<br />
oog.melee.Capulet 0.1,http://www.robocoderepository.com/BotFiles/3765/oog.melee.Capulet_0.1.jar<br />
oog.melee.CapuletDroid 1.0,http://www.robocoderepository.com/BotFiles/3829/oog.melee.CapuletDroid_1.0.jar<br />
oog.melee.Mercutio 1.0,http://www.robocoderepository.com/BotFiles/3848/oog.melee.Mercutio_1.0.jar<br />
oog.micro.MagicD3 0.41,http://www.robocoderepository.com/BotFiles/3801/oog.micro.MagicD3_0.41.jar<br />
oog.micro.Maui 1.1,http://www.robocoderepository.com/BotFiles/3779/oog.micro.Maui_1.1.jar<br />
oog.micro.SavantMicro 1.0,http://www.robocoderepository.com/BotFiles/3958/oog.micro.SavantMicro_1.0.jar<br />
oog.nano.Fuatisha 1.0,http://www.robocoderepository.com/BotFiles/3720/oog.nano.Fuatisha_1.0.jar<br />
oog.nano.MagicD2 2.4,http://www.robocoderepository.com/BotFiles/3749/oog.nano.MagicD2_2.4.jar<br />
oog.nano.SavantVS 1.1,http://www.robocoderepository.com/BotFiles/3714/oog.nano.SavantVS_1.1.jar<br />
oog.nano.SavantWS 0.1,http://www.robocoderepository.com/BotFiles/3709/oog.nano.SavantWS_0.1.jar<br />
pa.Improved 1.1,http://darkcanuck.net/rumble/robots/pa.Improved_1.1.jar<br />
pak.JakeTheTestingRobot .1b,http://www.robocoderepository.com/BotFiles/3373/pak.JakeTheTestingRobot_.1b.jar<br />
pak.Dargon 1.0b,http://www.robocoderepository.com/BotFiles/3388/pak.Dargon_1.0b.jar<br />
pak.Dargon .2c,http://www.robocoderepository.com/BotFiles/3389/pak.Dargon_.2c.jar<br />
paolord.TheHulk 1.0,http://www.robocoderepository.com/BotFiles/3595/paolord.TheHulk_1.0.jar<br />
patson.PatsonTestBot 1.0,http://www.robocoderepository.com/BotFiles/3324/patson.PatsonTestBot_1.0.jar<br />
paulk.PaulV3 1.7,http://www.robocoderepository.com/BotFiles/3502/paulk.PaulV3_1.7.jar<br />
paulk.PaulV3 1.6,http://www.robocoderepository.com/BotFiles/3497/paulk.PaulV3_1.6.jar<br />
paulk.PaulV3 1.5,http://www.robocoderepository.com/BotFiles/3496/paulk.PaulV3_1.5.jar<br />
paulk.PaulV3 1.3,http://www.robocoderepository.com/BotFiles/3495/paulk.PaulV3_1.3.jar<br />
pb.Oscillator 1.0,http://www.robocoderepository.com/BotFiles/2070/pb.Oscillator_1.0.jar<br />
pe.mini.SandboxMini 1.2,http://www.robocoderepository.com/BotFiles/917/pe.mini.SandboxMini_1.2.jar<br />
pe.minimelee.SandboxMiniMelee 1.1,http://www.robocoderepository.com/BotFiles/934/pe.minimelee.SandboxMiniMelee_1.1.jar<br />
pe.SandboxDT 3.02,http://www.robocoderepository.com/BotFiles/793/pe.SandboxDT_3.02.jar<br />
pe.SandboxLump 1.52,http://www.robocoderepository.com/BotFiles/731/pe.SandboxLump_1.52.jar<br />
pedersen.Hubris 2.4,http://home.comcast.net/~kokyunage/robocode/hubris/pedersen.Hubris_2.4.jar<br />
pedersen.Ugluk 1.0,http://home.comcast.net/~kokyunage/robocode/ugluk/pedersen.Ugluk_1.0.jar<br />
pez.clean.Swiffer 0.2.9,http://www.robocoderepository.com/BotFiles/1883/pez.clean.Swiffer_0.2.9.jar<br />
pez.frankie.Frankie 0.9.6.1,http://www.robocoderepository.com/BotFiles/1565/pez.frankie.Frankie_0.9.6.1.jar<br />
pez.gloom.GloomyDark 0.9.2,http://www.robocoderepository.com/BotFiles/1741/pez.gloom.GloomyDark_0.9.2.jar<br />
pez.mako.Mako 1.5,http://www.robocoderepository.com/BotFiles/1317/pez.mako.Mako_1.5.jar<br />
pez.micro.Aristocles 0.3.7,http://www.robocoderepository.com/BotFiles/1923/pez.micro.Aristocles_0.3.7.jar<br />
pez.mini.ChironexFleckeri 0.5,http://www.robocoderepository.com/BotFiles/2513/pez.mini.ChironexFleckeri_0.5.jar<br />
pez.mini.Gouldingi 1.5,http://www.robocoderepository.com/BotFiles/1351/pez.mini.Gouldingi_1.5.jar<br />
pez.mini.Pugilist 2.4.18,http://darkcanuck.net/rumble/robots/pez.mini.Pugilist_2.4.18.jar<br />
pez.mini.Tityus 0.9.1,http://www.robocoderepository.com/BotFiles/1657/pez.mini.Tityus_0.9.1.jar<br />
pez.mini.VertiLeach 0.4.0,http://www.robocoderepository.com/BotFiles/1744/pez.mini.VertiLeach_0.4.0.jar<br />
pez.nano.Icarus 0.3,http://www.robocoderepository.com/BotFiles/2353/pez.nano.Icarus_0.3.jar<br />
pez.nano.LittleEvilBrother 0.1,http://www.robocoderepository.com/BotFiles/2056/pez.nano.LittleEvilBrother_0.1.jar<br />
pez.rumble.Ali 0.4.9,http://www.robocoderepository.com/BotFiles/2416/pez.rumble.Ali_0.4.9.jar<br />
pez.rumble.CassiusClay 2rho.01b,http://www.dijitari.com/void/robocode/pez.rumble.CassiusClay_2rho.01b.jar<br />
pfvicm.Sobieski 7.2.3b,http://www.robocoderepository.com/BotFiles/2911/pfvicm.Sobieski_7.2.3b.jar<br />
ph.micro.Pikeman 0.4.5,http://www.robocoderepository.com/BotFiles/2364/ph.micro.Pikeman_0.4.5.jar<br />
ph.mini.Archer 0.6.6,http://www.robocoderepository.com/BotFiles/2326/ph.mini.Archer_0.6.6.jar<br />
ph.musketeer.Musketeer 0.6,http://www.robocoderepository.com/BotFiles/2281/ph.musketeer.Musketeer_0.6.jar<br />
ph.Thinker 0.2.5,http://www.robocoderepository.com/BotFiles/2336/ph.Thinker_0.2.5.jar<br />
pi.Dark 10,http://darkcanuck.net/rumble/robots/pi.Dark_10.jar<br />
pl.Drum 0.1,http://darkcanuck.net/rumble/robots/pl.Drum_0.1.jar<br />
pl.Patton.GeneralPatton 1.54,http://darkcanuck.net/rumble/robots/pl.Patton.GeneralPatton_1.54.jar<br />
pla.Memnoch 0.5,http://www.robocoderepository.com/BotFiles/2211/pla.Memnoch_0.5.jar<br />
PK.Twardy 0.4.2,http://www.robocoderepository.com/BotFiles/3272/PK.Twardy_0.4.2.jar<br />
pkdeken.Paladin 1.0,http://www.robocoderepository.com/BotFiles/3556/pkdeken.Paladin_1.0.jar<br />
PkKillers.PkAssassin 1.0,http://www.robocoderepository.com/BotFiles/3485/PkKillers.PkAssassin_1.0.jar<br />
pmc.SniperBot 1.0,http://darkcanuck.net/rumble/robots/pmc.SniperBot_1.0.jar<br />
positive.Portia 1.26e,http://sites.google.com/site/robopositive/portia/positive.Portia_1.26e.jar<br />
povik.nano.Smilee 0.2.1,http://www.robocoderepository.com/BotFiles/3950/povik.nano.Smilee_0.2.1.jar<br />
projectx.ProjectNano 2.0,http://darkcanuck.net/rumble/robots/projectx.ProjectNano_2.0.jar<br />
projectx.TestNano 1.0,http://www.robocoderepository.com/BotFiles/3444/projectx.TestNano_1.0.jar<br />
pulsar.PulsarMax 0.8.9,http://www.robocoderepository.com/BotFiles/2227/pulsar.PulsarMax_0.8.9.jar<br />
pulsar.PulsarNano 0.2.4,http://www.robocoderepository.com/BotFiles/2335/pulsar.PulsarNano_0.2.4.jar<br />
pulsar.Nanis 0.3,http://www.robocoderepository.com/BotFiles/2560/pulsar.Nanis_0.3.jar<br />
qohnil.blot.BlotBot 3.61,http://www.robocoderepository.com/BotFiles/546/qohnil.blot.BlotBot_3.61.jar<br />
Queens_teamrobot.UltraRazor 1.0,http://www.robocoderepository.com/BotFiles/2108/Queens_teamrobot.UltraRazor_1.0.jar<br />
quietus.Invader 0.1,http://robocode.rleach.id.au/quietus.Invader_0.1.jar<br />
quietus.NarrowRadar 0.1,http://robocode.rleach.id.au/quietus.NarrowRadar_0.1.jar<br />
radnor.DoctorBob 1.42,http://www.robocoderepository.com/BotFiles/2133/radnor.DoctorBob_1.42.jar<br />
radnor.RamRod 1.0,http://www.robocoderepository.com/BotFiles/2085/radnor.RamRod_1.0.jar<br />
rampancy.Durandal 2.2d,http://stanford.edu/~mchunlum/robocode/rampancy.Durandal_2.2d.jar<br />
rampancy.micro.Epiphron 1.0,http://stanford.edu/~mchunlum/robocode/rampancy.micro.Epiphron_1.0.jar<br />
rapture.Rapture 2.13,http://www.robocoderepository.com/BotFiles/15/rapture.Rapture_2.13.jar<br />
ratosh.nano.Debo 1.36,http://www.robocoderepository.com/BotFiles/1702/ratosh.nano.Debo_1.36.jar<br />
ratosh.Nobo 0.21,http://www.robocoderepository.com/BotFiles/1612/ratosh.Nobo_0.21.jar<br />
ratosh.Wesco 1.4,http://www.robocoderepository.com/BotFiles/1914/ratosh.Wesco_1.4.jar<br />
rc.yoda.Yoda 1.0.6c.fix,http://rednaxela-robocode.dyndns.org/data/robots/rc.yoda.Yoda_1.0.6c.fix.jar<br />
rcb.Vanessa03 0,http://www.robocoderepository.com/BotFiles/1364/rcb.Vanessa03_0.jar<br />
rcp.Kuramatron 1.0,http://www.robocoderepository.com/BotFiles/3307/rcp.Kuramatron_1.0.jar<br />
rdt199.Warlord 0.73,http://www.robocoderepository.com/BotFiles/1130/rdt199.Warlord_0.73.jar<br />
reaper.Reaper 1.1,http://www.robocoderepository.com/BotFiles/3412/reaper.Reaper_1.1.jar<br />
repositorio.NanoStep 1.0,http://darkcanuck.net/rumble/robots/repositorio.NanoStep_1.0.jar<br />
rfj.Sunburn 1.1,http://www.robocoderepository.com/BotFiles/1060/rfj.Sunburn_1.1.jar<br />
rijteam.SmartDodge 1.1,http://www.robocoderepository.com/BotFiles/2959/rijteam.SmartDodge_1.1.jar<br />
robar.haiku.Spike 1.0,http://invitel.hu/artrog/robar.haiku.Spike_1.0.jar<br />
robar.micro.Gladius 1.15,http://invitel.hu/artrog/robar.micro.Gladius_1.15.jar<br />
robar.micro.Kirbyi 1.0,http://hunrobar.freeblog.hu/files/myrobots/robar.micro.Kirbyi_1.0.jar<br />
robar.micro.Topaz 0.25,http://invitel.hu/artrog/robar.micro.Topaz_0.25.jar<br />
robar.nano.Assertive 0.3,http://invitel.hu/artrog/robar.nano.Assertive_0.3.jar<br />
robar.nano.BlackWidow 1.3,http://www.robocoderepository.com/BotFiles/3574/robar.nano.BlackWidow_1.3.jar<br />
robar.nano.Breeze 0.3,http://hunrobar.freeblog.hu/files/myrobots/robar.nano.Breeze_0.3.jar<br />
robar.nano.Mosquito 1.1,http://hunrobar.freeblog.hu/files/myrobots/robar.nano.Mosquito_1.1.jar<br />
robar.nano.MosquitoPM 1.0,http://www.robocoderepository.com/BotFiles/3559/robar.nano.MosquitoPM_1.0.jar<br />
robar.nano.Prestige 1.0,http://www.robocoderepository.com/BotFiles/3507/robar.nano.Prestige_1.0.jar<br />
robar.nano.Pugio 1.49,http://www.robocoderepository.com/BotFiles/3710/robar.nano.Pugio_1.49.jar<br />
robar.nano.Scytodes 0.3,http://hunrobar.freeblog.hu/files/myrobots/robar.nano.Scytodes_0.3.jar<br />
robar.nano.Vespa 0.95,http://hunrobar.freeblog.hu/files/myrobots/robar.nano.Vespa_0.95.jar<br />
robo.PartsBot 1.1,http://darkcanuck.net/rumble/robots/robo.PartsBot_1.1.jar<br />
RobotMarco.MarcoV 0.1,http://www.robocoderepository.com/BotFiles/3941/RobotMarco.MarcoV_0.1.jar<br />
rsim.micro.uCatcher 0.1,http://sites.google.com/site/rsimander/robocode/rsim.micro.uCatcher_0.1.jar<br />
rsim.mini.BulletCatcher 0.4,http://www.robocoderepository.com/BotFiles/3737/rsim.mini.BulletCatcher_0.4.jar<br />
rsk1.RSK1 4.0,http://www.robocoderepository.com/BotFiles/3284/rsk1.RSK1_4.0.jar<br />
ruc.nano.Zealot 0.2,http://www.robocoderepository.com/BotFiles/1229/ruc.nano.Zealot_0.2.jar<br />
rus.vv.Dzhigit 1.1,http://www.robocoderepository.com/BotFiles/4002/rus.vv.Dzhigit1.1.jar<br />
rus.vv.Snezhok 1.1,http://www.robocoderepository.com/BotFiles/3998/rus.vv.Snezhok1.1.jar<br />
ry.LightningBug 1.0,http://www.robocoderepository.com/BotFiles/3472/ry.LightningBug_1.0.jar<br />
ry.VirtualGunExperiment 1.2.0,http://www.robocoderepository.com/BotFiles/3662/ry.VirtualGunExperiment_1.2.0.jar<br />
ry.Worst 1.0,http://www.robocoderepository.com/BotFiles/3645/ry.Worst_1.0.jar<br />
rz.Aleph 0.34,http://www.robocoderepository.com/BotFiles/1993/rz.Aleph_0.34.jar<br />
rz.Apollon 0.23,http://www.robocoderepository.com/BotFiles/2098/rz.Apollon_0.23.jar<br />
rz.Artist 0.2,http://www.robocoderepository.com/BotFiles/2156/rz.Artist_0.2.jar<br />
rz.GlowBlow 2.31,http://www.robocoderepository.com/BotFiles/1354/rz.GlowBlow_2.31.jar<br />
rz.GlowBlowAPM 1.0,http://www.robocoderepository.com/BotFiles/1382/rz.GlowBlowAPM_1.0.jar<br />
rz.GlowBlowMelee 1.4,http://www.robocoderepository.com/BotFiles/1436/rz.GlowBlowMelee_1.4.jar<br />
rz.HawkOnFire 0.1,http://www.robocoderepository.com/BotFiles/1575/rz.HawkOnFire_0.1.jar<br />
rz.SmallDevil 1.502,http://www.robocoderepository.com/BotFiles/1322/rz.SmallDevil_1.502.jar<br />
sam.ChipmunkDuelist 1.0,http://www.robocoderepository.com/BotFiles/3094/sam.ChipmunkDuelist_1.0.jar<br />
sam.Samspin 1.0,http://www.robocoderepository.com/BotFiles/2823/sam.Samspin_1.0.jar<br />
sanyi.mikrobi.Roberto 1.0,http://www.robocoderepository.com/BotFiles/3929/sanyi.mikrobi.Roberto_1.0.jar<br />
sch.Simone 0.3d,http://www.robocoderepository.com/BotFiles/374/sch.Simone_0.3d.jar<br />
serenity.moonlightBat 1.17,http://www.robocoderepository.com/BotFiles/2877/serenity.moonlightBat_1.17.jar<br />
serenity.nonSense 1.39,http://www.robocoderepository.com/BotFiles/3586/serenity.nonSense_1.39.jar<br />
serenity.serenityFire 1.29,http://www.robocoderepository.com/BotFiles/3071/serenity.serenityFire_1.29.jar<br />
sgp.JollyNinja 3.53,http://www.robocoderepository.com/BotFiles/183/sgp.JollyNinja_3.53.jar<br />
sgp.MadHatter 4.13,http://www.robocoderepository.com/BotFiles/156/sgp.MadHatter_4.13.jar<br />
sgp.nano.FurryLeech 1.0,http://www.robocoderepository.com/BotFiles/802/sgp.nano.FurryLeech_1.0.jar<br />
sgp.ShiningBeetle 1.1,http://www.robocoderepository.com/BotFiles/498/sgp.ShiningBeetle_1.1.jar<br />
sgp.SleepingGoat 1.1,http://www.robocoderepository.com/BotFiles/500/sgp.SleepingGoat_1.1.jar<br />
SHAM.WOW 1.4,http://darkcanuck.net/rumble/robots/SHAM.WOW_1.4.jar<br />
shinh.Entangled 0.3,http://www.robocoderepository.com/BotFiles/1070/shinh.Entangled_0.3.jar<br />
shrub.Silver v048,http://www.robocoderepository.com/BotFiles/449/shrub.Silver_v048.jar<br />
shrub.Vapour v159,http://www.robocoderepository.com/BotFiles/2654/shrub.Vapour_v159.jar<br />
shu.nitro.LENIN .T34,http://www.robocoderepository.com/BotFiles/1956/shu.nitro.LENIN_.T34.jar<br />
sigterm.Sigterm 1.0,http://darkcanuck.net/rumble/robots/sigterm.Sigterm_1.0.jar<br />
simonton.beta.LifelongObsession 0.5.1,http://www.robocoderepository.com/BotFiles/3195/simonton.beta.LifelongObsession_0.5.1.jar<br />
simonton.GFNano_D 3.1b,http://www.robocoderepository.com/BotFiles/3114/simonton.GFNano_D_3.1b.jar<br />
simonton.nano.WeekendObsession_S 1.7,http://www.robocoderepository.com/BotFiles/3117/simonton.nano.WeekendObsession_S_1.7.jar<br />
simonton.mega.SniperFrog 1.0.fix2,http://rednaxela-robocode.dyndns.org/data/robots/simonton.mega.SniperFrog_1.0.fix2.jar<br />
simonton.micro.GFMicro 1.0,http://darkcanuck.net/rumble/robots/simonton.micro.GFMicro_1.0.jar<br />
simonton.micro.WeeklongObsession 3.4.1,http://darkcanuck.net/rumble/robots/simonton.micro.WeeklongObsession_3.4.1.jar<br />
simonton.mini.WeeksOnEnd 1.10.4,http://darkcanuck.net/rumble/robots/simonton.mini.WeeksOnEnd_1.10.4.jar<br />
skm.butterfly 1.0,http://www.robocoderepository.com/BotFiles/3868/sean1.jar<br />
skm.Ryubot 1.0,http://www.robocoderepository.com/BotFiles/3594/skm.Ryubot_1.0.jar<br />
skm.PateranBotlock2 1.0,http://www.robocoderepository.com/BotFiles/3591/skm.PateranBotlock2_1.0.jar<br />
sL300.Mozart life,http://www.robocoderepository.com/BotFiles/1992/sL300.Mozart_life.jar<br />
sm.Devil 7.3,http://www.robocoderepository.com/BotFiles/1481/sm.Devil_7.3.jar<br />
sng.arco.Arco 0.0,http://www.robocoderepository.com/BotFiles/3279/sng.arco.Arco_0.0.jar<br />
sos.SOS 1.0,http://www.robocoderepository.com/BotFiles/3489/sos.SOS_1.0.jar<br />
spinnercat.CopyKat 1.2.3,http://www.robocoderepository.com/BotFiles/3818/spinnercat.CopyKat_1.2.3.jar<br />
spinnercat.Limit .01,http://www.robocoderepository.com/BotFiles/3659/spinnercat.Limit_.01.jar<br />
spinnercat.Kitten 1.6,http://www.robocoderepository.com/BotFiles/3819/spinnercat.Kitten_1.6.jar<br />
spinnercat.haiku.Refrigerator 1.1,http://www.robocoderepository.com/BotFiles/3688/spinnercat.haiku.Refrigerator_1.1.jar<br />
spinnercat.mega.Tardis 1.2,http://www.robocoderepository.com/BotFiles/3692/spinnercat.mega.Tardis_1.2.jar<br />
spinnercat.Robovirus 2.718,http://www.robocoderepository.com/BotFiles/3657/spinnercat.Robovirus_2.718.jar<br />
sqTank.waveSurfing.LionWWSVMvoid 0.01,http://www.robocoderepository.com/BotFiles/3436/sqTank.waveSurfing.LionWWSVMvoid_0.01.jar<br />
starpkg.StarViewerZ 1.26,http://www.robocoderepository.com/BotFiles/1931/starpkg.StarViewerZ_1.26.jar<br />
staticline.Whiskey 0.5.3,http://www.robocoderepository.com/BotFiles/3972/staticline.Whiskey_0.5.3.jar<br />
staticline.whiskey.Whiskey 0.6,http://rednaxela-robocode.dyndns.org/data/robot_archive/staticline.whiskey.Whiskey_0.6.jar<br />
stefw.Tigger 0.0.23,http://darkcanuck.net/rumble/robots/stefw.Tigger_0.0.23.jar<br />
stelo.Chord 1.0,http://darkcanuck.net/rumble/robots/stelo.Chord_1.0.jar<br />
stelo.FretNano 1.1,http://darkcanuck.net/rumble/robots/stelo.FretNano_1.1.jar<br />
stelo.Lifestealer 1.0,http://darkcanuck.net/rumble/robots/stelo.Lifestealer_1.0.jar<br />
stelo.MatchupMini 1.1,http://darkcanuck.net/rumble/robots/stelo.MatchupMini_1.1.jar<br />
stelo.MatchupMicro 1.2,http://darkcanuck.net/rumble/robots/stelo.MatchupMicro_1.2.jar<br />
stelo.MatchupAGF 1.1,http://darkcanuck.net/rumble/robots/stelo.MatchupAGF_1.1.jar<br />
stelo.MatchupWS 1.2c,http://darkcanuck.net/rumble/robots/stelo.MatchupWS_1.2c.jar<br />
stelo.Mirror 1.1,http://www.robocoderepository.com/BotFiles/3034/stelo.Mirror_1.1.jar<br />
stelo.MirrorMicro 1.1,http://darkcanuck.net/rumble/robots/stelo.MirrorMicro_1.1.jar<br />
stelo.MirrorNano 1.4,http://darkcanuck.net/rumble/robots/stelo.MirrorNano_1.4.jar<br />
stelo.MoojukNano 1.2,http://darkcanuck.net/rumble/robots/stelo.MoojukNano_1.2.jar<br />
stelo.PastFuture 2.1.9,http://www.robocoderepository.com/BotFiles/3910/stelo.PastFuture_2.1.9.jar<br />
stelo.PatternRobot 1.0,http://www.robocoderepository.com/BotFiles/2995/stelo.PatternRobot_1.0.jar<br />
stelo.PianistNano 1.3,http://darkcanuck.net/rumble/robots/stelo.PianistNano_1.3.jar<br />
stelo.RamTrackSurfer 1.2,http://darkcanuck.net/rumble/robots/stelo.RamTrackSurfer_1.2.jar<br />
stelo.Randomness 1.1,http://www.robocoderepository.com/BotFiles/3021/stelo.Randomness_1.1.jar<br />
stelo.Spread 0.2,http://www.robocoderepository.com/BotFiles/3922/stelo.Spread_0.2.jar<br />
stelo.SteloTestNano 1.0,http://darkcanuck.net/rumble/robots/stelo.SteloTestNano_1.0.jar<br />
stelo.UnfoolableNano 1.0,http://darkcanuck.net/rumble/robots/stelo.UnfoolableNano_1.0.jar<br />
stelo.UntouchableNano 1.4,http://darkcanuck.net/rumble/robots/stelo.UntouchableNano_1.4.jar<br />
step.nanoPri 1.0,http://www.robocoderepository.com/BotFiles/2996/step.nanoPri_1.0.jar<br />
step.NanoBidu 1.0,http://www.robocoderepository.com/BotFiles/3014/step.NanoBidu_1.0.jar<br />
stf.PanzerGeneral 0.1,http://www.robocoderepository.com/BotFiles/2233/stf.PanzerGeneral_0.1.jar<br />
stordy.StordyBot 1.0,http://sites.google.com/site/stordyrobo/Home/stordy.StordyBot_1.0.jar<br />
strider.Festis 1.2.1,http://www.robocoderepository.com/BotFiles/2355/strider.Festis_1.2.1.jar<br />
strider.Mer 1.1.0,http://www.robocoderepository.com/BotFiles/2360/strider.Mer_1.1.0.jar<br />
stuff.Vlad 0.1,http://www.robocoderepository.com/BotFiles/3701/stuff.Vlad_0.1.jar<br />
sul.NanoR2 1.32,http://www.robocoderepository.com/BotFiles/3348/sul.NanoR2_1.32.jar<br />
sul.Pinkbot 1.1,http://www.robocoderepository.com/BotFiles/3346/sul.Pinkbot_1.1.jar<br />
sul.Bicephal 1.2,http://www.robocoderepository.com/BotFiles/3343/sul.Bicephal_1.2.jar<br />
sul.BlueBot 1.0,http://www.robocoderepository.com/BotFiles/3347/sul.BlueBot_1.0.jar<br />
SuperSample.SuperCrazy 1.0,http://www.csdgn.org/files/bots/SuperSample.SuperCrazy_1.0.jar<br />
syl.Centipede 0.5,http://www.robocoderepository.com/BotFiles/1254/syl.Centipede_0.5.jar<br />
synapse.Geomancy 15,http://sites.google.com/site/synapsebots/home/synapse.Geomancy_15.jar?attredirects=0<br />
synapse.rsim.GeomancyBS 0.11,http://robocoderepository.com/BotFiles/3758/synapse.rsim.GeomancyBS_0.11.jar<br />
synnalagma.NeuralPremier 0.51,http://www.robocoderepository.com/BotFiles/1557/synnalagma.NeuralPremier_0.51.jar<br />
synnalagma.test.MiniNeural 1.1,http://www.robocoderepository.com/BotFiles/1754/synnalagma.test.MiniNeural_1.1.jar<br />
tad.Dalek98 0.98,http://darkcanuck.net/rumble/robots/tad.Dalek98_0.98.jar<br />
takeBot.SpinSpiral 1.2,http://www.robocoderepository.com/BotFiles/312/takeBot.SpinSpiral_1.2.jar<br />
takeBot.SpiralCrash 1.0,http://www.robocoderepository.com/BotFiles/1013/takeBot.SpiralCrash_1.0.jar<br />
takeBot.WeavingWiggle 1.1,http://www.robocoderepository.com/BotFiles/1012/takeBot.WeavingWiggle_1.1.jar<br />
tango.Recrimpo 2.51,http://www.robocoderepository.com/BotFiles/2015/tango.Recrimpo_2.51.jar<br />
taqho.taqbot 1.0,http://www.robocoderepository.com/BotFiles/1316/taqho.taqbot_1.0.jar<br />
tcf.Drifter 29,http://www.7sun.com/robocode/robots/tcf.Drifter_29.jar<br />
tcf.Repat3 2,http://www.robocoderepository.com/BotFiles/3328/tcf.Repat3_2.jar<br />
techdude.kombat.FlamingKombat 1.5,http://www.robocoderepository.com/BotFiles/2810/techdude.kombat.FlamingKombat_1.5.jar<br />
techdude.Class2C.Class2C 0.1,http://www.robocoderepository.com/BotFiles/3078/techdude.Class2C.Class2C_0.1.jar<br />
test.Podgy 4.0,http://www.robocoderepository.com/BotFiles/3214/test.Podgy_4.0.jar<br />
test.Fuzzer 1.0.1,http://www.robocoderepository.com/BotFiles/3345/test.Fuzzer_1.0.1.jar<br />
testantiswapgun.AntiSwap 1.0,http://www.robocode.ilbello.com/asd.AntiSwap_1.0.jar<br />
throxbot.ThroxBot 0.1,http://www.robocoderepository.com/BotFiles/2548/throxbot.ThroxBot_0.1.jar<br />
tide.pear.Pear 0.62.1,http://www.robocoderepository.com/BotFiles/2393/tide.pear.Pear_0.62.1.jar<br />
timmit.micro.TimXJ 0.22,http://www.robocoderepository.com/BotFiles/1683/timmit.micro.TimXJ_0.22.jar<br />
timmit.mini.TimVA 0.43,http://www.robocoderepository.com/BotFiles/1681/timmit.mini.TimVA_0.43.jar<br />
timmit.nano.TimCat 0.13,http://www.robocoderepository.com/BotFiles/1600/timmit.nano.TimCat_0.13.jar<br />
timmit.nano.TimDog 0.33,http://www.robocoderepository.com/BotFiles/1602/timmit.nano.TimDog_0.33.jar<br />
timmit.TimmiT 0.22,http://www.robocoderepository.com/BotFiles/1468/timmit.TimmiT_0.22.jar<br />
TJ.Exupery 1.39,http://www.robocoderepository.com/BotFiles/3970/TJ.Exupery1.39.jar<br />
tjk.deBroglie 0.66,http://robocoderepository.com/BotFiles/3989/tjk.deBroglie_0.66.jar<br />
tlp.ThreeLeggedPig 1,http://pages.prodigy.net/franz1/house/tlp.ThreeLeggedPig_1.jar<br />
tm.Yuugao 1.0,http://www.robocoderepository.com/BotFiles/1056/tm.Yuugao_1.0.jar<br />
tobe.calypso.Calypso 4.1,http://www.robocoderepository.com/BotFiles/784/tobe.calypso.Calypso_4.1.jar<br />
tobe.Fusion 1.0,http://www.robocoderepository.com/BotFiles/649/tobe.Fusion_1.0.jar<br />
tobe.mini.Charon 0.9,http://www.robocoderepository.com/BotFiles/836/tobe.mini.Charon_0.9.jar<br />
tobe.Relativity 3.9,http://www.robocoderepository.com/BotFiles/360/tobe.Relativity_3.9.jar<br />
tobe.Saturn lambda,http://www.robocoderepository.com/BotFiles/685/tobe.Saturn_lambda.jar<br />
tornyil.bottomup.BottomUp 1.05,http://www.alpha-consulting.hu/robo/tornyil.bottomup.BottomUp_1.05.jar<br />
tornyil.Lajcsi2.Lajcsi2sm 1.0,http://www.alpha-consulting.hu/robo/tornyil.Lajcsi2.Lajcsi2sm_1.0.jar<br />
toz.Gnome 1.1,http://darkcanuck.net/rumble/robots/toz.Gnome_1.1.jar<br />
trab.Crusader 0.1.7,http://www.stud.ntnu.no/~grashei/bots/trab.Crusader_0.1.7.jar<br />
trab.nano.AinippeNano 1.3,http://www.stud.ntnu.no/~grashei/bots/trab.nano.AinippeNano_1.3.jar<br />
tw.Exterminator 1.0,http://www.robocoderepository.com/BotFiles/3607/tw.Exterminator_1.0.jar<br />
tzu.TheArtOfWar 1.2,http://darkcanuck.net/rumble/robots/tzu.TheArtOfWar_1.2.jar<br />
uccc.Dorito 1.12,http://www.devfluid.com/csc_w/images/e/e9/Uccc.Dorito_1.12.jar<br />
uccc.MilkyWay 1.01,http://www.devfluid.com/csc_w/images/a/a6/Uccc.MilkyWay_1.01.jar<br />
uccc.RingDing 1.12,http://www.devfluid.com/csc_w/images/5/5f/Uccc.RingDing_1.12.jar<br />
uccc.Scrapple 1.0,http://www.devfluid.com/csc_w/images/7/7a/Uccc.Scrapple_1.0.jar<br />
urdos.URDOS 1.3,http://darkcanuck.net/rumble/robots/urdos.URDOS_1.3.jar<br />
usa.nano.Nemo 2.0,http://www.robocoderepository.com/BotFiles/2045/usa.nano.Nemo_2.0.jar<br />
vic.Locke 0.7.5.5,http://www.robocoderepository.com/BotFiles/2115/vic.Locke_0.7.5.5.jar<br />
vft.Valkyrie 1.0,http://www.robocoderepository.com/BotFiles/3009/vft.Valkyrie_1.0.jar<br />
vft.Hrist 1.0,http://darkcanuck.net/rumble/robots/vft.Hrist_1.0.jar<br />
vjik.UnViolation 1.1,http://www.robocoderepository.com/BotFiles/3886/vjik.UnViolation_1.1.jar<br />
voidious.Diamond 1.5.30,http://www.dijitari.com/void/robocode/voidious.Diamond_1.5.30.jar<br />
voidious.Dookious 1.573c,http://www.dijitari.com/void/robocode/voidious.Dookious_1.573c.jar<br />
voidious.micro.Jen 1.11,http://www.dijitari.com/void/robocode/voidious.micro.Jen_1.11.jar<br />
voidious.mini.Komarious 1.88,http://www.dijitari.com/void/robocode/voidious.mini.Komarious_1.88.jar<br />
vuen.Fractal 0.55,http://www.robocoderepository.com/BotFiles/1579/vuen.Fractal_0.55.jar<br />
wcsv.Engineer.Engineer 0.5.4,http://darkcanuck.net/rumble/robots/wcsv.Engineer.Engineer_0.5.4.jar<br />
wcsv.PowerHouse.PowerHouse 1.7e3,http://darkcanuck.net/rumble/robots/wcsv.PowerHouse.PowerHouse_1.7e3.jar<br />
wcsv.mega.PowerHouse2 0.2,http://darkcanuck.net/rumble/robots/wcsv.mega.PowerHouse2_0.2.jar<br />
wcsv.Stampede 1.3.3,http://www.robocoderepository.com/BotFiles/2527/wcsv.Stampede_1.3.3.jar<br />
wcsv.Stampede2.Stampede2 1.1.0,http://www.robocoderepository.com/BotFiles/2714/wcsv.Stampede2.Stampede2_1.1.0.jar<br />
whind.Constitution 0.7.1,http://www.robocoderepository.com/BotFiles/2812/whind.Constitution_0.7.1.jar<br />
whind.Strength 0.6.4,http://whindgames.50webs.com/otherstuff/whind.Strength_0.6.4.jar<br />
whind.StrengthBee 0.6.4,http://whindgames.50webs.com/otherstuff/whind.StrengthBee_0.6.4.jar<br />
whind.Wisdom 0.5.1,http://www.robocoderepository.com/BotFiles/2742/whind.Wisdom_0.5.1.jar<br />
wiki.BasicGFSurfer 1.02,http://www.dijitari.com/void/robocode/wiki.BasicGFSurfer_1.02.jar<br />
wiki.mako.MakoHT 1.2.2.1,http://www.robocoderepository.com/BotFiles/1374/wiki.mako.MakoHT_1.2.2.1.jar<br />
wiki.mini.BlackDestroyer 0.9.0,http://www.robocoderepository.com/BotFiles/1927/wiki.mini.BlackDestroyer_0.9.0.jar<br />
wiki.mini.GouldingiHT 1.0,http://www.robocoderepository.com/BotFiles/1383/wiki.mini.GouldingiHT_1.0.jar<br />
wiki.mini.Griffon 0.1,http://www.robocoderepository.com/BotFiles/1774/wiki.mini.Griffon_0.1.jar<br />
wiki.mini.Sedan 1.0,http://www.robocoderepository.com/BotFiles/1676/wiki.mini.Sedan_1.0.jar<br />
wiki.nano.DevilFISH 1.0,http://www.robocoderepository.com/BotFiles/2235/wiki.nano.DevilFISH_1.0.jar<br />
wiki.nano.RaikoNano 1.1,http://www.robocoderepository.com/BotFiles/2163/wiki.nano.RaikoNano_1.1.jar<br />
wiki.WaveRammer 1.0,http://www.robocoderepository.com/BotFiles/3505/wiki.WaveRammer_1.0.jar<br />
wiki.Wolverine 2.1,http://darkcanuck.net/rumble/robots/wiki.Wolverine_2.1.jar<br />
wilson.Chameleon 0.91,http://www.robocoderepository.com/BotFiles/1608/wilson.Chameleon_0.91.jar<br />
winamp32.micro.MicroMacro 1.0,http://www.robocoderepository.com/BotFiles/2891/winamp32.micro.MicroMacro_1.0.jar<br />
wit.Chuliath 1.0,http://www.robocoderepository.com/BotFiles/2306/wit.Chuliath_1.0.jar<br />
wit.Deep7 2.0,http://www.robocoderepository.com/BotFiles/2313/wit.Deep7_2.0.jar<br />
xiongan.Xiongan 1.1,http://www.robocoderepository.com/BotFiles/3565/xiongan.Xiongan_1.1.jar<br />
yarghard.Y101 1.0,http://sliwa.ws/RoboCode/yarghard.Y101_1.0.jar<br />
yk.JahMicro 1.0,http://www.robocoderepository.com/BotFiles/3033/yk.JahMicro_1.0.jar<br />
yk.JahRoslav 1.1,http://www.robocoderepository.com/BotFiles/3032/yk.JahRoslav_1.1.jar<br />
zen.Lindada 0.2,http://www.robocoderepository.com/BotFiles/1679/zen.Lindada_0.2.jar<br />
zeze2.OperatorZeze 1.05,http://www.robocoderepository.com/BotFiles/3330/zeze2.OperatorZeze_1.05.jar<br />
zch.David 0.21,http://www.robocoderepository.com/BotFiles/3575/zch.David_0.21.jar<br />
zch.Hirkan 0.11,http://www.robocoderepository.com/BotFiles/1288/zch.Hirkan_0.11.jar<br />
zh.UnderDog 0.0.2,http://www.robocoderepository.com/BotFiles/3053/zh.UnderDog_0.0.2.jar<br />
zyx.mega.YersiniaPestis 3.0,http://darkcanuck.net/rumble/robots/zyx.mega.YersiniaPestis_3.0.jar<br />
zyx.micro.Ant 1.1,http://www.robocoderepository.com/BotFiles/3481/zyx.micro.Ant_1.1.jar<br />
zyx.nano.Ant 1.1,http://www.robocoderepository.com/BotFiles/3493/zyx.nano.Ant_1.1.jar<br />
zyx.nano.EscherichiaColi 1.0,http://darkcanuck.net/rumble/robots/zyx.nano.EscherichiaColi_1.0.jar<br />
zyx.nano.RedBull 1.0,http://darkcanuck.net/rumble/robots/zyx.nano.RedBull_1.0.jar<br />
</pre><br />
----<br />
'''''No chatting on this page. Use the /ParticipantsChat page for that.'''''<br />
<br />
'''''Removed because the jarcontent/filename is not correct'''''<br><br />
''cberendt.Bot1 0.160''<br><br />
''dmsr.MiniR101 0.6''<br><br />
''henriquevilela.TieFighter 0.1,3224''<br><br />
''jgap.Aspirant_7980_gen7 1.0,3552''br><br />
''jgap.Aspirant_13029_gen7 1.0,3553''<br><br />
''techdude.Carruthers 1.2.6''<br><br />
''uccc.Orbiter 1.0''<br><br />
''WhoAmI.WhoAmI 1.00''<br><br />
<br />
'''''Removed until file corruption is resolved:'''''<br />
<br />
''cas.CelsoKiller 1.0,3465''<br />
<br />
'''''Removed due to almost always giving '0' scores:'''''<br />
<br />
''com.syncleus.robocode.Dreadnaught 0.1,3426''<br><br />
''lazarecki.PinkerStinker 0.1,http://www.robocoderepository.com/BotFiles/3824/lazarecki.PinkerStinker_0.1.jar''<br />
<br />
'''''Removed because it's incorrectly packaged:'''''<br />
<br />
''Indesh.Indesh 1.1,http://jakobserlier.250free.com/Indesh.jar''<br />
<br />
<br />
----<br />
<br />
'''''Removed due to WontFix issues in Robocode 1.7+:'''''<br><br />
''* Hviela: ([[http://sourceforge.net/tracker/?func=detail&aid=2953268&group_id=37202&atid=419486 SF #2953268]])''<br><br />
'': hvilela.HVilela 0.9.3,http://henrique.vilela.googlepages.com/hvilela.HVilela_0.9.3.jar''<br><br />
''* Barney (Tries to write files without using RobocodeOutputStream. Robocode 1.7 punishes for that more harshly which will give 0 scores)<br><br />
'': Homer.Barney 1.0,http://www.robocoderepository.com/BotFiles/1932/Homer.Barney_1.0.jar<br></div>Ncjhttp://robowiki.net/w/index.php?title=Talk:Waves/Precise_Intersection&diff=18293Talk:Waves/Precise Intersection2011-01-30T09:54:28Z<p>Ncj: Thanks for the bottom-left tip.</p>
<hr />
<div>{{CreditForOldWikiArticle|oldpage=Rednaxela/SuperBotwidth|author=[[User:Rednaxela|Rednaxela]]}}<br />
{{CreditForOldWikiArticle|oldpage=Garm/BotwidthCalculation|author=[[User:Krabb|Krabb]]}}<br />
{{CreditForOldWikiArticle|oldpage=Skilgannon/PreciseIntersect|author=[[User:Skilgannon|Skilgannon]]}}<br />
<br />
== Wave Surfing ==<br />
<br />
So far I know a few robots use Precise Intersection in their wave surfing. Unfortunately their code is either too messy (Wintermute) or too granular (RougeDC) that I don't know which class to look. So I asked here. (Diamond is too new to look into for this)<br />
<br />
Normally you surf waves 'till the wave passed ''centre'' of the robot. But with precise wave intersection, in order to gain pixel-perfect surfing, you need to surf the wave until they passed the robot. So if anybody does this or the other way? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 11:20, 20 October 2009 (UTC)<br />
<br />
I was planning to add all 3 to [[Wintermute]], ie, branch when the wave first strikes, branch when the wave passes midway, and branch when the wave exits, but after adding in a stop branch for every tick on the second wave it was too slow to do that without skipping turns. I think it now branches at the mid-point only...--[[User:Skilgannon|Skilgannon]] 13:21, 20 October 2009 (UTC)<br />
<br />
My experience, precise intersect or not, is that I've seen a measurable decrease in performance any time I try surfing waves any longer than I do now. I surf until they are less than one bullet velocity away, meaning they will pass my center before I can move again. I have some thoughts on this. If you weight by distance or by time to impact, the weight of the wave after it passes your center will be very high, while the chance of it hitting you if it hasn't already is very low. Giving it less weight somehow might help. Also, be careful not to give it negative weight, since your time to impact or distance calculation may give a value less than zero. --[[User:Voidious|Voidious]] 13:32, 20 October 2009 (UTC)<br />
<br />
If you guys surf the wave only half-way, then how are you calculating precise botwidth in the danger calculation? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 14:33, 20 October 2009 (UTC)<br />
<br />
: In Diamond 1.47's bot width calculation, I start with the first tick the bullet will cross my front bumper and go until the tick where it will cross my center. I tried until it crossed the rear bumper and it performed worse. Again, it's probably because it's so rare you will be hit there that weighting all the ticks evenly is just inaccurate, probabilistically. The next iteration of my precise intersect experiments doesn't have that issue, and I will again try considering all possible intersections. --[[User:Voidious|Voidious]] 14:52, 20 October 2009 (UTC)<br />
<br />
: In Wintermute I take any additional danger that may happen after branching into account with my second-wave surfing - the method returns a range of hits over both waves, then adds them all together. --[[User:Skilgannon|Skilgannon]] 08:02, 21 October 2009 (UTC)<br />
<br />
:: And what about when you surf only single wave? --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 08:33, 21 October 2009 (UTC)<br />
:: Then it just continues through until the wave is completely past =) There's no reason to reverse unless there's another wave coming, in which case I would be branching and my statement above would apply =) --[[User:Skilgannon|Skilgannon]] 09:54, 21 October 2009 (UTC)<br />
<br />
:: I mean when your surfing algorithm only surfs single wave, not when you have only one surfable wave. Because that's what I'm implementing (because it is goto-surfing, I can't surf second wave without skipped turn =)) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 10:00, 21 October 2009 (UTC)<br />
<br />
:: In DrussGT I take a bunch of points and predict what GF would be hit if I fed it to my GoTo method. If you're only dealing with one wave then it's quite easy, simply keep predicting until the wave has passed your future bot. I found it is best to start surfing the next wave as the old one passes the center of your bot. --[[User:Skilgannon|Skilgannon]] 18:44, 21 October 2009 (UTC)<br />
<br />
::: Slightly offtopic: Nat, you should take a look at [[User talk:AaronR|the conversation I had with Voidious]] about how to surf multiple waves with goto surfing. You can cut down on the combinatorial explosion by not recursing if the danger for the first wave is already higher than the current minimum total. « [[User:AaronR|AaronR]] « [[User talk:AaronR|Talk]] « 21:12, 22 October 2009 (UTC)<br />
<br />
:::: Thank you. I have already known that, from Druss's code (I've read Druss's code at least 10+ times) --[[User:Nat|<span style="color:#099;">Nat</span>]] [[User talk:Nat|<span style="color:#0a5;">Pavasant</span>]] 11:41, 23 October 2009 (UTC)<br />
<br />
In [[YersiniaPestis]] I surf the wave until it passes completely, if I don't it gets hit more by simple targeters, I think is because YP doesn't go that far from the danger spots so when it starts surfing the second wave it ran towards the bullet near him. But as far as having a precise window calculated, you can keep track of the waves until it passes you even if you don't consider that wave for surfing it anymore. --[[User:Zyx|zyx]] 20:51, 20 October 2009 (UTC)<br />
<br />
I looked it up and I use Precise Intersection since [[GresSuffurd]] 0.1.1 (october 2006), but only in simplified form and only in my gun (e.g. almost Precise Intersection). Reading the reactions above, I already know where my focus for the first few weeks will lie: introducing PI in my surfing. --[[User:GrubbmGait|GrubbmGait]] 00:19, 21 October 2009 (UTC)<br />
<br />
== Psudocode ==<br />
<br />
I really like Precise Intersection. Here is some javalike psudocode to help explain this to those who see things better in code.<br />
<br />
*'''IntersectRectCircle(Rect rect,Point center,double radius)''' is a function that returns an array of points where the circle defined by center and radius, intersects the Rect rect. Otherwise it returns an array of length 0.<br />
*'''GetRectCorners(Rect rect)''' is a function that returns an array of 4 points, each making up the corners of Rect rect.<br />
*'''Rect''' and '''Point''' are generic classes that define a copy of what they say. Point is equivalent to a Point2D.Double and a Rect is equivalent to a Rectangle2D.Double<br />
<br />
<syntaxhighlight><br />
class Wave {<br />
Point center;<br />
public long fireTime;<br />
public double bearing;<br />
public double speed;<br />
<br />
/**<br />
* You will need to divide these min and max angles by the maximum escape<br />
* angle to get the guess factor, however since they are all part of this<br />
* wave, you do not need to convert them immediately to guess factors.<br />
*/<br />
public double min; /* Set these to a good initial value */<br />
public double max; /* like positive and negative infinity */<br />
<br />
boolean intersectStarted = false;<br />
<br />
/**<br />
* Return true if the intersection is complete<br />
*/<br />
public boolean intersect(Point target, long time) {<br />
Rect boundingbox = new Rect(target.x - 18, target.y - 18, 36, 36);<br />
Point[] current = IntersectRectCircle(boundingbox, center, getDistance(time));<br />
Point[] last = IntersectRectCircle(boundingbox, center, getDistance(time - 1));<br />
<br />
if(current.length > 0 || last.length > 0) {<br />
Point[] corners = GetRectCorners(boundingbox);<br />
<br />
/* Check the bearings on all the current points */<br />
for(Point p : current) {<br />
double angle = Utils.normalRelativeAngle(bearingFromTo(center, p) - bearing);<br />
if(angle < min) min = angle;<br />
if(angle > max) max = angle;<br />
}<br />
<br />
/* Check the bearings on all the last points */<br />
for(Point p : last) {<br />
double angle = Utils.normalRelativeAngle(bearingFromTo(center, p) - bearing);<br />
if(angle < min) min = angle;<br />
if(angle > max) max = angle;<br />
}<br />
<br />
/* Check the bearings on the bounding boxes corners */<br />
for(Point p : corners) {<br />
/* Make sure that the corner is between the distance of the current and last. */<br />
if(center.distance(p) <= getDistance(time) && center.distance(p) >= getDistance(time-1)) {<br />
double angle = Utils.normalRelativeAngle(bearingFromTo(center, p) - bearing);<br />
if(angle < min) min = angle;<br />
if(angle > max) max = angle;<br />
}<br />
}<br />
<br />
intersectStarted = true;<br />
} else if(intersectStarted) {<br />
return true;<br />
}<br />
return false;<br />
}<br />
<br />
public double getDistance(long time) {<br />
return (time - fireTime) * speed;<br />
}<br />
}<br />
</syntaxhighlight><br />
&#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 02:20, 17 July 2010 (UTC)<br />
<br />
== Smashing it down to bins ==<br />
<br />
Although the concept is very clear to me, calculating the precise intersection between a bot and a wave is one step to far for my mind. Also, why bother calculating it with 6 figures behind the comma, and then force it with a sledgehammer into those coarse bins. With some straight-forward programming and some brute CPU power you can get the same results. I must give a warning though: this looks a lot like virtual bullets, firing one bullet per bin.<br />
<br />
When the wave is less than 2 ticks away from the opponent, the calculation should start. Starting with the bin where the center of the opponent is, the bullet is checked for if it lies in the robot bounding box. If it is, this bin is noted as 'left bin' and 'right bin' and then the bullet (bin) on the left is checked. It this still in the bounding box, then this bin is noted as left and the next left bin is checked, and so on. The same for the bins on the right side. On the next tick, the same goes again, starting from the 'left bin' to the left and the 'right bin' to the right. This is repeated every tick untill the wave has passed the opponent. Now you have the bins that would have noted a 'hit' if you indeed fired at one of them. In a slightly other form, this is present in the gun of GresSuffurd since October 2006. But this only adressed the first point mentioned on the Precise Intersection page, so it is better called ''Not so precise intersection''.<br />
<br />
To have a precise intersection, also the movement of the bullet and the movement of the bot must be taken into account. The movement of the bullet can be calculated quite simple. Just repeat the above with the distance '''increased''' by 'bulletvelocity' (point of T+1). The movement of the bot seems more difficult to calculate, but think about this situation: the bullet has passed a corner of the bot, and the bot moves towards the bullet, intersecting the calculated angle behind the bullet. It just means you have to look backwards to check if the bot was hit in the back. So repeating the same steps as above with the distance '''decreased''' by 'bulletvelocity' (point of T-1) would do the trick. This adresses the second point mentioned on the master page.<br />
<br />
How can the third point taken care of? Brute-force calculating! Just repeat the above with several points between the 'T-1' point and the 'T+1' point and we have an 'almost precise intersection' ready. Better would be to check if the 'bulletline' would intersect the robot bounding box, but that function I could not find.<br />
<br />
The routine implementing this will be part of a next version of GresSuffurd. If I made wrong assumptions, please let me know, I'm still not too old to learn. --[[User:GrubbmGait|GrubbmGait]] 23:02, 28 January 2011 (UTC)<br />
<br />
Neat! I think this approach is a sensible one for bots that use bins (all my uses of precise intersection have never been with any form of bins in the same robot). One note though, is that when checking if the bullet is in the bounding box, be sure to treat the bullet as a line, not a point. The graphics of robocode are rather misleading, since bullets are treated as continuous line segments for purposes of collisions. You may be accounting for this, but just thought I'd mention it since it's not clear whether you are. --[[User:Rednaxela|Rednaxela]] 00:37, 29 January 2011 (UTC)<br />
<br />
Hey, I also think this is pretty cool! I do have some corrections:<br />
* To really be precise, you should start 3 or even 4 ticks ahead in some situations. A min speed bullet (11) could be a distance of 35 from the enemy bot's center, making it > 3 ticks away. But before the enemy bot moves again, this bullet will move and check for collisions, so in effect the wave's closest point (with respect to collisions) is already 24 from the bot's center. The distance from a bot's center to its corner is ~25, so it could intersect.<br />
* If a bot moves into the bullet line, it is not a collision. Each tick, the bullet moves forward, forming a line segment, and it is checked if this line segment intersects the bot bounding box, then the enemy bot moves. So you don't really need to check the T-1 thing. Just check T, T+1, and some points in between, checking if any of them lie within the current enemy bounding box. (And do that each tick, like you said.)<br />
* This page is kind of confusing - in my opinion, it should talk about "this tick" and "next tick", never "last tick"...<br />
I also have only done this in a bot without bins ([[Diamond]]), and only in the movement. I was surprised it helped as much as it did... Good luck!<br />
<br />
--[[User:Voidious|Voidious]] 01:36, 29 January 2011 (UTC)<br />
<br />
Oh yeah, and this might save you some brute forcing. :-) [http://download.oracle.com/javase/1.5.0/docs/api/java/awt/geom/Line2D.html#intersects(double,%20double,%20double,%20double) java.awt.geom.Line2D.intersects(...)] --[[User:Voidious|Voidious]] 01:56, 29 January 2011 (UTC)<br />
<br />
: Sorry for triple post - clearly you've got my brain churning over this. :-) Note that because Robocode's coordinates start from bottom left, you should use x/y of bottom left corner, not top left like the API says... Same with how we use Rectangle2D's. Or you could just brute force... :-P --[[User:Voidious|Voidious]] 02:05, 29 January 2011 (UTC)<br />
<br />
:: Thanks for the tip! I was just about to give up on the built-in Rectangle2D and Ellipse2D intersection when I ran across your comment. Changing to the bottom left instead of top left solved my problems. [[User:Ncj|Ncj]] 09:54, 30 January 2011 (UTC)<br />
<br />
Thanx for the comments, now the implementation can be quite small and fast.<br><br />
@Rednaxela: I know, but I couldn't find Rectangle2D.intersects( line2D). The other way round is just so obvious I hadn't thought of it . . . duh<br><br />
@Voidious: Regarding point 1, you're absolutely right. On the second point you are probably right, it seems logical to me, but I found the page also a bit unclear regarding this. Third point, well, you're right (again)<br><br />
Now let's see howmany points it will gain me in the rumble . . . --[[User:GrubbmGait|GrubbmGait]] 09:51, 29 January 2011 (UTC)<br />
<br />
Yes thanks for your comments :) They've nicely followed my own recent work the last couple of days :) I also used the Line2D.intersec.... For simplicity I currently just check all the bins, instead of the whole center, left, right thing.. Being I won't be firing waves and only surfing, my "sim" starts with onHitByBulletEvent, logs the bulletLine.intersect/contains in a buffer (this and 2 more ticks) , and adds the those binsHIT to my stats , all in the same loop.. The code is surprising very simple and short, works great -[[User:Jlm0924|Jlm0924]] 22:55, 29 January 2011 (UTC)</div>Ncjhttp://robowiki.net/w/index.php?title=User_talk:Ncj&diff=18285User talk:Ncj2011-01-29T05:50:59Z<p>Ncj: I moved the content to the user page, since this is the talk page...</p>
<hr />
<div></div>Ncjhttp://robowiki.net/w/index.php?title=User:Ncj&diff=18284User:Ncj2011-01-29T05:50:25Z<p>Ncj: Created page with 'Hello! I'm a programmer by trade, and I've been playing with Robocode on and off for a couple of years. From the beginning, the wiki is what really drew me in. At first I didn't…'</p>
<hr />
<div>Hello!<br />
<br />
I'm a programmer by trade, and I've been playing with Robocode on and off for a couple of years. From the beginning, the wiki is what really drew me in. At first I didn't want to build my own robot, but I spent hours reading everything on this site to learn how the best bots were able to dance around, magically avoiding bullets.<br />
<br />
I finally have a bot in the works that's doing well in my own tests. I'm trying out what I think is a new strategy; my first goal is to get at least a 50% win record against every bot in the rumble, though I'm sure those nice results won't last long. I'm making this page to motivate myself to actually release the thing instead of tweaking forever and ever.<br />
<br />
Robots!</div>Ncjhttp://robowiki.net/w/index.php?title=User_talk:Ncj&diff=18283User talk:Ncj2011-01-29T05:41:16Z<p>Ncj: Added egotistical user talk page.</p>
<hr />
<div>Hello!<br />
<br />
I'm a programmer by trade, and I've been playing with Robocode on and off for a couple of years. From the beginning, the wiki is what really drew me in. At first I didn't want to build my own robot, but I spent hours reading everything on this site to learn how the best bots were able to dance around, magically avoiding bullets.<br />
<br />
I finally have a bot in the works that's doing well in my own tests. I'm trying out what I think is a new strategy; my first goal is to get at least a 50% win record against every bot in the rumble. I'm making this page to motivate myself to actually release the thing instead of tweaking forever and ever.<br />
<br />
Robots!</div>Ncj