Re: Work In progress (WIP) #6
 

About camping, here i have a snippet of code (can't reply more, gotta go now)

Re: Work In progress (WIP) #6
 

Help me. I downloaded the latest WIP. I foolwed the insructions. I start my listen server. Meta mod loads ok. I type meta list in the console. It says realbot has loaded. But how do i add bots. The h menu doesn't work.

Re: Work In progress (WIP) #6
 

The random camping is kinda odd, but the only major bug that i think of is that the bots need to be able to react when they are hit. Maybe have them spin around in a 360deg circle when they take damage or something. Just to give them some kind of reaction till something better is coded out.\

As for the menu, it needs to re programed from the mune file in the Cstrike directory. The WIP versions use a diff command(Realbot) from the origional AI 1.0. People posted an updated one in another thread that you can use.

Re: Work In progress (WIP) #6
 

Check the progress thread everyonce in awile...

instead of using rb in commands, use realbot. So "realbot add" is a command that would work...

Re: Work In progress (WIP) #6
 

This is everything ive noticed with the bot so far.

Bots dont plant as much as they should... They plant rarly, but they often run right past the sites.

Also I have never seen a ct defuse the bomb yet...

On the map de_train, the bots often get stuck on the trains, and cant get around, or under...

Re: Work In progress (WIP) #6
 

I thought of a simple way to keep the bots from doing that damn annoying "trying to walk to a node 3 stories above them" bug. Do a height comparison between the bot's current position and the node it is trying to reach. If the destination node is greater than X units higher than the bot's current position (where X is the maximum jump height given the current value of sv_gravity) pick a different destination node. If the destination node is greater than Y units below the bot's current position, (where Y is the maximum non-damaging fall distance given the current value of sv_gravity) again, pick a different node. And don't allow nodes in mid-air.

Currently the bridge of cs_siege, the stairs of cs_matrix, and the overpass area of de_dust are terribly confusing to the bots. Also, bots are really stupid about getting unstuck. They sometimes do the same thing over and over again, and never try a different route. They are also very stupid about crouching to get to low-clearance places (like under the cars in de_train or into a vent) or jumping over low obstacles in their path.

Re: Work In progress (WIP) #6
 

it is not that easy to declare 'nodes higher but me' faulty. This is because you also have steep slopes... so i do multiple checks to eliminate a lot of errors.

the bots somehow seem not to learn from the mistakes in these cases. I don't know if i fixed the 'check for floating node' bug in the build you guys have. I think i'll release a new version today or something, just to give you a more stable/fixed version to play with. I will add new features later.

Re: Work In progress (WIP) #6
 

Here's another thought:
Don't use visibility calculations to try to connect nodes, use the movements of human players. As humans are moving around, maintain a list of the nodes the human was at in the last 5 seconds. Before nodes can be considered candidates for connection, they have to both be in a human player's "nodes I visited in the last 5 seconds" list. If a player is at node #785 and moves to node #819, add 819 to node 785's list of "nodes I can move to from here". And make a note of whether or not the human jumped or crouched when moving from 785 to 819. If humans only ever move from 785 to 819 while crouched, that should be a good clue bots need to do likewise. That would eliminate the major problem with cs_militia where the CT bots spend most of the round trying to walk through the fence by the sewer tunnel entrance.

As to the steep slope thing, simply add enough nodes so that they are within the connection limit tolerance. That way, if I'm walking up a steep slope, legitimately connectable nodes would be added frequently enough so that they will be within the vertical connection checking limit. One other thing, it wouldn't be necessary to do eliminate nodes below current position if they are water nodes, since falling into water doesn't cause damage.

Oh, one other thing, when a bot decides to camp, make them do a "am I on a ladder" check like they do a "am I under water" check, so they won't camp on ladders. Camping on a ladder often blocks other players from being able to go where they need to go. You can't shoot accurately on a ladder, and your ability to take cover in a ladder is quite limited, so ladder camping is something no intelligent human player ever does. It would be greatly appreciated if the bots didn't do it either.

Re: Work In progress (WIP) #6
 

I'm starting to have a significant crashing problem that seems to be related to the size of the experience file. Once the file reaches its maximum size of 2244KB, the server will frequently crash while that map is playing. I have 12 maps now where the experience file has reached maximum size, and have to restart the server several times a day now. Email or PM me if you want me to send you copies of the node/experience files that seem to be part of the problem.

Re: Work In progress (WIP) #6
 

i will take a look at these memory problems for experience files...

edit:
i have taken a look, and i think it has something to do with the size buffer being to much to write at once. I could not find information on what the max size may be. I have read you can write endless amount of data, and also read you could write chunks of 2 MB at max. So, i am not 100% sure.

What i added:
i added 1 line of code which could (most unlikely though) exceed the limit of nodes, therefor trying to write pieces of memory that is not allocated

Sollution: none yet.
Possible sollution/thought:
chop the piece of data in 2 to make sure it never writes to much data. Problem though -> I don't know how to do that, as i am not a real bytes/bits guru on this issue.