|
|
| (125 intermediate revisions by 15 users not shown) |
| Line 1: |
Line 1: |
| | + | Sub-pages: [[/Archive20130317]] |
| | + | |
| | == RoboRumble history == | | == RoboRumble history == |
| | 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 | | 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 |
| Line 10: |
Line 12: |
| | February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar | | February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar |
| | | | |
| − | 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 | + | 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 |
| − | | |
| − | == Subpages ==
| |
| − | Should we replace ALL of the subpages? or just the 'important' ones? -- [[User:Starrynte|Starrynte]] 22:16, 17 November 2007 (UTC)
| |
| − | | |
| − | == Name ==
| |
| − | | |
| − | 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)
| |
| − | | |
| − | I second this change. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 02:30, 28 April 2009 (UTC)
| |
| − | | |
| − | == RR seems to be down ==
| |
| − | | |
| − | 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)
| |
| − | :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)
| |
| − | ::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)
| |
| − | ::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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--[[User:Robar|HUNRobar]] 17:40, 11 October 2008 (UTC)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == Lynch the Multi-Threaders! ==
| |
| − | | |
| − | A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?
| |
| − | # 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.
| |
| − | # 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.
| |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | : It looks like [https://sourceforge.net/tracker/?func=detail&aid=2456831&group_id=37202&atid=419489 this] » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 12:53, 7 August 2009 (UTC)
| |
| − | | |
| − | :: Hm? "ERROR This artifact is not accessible." is what that page gives --[[User:Rednaxela|Rednaxela]] 13:11, 7 August 2009 (UTC)
| |
| − | | |
| − | ::: 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. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 13:53, 7 August 2009 (UTC)
| |
| − | : 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)
| |
| − | :: 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)
| |
| − | :: 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)
| |
| − | :: 1.7.1.5? It was there for about eight months. I think maybe 1.8 or so... » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 06:10, 8 August 2009 (UTC)
| |
| − | | |
| − | == What Now? ==
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | : 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == Nanos get little love when things get busy ==
| |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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!
| |
| − | | |
| − | 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)
| |
| − | | |
| − | I second Darkcanuck's suggestion, as it seems most fair to me. :) --[[User:Rednaxela|Rednaxela]] 05:12, 20 June 2009 (UTC)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | * 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | : 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | : 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)
| |
| − | :: 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)
| |
| − | ::: 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)
| |
| − | :: 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)
| |
| − | : 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)
| |
| − | | |
| − | == Mobile Devices ==
| |
| − | | |
| − | Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --[[User:Rednaxela|Rednaxela]] 02:01, 7 August 2009 (UTC)
| |
| − | | |
| − | * Definitely crazy. --[[User:Simonton|Simonton]]
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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:
| |
| − | <pre>Iteration number 0
| |
| − | Downloading rating files ...
| |
| − | Downloading participants list ...
| |
| − | Downloading missing bots ...
| |
| − | Removing old participants from server ...
| |
| − | Preparing battles list ... Using smart battles is true
| |
| − | Prioritary battles file not found ...
| |
| − | java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
| |
| − | at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)
| |
| − | at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)
| |
| − | at robocode.manager.RobocodeManager.initSecurity(Unknown Source)
| |
| − | at robocode.control.RobocodeEngine.init(Unknown Source)
| |
| − | at robocode.control.RobocodeEngine.<init>(Unknown Source)
| |
| − | at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)
| |
| − | at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)
| |
| − | at roborumble.RoboRumbleAtHome.main(Unknown Source)
| |
| − | Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path
| |
| − | at java.lang.Runtime.loadLibrary(Runtime.java:763)
| |
| − | at java.lang.System.loadLibrary(System.java:662)
| |
| − | at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)
| |
| − | at java.lang.VMClass.forName(Native Method)
| |
| − | at java.lang.Class.forName(Class.java:233)
| |
| − | at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)
| |
| − | ...7 more
| |
| − | </pre> It seems that both:
| |
| − | # RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line
| |
| − | # The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only
| |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | : Ouchie, building the robot database this first time sure isn't fast... --[[User:Rednaxela|Rednaxela]] 02:39, 7 August 2009 (UTC)
| |
| − | | |
| − | Sadly, while it mostly ran, it didn't quite work:
| |
| − | <pre>java.lang.ArrayIndexOutOfBoundsException: 1
| |
| − | at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27
| |
| − | 5)
| |
| − | at java.util.AbstractList$1.next(AbstractList.java:354)
| |
| − | at robocode.battle.Battle.updateBullets(Unknown Source)
| |
| − | at robocode.battle.Battle.runTurn(Unknown Source)
| |
| − | at robocode.battle.Battle.runRound(Unknown Source)
| |
| − | at robocode.battle.Battle.run(Unknown Source)
| |
| − | at java.lang.Thread.run(Thread.java:743)
| |
| − | | |
| − | ...
| |
| − | | |
| − | java.lang.NullPointerException
| |
| − | at robocode.battle.Battle.updateBullets(Unknown Source)
| |
| − | at robocode.battle.Battle.runTurn(Unknown Source)
| |
| − | at robocode.battle.Battle.runRound(Unknown Source)
| |
| − | at robocode.battle.Battle.run(Unknown Source)
| |
| − | at java.lang.Thread.run(Thread.java:743)
| |
| − | | |
| − | ...
| |
| − | | |
| − | Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException
| |
| − | at robocode.peer.RobotPeer.setEnergy(Unknown Source)
| |
| − | at robocode.peer.RobotPeer.setEnergy(Unknown Source)
| |
| − | at robocode.peer.RobotPeer.run(Unknown Source)
| |
| − | at java.lang.Thread.run(Thread.java:743)
| |
| − | Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException
| |
| − | at robocode.peer.RobotPeer.setEnergy(Unknown Source)
| |
| − | at robocode.peer.RobotPeer.setEnergy(Unknown Source)
| |
| − | at robocode.peer.RobotPeer.run(Unknown Source)
| |
| − | at java.lang.Thread.run(Thread.java:743)
| |
| − | </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)
| |
| − | | |
| − | == Rumble Computers ==
| |
| − | | |
| − | 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:
| |
| − | * Intel Core 2 Duo T5300 (1.73GHz), 2GB ram, laptop, usually avaliable
| |
| − | * AMD Athlon XP 2000+, 512MB ram, often avaliable
| |
| − | * AMD Athlon XP 2400+, 1GB ram, rarely avaliable
| |
| − | 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)
| |
| − | | |
| − | I have:
| |
| − | * 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.
| |
| − | * AMD 2000+, 768MB RAM (Ubuntu 8.10), which I've been running a rumble client on almost 24/7 for a while now.
| |
| − | * 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. =)
| |
| − | 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)
| |
| − | | |
| − | : 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)
| |
| − | | |
| − | My client runs on an old laptop -- all it does is run roborumble + meleerumble:
| |
| − | * Intel Pentium M w/512MB ram, 100% available
| |
| − | 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.
| |
| − | --[[User:Darkcanuck|Darkcanuck]] 04:26, 16 August 2009 (UTC)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | : Wow, 2.66 MHz!!?! :-D J/k. --[[User:Voidious|Voidious]] 15:04, 16 August 2009 (UTC)
| |
| − | | |
| − | : 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)
| |
| − | | |
| − | 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. » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 11:31, 16 August 2009 (UTC)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == Lower Rank Limit? ==
| |
| − | | |
| − | 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) ) ?
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == Whoops ==
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == Iteration ==
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == JVM Crash ==
| |
| − | | |
| − | 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)
| |
| − | | |
| − | 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)
| |
| − | | |
| − | == Contributor's Sum ==
| |
| − | | |
| − | 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)
| |
| − | | |
| − | : 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)
| |
