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)
