Tempest Bot [v5_3]

[MTK5012]

you need someone tthat is good with math? I am taking honors geometry, I know quadratics, algebra, and geometry. I can also do very basic trigonmetry.

ggod,calculate the demo aim code

[Orpheon]

you need someone tthat is good with math? I am taking honors geometry, I know quadratics, algebra, and geometry. I can also do very basic trigonmetry.

All right. You could try making an automatic node-generating algorithm, or you could find a direct way to calculate the demo aiming code.
I'll give you details later, right now I'm a bit pressed for time.

Hey Orpheon! I noded the maps ctf_truefort and ctf_2dfort. Here they are!

truefort
http://www.mediafire.com/?9ocnbw1o471p2x8

2dfort
http://www.mediafire.com/?17l3trwibbqrb1l

Great!

[Machidro]

you need someone tthat is good with math? I am taking honors geometry, I know quadratics, algebra, and geometry. I can also do very basic trigonmetry.

Real men take calculus 

But in all seriousness, right now, the equation to be solved is the demoman sticky arc, and knowing that arc, having the demoman aim where a player is going effectively.

The equations tougher than it sounds, and has to be solved by the computer in real time. Good luck.

[Green Wolf]

you need someone tthat is good with math? I am taking honors geometry, I know quadratics, algebra, and geometry. I can also do very basic trigonmetry.

Real men take calculus 

But in all seriousness, right now, the equation to be solved is the demoman sticky arc, and knowing that arc, having the demoman aim where a player is going effectively.

The equations tougher than it sounds, and has to be solved by the computer in real time. Good luck.

thanks. The equation is pretty simple as far as quadratics go, but the problem is calculating the variables.

[Orpheon]

you need someone tthat is good with math? I am taking honors geometry, I know quadratics, algebra, and geometry. I can also do very basic trigonmetry.

Real men take calculus  

But in all seriousness, right now, the equation to be solved is the demoman sticky arc, and knowing that arc, having the demoman aim where a player is going effectively.

The equations tougher than it sounds, and has to be solved by the computer in real time. Good luck.

thanks. The equation is pretty simple as far as quadratics go, but the problem is calculating the variables.

Actually, when I tried calculating it, I came on a x^4 equation.

The main problem is that you have a cos() and a sin() of the searched angle. So you need to replace some stuff.
Say sin(alpha)=u; then cos(alpha)=sqrt(1-u^2)
That translates to a lot of pain when you put it in here:

enemy_x +enemy_hspeed*time = your_x + hor_speed*time

Thus:

time = (enemy_x-your_x)/(hor_speed-enemy_hspeed)

hor_speed is the horizontal speed of your projectile, which means it's cos(aimDirection)*speed

Speed of course is a constant (12 in the case of mines), and so is gravity.

So now you have "time" as a function of aimDirection.

enemy_y = your_y + time*vertical_speed + gravity*(1/2)*(time^2)

A bit of inserting:

enemy_y = your_y + (enemy_x-your_x)/(hor_speed-enemy_hspeed)*vertical_speed + gravity*(1/2)*((enemy_x-your_x)/(hor_speed-enemy_hspeed)^2)

enemy_y = your_y + (enemy_x-your_x)/(cos(aimDirection)*12-enemy_hspeed)*sin(aimDirection)*12 + gravity*(1/2)*((enemy_x-your_x)/(cos(aimDirection)*12-enemy_hspeed)^2)

Now you can solve that to aimDirection, and you're all set.

enemy_y = your_y + (enemy_x-your_x)/(u*12-enemy_hspeed)*sqrt(1-u^2)*12 + gravity*(1/2)*((enemy_x-your_x)/(u*12-enemy_hspeed)^2) --> u=cos(alpha)
or
enemy_y = your_y + (enemy_x-your_x)/(sqrt(1-u^2)*12-enemy_hspeed)*u*12 + gravity*(1/2)*((enemy_x-your_x)/(sqrt(1-u^2)*12-enemy_hspeed)^2) --> u=sin(alpha)

Ugh.

[Orpheon]

Every time i try to read your coders coding, a part of my brain dissolves.

This isn't code. This is math.

Code is a ton simpler, believe me. It's actually figuring out what the computer should do in exact terms, and then finding out why it isn't doing it, that's hard.

