Talk:Midboss
"Ahab is stuck at sea in shark infested waters" <<< Ahab is dead now, even he survived from the battle White Whale, because whaling was in 1800s. But this made me laughed for a good while. --Nat Pavasant 11:35, 10 January 2010 (UTC)
And isn't WaveSerpent use full Anti-Alias/Interpolation already? --Nat Pavasant 12:46, 10 January 2010 (UTC)
- Ah true, WaveSerpent did implement it too yeah. --Rednaxela 16:17, 10 January 2010 (UTC)
Version 1d
Well... this is a refreshing surprise... it looks like 1d is gaining a few spots over 1c, and all I did was the following:
add
add(Dimension.ADVANCINGV, true, -8, 0, 8); add(Dimension.BFT, true, 0, 30, 60, 95);
to
add(Dimension.DISTANCE, true, 75, 225, 375, 525, 675); add(Dimension.LATERALV, true, 0, 1, 2.5, 5, 7.5); add(Dimension.ACCEL, true, -0.5, 0, 0.5); add(Dimension.VCHANGETIME, true, 0.0, 0.2, 0.5, 0.95, 1.6); add(Dimension.FWALL, true, 0.05, 0.25, 0.45, 0.65, 0.85, 0.95); add(Dimension.BWALL, true, 0.175, 0.875);
I find this particularly funny because I found similar things to not help when I made SaphireEdge long ago. Of course, the reason I decided to try adding those segments, is because I felt they would come much more strongly into play once my own bot is moving, which doesn't happen during targeting tests.
It's been far too long since I've seen tangible gains from a 5 minute change... :) --Rednaxela 07:32, 10 January 2010 (UTC)
- Nice work! You may drag me back in now that Pris has lost the top Canadian spot to Midboss... --Darkcanuck 16:34, 10 January 2010 (UTC)
Very nice indeed! I never got higher than #21 (APS 81.84) with GresSuffurd 0.2.13 which used only absolute velocity as surfing dimension. Seems that spot #11 is feasible without to much effort. --GrubbmGait 16:50, 10 January 2010 (UTC)
- Thanks. True, but I'm pretty sure it's simple surfing is the biggest thing holding Midboss back. Benchmarks show it's gun being in the same league as the top 10 bots, if not better than some, and various evidence over time has always shown the movement of RougeDC to be much weaker than it's gun really. --Rednaxela 17:50, 10 January 2010 (UTC)
Version 1e
Version 1e has a slight problem with rambots. At point blank it selects a firepower between 0.1 and 0.25, probably not the best defence. Also it does not move away anymore after a few collisions. --GrubbmGait 01:26, 11 January 2010 (UTC)
Yeah, there was a bug in my new shiny/fancy score-estimation code, one of those little one-keyword typos, causing it to mix up it's own damage bonus with the enemy's damage bonus in one important branch of the code. That's now fixed in version 1f and it should be choosing bulletpower much smarter now. Early tests show it boosting performance by as much as 10% compared to version 1d against some bots so let's see how my new bulletpower selection experiment turns out. About the movement, that hasn't changed since... some old version of RougeDC so that's nothing new. --Rednaxela 03:03, 11 January 2010 (UTC)
Version 1g
Hey Voidious, any idea what's happening on your client? It's uploading bad results for Midboss 1g [1][2] and also uploaded a huge number of bad results for Midboss 1f. Is it an out of memory error perhaps? I know that ever since Midboss 1d, the gun has taken up an enormous amount of memory, but there were no bad results for version 1d so maybe it's something else? If it's an out of memory error, are you running with ITERATE=YES or are you using a loop in the bash script? If the former that could be the source of the problem because robocode for some reason seems to leak memory. Considering how some of the results seem notably improved... this issue is rather frustrating. --Rednaxela 17:34, 11 January 2010 (UTC)
Yeah, one of my clients hit an "out of memory / Java heap space" overnight. I killed that one and left just one client running since this morning. I checked the one that crashed and it was not iterating, just looping via shell script. Sorry I didn't post about it, I was on my way out the door and it didn't strike me as likely to have caused bad results before crashing. I'll stop my other client when I get home and double check my config. Sorry man. =( --Voidious 17:55, 11 January 2010 (UTC)
Here's one theory about the running out of memory: Testing is showing that Robocode, at least 1.7.1.6, is not allowing memory in static variables of bots to be cleared by the GC ever, even after the same bot loads again. This is odd because it was my understanding that when the classloader that robocode made the to load the robot dies it should allow GCing of everything that classloader loaded[3][4]. This says to me that robocode has a bug where it keeps using the same classloader, or keeps references to it's old classloaders. Anyway, I've found that Midboss 1d uses roughly 60MB of memory per load, and Midboss 1g uses roughly the same. As a workaround, in Midboss 1h, I'll make an 'unload' type hook in the bot, which will clear out all static variables at the end of round. I have no clue what this wasn't an issue with Midboss 1d..... Perhaps there are more problems when there is a greater number of high-memory-usage distinct bot versions running in a single 10-battle iteration. --Rednaxela 19:45, 11 January 2010 (UTC)
The other client that I left running seems to still be having no problem with Midboss, but I stopped it when I got home. They're both configured the same: 512 mb, NUMBATTLES=25, ITERATE=NOT, and looping via a shell script. I'll just leave 'em off for now, but I'm skeptical there's anything wrong with my client, besides any problem with Robocode itself/the bot. I'll just leave my clients off for now, until we investigate further or you post a new version that you think has a workaround. --Voidious 01:46, 12 January 2010 (UTC)
It's probably the NUMBATTLES=25 that's making it show as an issue on your client but not mine I think. I've reported at ticket to the robocode tracker, since I'm very certain it's a problem in robocode itself, and will in the meanwhile make a workaround by forcing the bot to clear ALL static variables upon receiving the onBattleEnded() event. This bug concerns me significantly because really, it doesn't just affect Midboss, but I'm pretty sure affects all bots with very high memory usasge. Of course, once this gets fixed, there should finally be no issue with using ITERATE=YES. --Rednaxela 02:32, 12 January 2010 (UTC)
Interesting Emergent Behaviors
The new bulletpower selection is seeming extremely helpful against some bots, see the comparison for Druss, Gaff, and Chalk for instance! It's interesting when I make an algorithm designed to optimize for score, it sometimes does things I just didn't expect. It sometimes seems "give up" just before dying, by shooting a few very high power bullets to use up it's last energy very fast. My theory of why this causes benefit in the score evaluation is because it denies the enemy some bullet damage score. Any thoughts on this? :) --Rednaxela 21:29, 11 January 2010 (UTC)
- It's not the first time I've heard of that idea, but it's very impressive that your system would come up with it! Your analysis of the effect on score must be pretty sophisticated. =) --Voidious 21:47, 11 January 2010 (UTC)
- Well, it does some prediction, assuming it keeps firing the same power, the enemy keeps firing the same power, and the distance remains the same, what could happen. It tries to explore a variety of scenarios of what the result of the next few waves (both self and enemy) could be, but since CPU is not unlimited it must limit it's depth of exploration, based on both depth and the likelihood of that possible branch of waves hitting/missing. When it gets to it's limit (which is a fairly small limit really), it falls back on a more heuristic calculation. Based on all this it finds the average expected score change from now to the end of the match, for a given firepower. So far it seems to work decent but it's much more difficult to debug than the old adaptive algorithm I developed in RougeDC. --Rednaxela 21:56, 11 January 2010 (UTC)
