Let go off auto-waypointing?

[V or 'Tex]

If there is a limit it must be approx 128 or 256, and it doesn't seem to care whether or not they are visible. If I am in a room with ~20 nodes, and I look towards a wall where there are at least ~500 nodes outside, sometimes I get 0 nodes inside visible. But if I walk over them they are there.

[stefanhendriks]

its undoable to do a distance check to all of them. As i said, i will take a look at it, but not now, its too late now tomorrow

Stefan,

Regarding the nodes and how to debug them on a dedicated server, I found two issues (fixed in the attached code):

- added 'realbot nodes connect/disconnect x y', to connect two nodes (addto does not work on a dedicated server)

- put some throttle code on the cNodeMachine::draw and cNodeMachine::connections as I was running in the 'sz_getspace overflow' followed by 'overflow netchan->message' issue (too many messages -- one per nodes/connections -- per frame). The new code displays a node every 10th frame which is fairly enough since it stays visible for 10 frames ;-)

BTW, regarding the lag on Linux, I do believe it was linked to too many 'log' messages or establishing new connections/nodes. When the map is waypointed, this is pretty smooth.

NB: as usual, I'm also trying to add new goals (like weapons in es_cell) but the heurestics for goal selection are still unclear for me.

NB2: using 'manual' waypointing allows for bots crossing doors & going over ladders (which is still the issue with auto-waypointing).

-eric-the-long-post-writer

[stefanhendriks]

thx evy, i will use them for sure! The goal heuristic is quite logical, but it is not tuned yet, ie the bots do not visit the other spawn point that much.

Actually i have to revise the entire heuristic since the original idea is kind of messed up.

