[Home]Muffin/Questions

Robo Home | Muffin | Changes | Preferences | AllPages

Difference (from prior author revision) (minor diff)

Added: 9a10,13

Jim, I think the direction is accounted for. If you look again you'll see that the first subtraction can end up either positive or negative, depending on the direction of lateral movement. As long as the sign there correlates to the sign of the direction stored in his waves (or the sign used when firing virtual bullets), then it should work. That is what I'd look at first. I would calculate the bot's current direction using:
(getAccumulatedLateralVelocityAt?(currentTime) - getAccumulatedLateralVelocityAt?(currentTime - 1)) < 0 ? -1 : 1
So that it can only be the same sign. My other speculation is that (currentTime - fireTime) is not necessarily equal to (targetDistance / BULLET_VELOCITY), and that may be a source of inaccuracy. You should probably use (8 * (currentTime - fireTime)) instead. (This is assuming I know what fireTime is. ;) -- nano

Can anyone explain to me why I'm getting funky results with this function for GuessFactor determination...?

I'm trying to find a decent alternative to the asin(8/11) method.

int bin = (int)(((getAccumulatedLateralVelocityAt(currentTime) - getAccumulatedLateralVelocityAt(fireTime)) / (8 * targetDistance / BULLET_VELOCITY)) * BINS_PER_SIDE + BINS_PER_SIDE);
It seems to like to either fire wide or on the wrong side (behind when it should be in front) depending on how I have it set up, but I can't get it to quite nail targets. Can anyone forward an explanation or should I just assume I have a bug elsewhere? -- Kuuran

I am more of a mimic than a prophet when it comes to these things so take what I say with a grain of salt. I do not see you accounting for target direction in your calculation. This could be the source of not firing in the right direction very often. At the risk of insulting your intelligence, you need to account for target direction in your GF gun so that +1 is always in the same direction relative to your targets movement. If he is moving left to right (clockwise and robocode positive direction) around you, then you need +1 to be to the right (positive direction). As you may well imagine that all flips for left to right movement. You can look at BlackPearl/Code for my calculation of eDirection to see how I do it. Also, using 2 X BINS_PER_SIDE which to me intimates that you are using an even number of bins. This may work but it leaves no definitive bin for GF zero. I would imagine that hitting a target there at a distant range may be difficult. I hope that helps some. -- jim

Jim, I think the direction is accounted for. If you look again you'll see that the first subtraction can end up either positive or negative, depending on the direction of lateral movement. As long as the sign there correlates to the sign of the direction stored in his waves (or the sign used when firing virtual bullets), then it should work. That is what I'd look at first. I would calculate the bot's current direction using:

 (getAccumulatedLateralVelocityAt?(currentTime) - getAccumulatedLateralVelocityAt?(currentTime - 1)) < 0 ? -1 : 1
So that it can only be the same sign. My other speculation is that (currentTime - fireTime) is not necessarily equal to (targetDistance / BULLET_VELOCITY), and that may be a source of inaccuracy. You should probably use (8 * (currentTime - fireTime)) instead. (This is assuming I know what fireTime is. ;) -- nano

Robo Home | Muffin | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited February 16, 2004 16:43 EST by Nano (diff)
Search: