Bots and Simulations > Tips and Tricks
Shot Projection/Position Prediction..
Trafalgar:
--- Quote from: abyaly ---Although if you really want sine and cosine, you can use polynomial approximations. I'm pretty sure that's what trafalgar did in Guardian.
--- End quote ---
What Guardian did was:
1. Determine how far away a target bot was and what its relative x and y velocities were, estimate how long it would take a shot to reach that position,
2. Estimate where that bot would be at that time if it had continued moving at its current speed, then
3. Estimate how long it would take a shot to reach that second predicted position, and then where the target would be at that time, and then
4. Calculate the angle to fire a shot at in order to strike the third predicted position at the time when it was estimated the target would be there.
In order for that to work, I had to measure how fast shots moved in F1 conditions, and how the firing bot's speed affected them. It turned out that (IIRC) shots moved at 39 units per tick relative to their firing bot, or something like that.
Things I'm not sure of at the moment:
1. Would it work on sims with gravity? Theoretically it might do OK with buoyant bots and others that aren't beginning to freefall - if shots aren't affected by gravity.
2. Does it work on sims above 32000 x or y size?
3. Does it still work at all on smaller sims?
4. Is the shot speed still correct?
It was defined like this: (These are essentially macros, and yes, this results in a lot of code duplication but no stores)
--- Code: --- define nextrefxpos: refxpos+((refveldx*dist(refxpos,refypos))/39)
define nextrefypos: refypos-((refvelup*dist(refxpos,refypos))/39)
define betternextrefxpos: refxpos+((refveldx*dist(nextrefxpos,nextrefypos))/39)
define betternextrefypos: refypos-((refvelup*dist(nextrefxpos,nextrefypos))/39)
define fixedangle: angle(betternextrefxpos, betternextrefypos)
define range: (dist(betternextrefxpos, betternextrefypos))
--- End code ---
It used range to decide how much to power up for distance shots, and whether to even fire at all.
gymsum:
I've managed something even simpler. It uses .sx and distance to correct a shot. Since I programmed the default circle maneuver around an enemy always to one direction, I simply used these three store commands;
*.refvelsx *.velsx sub 1 add mod *.maxvel -1 rnd 1 mult .sx store
*.refxpos *.refypos angle .setaim store
*.refxpos *.sx add *.refypos angle .aimshot store
I'm not yet sure if negatives are supported in .sx and .dx, but if its at all like pleasure or pain they should be inverse of each other. The problem that is inherent shows up in more chaotically maneuvering bots, the change in direction or speeds can result in errors, as was inherit with Guardian. I'm still working out the kinks for a sytem similar to the behvior learning genes, only it would provide adaptable tactics.
Trafalgar:
--- Quote from: gymsum ---I'm not yet sure if negatives are supported in .sx and .dx, but if its at all like pleasure or pain they should be inverse of each other. The problem that is inherent shows up in more chaotically maneuvering bots, the change in direction or speeds can result in errors, as was inherit with Guardian. I'm still working out the kinks for a sytem similar to the behvior learning genes, only it would provide adaptable tactics.
--- End quote ---
Negatives are supported in .sx, .dx, .dn, and .up. Guardian maneuvered using only .dn and .sx (and made sure .up and .dx were set to 0).
As for targetting chaotically moving bots, in order to really move sufficiently chaotically to confuse aiming, you have to be small, and small bots are difficult to hit to begin with.
--- Quote from: gymsum ---*.refvelsx *.velsx sub 1 add mod *.maxvel -1 rnd 1 mult .sx store
*.refxpos *.refypos angle .setaim store
*.refxpos *.sx add *.refypos angle .aimshot store
--- End quote ---
Edit: Say, it looks like you've made a mistake (or more than one) in that code you pasted. Firstly, you're missing a parameter to %, aren't you? And the first parameter to the first angle seems to be maxvel, which you put on the stack before setting sx to rnd(-1)*1, and I don't know why you are doing the *1, or whether rnd(-1) does something useful.
This is what I got when I tried to translate it (manually):
--- Code: --- MISSING PARAMETER % ((refvelsx - velsx) + 1)
sx = rnd(-1)*1
setaim = angle(maxvel, angle(refxpos, refypos))
aimshot = angle((refxpos+sx), refypos)
--- End code ---
Numsgil:
Shot speed should be bot's firing speed + 40 units per second (1/3 of the default robot diameter or radius (can't remember which) of 120). That you arrived at 39 is interesting.
gymsum:
I'm not calling for sysvar 1, I wanted to add 1 to the difference of refvelsx and sx so that when it returns 0, 1 is used instead. I used -1 rnd 1 because I thought that was the syntax for random values, oh well, it makes the sx store either left or right with a 50/50 chance. It needs fixed. But it was intended to wrap the speed difference between two bots around the maximum velocity, so it doesnt overstore velocity.
Also, the number you used seems to be a nice and true ratio in geometry.... It seems to be the projection of the bots radius to the hypotenus, or the adjacent/opposit leg, or in the case of right triangle A-B-C where angle AB is 90 and theta is angle BC/CA. Anyways, it seems to follow Kepplers Golden Triangle Dimensions, which are taken from the half of the GOlden Square dimensions, which are actually formed inbetween two points connected by an arch. In other words, its the perfect geometric targeting system I can say I've seen yet. Its not quite the results in the theorom, but DB deoesnt support floating points. Brillant design inginuity their, he took something from algebra and applied its physical properties to the dimensions of two orbiting bots; its actually the future of modern warfare, orbital mechanics.
Sources WIKI:
A golden rectangle is a rectangle whose side lengths are in the golden ratio, 1: (one-to-phi), that is, approximately 1:1.618.
A Kepler triangle is a right triangle with edge lengths in geometric progression. The ratio of the edges of a Kepler triangle are linked to the golden ratio
and can be written: , or approximately 1 : 1.2720196 : 1.6180339.[1]
Images of formulas did not carry. Anyways, using only geometric means, the guardian has an effective targeting calculation of about 70-80% which is extremely efficient for such a simple bot.
Navigation
[0] Message Index
[*] Previous page
Go to full version