BotAim 2 announced. Best aiming ever.

[Pierre-Marie Baty]

I have worked out a new aiming algorithm, and I wouldn't be surprised if it was of the same level, or even better, than the official CZ bot. I based it on the same algorithm we use in electronics for commanding motion control devices (such as satellite orientation). It assimilates the player's hand to a spring with certain mechanical constraints, such as stiffness and damper.

Does that mean that it'll be included in RACC ? Hell yeah.

Does that mean that there'll also be chances that a new BotAim plugin be released soon ? VERY likely.

In the meantime, I invite you to toy with this little app I quickly wrote in LabVIEW (this thing is great for signal processing). The diagram is included, with the algorithm

http://filebase.bots-united.com/inde...on=file&id=246

Har Har Har. It won't be said that all the fun is happening without me

[stefanhendriks]

i checked it out, looks very nice

[@$3.1415rin]

you know what the motivation of the aiming system initially used in parabot was ? exactly the same just that damping and spring stiffness are related via stiffness + damping = 1. I think the main problem there was, that the damping was based on a fixed coordinate system, therefore this correction I added some days ago.

[Cpl. Shrike]

Very nice.
If im getting it correctly the aim will dead on target after the delay.

Is it possible to always keep aiming slightly off
Or keep sinusing around the 0 line (at variable amplitude) ?

[Pierre-Marie Baty]

Yes, it is possible to keep it off, there are several means. One is to prevent the combined angle speed to go below a certain absolute value, the other is to introduce a vector offset that changes from time to time.

You can also do other interesting things, like for example induce a different spring stiffness for the horizontal movement and for the vertical one (since it is easier for a human to move the mouse horizontally than vertically). You can also have the damper evolve over time, according to the acceleration for example. And finally, you can also make the X movement influenced by the Y movement and vice versa, like what I did with BotAim, but you have much more control over it than what was possible before.

@Joe: this algorithm is not quite identical as yours in fact ; not only the maths are MUCH simpler (no exponential nor logarithmics), but in yours the acceleration gradually increases then decreases ; here as soon as a new ideal angle is set, the mouse is "pushed" towards it and then slowed down, it is not "accelerated". This provides the bot with very quick reaction times.

[@$3.1415rin]

that exp log stuff ( or pow, whatever you like ) was just for the framerate compensation, since in my calculation the last results were taken into the calculation the next frame, thus not allowing me to take a simple division. but as I said, I cannot proove that, I can just justify it a bit.

