Difference between revisions of "Talk:LittleBlackBook"
Jump to navigation
Jump to search
(HunRobar response.) |
(Rednaxela response.) |
||
| Line 4: | Line 4: | ||
: Math.signum() off e.velocity screws up 0 velocity checks and I have no velocity averaging. I'll check other bots for inspiration though. Has to be TINY though | : Math.signum() off e.velocity screws up 0 velocity checks and I have no velocity averaging. I'll check other bots for inspiration though. Has to be TINY though | ||
: What about... <code>static double foo = 1; foo = e.velocity + 0.01*foo; foo /= foo;</code>? Not sure if that would be small enough, and I haven't checked it's codesize, but I think it's smaller than any others ways to handle that which come to my mind. I think it's smaller than <code>static double foo = 1; foo = (e.velocity == 0) ? foo : Math.signum(e.velocity);</code> anyway, since conditionals and function calls are expensive if I remember right. I'd also suggest seeing if you can get rid of the need to normalize the value to 1/-1 all together, but that may not be possible in this case. --[[User:Rednaxela|Rednaxela]] 04:15, 15 June 2009 (UTC) | : What about... <code>static double foo = 1; foo = e.velocity + 0.01*foo; foo /= foo;</code>? Not sure if that would be small enough, and I haven't checked it's codesize, but I think it's smaller than any others ways to handle that which come to my mind. I think it's smaller than <code>static double foo = 1; foo = (e.velocity == 0) ? foo : Math.signum(e.velocity);</code> anyway, since conditionals and function calls are expensive if I remember right. I'd also suggest seeing if you can get rid of the need to normalize the value to 1/-1 all together, but that may not be possible in this case. --[[User:Rednaxela|Rednaxela]] 04:15, 15 June 2009 (UTC) | ||
| + | :: Anything having to do with statics are expensive. Your above code is probably around 25 bytes or so. Math.signum(e.getVelocity()) is 6 or so. I can easily fix my problem by adding +1 to the e.getVelocity() check on the inside of the gun( for 2 bytes)... But! It will only hit perfect stop/go 50% of the time as it is setup to use the velocity to know how far to lead. Also, bots like FretNano who have good guns, but get stuck on walls randomly, would then be unhittable. I get 1 lead value per distance segment at the moment. I've got a few ideas on how to improve this, though it will double+ the size of my string table. I will adhere to the 200k max limit and with 1000 or so bots to profile, I have to be careful on size. | ||
Hi! Awesome results! Now that I looked at the code, I think there is one little problem with the overall concept: every time a new robot or a new version of a robot appears, you have to update the stats in your bot. --[[User:Robar|HUNRobar]] 10:31, 15 June 2009 (UTC) | Hi! Awesome results! Now that I looked at the code, I think there is one little problem with the overall concept: every time a new robot or a new version of a robot appears, you have to update the stats in your bot. --[[User:Robar|HUNRobar]] 10:31, 15 June 2009 (UTC) | ||
Revision as of 15:47, 15 June 2009
Congrats!
Congrats! It's nice to see some movement in the nano scene lately. I was pondering predefined data bots myself actually. I'm curious though, you say "Any perfect dodge stop and go will kill it", which seems odd to me. It should be quite trivial for a distance/lateral segmented GF gun to hit that I'd think... --Rednaxela 01:51, 15 June 2009 (UTC)
- Math.signum() off e.velocity screws up 0 velocity checks and I have no velocity averaging. I'll check other bots for inspiration though. Has to be TINY though
- What about...
static double foo = 1; foo = e.velocity + 0.01*foo; foo /= foo;? Not sure if that would be small enough, and I haven't checked it's codesize, but I think it's smaller than any others ways to handle that which come to my mind. I think it's smaller thanstatic double foo = 1; foo = (e.velocity == 0) ? foo : Math.signum(e.velocity);anyway, since conditionals and function calls are expensive if I remember right. I'd also suggest seeing if you can get rid of the need to normalize the value to 1/-1 all together, but that may not be possible in this case. --Rednaxela 04:15, 15 June 2009 (UTC)- Anything having to do with statics are expensive. Your above code is probably around 25 bytes or so. Math.signum(e.getVelocity()) is 6 or so. I can easily fix my problem by adding +1 to the e.getVelocity() check on the inside of the gun( for 2 bytes)... But! It will only hit perfect stop/go 50% of the time as it is setup to use the velocity to know how far to lead. Also, bots like FretNano who have good guns, but get stuck on walls randomly, would then be unhittable. I get 1 lead value per distance segment at the moment. I've got a few ideas on how to improve this, though it will double+ the size of my string table. I will adhere to the 200k max limit and with 1000 or so bots to profile, I have to be careful on size.
Hi! Awesome results! Now that I looked at the code, I think there is one little problem with the overall concept: every time a new robot or a new version of a robot appears, you have to update the stats in your bot. --HUNRobar 10:31, 15 June 2009 (UTC)
- And a decent problem it is. I'm going to review the string libraries today to see if I can find a "closest to this name" type function for my search. That'll at least handle versioning. The version in there right now is using default behavior against Pugio because my table is setup for 1.40. When all your other versions get cleared from the rumble, my rating will go up another .5 or so. --Miked0801 13:38, 15 June 2009 (UTC)
Nice! I may re-release Ocnirp 1.0 to screw your stats =) Updated Wikipedia page for you now. » Nat | Talk » 12:00, 15 June 2009 (UTC)