The actual coding resumes itself to "if this then that", "while this do that" and some occasional array/list stuff.
Oh, and stuff like "draw_circle()".

[Green Wolf]

I found a way to create demo aim code. Good demo men can judge where the mine will land, give or take a little, just by looking at the angle of the gun. So how about this. If distance to target is between x and y, aim z amount of pixels above target. This will also mean that the bot is not accurate 100% of the time, just close. This gives the appearance of the intuition found in good demomen. By using a similar code in the other bots, we can make them be just as good as a human player,  because they won't  hit all the time.

[MTK5012]

I tried it and i think orpheon did it too.i failed.it's possible but idk how yet

[Unsung Hero]

In addition, it'd be tedious to calculate the position at which you should launch a sticky, for you also need to factor in whether or not you're moving forwards, backwards, or just staying still.

[Green Wolf]

stickybombs travel at the same speed regardless of whether you  are moving or not. Also, for the intuition code, just play as demoman with one other person, have them stand still, and record where you aim based on where you target is. I'll do it for you if you want.

[Orpheon]

The problem is that it changes to the distance to the target :/

I want a clean way to calculate it.

[Machidro]

The problem is that it changes to the distance to the target :/

I want a clean way to calculate it.

Take the instantaneous slope between you and the target using the equation, plugging in X and Y to calculate the theta of the angle, with X and Y as inputs with your answer in terms of the guns direction?

You could probably use the Atan2 with the output of the above equation to calculate the angle to aim your gun at.

[Orpheon]

The problem is that it changes to the distance to the target :/

I want a clean way to calculate it.

Take the instantaneous slope between you and the target using the equation, plugging in X and Y to calculate the theta of the angle, with X and Y as inputs with your answer in terms of the guns direction?

You could probably use the Atan2 with the output of the above equation to calculate the angle to aim your gun at.

So basically, guess, and then try to correct it?

The old demoman script

It might actually work if I had a good way to guess.

[Green Wolf]

to determine where the bot aims, just create a series of 9 invisie nodes that move with the bot. So taking into account that the bot is in the ceter of the scree, the first node is a a half a screen away from bot (at the edge of screen). The second node would be halfway between the third node and first node. the third node will be halfway between bot and first node, and fourth node will be halfway between third node and bot. Mirror this on the otherr side of the bot, then place a  node on the bot. 9 nodes. When a target comes within a nodes area (meaning it is closer to one node than another) the bot will aim at a predetermined point above the node, the aim point being decided through trial and error ( I suggest using lorgan'a pluginloader because of it's plugin for drawing the path mines will follow). After that we just determine what priority targets are.

[Orpheon]

The problem is that it changes to the distance to the target :/

I want a clean way to calculate it.

Take the instantaneous slope between you and the target using the equation, plugging in X and Y to calculate the theta of the angle, with X and Y as inputs with your answer in terms of the guns direction?

You could probably use the Atan2 with the output of the above equation to calculate the angle to aim your gun at.

So basically, guess, and then try to correct it?

The old demoman script

It might actually work if I had a good way to guess.

Found an equation system on wikipedia that may help, called the angle of reach.



So, whatever gg2's gravity acceleration rate is, compared to the target's polar distance, at an initial velocity of 10 (Stickybomb speed). For distance, you could just plug in the point_distance output from self to them.

I went over the way to solve this problem with my calculus teacher, along with movement prediction. I can't remember the steps of his proof, should have wrote them down. I'll ask again tomorrow if he's feeling patient.

Woah what? This compensates for current enemy hspeed?

to determine where the bot aims, just create a series of 9 invisie nodes that move with the bot. So taking into account that the bot is in the ceter of the scree, the first node is a a half a screen away from bot (at the edge of screen). The second node would be halfway between the third node and first node. the third node will be halfway between bot and first node, and fourth node will be halfway between third node and bot. Mirror this on the otherr side of the bot, then place a  node on the bot. 9 nodes. When a target comes within a nodes area (meaning it is closer to one node than another) the bot will aim at a predetermined point above the node, the aim point being decided through trial and error ( I suggest using lorgan'a pluginloader because of it's plugin for drawing the path mines will follow). After that we just determine what priority targets are.

That's unflexible, and you need far more than 9 nodes, since you need several in all directions.