Progress

Jump to navigation Jump to search

I've discovered that there are some really weird cases that happen when trying to run a Precise predictor on a bot that is already against the wall... and dealing with it properly means adding all sorts of extra distance checks into the code with extra sin()s and cos()s hanging out all over the place... it's an affront!

And it means sometimes the prediction angles are crazy tight, meaning that when those waves actually reach the real bot, it's well beyond them.. meaning Guess Factors >> 1 are getting into my data. Eww!

Blah.. Sorry. Just venting.

Tkiesel17:51, 31 May 2012

This is for a precise MEA calculation? One of the predictions I do in my precise MEA calculation is having the enemy move with wall smoothing, but ignoring wall collisions (he can just move outside the battle field). Getting stuck on the wall is never going to be the optimal way to reach the MEA, and precise MEA calculation is never going to be exact, so I just try a few predictions and take the max MEA I can find.

Voidious18:34, 31 May 2012

So you calculate wall-smoothed MEA without wall collisions? Interesting!

My intuitive guess about Escape angles is this:

naive MEA >= accel/decel-accurate naive MEA >= Wall-smoothed MEA ignoring wall collision >= Perfect implementation of Robocode physics Wall-smoothing MEA

(ignoring bot bounding box issues of course...)

So the tack you take is that the difference between those last two is too small to worry about the extra processing overhead of really getting it perfectly implemented? Or, (equivalent outcome, not equivalent motivations) that the last one is just too iffy to really get properly right, so settle for the second to last one?

This is good news for me! Maybe I can stop dashing my head against a stone here, and move on to getting the Wave Surfing happening finally! :)

Tkiesel18:47, 31 May 2012
 

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:User talk:Tkiesel/MovementPredictor/Progress/reply (3).

I like your algorithm as described on the MEA talk page. A nice, clean solution, and after a few extra iterations, I do think you probably bump up against the law of diminishing returns.

I think I'll give that a shot, it should blow some annoying cobwebs out of the code, not needing to jump through the hoops I was starting to jump through to get it right.

Tkiesel19:08, 31 May 2012
 

I'm refactoring this now, and just to be accurate, I actually don't ignore wall hits in the prediction, though I thought that was my intention. I wrote this code so long ago I'm not really sure if I screwed up the code or the original description! My old predictor didn't do wall hits right anyway, so either way would've been a bit off....

Voidious01:57, 13 June 2012
 

Well, I've got this code in a pretty workable state (I think) but I haven't done any unit tests on it like you have. Depending on how portable your new work is, I very well might consider jumping ship!

The pluggable orbit distance controller (which I also use to drive the bot itself) and the pluggable wave surf prediction ender (should be dirt simple for me to implement surfing until the first wave hits me, even if that's a different wave for CW and CCW) are both things I really like, and would like to offer though.

Tkiesel04:42, 13 June 2012