Let go off auto-waypointing?

Stefan

Originally Posted by stefanhendriks

@ Evy, yes i am interested in any source!

Please find attached some source code:
- DrawNodes.c takes a .RBN as input and generates a .BMP will all nodes and all neighbourood relationships
- DumpNodes.c takes a .RBN as input and displays some statistics about the nodes
- bot.* dll.cpp NodeMachine.* by adding new command (realbot debug nodes/goals/draw) it dumps existing nodes/goals in reallog.txt or generates a realbot0000.bmp with nodes, neighbourhood, goals and paths
- NodeMachine.cpp has also been modified to detect new goals (and to create a node if there are no node close to a goal)

I'll look further in the code for the auto-waypointing.

Thanks again for your time and the information you provided

-eric

[stefanhendriks]

thank you i will take a look at them asap. I also have changed my nodeMahcine cpp file to auto-add goals , in fact it was only one line of code ...

EDIT:
this dump to bmp thing is actually pretty cool. You can cleary see how many nodes are where and how/if they are connected. I don't see any real problems with that at all. Also goals are found pretty good too. I saw de_dust and de_dust2 being really being 'black' on some spots due so many possible connections. So i'd say this stuff works good.

Its like with most things, the information is available, now lets make some good use of it.

[stefanhendriks]

Warning,

when you do auto-add a goal, then be sure you skip this for HOSTAGES. Somehow hostages (EVEN WHEN DEAD!) block tracelines/hulls... and they sort of return WORDSPAWN. I dont know why yet. I am investigating how the goal-machine reacts when i walk NEAR a hostage. ..

[stefanhendriks]

NEW:

Okay guys,

in addition to the annoying 'bots don't do anything' thingy i have the following:

- a goal can have a bad score

this means;
ie a bot tries to create a path to a goal, when it fails, it gives the goal a BAD score of PLUS 1. So when 10 bots try to go to a goal, and 10 fail, the bad score is 10.

The goal with the fewest bad score is a good one. This means, when you run around the map for the first time and only 1 goal is reachable for some, that this goal will automaticly (pretty fast) become the goal and bots start moving. I saw a bot moving after 1 round now instead after a few. It took some time for the bot to realize the other goals are not ready yet. They will become ready soon.

Every round the bad score gets 1 point less, so eventually they end up to a ZERO score. (and all goals will be reachable again).

I am trying to balance this more or perhaps someone else has a good addition to this?

[davek]

does this mean that if i start a round with my team vs 10 bots but the bots only have a way to reach one goal, will the other goal get a bad score of 10 if they happen to all try the unreachable one first?

if so, then wont they always choose the reachable one for the next ten rounds, even if i add a path to the previously unreachable goal?

[stefanhendriks]

@davek,

Lets say you are on a team with 10 bots, and you have made ONE path to to the terrorist spawn, meaning lets say 2 spawn points are connected. (2 goals).

This means for 10 bots that a few will move to one of the 2 spawn points. The others get a score of 1 (since the goal with the fewest bad score is checked you wont get accumulation that fast, unless EVERYTHING is score 1.. which will not happen with 2 good goals)...

now, when all things EXCEPT the bad goals are scored 1. The next round the bad scores get - 1 and all goals are again at score 0. Meaning the goals are 'in the race' again to be choosen.

THere is one problem, when a specific spawn point cannot reach the 'reachable' goals (because the spawns are not connected) , then bots can give the 'good goals' a bad score as well. However, since a few bots give those good goals NOT a bad score, they will eventually be choosen anyway.

The next step for me is to get the spawn points connected pretty fast. Do mind that when any RB version is officially released the RBN files will be included (as optional package though).

There is code that gives RB the posibility to 'walk around' when no nodes are present. It is quite hard though to make bots walk in a more logical way when there are no nodes available.

[davek]

ok. cool. sounds good to me now that u explain it that way

[dstruct2k]

Nice! I assume the CVS is updated?

Stefan,

As I'm still puzzled ??? why some nodes are lacking neighbours even when I first run as a human player all over the map... I tried to dig deeper in the RBN files and in NodeMachine.cpp.

It looks like in cNodeMachine::add(), there is probably a mistake:

if ((Nodes[j].origin.z - Nodes[index].origin.z) > 0)
				  hull_type = human_hull; // when we fall, be sure we can freely fall.

If I understand it correctly, this means that as soon as the move is not strictly horizontal, a check is done whether a human shape can go through the move without hitting anything.

Which is correct when the player/bot falls, but, IMHO it is not correct when the player/bot just move from one plane to another one (like in moving from an horizontal plane to a downhill slope -- like in as_oilrig when going from the horizontal platform to the downhill slope leading to the 'control tower').

What about a basic test to check whether the player/bot is falling or simply going downhill ? Like:

 
if (Nodes[j].origin.z - Nodes[index].origin.z) > func_distance(vNormalizedOrigin, vNormalizedIndex)) // Falling since maximum safe slope is 45 degree
  hull_type = human_hull; // when we fall, be sure we can freely fall.

NB: attached newer version of DumpNodes & DrawNodes with more information and checks.

-eric

[stefanhendriks]

Hmm, well i did not really check on that but i did not see troubles with slopes yet. I have to investigate that.

There would be an easier check though to know if a bot is falling (or floating...), i thought there was a function who returns true/false on floating on a specific vector, i think that works better. Anyway, will test ur suggestion.

On what maps does this happen btw? Only as_oilrig?