http://robowiki.net/w/index.php?action=history&feed=atom&title=Thread%3ATalk%3ARoboRumble%2F30_day_battle_records%2Freply_%2837%29 2026-04-17T23:29:57Z Revision history for this page on the wiki MediaWiki 1.34.1 http://robowiki.net/w/index.php?title=Thread:Talk:RoboRumble/30_day_battle_records/reply_(37)&diff=28513&oldid=prev 2013-02-03T19:27:18Z

<p>Reply to <a href="/wiki/Thread:Talk:RoboRumble/30_day_battle_records/reply_(32)" title="Thread:Talk:RoboRumble/30 day battle records/reply (32)">30 day battle records</a></p> <p><b>New page</b></p><div>Yeah, I certainly wasn't saying it was a reasonable list. =)<br /> <br /> RoboRunner runs each engine in its own process, communicating with STDIN/STDOUT. I think that means it would be able to recover from OOME, but I haven't tested it.<br /> <br /> I've never used Distributed Robocode either, but I've always wanted a client that would switch to RoboRumble after finishing running challenges, and vice versa. My main issue with DR and similar CPU pooling (besides for RoboRumble) has been that I never thought it would reach a happy medium - I thought you'd either be stuck contributing all your power when you'd be better off just using it yourself, or you'd be trying to use it and nobody else would be contributing. But we have a surplus of CPU power these days (12k min battles in General 1v1), so if pooling it were simple, I think it could work.</div>

Voidious