Talk:Geomancy/Version History

Version 2: Velocity Manipulation While Enemy Is Aiming

Just keep in mind that their movement is going to be delayed by 2 ticks, once for them to read yours, then change, and the next for you to read their changes. But so far it sounds good =) --Skilgannon 16:35, 5 July 2009 (UTC)

I hadn't thought of that, but of course you're right. Building that delay into the design will allow me to use a tighter tolerance on detection. -- Synapse 19:45, 5 July 2009 (UTC)

Just interested, did you add the 'snapping' to your precise prediction? And to clarify, you reach the 8,4 or 0 2 ticks before they fire? Have you made a test bot that prints out the enemy velocity that it uses to aim with, ie. the tick before the bot fires, to make sure it lines up correctly? Wave Surfing is difficult to wrap your mind around, I'm just going over the mistakes I think I'd be most likely to make =) --Skilgannon 21:33, 12 July 2009 (UTC)

I didn't add the snapping to my precise prediction yet, but watching the factors as they are surfed, the impact seems to be minimal. I reach the 8, 4, or 0 mark two ticks before they fire, and maintain it the tick before they fire. I tested the timing with the new method AdvancedRobot.setDebugVariable, and confirmed that it was lining up correctly. I haven't set up a grapher yet to see what it makes my profile look like, but that's another way I could confirm that it was doing its job. -- Synapse 21:40, 12 July 2009 (UTC)

Cool =) Although, I'm guessing unless you add it to your precise prediction (ie. X ticks forward I will change my velocity to Y...) any gains you make due to shrinking the enemy's data will be offset by having bad predictions. Would you believe, in an early version of DrussGT, correcting a 3 pixel error in my precise prediction caused me to jump about 10 places in the rumble. And that was before I had a decent stats buffer system, surfed the second wave, or anything. IMHO, until you get within less than 1 pixel of '100% accurate', there is a HUGE amount of unrealised potential in your bot. I would suggest adding the snapping to your precise prediction before doing any further development, and then comparing the 2 versions side by side. You should see a very big difference in their performance, especially against the weakest bots where your stats system can do a 100% job and the rest is left up to the prediction side of things. But ultimately, if you want a top bot, anything your bot does in real battle, you need to add to the prediction. --Skilgannon 22:20, 12 July 2009 (UTC)

Based on your advice I may add precise bot width calculation too. -- Synapse 22:37, 12 July 2009 (UTC)

It looks like things went downhill with this release. For the next one I'll remove this and focus on testing for surfing precision and adding precise bot width. -- Synapse 06:03, 13 July 2009 (UTC)

Wave Surfing Rolling Depth

From 50 to 15!?! Quote: "For what it's worth, I think even 3 is a high rolling depth in movement. If I were using just one depth on all my stats, it would be 0.7 (and used to be). Right now, I have a variety of depths ranging from 0.5 to about 5. I'd definitely encourage experimenting with some lower depths, at least on the hiseg. --Voidious" [from oldwiki:DrussGT] DrussGT currently has a rolling depth of 0.1 - 3 (3 only use for a very few buffers, most of them are 0.1-0.7) Komarious use 0.7, IIRC. » Nat | Talk » 11:31, 10 September 2009 (UTC)

Yep, the early versions of DrussGT had a very high rolling depth and didn't score very high, what helped was increasing the number of buffers and lowering the depth a lot. --Skilgannon 12:05, 10 September 2009 (UTC)

Ha! Hahahaha! Yes!! I've now added in much lower variable rolling depths for the different segmentations, based on how heavily segmented they are. I'm seeing immediate, appreciable gains against adaptive enemies like Portia, Diamond, and Shadow. -- Synapse 12:55, 10 September 2009 (UTC)

Getting good results also from variable rolling depth on the gun - depth ranging from 80 to 40 - with fired waves at weight 4 vs non-firing at weight 1. I think I'll drop version 7 right now and let it run while I sleep. Thanks again for the tips guys! -- Synapse 13:28, 10 September 2009 (UTC)

On an off-topic note, this has been one of those truths that I've found difficult to translate into DC-surfing. First instinct is to use age as a dimension or to discard old data, but neither is really the same: a low rolling depth will replace data quickly when there's new data, but won't just throw it away for no good reason (in less-visited segments). There's probably just no analogous solution on the DC side, and I just need to free my mind. =) --Voidious 14:07, 10 September 2009 (UTC)

I had some success with a 'hits logged' dimension. However, how about having a VCS system which stores the scans, and you have a max 'bucket size, so after X scans are added to a bucket you remove the oldest scan in that bucket from the tree? By altering the max bucket size you could effectively alter your rolling depth. --Skilgannon 14:59, 10 September 2009 (UTC)

I've had some success in just using the 50 most recent scans, but not the "magic bullet" kind of success I've had with a 0.7 rolling depth in my VCS buffers. Your idea of a VCS system for deciding which scans to remove is really interesting, I might play with that. A similar idea I had (while writing my previous comment =)) was instead of just removing the oldest scan, remove one of those that is closest in distance to another scan, so the points left would cover a wider range of situations. That might be a terrible idea, if you end up with mostly data about rare situations, but I may still try it. I still think it might be counter-productive to try and "translate" these ideas from VCS to DC, though... (thinking of Neo: "Right, no problem, free my mind, free my mind, no problem, right... " =)) --Voidious 15:19, 10 September 2009 (UTC)

