Author
Topic: Shot Projection/Position Prediction.. (Read 2926 times)

The simplest method would be using the velocity vectors as a distance factor over time, however many problems arrise in the bots that use these (enemies use circular paths / affect of gravity on the position of a bot / friction / changes in velocity (acceleration) and so on. So we begin from scratch.

A shot travels with a set speed one direction, and recieves a constant force in the direction that the gravity has been set. So to hit a target under the influence of gravity, and only gravity, you would not have to correct for anything (I.e. make the bot stop and shoot at it a lot). But say the bot has some defensive mechanism to travel left or right (relative to your bot) with gravity, any prediction (using averages - easier) would have to sum up the velocities over time, meaning a lot of memeory dedictted to the position of one bot, and would be very impracticle for long term predictions, but for a combat situation, time is relatively small. Provided the velocities do not change because the bot finds something else to do, a differnce in velocities would not be very accurate, so we will use theta (I.e. angle relative to yours). The immediate known angle would be 90 degrees, as their would also be a right triangle between your bot and the enemy bot, unless their x or y values are =. So if the bot apears to be headed for = x or y positions, a simple side (relative) shot would make up for that movement.

(((Sin (theta)) / (myx - yourx)) * velocity + (Sin (aimshot) / (myx - yourx) ) * 40) * time to shot hitThe following returns the distance (hypotenus) to the enemy bot over the time required to hit the bot. But no where does it account for the affect of gravity, but there is no need. So I've probably confused you, but the reason I bring up gravity is because it the same thing as circular momentum (which is how many bots maneuver anyways). It would be impractical to assume that a bot traveling in one direction will not suddenly change slightly for one reason or another, regardless of Gravity, it has to do with turns and vectors. The initial jump to maxvel in one direction, creates an inertia that continues acting on the bot even after it switches direction or velocity, and that inertia is not overcome until after enough force in the opposit direction has been applied. This means that a bot that does a 180 will drift somewhat backwards, making the shot a little more difficult. But say its a 90 degree turn, now the bot has some side drift, and the new velocity vector has a minimum affect on the previous inertia vector.

F = M * AThe above formula could be used to claculate a future inertia of a bot to the next second, as long as the acceleration does not change (or accelerate). In order to calculate this, one would need to record the velocities of the bot and the direction of the bots' active vector over at least 3 seconds.

F = M * A = M * (vel3 - vel2 - vel1) ^ tAnd yes, acceleration is to the power of time, derived using Sigma. Now we have an idea of the basic mechanics of the enemy bot's manuever functions, but no real way of telling how the bot will act. Algorythmic/Memory Mining Genes requrie a lot of variables to stored over the entire battle between a single bot, pushing for more short-termed style bots, but it's not very affective in the long run. As most of these variables most likely need to be used for some various important fact, (I.e. tie info). So then using some array established in the genes that record the enemy bot info for however many seconds desired, we can gain an idea for the path that the enemy has drawn. Most likely its circular or of some logorythmic function (not important). If its circular, their will be a common point of reference known as the center. Then there are radii and few other nice geometric functions to help us predict the next shot to make. So, the only method that would be practical to predicting if it is circular, requires three cycles of memory dedication at the least, 2 points of refence forms only a line, and will not be conclusive enough for any logic fuction. So we use our noggins and calcualte where this point lies (the center of their circular pattern, works for ovals and odd shapped things with circular bends I.e. uses some power of change). From that knowledge we can assume one of two things a), the bot is just going in a circle to find something or sees nothing or , the bot is about to do something unpredicted. If B is the case, we're SOOL, but if A is the case, then we have an easy target. We already know how fast it is traveling relative to ourselves, so we just take the conics formulas for a circle and plug and chug (conics are anything involving circles and other shapes found inside cones). Conics are your best bet always, there is no movement in nature which is not conical in form (regardless of friction), as the inertia caused by a movement is always there, so there are many forces acting against the goal vector of a bot.

Comparators of the differences of the points of position collected would show which conics formula to use. To make this more difficult, is the limitations of the eye and memory tool. It would be nice to record at the begining of a cycle a bots position, and then again at the end, this gives n cycle then n.5 cycle references and would be helpful with predicting accelerations of the enemy. But if you're too lazy for that and don't care about 98% efficiency, then just use Pythagorous and various points of reference. I mean things like last known position to most recent, or vel*angle + positions. Either system works, but Pythagoros does not include accelerations as accelerations are not linear, but exponential.

I have not included any ideas for genes because I want my Slim Evo to be able to out smart the bot community, but feel free to post any ideas and I will be glad to critque them. Also, I have not included any sources or theoroms, but that's because I can't find my theorom's list (plus everyone has different naems for each theorom). A more radical approach may be to use the Side Splitter Theorom, which uses a central point within a triangle, and a cricle can of coarse fit inside this triangle. The use of Geometry in DB would be way better than any algebra; but still the best would be calculous, but I don't have time for that, and I don't think imaginary numbers are supported in any version of DB.

I don't think Sin is suported either I couldn't find one when I was trying to figure out my angle from an oponents point of view... ended up just using the angle operator to find his angle and add 682...It still didn't help with my idea of having a controlled alge shoot at enemies... it's easy to find the enemy's angle from my own bot, but I can't get the angle from the alge without using sin or tan and I don't see them listed as operators and I don't know how to to do that manualy if it's even possible...But that was for my first bot (ebola) and I'm working on different ideas now anyway

I think guardian uses shot prediction... but it also causes heavy lag with just a few of them. (I guess you can't steal it without it being painfully obvious )

well, they are ratios with many decimal places, and decimals really were never supported. So then what about the Square Root function? How well does it work? Let me check my geo notes.... Good ol spark notes.

Ok. Using two or more eyes to accurately look at the target, we can form a number to be its width. The number really requires Sin and Cosine to work, but in our case we can just use the input from eyes to determine this. The bot should be dead center if your bot constantly tracks its every movements. You can assume that the number is not all, but each focuseye would have to cycle to accurately show whats in the area. We know the angle of them from us based on our aim, and the amount our eye has turned. The purpose of Sin Theta was to find a length to use, or a vector of velocity. One way to avoid the bot from getting away, would be to shoot two shots, one towards the left by some measurable value, and one in the direction it is already moving plus another measurable value. If that fails reproduce a leach and through it with a tie to the victim and have it feed and erturn nrg through the tie to the parent.. Either one is difficult, aiming or leaching, but are very effective.

Although if you really want sine and cosine, you can use polynomial approximations. I'm pretty sure that's what trafalgar did in Guardian.

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, then3. 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 then4. 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)

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;

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.

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.

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.

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.

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.