just wanted to say that the idea is the same. dunno about your implementation and formulas, I think you havnt posted anything yet.
the mechanic analogon to my algorithm would look like m x'' + k ( x' - v0 ) + d ( x - x0) = 0 where v0 is wanted velocity and x0 wanted position. then one gets that k^2=4dm for the ideal configuration ( no oscilations ). but to keep things simple in old joebot, i just copied tobias code and made it better/worse whatever.

[Pierre-Marie Baty]

Originally Posted by Aspirin

just wanted to say that the idea is the same. dunno about your implementation and formulas, I think you havnt posted anything yet.
the mechanic analogon to my algorithm would look like m x'' + k ( x' - v0 ) + d ( x - x0) = 0 where v0 is wanted velocity and x0 wanted position.

Did you see the png file that I included with the zip ? the implementation is there, actually that's all there is

[@$3.1415rin]

ah right, not only fancy icons, but also some text

with that implementation you'll still have that problem with the moving target, that problem that i fixed last week in my algorithm. therefore I wrote ( x' -v0 ) in the DEq above that k^2 = 4 d m is right for both differential equations, since the oscillating part is part of the solution of the homogeneous equation.

but with that equations there in your png file, it's still "accelerated", like in my implementation, I still don't see a difference. anyway, it's a good idea to think about such stuff from scratch ( from scratch is somehow often a good idea ), currently I dont understand that exp log stuff myself.

[Pierre-Marie Baty]

here's the difference, if ASCII art allows me to explain it:

Yours:
 
ideal -------		 .-°-..-----
					 /
					 |
current ----- ____../
 
 
Mine:
 
ideal -------	 .-°-..-----
				 /
				 |
current ----- ____|

[@$3.1415rin]

it's not that black and white, since the spring doesnt allow you to bring all speed on the 'cursor' instantly, unless you have a infinite high spring constant.

anyway ...

I couldnt stop me from working also on this, so here a little info on the little I did ( works really nice btw )

Idea ( that's almost the standard spring with damping differential equation ) : m x'' + k ( x' - v0 ) + d ( x - x0 ) = 0 o_O
where we have

• x : the position of the mass ( in our case, the cursor ) or better, a function depending of time for the position.
• v0 : the velocity of the target to follow
• x0 : the position of the target to follow
• ... I hope you know what the ' are meaning. if not, that are the derivatives of x. x' is the change of position over time, i.e. the speed. x'' is accordingly the acceleration.

As always with differential equations, we search a function x which fits in that equation above, where that relation is true. This is usually done by searching the solution of the homogenous DEq, in our case that's m x'' + k x' + d x = 0. You can solve this with an exponential approach, i.e. you set x = exp( l * t ), put it into the hom DEq and divide by exp ( l * t ). This way we get a quadratic expression for l : m l^2 + k l + d = 0 which can be easily solved : l = -k/2m +- Sqrt( k^2 - 4 d m )/2m
Here the oscillations come into play : We know that exp ( i x ) = i sin ( x ) + cos( x ) and that exp(a) exp(b) = exp (a + b). Thus, if we get a l which contains i ( i = Sqrt(-1), called imaginary number ( dunno the english term )), we'd get oscillations. Since we don't wanna get them, we have to chose d and k accordingly. when we have k^2 = 4 d m, this is called the aperiodic limit, which means that if this is the case, this is the fastest way to get to 0 ( in our hom DEq ). if k^2 > 4 d m we'd still have no oscillations, but approaching will be slower. ( for aiming in the bot a little bit of oscillations might be acceptable since we have bullet spread, the punchangle stuff etc. )
the solution of the inhomogenous part of the DEq isnt of interest here since it's constant if v0 and x0 are constant. x0 isnt of course constant, since v0 is normally nonzero, but solving the DEq with x0 and v0 = x0' only gives nasty stuff ( at least that's what mathematica tells me ) which looks pretty nonoscillating, and the main interest here were the oscillations.

OK, enough ! I know how you like math, but I hope this is understandable, at least I tried 8D

float m = 1,
k = -1,
d = k*k / 4.f / m;
if(abs(m_VIdealAngles.y - m_VCurrentAngles.y) > 180){
if(m_VIdealAngles.y > 0){
m_VIdealAngles.y -= 360.0f;
}
else{
m_VIdealAngles.y += 360.0f;
}
}
m_VAnglesSpeed.y += (k/m * (m_VAnglesSpeed.y - m_VAngLookSpeed.y) + d/m * (m_VIdealAngles.y - m_VCurrentAngles.y))*m_fmsecCount / 1000.f;
m_VCurrentAngles.y += m_fmsecCount / 1000.f * m_VAnglesSpeed.y;
m_VAnglesSpeed.x += (k/m * (m_VAnglesSpeed.x - m_VAngLookSpeed.x) + d/m * (m_VIdealAngles.x - m_VCurrentAngles.x)) * m_fmsecCount / 1000.f;
m_VCurrentAngles.x += m_fmsecCount / 1000.f * m_VAnglesSpeed.x;
//---------------------------
if(abs(m_VIdealVAngle.y - m_VCurrentVAngle.y) > 180){
if(m_VIdealVAngle.y > 0){
m_VIdealVAngle.y -= 360.0f;
}
else{
m_VIdealVAngle.y += 360.0f;
}
}
m_VVAngleSpeed.y += (k/m * (m_VVAngleSpeed.y - m_VAngLookSpeed.y) + d/m * (m_VIdealVAngle.y - m_VCurrentVAngle.y))*m_fmsecCount / 1000.f;
m_VCurrentVAngle.y += m_fmsecCount / 1000.f * m_VVAngleSpeed.y;
m_VVAngleSpeed.x += (k/m * (m_VVAngleSpeed.x - m_VAngLookSpeed.x) + d/m * (m_VIdealVAngle.x - m_VCurrentVAngle.x))*m_fmsecCount / 1000.f;
m_VCurrentVAngle.x += m_fmsecCount / 1000.f * m_VVAngleSpeed.x;
m_VOutVAngle = m_VCurrentVAngle;
m_VOutAngles = m_VCurrentAngles;

( I thought tobias algorithm was based on this one, but if it is, it's a very rough approximation I think. anyway, that code is also used in other circumstances, e.g. in learning algorithms for neural networks etc. )