Getting kind of off topic here, but how about removing the scan which is closest to the one you are adding? That seems like it would give the same results as the VCS rolling average but without any of the discrete bucket issues VCS brings along. --Skilgannon 17:28, 10 September 2009 (UTC)

Yes! And in comparison to just removing a point with a close neighbor, that would also save you from calculating a ton of distances each time, or keeping running stats on the nearest neighbor to each point in your data set. A single nearest neighbor search would be really fast. I like it! (Should we move this off-topic thread to Talk:Wave Surfing?) --Voidious 17:40, 10 September 2009 (UTC)

Version 7 battles that puzzle me

Geomancy 7's worst problembot is myl.micro.Troodon 1.10. In battles on my computer, with either Robocode 1.6.1.4 or 1.7.1.2, Geomancy 7 routinely gets a score approaching 99%. Something similar happens with one other new problembot, lrem.Spectre 0.4.4. Locally I get scores around 70%, but the result from the rumble is much lower. Am I missing something? -- Synapse 08:14, 11 September 2009 (UTC)

You got a battle from spinnercat's client that says you got 44%. Are you sure Geomancy didn't crash? --Skilgannon 09:40, 11 September 2009 (UTC)

I haven't been able to duplicate it locally, even using the Rumble-approved client 1.6.1.4. I checked memory consumption too, thinking maybe with the recent additions to my segmentation I might be using more memory, but that's not the case that I can tell either, since Java memory during the fight seems to cap out at 100mb after it's been doing other battles for a while. -- Synapse 18:20, 11 September 2009 (UTC)

It's probably a bad result from spinnercat's client - maybe he was running something CPU-intensive at the time and it caused your bot to skip a bunch of turns or even get disabled? I've posted a request on http://robowiki.net/wiki/Talk:Darkcanuck/RRServer#Bad_results for Darkcanuck to remove it for you =) --Skilgannon 19:38, 11 September 2009 (UTC)

GF/WS Bins

I'm not sure about this, but shouldn't the number if bin be an odd number? Because the middle bin would be GF0 and the first and last bin will represent GF±1. If we use an even number of the amount of bins, we won't have anything to represent GF0. » Nat | Talk » 11:03, 12 September 2009 (UTC)

For hitting an unmoving opponent, the bins on either side of 0 work nicely, and it protects me from opponents like GeomancyBS :-P -- Synapse 15:53, 12 September 2009 (UTC)

Flatteners and Testing on Low Sleep

I should have set the flattener to only kick in when I was losing badly. Since it's always running to a degree in version 8 I lost a lot of score in little nibbles from the whole left end of the field—all the completely predictable targeters. I've changed things so the flattener is left disabled until it's actually needed. That's what I get for doing my testing while I'm falling asleep! -- Synapse 16:32, 12 September 2009 (UTC)

I think many top robots trigger its flattener on enemy hit rate. Sometimes it is still winning, but it enable the flattener to reduce enemy hit percent, which will reduce enemy bullet damage score. I know that many robocoders carefully calculate the enemy hit rate and carefully choose the hit rate to enable its flattener. To choose the hit rate which trigger flattener, just battle it with the weakest robot you want it to enable the flattener on. (IIRC, Skilgannon use Ascendent) » Nat | Talk » 02:37, 13 September 2009 (UTC)

"Geomancy has been stopped"

I'm getting quite a lot of these errors for Geomancy 10 in my RoboRumble clients:

synapse.Geomancy 10 has been stopped.  No score will be generated.

Watching battles at normal speed, it didn't happen, but when I cranked to 300 FPS, it did. It was at the end of a round every time, so I assume it was the garbage collection. I'm not sure if this affects the score or not, but I thought you should know either way. Nice victory dance and ramming of disabled opponents, btw. =) --Voidious 21:37, 14 September 2009 (UTC)

Thanks for the compliments! I'm still considering ways to perhaps leave less garbage for the VM so the call to GC is less disruptive. The original problem was when garbage was being automatically collected in the middle of a fight, so Geomancy would be disabled and removed from the battle. You can see the problem even more often if you put Geomancy against a rambot like GrubbmThree, so the matches go by quickly. Unfortunately, I can't blame version 10's score problems on skipped turns any more! I have a lot of battles to watch and a lot of testing to do. -- Synapse 01:57, 15 September 2009 (UTC)

The skipped turns are caused by my intelligence module - I just recently added proper onWin and onDeath handling so I can collect the statistics that are in the queue when I win or die. It turns out something happening in that module is preventing actions. I'm not sure yet but I'll know soon. -- Synapse 05:50, 15 September 2009 (UTC)

I was doing something artarded when I saw an enemy dying - when I saw an enemy die I'd set its last seen field to Long.MAX_VALUE for some reason, which was causing issues if the enemy was dead. No idea why I did that either. -- Synapse 06:09, 15 September 2009 (UTC)

v15

Very nice jump! And welcome back. =) --Voidious 21:36, 19 March 2010 (UTC)