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)