.:: Bots United ::. - Bot Aiming

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- General Bot Coding (http://forums.bots-united.com/forumdisplay.php?f=24)

- - Bot Aiming (http://forums.bots-united.com/showthread.php?t=3179)

because KWo asked me to tell something about bot aiming, I started some pages in the wiki.

http://wiki.bots-united.com/index.php/BotAim

not yet finished, also no error reading yet, but comments or €diting would be fine nevertheless

I commented a bit what I could understand...

At the moment, i'm pretty sure the framerate independant stuff isnt correct. it works, ok, but it can hardly be mathematically correct. added some comments and a little bit of an explanation in the wiki

I guess I can work on that over christmas, or on my 7,5 hour trip back to my parent's place :)

I was wanting to use Fitt's Law to create an aiming offset for bot aiming, I guess it could be adapted to 3d environment, it's currently used for analysis in HCI on 2d planes to get probabilities of peoples ability to hit a button on a screen.

check out Fitt's Law : http://ei.cs.vt.edu/~cs5724/g1/glance.html

I'm sure you've heard of it, ever had a look? (Just the fact it's quite well known and has been tried & tested)

Really this is what you want to use for multiplayer gaming bots, afterall we're simulating real people trying to hit a target with their crosshair on a 2d screen.

If I understood good - sPlOrYgOn made something to have botaim depanding of framerates and we have tested it at slower and faster computers. This part seems be OK. Look into podbot source to see this sPlOrYgOn's tweak.

hm, downloaded http://www.geocities.com/scarletspid...Bot-Manual.zip and it looks like that's also based on my code, just having added some if statements to avoid bad behaviour on low fps systems.

€: also checked those links you posted after this, but they are offline, or telling something about contacting the billing department :)

The latest podbot source is here:

http://www.mapzap.org/files/podbot/podbotsrc.zip

or You can take it directly from sPlOrYgOn's PC:

http://splorygon.game-host.org:8080

the latest source doesnt differ in this aspect with the source I got from the link I posted.

that one (in my geocities site) is proabably 2 builds old

i have to update all the stuff :S

I'm so happy :)
It's Christmas and I've finally figured out what made the aiming look so strange...

Lets say theres a bot that wants to turn all the way around because there was an enemy on a raised platform behind him..
He'd move his crosshair up then to the right or the left (depends which is faster) then move his crosshair back down right near enemy..

if it was a human in this situation.. he'd turn to the right or the left (depends on which one he thinks is faster) then move his crosshair up at the enemy..

I noticed this on cs_assault when the bot was facing away from the warehouse and there was an enemy on roof and also when the bot was on the roof and enemy was on ground it'd turn down and up to aim at enemy..

then again this info has almost nothing to do with the algorithm made by @$3.1415rin and Killaruna, but is has something to do with the thread('s title).

this is something in Michael Booth's docs about the official CZero bot, it seems to be different from the above algorithm, also I don't quite understand it

(the greek characters just messed up if I post it as text so I have to post it as picture)

ok, he looks at the speed, which isnt a bad idea neither. It's pretty similar to my code, but in my code k and d are a directly related ( k = 1-d ). looks a bit scary though since dw is normally used when having differentials, which he does not ... anyway, might be a simpler way to go, avoiding this time expensive log / exp stuff when calculating time independant angels instead of their derivatives. gotta put that to my win32 aiming test application :)

Quote:

time independant angels

Feeling metaphysical, aspirin ? :)

didnt knew my own code that well ... my code actually is the same, just that I think there is the need for framerate dep d and k

if you run around a bot using this aiming algorithm with a constant angular velocity, you won't be hit ( if momentum, speed are not at instant aiming and the bullet spread isnt that big :D ).

some more info : http://johannes.lampel.net/joebotxp/botaim/index.html

the difference between the current angle will stay at a constant value, see diagram 1. This difference is related to the speed as (1-c)*currentSpeed. Thus the last diagram is the corrected one, which should allow a bot to kill you when you are running around a bot :D. so just a bit of correction is needed, and of course a local storage of the current state of the algorithm, before correcting :)

Code:

float a=.95,  // momemtum

 idealSpeed,

 c=.02,   // overall_speed

 aNow,   // recalculated momentum based on framerate

 fADiff;

float fmsecCount50 = m_fmsecCount / 50.0f;

float fAngleChange;

fADiff = abs(m_VIdealAngles.y - m_VCurrentAngles.y);

if(fADiff>180.0f){if(m_VIdealAngles.y > 0){m_VIdealAngles.y -= 360.0f;}

 else{m_VIdealAngles.y += 360.0f;}}

// compute the ideal angle speed (i.e, the amount of turning we WOULD want to do)

idealSpeed = (m_VIdealAngles.y - m_VCurrentAngles.y);

idealSpeed = idealSpeed*c;

// compute the new momentum given the previous one

aNow = exp(log(a) * fmsecCount50);

// compute the angle speed (i.e, the amount of turning we will actually achieve this frame)

m_fAngleSpeedYaw = m_fAngleSpeedYaw*aNow + idealSpeed*(1.f-aNow);

// calculate how big the actual angel change is

fAngleChange = m_fAngleSpeedYaw * (fmsecCount50);

m_VCurrentAngles.y += fAngleChange;

// ((1.f - c) * fAngleChange) to compensate 'shooting behind enemy'

m_pEntity.getEntity()->v.angles.y = m_VCurrentAngles.y + (1.f - c) * fAngleChange;

at least it's better than before, but I gotta test it in more different situations ... testing aiming inside the game isnt funny :)

the more i think about this exp log stuff, the less sense it makes ....