http://geeksrobots.googlepages.com/home With developmental versions!
Sorry! Unfortunately, the source for v. 1.0 to 1.8 has been lost. All later versions will include source.
Welcome to the wiki. =) No shame in losing to any of the Duelists, all of David's bots are impressive. Good luck with your bots! -- Voidious
Welcome! A next-step-up from fast targeting would probably be PatternMatching. Imagine your iterative circular targeting, but instead of keeping the delta-heading and velocity constant, you change them each iteration with data you recorded from what they did last time they were in a situation similar to the current one. Kuuran put an excellent description on the PatternMatching page on how to store your patterns symbolically in a String, so that you can use Java's String.substring() and String.indexOf() fuctions to search for previous patterns, making the whole thing a lot less painful. Good luck with your Robocoding endeavours! -- Skilgannon
Welcome! The behaviour of your current botversion does have a familiar ring to it ;-) Just keep in mind that when it comes down to it, movement is more important than targeting. Have much fun with improving your bot! -- GrubbmGait
Thanks all. Right now I've managed to convince myself that moving in ovals would annihilate everything that's fairly simple, but it's not working too well. The robot that has the oval code in it DOES move in an oval, but it still gets nailed by DreamBot's targeting system. No, it doesn't revert to HeadOnTargeting. That would make me feel a whole lot better about it. If I can get it to work, I'll put it in DreamBot, with some tweaks to make it deal with PatternMatching guns. Are there any pages appropiate to discuss that? At Skilgannon: why do you think I made my CircularTargeting system work like that? Something else; Robocode doesn't seem to be packaging the source in the .jar file. Does anyone know why (the checkbox is checked)? -- Geekgymnast?
Well, moving in ovals of most sizes, are either going to involve moving close-to-straight most of the time, or moving in circle-like arcs most of the time, depending on just how oblong the oval is. So pretty much any possible oval is going to get hit well-enough by either linear or circular targeting. As far as packaging the source, I think it might require the .java and .class files to be in the same directory but I'm not certain of that. --Rednaxela
I tried to give it a symbolic pattern matcher, but it doesn't work. Also, the radar has been slipping, so I gave it the FACTOR lock...but now nothing else works (!!??). The new version does, however, have a nice new structure without the sloppy looking turnGunToTarget?(EverythingButTheKitchenSink e) {...}. If I really wanted to temporarily remove the pmc, I could with "//" before 1 specific line. Once I get the FACTOR lock working, I'll make that PatternMatcher wish it had worked from the start. -- Geekgymnast?
From what it sounds like, you are calculating how long it would take for your bullet to get to the enemy, iterating that many ticks forward, calculating for the new one, and iterating forward again. This can still leave you slightly inaccurate, especially if they are moving away and towards you a lot. What is better is to iterate forward, but as you are iterating calculate how far the bullet could have traveled at this time. Once the bullet has traveled a further distance than the distance from the firing point to the predicted position you stop iterating. Take a look [here] for an example. -- Skilgannon
It does do that, in v. 0.1.9 (at least, it did until I implemented the FACTOR lock. Why did that mess it up???). The CircularTargeting works perfectly. My SymbolicPatternMatcher and FACTOR RadarLock? are what is giving me grief. The PatternMatcher misses repeatedly, but I cannot figure out why. The new radar lock somehow is stopping everything else. -- Geekgymnast?
![[Home]](/images/RoboWiki.png)