User talk:Tkiesel/MovementPredictor

I posted what I used to test my prediction here: User:Voidious/LocationBot. Basically it's a bot that records its movement along a bunch of random paths and prints the input (start location / heading / velocity, movement commands) and output (final location / heading) that you'd need to pass to a precise prediction unit test. (Actually it prints the actual method call so you can just copy/paste it into a unit test, if you sync it up with your method name and parameter list.)

Thanks! I'll use that to suss out any MovementPredictor bugs.

The whole thing is probably far far less than ideal in performance terms.. but the pluggable prediction ender and pluggable distance controller are features I liked adding for the purpose of letting people plug this into their own bots. :)

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.

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.

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! :)

Well, actually I think #4 could be > #3 - wall smoothing is not the way to get true MEA, turning and moving directly to the farthest point you can reach is, but I use wall smoothing w/o wall collisions as an approximation as I try to iterate towards the max MEA. The full algorithm I use is here: Talk:Maximum_Escape_Angle/Precise#Calculating.

But yeah, I think getting close to precise MEA is good enough, and GFs barely > 1 aren't really the worst thing, although obviously can result in shooting at unreachable spots in situations where your MEA is accurate. At the same time, just because I settled doesn't mean you have to... =) My current method has room for improvement, and it is one of the things I consider revisiting in Diamond's gun.

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.

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....

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.

Anyone have a favorite license they'd like this work to be under? Nat's original is Public Domain.

Nothing wrong with public domain. =) I've been using zlib, and I also like MIT. A common one on the wiki (which I also once used) is RWPCL. I actually posted some thoughts on licenses a while back here: Archived_talk:User:Voidious_20110909#Choice_of_license. It's definitely up to personal preference.

zlib, MIT and Creative Commons Attribution all look nice to me as "credit where credit is due" permissive licenses.

The smoother method I'm hoping to use is from a talk page here on RoboWiki. RoboWiki:Copyrights is blank, so I'm not sure how to proceed with that code.

Should have this code in a testable state, hopefully with a test painter bot to squash bugs this weekend or on Monday, depending on how life goes.

Anything without a license listed is probably free to use as if it's public domain. I think we stumbled on deciding on a license for wiki content because so much of it was added before any license was specified, so it seems wrong to try and retroactively add a license. Very good point that we should update RoboWiki:Copyrights, though, given how prominently it's displayed.

I've just capped off all of deBroglie's files, including the MovementPredictor with a zlib notice.

I added a clause to two files regarding not using the code in programming competitions without my consent. Those two files are a bit more uniquely "me" (or at least represent a lot more of me bashing my head against the wall) than the rest.

As of the next release, deBroglie will be a majority zlib bot. :)

Thanks for the food for thought!

I never thought someone would actually use my code, so I never got around posting the improved version. I'll try to do that for you soon (as soon as I can find the code)

Though the core movement function hasn't changed, and my improvements probably wouldn't affect your expansion, it does include (what I believe to be) some cool features. GoTo-wrapping is one, another is method to find possible sequence of 'PredictionStatus' from one status to another over given time. It is extremely useful in melee battle, though I haven't test if it give better result than simple linear-prediction.

That's wonderful! I'd love to incorporate your improved version, and hopefully the work I've done will be useful to you and others here on RoboWiki!

I've got precise MEA up and working, including an example bot. I've put it into DeBroglie so I can see how it looks with real firing waves, and enemy bots sometimes do get outside of the marked angular bounds on the wave. Something to debug here...

The wall smoothing freaks out a bit when a bot intentionally goes for the wall.. and its especially touchy with a bot like sample.Walls.