Server Help :: View topic - AI bot problems

Server Help

Bot Questions - AI bot problems

Anonymous - Fri Nov 07, 2003 4:21 pm
Post subject: AI bot problems

Been working on an AI bot by having a bot send in keystrokes to a continuum client.

Problem 1:
Getting it to turn correctly to an angle. Here's the code I'm currently using:

Code: Show/Hide

#include "ExternalPrgController.h"

StartPriority(); // sets thread to high priority

for (count=0; count < turnangle; count++)
{
keybd_event (VK_RIGHT,0,0,0);
Sleep (29);
keybd_event (VK_RIGHT,0,KEYEVENTF_KEYUP,0);

EndPriority(); // ends high priority
}

The problem is it turns inconsistently, sometimes several angles off. Without high priority its even worse, real time priority isn't noticably different. Need a way to match something to the time it takes to turn 1 angle in SS. Sleep(29) is the closest thing I've found, large for() loops, using windows time ticker, etc are all more inaccurate. Anyone know a better way than Sleep(29)?

Problem 2:
Getting the angle to turn to fire at an enemy. Current code:

Quote:

BYTE fireangle = TriangulateFireAngle(bot->work - p->work, p->vel - bot->vel, settings->ships[bot->ship].BombSpeed / 1000); // bot = me, p = enemy

BYTE TriangulateFireAngle2(Vector &rel)
{
double dx = -rel.x,
dy = rel.y;

if (dy == 0)
if (dx > 0)
return 10;
else
return 30;

double angle = atan(dx / dy) + PI;

if (dy >= 0)
{
if (dx >= 0)
angle -= PI;
else
angle += PI;
}

return BYTE(angle * 40.0 / TwoPI);
}

BYTE TriangulateFireAngle(Vector &pos, Vector &vel, Sint32 scalar)
{
// pos = relative positions
// vel = relative velocities
// scalar = velocity of bullets

double a = vel.x * vel.x + vel.y * vel.y - scalar;
double b = 2 * (pos.x * vel.x + pos.y * vel.y);
double c = pos.x * pos.x + pos.y * pos.y;
double time = (-b - sqrt((b * b) - (a * c * 2))) / (2.0 * a);
if (time <= 0.0)
time = (-b + sqrt((b * b) - (a * c * 2))) / (2.0 * a);

return TriangulateFireAngle2(Vector(pos.x + Sint32(double(vel.y) * time), pos.y + Sint32(double(vel.y) * time)));
}

Thats mostly copy/paste of the built in merv code used to autofire when put in a ship. Can anyone explain it in physics/trig? Does it work when both ships are in motion? If not thats what I need.

Problem 3:
Need more physics formulas to calculate non-linear flight paths. Example: ship is flying along and wants to fly to some point. How to map that path without making the bot stop and then fly in a line to that point.

Problem 4:
During movements mervbot doesn't get any incoming information, which is usually .5 - 1.5 seconds. There an easy way to fix that? Add another thread? Pipe information to another bot?

Problem 5:
Takes too long to calculate fire angles, etc.. by the time its calculated and the ship has moved inches and the angle is off. Need a faster way to calculate angles or someway to compensate.

source code:
http://www.hardwerk.net/dueling/bots/ai2
(use !fly x (secs) or uncomment sections out of spawn.cpp (player move, weaponfire, ball move) etc.. still heavily in testing, bot needs sysop or lags out, settings.ini = first line = continuum window name, second line = player name to control)

Cyan~Fire - Fri Nov 07, 2003 5:24 pm
Post subject:

Tough stuff, but there is one thing I can suggest (I know this means redesigning part of it): Use the 'me' bot struct and just manipulate the position/angle there, not by keystrokes. Keystrokes will always be ineffecient.

Dustpuppy - Fri Nov 07, 2003 6:40 pm
Post subject:

I think you missed the entire point of the post.

50% Packetloss - Fri Nov 07, 2003 6:46 pm
Post subject:

ekted answered this on ssforum.net

Cyan~Fire - Fri Nov 07, 2003 7:15 pm
Post subject:

I wasn't answering any of his questions (except maybe 5?), I was just suggesting a different method.

Mine GO BOOM - Fri Nov 07, 2003 11:58 pm
Post subject:

The problem you are having with the aiming delays is that you are not predicting their current positions. You have to take the times into effect. How I did it with my aiming bot is as follows.

Hopefully the bot core records the time from the position packet. You then have to take the difference of the now time (or the future time, if you plan on shooting after a short delay) and the time that position packet said it was valid for. Hopefully again, either the bot core converts the position packet's time into your local clock, so you can use GetTickCount(), or has a function to return the current server clock. Either way, it should return something small, like 20 - 200. This is the same value Continuum places next to player's names, if you turned that option on.

Now, take their speed, multiply by the time, divide by 10000 (I think speed was in pixels / 10 seconds, and the timing difference should be in milliseconds), then add their current X/Y position to that. Thats their current estimated position. If you want to get all fancy, you can record their accerations, thus predicting curves, but first do this simple vector calculations for now.

That should fix your slight angle delays, assuming the math in the function is correct. Using Sleep + sending keystrokes is going to be bad. The only way to really overcome this is to make your own physics engine local to your bot, and not require a third-party client to do it for you. This would also fix your problem of the delayed information for positions.

For the flight path, you'll need to work on collision detection, as you'll end up flying through objects sooner or late. If you do this, you'll be making for own little gaming engine, which is what I am recommding you do for the above steps too.

This is why I stopped at the turret aiming bot. Anything more requires a great deal of effort and time.

Now that I'm thinking of it, you could always see if Continuum does its control actions via Windows's command system. A program I can recommend for easy testing and recording of this information would be Girder. Check out some examples of how it can control other programs, and you should get the hang of it. If this method works, you should be able to tell Continuum movement commands in a more controlled method.

Dr Brain - Sat Nov 08, 2003 12:15 am
Post subject:

But what you really want is to extrapolate their movement into a function, then use calculus to find the firing angle so that the bomb will hit them, and not just fire at their last position.