Archived talk:User:Nano 20090519
- Nano Sub-pages:
- Nano - Archived Talk 20090519
|
It took a year before anyone corrected that spelling on the ReadMe page. I'd say that we now have taken the next step in wiki-land. =) -- PEZ
Wall smoothing is heavily dependent on your implementation of movement. How to do it for an orbital movement that selects direction and angle of attack is completely different from a movement that selects points. One good example is in RandomMovementBot. The general principle is to translate your point of impact back inside the acceptable battlefield, head to it, translate the subsequent point of impact, and so forth until you're perpendicular to the wall. -- Kuuran
I suppose that that is the algorithm for WallSmoothing if using a go-to movement, however, most rotation is done per tick (in an attempt to stay perpendicular to the enemy), and in this case it becomes impossible to merely translate the point of impact. When I attempt something like this, I have problems with bouncing back and forth between two angles (the one inside the battlefield and the one perpendicular to the enemy). Has anyone had this problem and developed a good solution? -- nano
As I said, RandomMovementBot has something like this. But when you adjust to the new angle aiming at inside the battlefield you should still be headed for a wall collision, that's not actually gone until you've come parallel to the wall. Ensure that your normal movement code can't assert it's angle if there is wall collision impending and ensure that you're aiming for the legal portion of battlefield closest to the point of impact and you shouldn't be having this problem.
RandomMovementBot closes on the enemy if a wall collision is impending and moves away from the enemy at all other times to achieve the smoothing effect. It just sets an optimal distance and shrinks it until it's projected movement isn't leaving the battlefield. The turn to close to the distance from the enemy that's still inside the battlefield (basically the distance between the enemy and the wall) is also the turn required to just miss the wall, for obvious reasons. Either method should provide the results you're after.
-- Kuuran
"When you adjust to the new angle aiming at inside the battlefield you should still be headed for a wall collision." This just doesn't make sense, unless by "headed for a wall collision" you mean "aimed toward a wall", which is always, of course, true. If you translate some line projected in front of your bot to be inside the battlefield, it follows that that line is now inside the battlefield, and thus by definition, you are not headed for a wall collision. Thus the next tick will not use the correction as it should, and will instead rotate into the wall (to be more perpendicular to the enemy). This oscillation between the two angles is evident in all three of my attempts at real-time WallSmoothing (that is, not using goTo). It is obviously just a bug in my code (or perhaps a flaw in my approach), but I will look into this again in a few days. For tonight I am running the TC again with a new stat segmentation algorithm. My fingers are crossed. -- nano
There's nothing in RandomMovementBot's WallSmoothing approach that depends on a goTo() function. I just happen to use goTo() to give the right setAhead() and setTurn() commands, implementing BackAsFront while at it. RandomMovementBot uses an orbital movement approach that could do very well without the goTo() for driving around. What RandomMovementBot assumes is that its enemy is inside the battle field. A reasonable assumption, in'it? =) -- PEZ
Obviously your approach is wrong. I don't see why you're so hung up on goTo(), as PEZ said, but anyway, if you translate your destination inside the battlefield all you're doing is wall avoidance. When you head for the point nearest the point of impact unless your angle of approach was extremely shallow you're still going to be heading for a wall collision, just at a slight delay, until you've finished the smoothing and are riding the wall. Prevent the perpendicular to your opponent angle from asserting itself while this is happening and project your movement before applying the select change in angle (after picking the angle before putting it into setTurnRightRadians() or whatever use that angle to project if you're going to have to smooth with it, and do so before it asserts itself). -- Kuuran
You could regard RandomMovementBot's way of doing WallSmoothing as a flexible "blind mans' stick" with a little wheel at the end. RMB is sticking out this stick in the direction it wants to move. When the stick hits the WALL_MARGIN it "folds" and "rolls" towards the enemy until it has room to extend to its full length. Then the bot moves there. Does this make sense? It is how I came up with the technique to begin with. -- PEZ
Yes, that's the approach I am using (projecting a "stick" in front of my bot and translating it inside the battlefield). I will look at RandomMovementBot's code more closely and see how I can translate it to my code. Thanks much for the help! It sounds like this is much easier than my failures at coding it had led me to believe. -- nano
Just making sure it is clear; RMB does no translation of the destination point. It just iteratively moves the end of the stick closer and closer to the enemy until the stick end is inside the battle field (with some margin). I think this is much better than translation. Like Kuuran says, that's just WallAvoidance, not WallSmoothing. Check Tityus movement code for a way to control just how much smoothing you dare do. -- PEZ
Yes, that is the idea I meant to communicate. My first attempt did do this "translation" by mathematically translating the point instead of iterating over closer and closer angles, but my current attempt follows the pattern you describe. Hopefully I can get this fixed by the end of tonight so that I can move on to more interesting things. :) -- nano
Thanks for the help again, and the firm bludgeoning! After reading Raiko and RandomMovementBot's wall-smoothing code I finally got mine to work. My problem? I had a bug in my getAngle function (to get the absolute bearing between two points), in that it did not return Robocode angles. That didn't matter for my stat gun, but it mattered everywhere else. Now Unnamed's movement is siiilky smooooth. I also implemented a neat bullet-power selection algorithm and my patented segment-balancing algorithm (which actually only helps my aim a very little bit, but it does help). Next step: some semblance of a good movement. I may try a little CoolMovement + adaptive movement, we'll see if I can get anything to work. -- nano
