View source for Talk:Gilgalad

So, I added Gilgalad to the 1v1 participants list on Thursday, but it still isn't listed in the rumble, does anyone know if I did something wrong?--AW 20:12, 5 August 2011 (UTC)

Just fixed it for you. You put "aw.Gilgalad" on the participants page when your java class is actually "aw.Gilgalad.Gilgalad". --Rednaxela 00:19, 6 August 2011 (UTC)

Thank you, I will have to change that in the next version. --AW 18:08, 6 August 2011 (UTC)

So, I have been re-writing my movement over the past months and I have a question about the robocode physics. When finding the correct wave to log a hit as in onHitByBullet I could use:

(time - wave.getStartTime()) * wave.getBulletVelocity()

However onBulletHitBullet would need:

(time - wave.getStartTime() - 1) * wave.getBulletVelocity()

Does anyone know why this is the case? (My guess is that the onBulletHitBullet event is called on the turn after bullets hit while the onHitByBullet event is from the current turn but I would like to be certain.) --AW

Actually in my experience it varies far more then this, much to my annoyance. For a bullet bullet collision it is usually -1 or -2 offset and even that distance may be up to 11.5 off (regardless of bullet speed). The normal collision is usually same for normal collision as well. I have been looking for a more elegant way of handling these, but so far nothing has really presented itself. — Chase-san 19:55, 17 November 2011 (UTC)

The method I showed above seems to work 100% of the time. Are you using getHitBullet() or getBullet()?

When I try to match bullets to waves, I find the closest wave, and then consider it a match so long as (closestWaveDist <= bullet.getVelocity()*2 + 0.1). Pretty sloppy tolerance there, but I get by with it. -- Skotty 00:14, 20 November 2011 (UTC)

So I looked in the sources (BulletPeer.java) and it appears that for some reason bulletHitBullet events report the bullet locations from the previous turn. Weird, but now I know that my method should work. (If no other wave surfers handle this the way I do, that should probably be changed. Any thoughts?)

Well, if it's a bug, I agree it should be fixed. But if you match on the nearest wave that has a matching bullet power, you should be fine - you're guaranteed to get the right wave and the angle you record won't be any different. I also restrict my matches to waves within distance 50, as a sanity check - though I now realize that two power 3 waves could be distance 48 apart if the enemy is also moving full speed directly at my position when the wave intercepts, so I should decrease that. Hopefully if you're firing power 3 and moving directly at me, I'm sufficiently accurately blowing the crap out of you that this isn't a huge issue. ;) --Voidious 03:20, 20 November 2011 (UTC)

Does anyone know why Gilgalad, and many other megabots are now listed under minibots in the rankings page?

We discussed it about a month ago and agreement was that this it the bug in 1.9 robocode. I think we still have not reported it to developers.

I also noticed that the new robocode seems to run multi threaded (at least in 1.9.2). In my opinion this is not a welcome change, since it eats all available cores of my CPU. I used to run rumble, melerumble, and top 30 melee on my machine, but now they fight between each other and consume more than I want to spare for robocode.

There are a couple different uploaders presently. When some of them upload, it appears the codesize isn't respected. As soon as a couple others do, the big bots get pruned.

Well, I think my uploaders use to be (and probably still are) culprits. But I did not do any tweaking or modification of stock client. I was also under suspicion that even with mine, some of my machines were doing the correct size report and other were not. But they all have identical configs and java distributions.

The only thing which might be of importance: I run everything on OpenJDK, may be it has a different way to evaluate the code size.

Nevertheless, I stopped uploading for a week, so new wrong entries are due to new uploaders. May be we should look for correlation, and see what is the possible reason for the size misreporting.

Hi all. Apparently all we need to do is to report bugs to developers :) I did so and Fnl fixed it within a day.

I suggest everyone to upgrade to 1.9.2.2 and kindly ask Rednaxela to tune rumble server to accept client with this version and above.

It would be Skilgannon that runs the rumble server, not I. ;)

I've noticed that Gilgalad will sometimes throw a lot of ArrayIndexOUtOfBounds exceptions at the start of the first round when I pause robocode, hit restart, minimize, and unpause from the "Gilgalad console" window. However, it never happens if I start the battle from robocode, and then minimize it. Also, I saw some strangely low scores against Raiko mini in local tests (one as low as 15%) which may be related. I'll try to test on different JVM's, OS's and machines in the next few days, but I was wondering if you had any idea why minimizing the robocode window would do this?

Minimizing the window puts the engine in max speed. Might affect skipped turn detection.

Yeah, speed is the only thing I can think of. You aren't doing any threading or anything like that, are you? Because it could be something like race conditions if you are. Where is the ArrayIndexOutOfBounds being thrown from? I suggest you do try/catch around all errors, and write them to disk so you can check them out later.

Also, avoid testing against Raiko (mini) if you can because it saves data. Rather test against RaikoMicro, or do something about that data-saving, like modifying Raiko or deleting the files each time.

Yeah, from experience I know the CPU being pushed will cause more skipped turns, though you get the impression it should be immune to that. I usually attribute it to the CPU measurement being inaccurate and the high load exacerbating it somehow. You'll also skip more turns against a CPU heavy opponent.

One interesting thing I've found with BerryBots is that when I'm drawing graphics, bots take about twice as much CPU time. I've guessed it has to do with memory or CPU cache misses increasing when it's switching between robot code and graphics code. I could imagine a similar change in cache behavior when a CPU starts experiencing high load - maybe the Robocode engine code is what stays cached in that case and so your bot takes longer. But I'm just speculating and don't really know that much about CPU cache behavior.

Well, I'm not entirely certain and I don't want to spread false information, so we'll just wait until Rednaxela fills us in...

Regarding my problem, it was indeed related to skipped turns. I have a record of the enemy's positions and I use it to check the wave intersection with the enemy robot after I retroactively set the bullet powers. Skipped turns caused me to miss the entries on some turns, resulting in the OutOfBoundsException.

But this led me to think of another question. In PIF guns, how do you deal with the end of a round. Do your logs just jump to the next round or do you keep separate logs for each round or what?

Thanks for the help!

Any PIFs that hit the end of the round I discard. I pull a bigger cluster than I need and just do the first N that work.

Keeping separate logs for each round is more accurate, but with bigger codesize as well.