User talk:Pedersen

Welcome :) this text could bee mine apart from grammatical mistakes i would have made. The only thing i read was the CircularTargeting Turtorial!! And i have no mini micro or macro Bot :D --Krabb

I got a call from a former customer interested in reviving a project I had worked on, so I'll be busy reviewing where I left off and what I can do with the project for him. I'm also actually being tasked with real work lately at my day job. Consequently it will likely be a while before I find any time to make any tangible improvements to Ugluk. I'll still be checking in on the Wiki though several times a day, and I'm available on IM for random gabbing. -- Martin

I have started using RobocodeSG and your testbots. This really is much easier than using RobocodeGL!! Would you mind publishing the code for painting the bullets and waves? --Loki

Sure thing. I posted it under Ugluk/RobocodeSG. I'm sure you'll need to modify it to meet your implementation. I've got a lot of my physics stuff in it. -- Martin

Thanks to my work on Roland v0.2 I found a glitch in my wave timing and the energy management of the test bots. I'll update them shortly. -- Martin

The three test bots have been updated with more precise inbound wave tracking, including the addition of a box around the firing position. They will also no longer fire without the turret being aimed. -- Martin

If I pick up the reins of Ugluk again, one of the first things I'll do is create an interface that hides all of the blocking calls (e.g. fire() ) so that they aren't used by mistake, and cast my AdvancedRobot using that interface. That should reduce the errors introduced by calling the simpler Robot methods. I was looking at the Radar thread and it reminded me of an issue where I was missing scans and getting my bullet projections out of sync because I was calling the wrong method while trying to place a bullet in the queue. -- Martin

Grr. I'm having trouble finding out the maximum storage capacity allowed by the RobocodeFileWriter mechanism. -- Martin

Ok. I've spent hours and hours, and some hours on top tracking this down. When a bullet makes contact with an opponent, it doesn't go straight in. For whatever reason, the final position is neither the normal angle nor normal distance from the previous position. What this means is that the bearing from a bullet's point of origin to its final position is not an exact match to its heading. And I'm not talking an issue with precision of doubles. The significance of this is that I was trying to match my onHitByBullet events with the wave that fired the bullet, and I couldn't do it based on the bullet's heading. There are other ways to determine it, with less confidence, but it sure was frustrating and shook my faith in the foundations of my wave infrastructure (which I have since found was flawless all along). Here is an example of some debugging output:

[30] Firing shot from position: ( 185.0126, 245.5766 ) bearing: 0.3912
A: ( 232.6758, 361.1327 )
B: ( 237.2175, 371.7775 )
Vector: 0.40327927217322446, 11.57313768145533
Bullet: 0.39120829168722615, 12.5
Bullet heading is not consistent.

-- Martin

I don't have the source anymore - so this is a wild stab in the dark - but perhaps Robocode sets the (x, y) of the bullet to that of the enemy it hits upon collision? -- Simonton

I've checked that, and it isn't it. It appears the bullet becomes stuck to the tank and moved with it once before you even get the event. I've translated the bullet back to the alleged point of impact (based on the opponent's change in position) and it's pretty close, but not dead on. I've decided to move on for now. I am able to associate the bullet with the originating wave with a good deal of confidence. It just irks me that there's no explanation for it yet. -- Martin

Have you considered using setFireBullet() & storing a referance to the bullet object in the wave it represents? Then search your waves for the given bullet when one hits - 100% confidence. Or better yet, use a HashMap of bullet objects to waves. -- Simonton

Phoenix uses a HashMap to look up bullets for its VirtualBullets system. Just do HashMap.put(bullet, gun) when you fire and you can get the gun back in onBulletHit and onBulletMissed to update the gun's scores. Highly recommended! =) --David Alves

"The significance of this is that I was trying to match my onHitByBullet events with the wave that fired the bullet"
I am trying to determine the firing position of the bullet. I have all firing positions because I am already tracking waves created by my opponent. The problem lies in being absolutely sure that a bullet belongs to a wave. In order to be satisfied, I wanted to be able to take the bullet's point of impact and project it back along its heading (in reverse) to see if it runs through the center of any waves I have. (I am simplifying my logic for explanation.) It never matches. I've tried comparing the bearing from the wave to the tank's start and end positions, the bullet's position and the bullet's position translated back to where it hit the tank (since apparently they stick to the tank). None of them worked well enough. The closest (translated back) was still off by about 0.04 to 0.1 radians. That bugs me. I've taken a looser approach so I can move on, but there's something screwy going on. -- Martin

