fundynamic/realbot

Counter-Strike 1.6 - AI Opponent

The fundynamic website is now hosted by Wordpress, this repo is made public for archiving purposes

Fundynamic

The homepage of Fundynamic (http://www.fundynamic.com) is open-sourced here.

(Of course) I build my own website and while I do so I learn new things. Like grunt, bower, throw in some bootstrap and so forth. Its a great learning experience and at the same time benifitial for me in multiple ways.

Feel free to fork/clone/etc this branch.

Getting started

Make sure you have npm installed. See https://www.npmjs.org/

Make sure you have Grunt installed. See http://gruntjs.com/getting-started

Make sure you have bower installed. See http://bower.io/ -- or npm install -g bower

After your dependencies are set up, run: npm install

Development

Simply run grunt watch and start developing, and view results from build/*.

realbot's Issues

Crash after changelevel

There is a bug in NodeMachine.cpp that causes hlds to crash after the map changes several times. The error report states that an Access Violation has occurred. Removing the offending lines from the code fixes the crash, but it cripples the bots' navigation system. The exact error is:

Unhandled exception in hlds.exe (REALBOT_MM.DLL): 0xC0000005: Access Violation.

The error occurs in this function:
void cNodeMachine::AddToMeredian
on this line:
if (Meredians[iX][iY].iNodes[i] < 0) {

Headshot rate for RB bots are too high

Looks like bots have a very high rate of headshots.

See also: http://forums.bots-united.com/showthread.php?p=67217

Deal with func_illusionary

Related to #28

So this is what I know:

The fences are func_illusionary:

And in code dll.cpp around Spawn_Post there is already a piece of code that unsets some flag. However, that deals with windows. Ie, everything with a render mode: kRenderTransTexture.

However, the func_illusionary are actually drawn with rendermode kRenderTransAlpha.

Now, having tested this by adding the following:

        (pent->v.rendermode == kRenderTransAlpha && strcmp("func_illusionary", STRING(pent->v.classname)) == 0)) { // func_illusionary on cs_italy uses this rendermode

to the if statement and then nothing, makes them still undetectable by a trace_hull or trace_line. But.. when I add this:

        pent->v.solid = SOLID_BSP;
        pent->v.movetype = MOVETYPE_PUSHSTEP; // this seemed to be the best choice, does not do much

the trace_hull and trace_line do find them. Which is nice and good. But when applying this to the level, there is strange behaviour:

the leafs are also func_illusionary and they become solid and at the floor. Hence you can't walk through them making that path unplayable.

Also, this would probably make cs_747 unplayable as well because it would make the curtains solid. So that won't be an option for #28 :/

So what other options are there?

This is just a brain fart:

• perhaps we can remember which entities we have altered, do some tracelines at the beginning to determine if node connections (neighbours) are blocked by anfunc_illusionary, then remove the changes again and we have some metadata?
• another way would be to not change anything, but enhance the 'trace' detections? Perhaps we can add the entities ourselves to some kind of function? Ie. remember the coordinates and create our own version of trace_line where it only detects func_illusionary things? Not sure how to do that
• yet another way , a more crude but feasable approach, is when bots get stuck (which they evaluate every 0.1 sec anyway) the bots check in sphere if a func_illusionary is blocking them to judge if they should jump. That will solve the movement for cs_italy, but it won't solve the curtains in cs_747

Known cases to deal with:

• cs_italy the fences to jump over
• cs_747 the curtains bots seem to be able to see through (#28)

... other cases??

RealBot does not compile with XCode 10 or higher

Because:

ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libc++.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libc++.tbd
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libdl.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libdl.tbd
Undefined symbols for architecture i386:

Counter-Strike also stops working at this point.

Consider downgrading to Xcode 9. Go to https://developer.apple.com/download/more/ (login with your apple ID) and download an older version.

Remove the latest XCode version and install this one should work.

Bots try to reach button in as_oilrig from other side of the wall

See:

The bot tries to reach the button at the right.

Strange thing: the bot seems to realise it cannot reach the button. Then it tries to find a 'close node' (using getCloseNode). But the close not seems to be the very node where the bot is. This is strange because the node we have to look for should be able to do a traceline to the button. Funky!

Check / Upgrade to latest HLSDK version

rblog() causes extremely low FPS when running on normal magnetic HDD (non-SSD)

as title.

video:
https://youtu.be/5g2ZyasCHQc

I profiled a bit with Instruments tool included with xcode, and found that rblog() (which writes a lot of log messages to reallog.txt) caused problem:

possible solution:
only open the reallog.txt file once, and close it when program exits.

[r3073] Bots wont diffuse/plant bomb

Bots wont diffuse/plant bomb, bots kill 1 bot team mate (1 in T 1 in CT), 1 random bot camp in base sometimes stuck

Tested with the ff:
HL 1.1.0.4HL 1.1.2.2/CS1.01.6
MetaMOD/Steam/Non-Steam/Working

http://forums.bots-united.com/showthread.php?p=66803#post66803

On new round logs report bots are blinded by flashbang

In the logs I see:

[realbot] [cs_italy] [4:59] - [Blaster 'rprint()']-[Team TERROR] : TODO: Make bot react upon screenfade/flashbang

when a new round is started (every time).

This is obviously wrong. Need to make it more accurate.

Upgrade to metamod 1.20

Use statemachine for bots

Currently the bot is a whole big bunch of if statements. A good way to deal with this is a state machine.

It also makes it way easier to think about the bot and deduce how it behaves. Now it is one big ball of ifs and maybes :/

Bots camp too much

Bots camp too much, the rate configured should have less impact.

Do not camp when:

• last (2?) bot(s) in team, keep on moving
• CT - when bomb is planted
• VIP should not camp

Sometimes it is fine to camp, see different ticket for this: #16

CS_ASSAULT CT bots do not rescue hostages

Bots can find hostages, but they can't find any func_hostage_rescue or info_hostage_rescue entity so they don't know where to bring them to rescue.

Although I could hack something like "when no rescue zone found bring to CT spawn", I'd like to be sure if there is no other entity in the map perhaps...

Support AS_ mode

Looks like AS_ mode became broken.

Reference point is as_oilrig: https://counterstrike.fandom.com/wiki/Oilrig

See also https://www.youtube.com/watch?v=hY6Cp38agzM

Bots get stuck into other bots

Related to #17 - bots who seem to get very close to each other get stuck. Not sure if it is because of the bot logic itself or that the client logic (Fake clients) causes them to get stuck easily.

Whatever the case, this interrupts any logical conclusion we can make for #17 because if the bot is getting stuck because of another bot then this means we can't conclude the connection is wrong.

Several things should be done:

• avoid other bots at all times
  • ie perhaps scan in a radius where other bots are and try to move away from bots. The ideal angle would be towards the next node, but if other players are in the way try to move away from them (and update allowance timer for reaching other node).
• if the node to head for is occupied by a player (bot or not) try to find a node that is not occupied and still goes to the node after. So we can sort of diverge our path without recalculating it entirely.

Screenshots:

i should be j

https://github.com/Fundynamic/RealBot/blob/master/NodeMachine.cpp#L1981
there i should be j

Improve the mechanism that creates node connections

There is a function Reachable which plays an important role for connecting nodes. Improving this should reduce the need for #17 . For example, in as_oilrig it learns some connections that are impossible to make:

This is typical on as_oilrig for instance, it also messes up the connections here:

The same symptom - although you don't see any connections drawn here.

I believe it has something to do with improper usage of point_hull. Perhaps we should use a crouched hull (head_hull?).

This will probably also reduce the errored connections in #17 for cs_italy.

Support FY_ maps

Like #17 mentioned the map fy_iceworld.bsp.

• bots should know they don't need to buy stuff (check if in buyzone, instead of assuming)
• there is no freezetime? if so, respect that
• there are weapons on the ground? pick those up (GOAL_WEAPON ?)

Ladder does not autoconnect in as_oilrig

Looks like the ladder in the tower for T-SPAWN is not connecting automagically:

The nodes at the left should connect with the ladder (red node) on the right. Looks like auto connecting failed. Need to investigate why.

Config of bots only works in first round?

In a post from here is mentioned:
http://forums.bots-united.com/showthread.php?p=67217

that the bot config is only used once (first round).

Investigate this.

Pathfinder sometimes creates inefficient paths

Using A* algorithm, see also: https://www.youtube.com/watch?v=-L-WgKMFuhE

Regardless.

It looks like bots, especially when retrying connections, they re-create a path that seems to go way around only to end up at the same place they started from and continue from there.

Ie:

For testing #17 i noticed the bots detected this wrong connection, but then went way back and retried. Not only going back one node but several.

Now I removed all the danger/contact heuristics already and it still happened. The heuristic is quite simple:

cost = distance from open node to destination + distance from open node to start vector

where start vector is the start of the path. Since this is testing as_oilrig which is a vertical map, I suspected the inefficiency came from the height of the map. Ie, some nodes, although going backwards horizontally are closer to the target vertically.

I removed that complexity by setting the z axis for all vectors to zero so we compare as if we were on a 2d grid. This reduced the inefficieny a bit, but still there is some.

I wondered if this is due to the algorithm, or something else going on.

It is almost as if not all nodes are connected as expected (ie, it would overwrite open connections with better scores).

Another way would be to run some final check over the created path:

• for each node in path
• check if there are future nodes in path that this node could reach, if so skip to that node and remove all nodes in between, ie:

[0] = node 100
[1] = node 200
[2] = node 201
[3] = node 190
[4] = node 99
[5] = node 110

suppose 100 could reach 110, then starting from index 0 it would check if node 100 could reach 200, 201, 190, 99, and at last 110. If it concluded that 110 is reachable, it would reduce the path to:

[0] = 100
[1] = 110

Still, this feels like solving a bug somewhere in the heuristic. Or perhaps this is just because of the drawbacks of A*?

Combat of bots is stupid

Perhaps I broke it, but it struck me that bots in combat just stand there and shoot.

While they have a very high accuracy (bug as well?) they don't move around and such, making them sitting ducks if aiming was less accurate.

Bot camping behaviour should be more object oriented

Camping can be a valid tactic, only in specific scenario's:

This issue is about making the bots camp in some scenario's, taking the 'wanting to camp' personality factor into account:

for terrorist team:

• When a bomb is planted, camp around the bomb spot to 'defend' it.
  • get away in time before bomb explodes
• Camp near hostages (sometimes)
• When hostage is being rescued (notification?) - find other hostages?

for counter-terrorist team:

• When a bomb is dropped and detected, camp nearby?
• should not camp when a bomb is planted
• Camp nearby bomb spot(s)?

Goal nodes should not float too high

As noted in #17 playing FY_iceworld, you'd see that the CT and T spawn's are floating higher up in the sky. Bots cannot reach that and thus it messes up their pathfinding.

Best would be to do:

• pick vector
• check downwards until it hits something, pick that vector + some height (0,0,32) and that should be the goal vector

Do something about line endings between unix/mac/windows

When I checkout on windows it always messes up the lineendings and persists there are changes. While there are not. This makes working on Windows a PITA.

See also: https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git/1112313

Bots should learn what connections are very good and prefer those over others

As opposed to #17 it should be possible to store how fast a node connection from A->B is reached. Given that we could influence the path finding by using that in addition to Checked. Now bots will vary their paths because they don't want to re-pick the same nodes. However, we could remove that and basically add this 'how easy is it reachable' so that bots will prefer the better connections over those harder connections.

A caveat is that this can also be seen as the 'fast' or a 'slower' route. If implemented too strictly and bots will not vary anymore (always prefer the most fastest path). This should be avoided to keep the bots randomized enough so the play differs from round to round.

When a bot detects a wrong connection it should remove it (learn)

It looks like when a bot walks a path and encounters a 'troubled' connection it won't forget (after too many retries) the connection. Although the logs seem to indicate it would forget it - it does'nt.

Examples

• cs_italy stairs going up to hostages
• as_oilrig ramps

Ideas

• use trace_hull when connecting nodes, instead of trace_line?

Example of troubled connection not working:

Logs saying:

RBPRINT->[FragMe 'setGoalNode()']-[Team COUNTER] : Setting iGoalNode to 124
RBPRINT->[FragMe 'cNodeMachine::path_think']-[Team COUNTER] : I have chosen a goal: Node [124], Goal type [GOAL_HOSTAGE], score [6.177016], distance [561.016296]

RBPRINT->[FragMe 'cNodeMachine::path_think']-[Team COUNTER] : I have chosen a goal: Node [124], Goal type [GOAL_HOSTAGE], score [6.177016], distance [561.016296]
RBPRINT->[FragMe 'cNodeMachine::path_walk()']-[Team COUNTER] : Next node will be the destination!

RBPRINT->[FragMe 'cNodeMachine::path_walk()']-[Team COUNTER] : Next node will be the destination!
RBPRINT->[FragMe 'cNodeMachine::path_walk()']-[Team COUNTER] : Next node will be the destination!

RBPRINT->[FragMe 'cNodeMachine::path_walk()']-[Team COUNTER] : Next node will be the destination!
RBPRINT->[FragMe 'cNodeMachine::path_walk()']-[Team COUNTER] : Heading to destination!

RBPRINT->[FragMe 'cNodeMachine::path_walk()']-[Team COUNTER] : Heading to destination!
RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : ForgetGoal

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : ForgetGoal
RBPRINT->[FragMe 'cNodeMachine::path_think']-[Team COUNTER] : No goal yet


RBPRINT->[FragMe 'cNodeMachine::path_think']-[Team COUNTER] : No goal yet

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : Setting final goal after choosing a goal from goals list

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : Setting final goal after choosing a goal from goals list
RBPRINT->[FragMe 'setGoalNode()']-[Team COUNTER] : Setting iGoalNode to 109

RBPRINT->[FragMe 'setGoalNode()']-[Team COUNTER] : Setting iGoalNode to 109
RBPRINT->[FragMe 'cNodeMachine::path_think']-[Team COUNTER] : I have chosen a goal: Node [109], Goal type [GOAL_HOSTAGE], score [22.698469], distance [146.518631]

RBPRINT->[FragMe 'cNodeMachine::path_think']-[Team COUNTER] : I have chosen a goal: Node [109], Goal type [GOAL_HOSTAGE], score [22.698469], distance [146.518631]
Wrote HalfLife03.tga

Wrote HalfLife04.tga

RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : players near? 0, shouldMove? 1, walking path? 1, previousPathNodeIndex? 0

RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : players near? 0, shouldMove? 1, walking path? 1, previousPathNodeIndex? 0
RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : MoveToNodeTime expired

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : MoveToNodeTime expired
RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : ForgetGoal

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : ForgetGoal
RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : a troubled connection!

RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : a troubled connection!
Connection may be retried
Scoring will not start until both teams have players

Scoring will not start until both teams have players

RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : players near? 0, shouldMove? 1, walking path? 1, previousPathNodeIndex? 1

RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : players near? 0, shouldMove? 1, walking path? 1, previousPathNodeIndex? 1
RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : MoveToNodeTime expired

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : MoveToNodeTime expired
RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : ForgetGoal

RBPRINT->[FragMe 'rprint()']-[Team COUNTER] : ForgetGoal
RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : a troubled connection!

RBPRINT->[FragMe 'path_walk']-[Team COUNTER] : a troubled connection!

Still even with 'forgetGoal' and such being called (which should clear the path!) it keeps going to this node.

Bots are able to see through curtains on cs_747

Probably to do with with not dealing with func_illusionary.

Improve CT bots awareness when losing a hostage

I noticed when a bot think a hostage is following him, the hostage might actually get lost or stand still etc. Now bots only re-evaluate this when they arrive at their goal or are forced to rethink their goal because of encountering an enemy etc.

This could be a bit smarter. Bot could for instance re-evaluate this every 5 seconds orso and then decide to go back or not.