[V or 'Tex]

You ought to redo part of the node system, because if you think about it, for a straight path you have way too many nodes.

I think that Realbot should consider two types of positions, and that nodes should be placed accordingly.


When walking in a straight line, a 'moving node' is created. As you walk further, the degree of change from the starting node decreases. Allow me to explain.

If I walk 10 feet in a straight line, and walk 3 foot left. That should cause the new node to be placed -where I started the change in direction-.

However, if I walk 10 feet and only drift by... say, a half a foot. Then I am OK and I can continue walking forward.

If I walk ~80 feet and make a tiny movement, it should automatically add a new node because of the high distance.

So, what needs to be done is that nodes can change after they are created based on movement patterns. If five nodes are created in nearly straight line, they should be replaced by two nodes with one large connection.

Next, nodes should no longer be -1 if you are not directly on, or near, a node. Connections should allow the bot to sense it is on a line between a node, or near one. So that a bot may move along that line to a node. So if a node is near a node, it may decide where to go next. But if a bot is between nodes and in a connection, then it should realize that it is going from one node to another, instead of getting stuck because it no longer detects a node nearby.

Next, nodes need to be created automatically whenever two connections cross, so that when large connections are made, they can be connected later.


So, ultimately that would reduce the number of nodes being created (many paths can be reduced to two waypoints, while Realbot prefers to create dozens or even hundreds of nodes).

Another thing that ought to be done is that you should be able to specify 'supernodes'. A supernode is an important area specified as a group of nodes. To create a supernode you would type:

realbot supernode create [name]

This would create a single node with the specification of [name]. Then, you would be able to go somewhere and specify various things. For example, you could specify aim-to nodes, attached nodes (similar nodes which should be strafed or moved back and forth between) and other things.

The variety of supernodes should be simple: bombsite, sniping, camping, spawn area.

A supernode shouldn't be a single node, but instead it should be defined as a rectangular region specified as the area between 4 (or if you take the time to code it, more) nodes.

One of the problems I have had is that bots often move about chaotically near the spawn point, resulting in over a 100 nodes in a very tight area around the spawnpoint. Obviously, the bot will think about moving to each one and it increases the latency at startup because each bot has to eventually leave the spawn. They usually do fairly quickly, but not without a bit of aimless wandering between nodes.

So specify a supernode of the category 'ctspawn' via something like this:

realbot supernode create ctspawn

Then, walk to the corners of the spawn area and specify:

realbot supernode vertexadd [type of supernode] [name of new supernode]

Use ctspawn for the type, and ct1 for name.

To simplify it even further, the vertices specified could be limited to 2, one for a max xy and one for a min xy.

Supernodes would also be extremely useful for specifying large areas where lots of nodes would otherwise be needed. Instead, the tunnel in de_dust would consist of a large supernode, such as this:

realbot supernode create hotspot [name]

The specified supernode then has three addable properties. One, you should specify camping/hiding spots, two, you should specify aiming spots, and three, where to go from the supernode.

If you put the effort into overhauling your current node system, so that it supports regions and nodes (nodes being more accurate, but usually the game will create tons of these) and supernodes being more flexible entities with more properties... A big map could use a few supernodes and replace hundreds of other nodes, while adding the flexibility that would be hard to apply with nodes.

If I'm right, the reason you haven't added aim-to and camp-at nodes is because the more bits you add to each node, the more data. If you specified that each node had two possible aim-to locations, then each node would be 24 bits bigger. With 4096 possible nodes, that sums to 96KB. A region would not only remove unnecessary nodes and reduce the number of excess connections, but allow you to specify that a group of nodes had similar properties!

I think you should take this into serious consideration.

[Maleficus]

Originally Posted by V or 'Tex

If I walk 10 feet in a straight line, and walk 3 foot left. That should cause the new node to be placed -where I started the change in direction.

Thats could actually be a good idea - you'd have to have the code be checking the clients angles every frame, and if they made a change beyond a certain point, it would trigger another node being dropped.

To be a bit OT: I've kicked around the idea of auto nodes myself for Fritz (I HATE waypointing a map), but the problems of placing just the right amount of nodes where and when you need them have stopped me: I can hand place nodes in just the right places to give a bot not only navigation information, but more, like tactical information and layout. With auto nodes, you can't always predict how well the world will be represented to the bot, and it always seems like auto nodes make more nodes than are needed (but that may just be my experience).

I like the idea of auto nodes in Realbot, but I would still like to add/delete/modify nodes by hand if desired, if at all possible. I've been tinkering with the node paths for every bot on this forum, making my own little tests or what not, and enjoy having some control over how the bots move about the world.

[stefanhendriks]

long read, good suggestions!

There is one thing that makes 'a lot of nodes' so interesting though... haven't you noticed their movements are less static then any other RB version? (or any other bot?)


I like the idea of having area's (rectengular or whatsoever) instead of single nodes. Currently i am using 'important nodes' (single ones) which are used as goals for the goal heuristic.

When i think of rectengular areas, i think of navmesh btw.

For CT's leaving spawnpoints chaoticly; they indeed tend to take some 'safe' nodes instead of going straight out of the spawn point and get 'safe' later. I think this is also fixable by just changing the path heuristic.

A major overhaul of the node system will take quite some time i think. The whole principle is to have MANY nodes on MANY locations. Hence, i increased the distance, but i find this the MAXIMUM of what i can do on that part.

For camping, i want RB to make up its own mind for camping... so it is more dynamic. Though sometimes they camp plain stupid, the more they learn about their nodes (ie, visibility, which is only calculated when nescesary, therefor increasing the RBX file, and providing more accurate data) the better they camp.

I'll take things in consideration, but i won't promis i will overhaul my system for something new. I might as well try navmesh again then. Although i suck at math... very.. (ask pmb )....

gtg have some breakfast now, can't think properly with empty stomage.

[frashman]

in my opinion its better to have more nodes then to have less.

i'm agree with stefan, to think about a rectangle-like navigation, but i think its very difficult, but the best is it, because of natural movement.

maybe it can be realized like to cut everwhere anyone can walk so walkable-rectangles can cut out of a big one (the whole map). so you know after a while where you can walk. the good thing is, if a bot run across an area, and there is a box in the middel, he runs against him, and can cut a new rectangle out of the big (mapsize) rectangle...

so a bot can completly selflearn.

there are 2 problems.
1- the map is 3D
2- its only my wild theory :-)

[stefanhendriks]

well in fact, there was a bot that learned completely how the map layout was. I think its doable too.

[V or 'Tex]

I really think that 'important' areas with special properties, like supernodes, should be implemented. In maps there are areas which are simply very hard to get a bot to act realistically at. Like the tunnel in de_dust. A real human will usually be stupid, camp near the middle. A smart person will camp at the dark spot by the boxes in the far right (from T entrance), or watch doubledoors near the boxes over there. The entire region has only two aim-to areas, which is an area right in front of the double doors-tunnel entrance (just after the hallway) and the middle of the hallway leading to the sniper's nest and underpass. If you could code it so that the bots camp at those 3 spots, and the middle area, and they automatically aim in the region of those two areas... BAM, realistic human response.

Yes, lots of nodes = very chaotic... but what I also noticed is that bots follow the nodes almost precisely, so perhaps that should also be corrected. Bots should also detect ledges, so that they dont fall off them just because a node walks along one and they dont turn or they go too far. The problem is, once ONE bot falls, then it becomes a noded path, which means more bots may fall. Then by the time you've played Mindmaze2 enough to get sick of it, you have bots that will fall off ledges and lose half of their life EVERY ROUND.

Yes, I want many things fixed in Realbot... but, now that it is open source I can post these suggestions without feeling guilty about having one person have to implement all the good ideas.