That is strange, but you can just use a HashMap to associate bullets with waves. =P --David Alves

Yes, but I think you are looking at bullets from the setFireBullet method. That is only available to the person firing the bullet, not the person being hit by it. -- Martin

Oh, you're talking about enemy bullets? I match those to waves by bullet power and by how close the wave is to the position of impact. E.g. If I get hit by a bullet, I check what waves are closest to me and see if any of them have the same power as the one that hit. If so, I have a match. --David Alves

That's what I ended up doing. It isn't as clean as matching on bullet heading and velocity (i.e. power), as I wanted to do. -- Martin

Martin, please, do slightly easier with "some redundant versions". You have been deleted some not redundant versions. -- DemetriX

• Can you give an example? If you want something put back in, you are welcome to put it back on the list. -- Martin
• Was about to ask the same, all of Martin's removals seem valid to me... -- Voidious

Today I wrote a Java utility to remove old versions of robot jars from the robots directory. For some reason I can't get it to run from the command line, but when I finally ran it from within Eclipse it was done in under 2 seconds and had moved 187 files to an archive folder. Most of these were various updates from myself, voidious, wcsv, chalk, davidalves, pez, demetrix, and others who have updated regularly over the past few months. It also caught some versions that are redundant in the rumble or across rumbles (e.g. different versions for melee vs. duels). I'll work on a new version that will pull a listing from a URL (i.e. participants list) and move everything not on that list to the archive, as well as moving the extracted jar files from the .robotcache directory. This would allow some easy hot swapping between the roborumble and meleerumble with the least overhead in terms of loading jar files. I don't know how soon I'll get around to finishing it and releasing it as a general use tool. -- Martin

Nice tool, I still cleanup the robots directory by hand. Maybe I put together some Perl-script to automate it. The .robocache directory is automatically cleaned up everytime Robocode (or RR@Home) is (re)started. -- GrubbmGait

• The client will clear out old cache entries, but it has to extract them over again if you are only moving the jar files around and not the extracted classes. I want to move both to minimize the extraction process. -- Martin
  • Therefor I have separate 'installations' for oneonone, melee, team and own development, but the tool would still be handy for me to cleanup the old and obsolete entries. -- GrubbmGait

Yeah, very cool, I'd definitely make use it if / when you release it. I basically don't clean up my robots directories save every once in a great while, and they really do pile up... -- Voidious

Ok, I wrote the tool. It basically moved everything in /robots (except the roborumble folder) and /.robotcache into an archive, grabs the participant list you feed it (roborumble or meleerumble .. team rumble won't work I think), and then moved all of the participants that you have back into the /robots and /.robotcache folders. I am sure it will have some quirks, such as if the file system prevents a file move for any reason. It's not written to be really robust. The file is here: <a href="http://home.comcast.net/~kokyunage/robocode/RumbleCacheTool.class">Rumble Cache Tool</a>. If you execute the class it gives you the following usage instructions:
Welcome to the Rumble Cache Tool by Martin Alan Pedersen.
This utility requires two parameters: the path to your rumble installation, and the URL to the participants listing.
Usage example: java RumbleCacheTool c:\roborumble http://robowiki.net/cgi-bin/robowiki?RoboRumble/Participants
-- Martin

For example, serenity.serenityFire 1.27, that today was reverted to the rumble -- DemetriX

• "serenity.serenityFire 1.28 test" is a newer version of "serenity.serenityFire 1.27", and they were both entered at the same time. I am not trying to offend anyone. I cleaned up about 12 listings that were clearly old versions of the same basic bot. There are a few others to be cleared up, but their owners are not around, I think. -- Martin

You've just passed me in the RoboRumble contributors list. Now it's on :D Christopher.Hilla 21:19, 6 February 2010 (UTC)