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

stefanhendriks · 2019-09-06T18:39:21Z

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.

The text was updated successfully, but these errors were encountered:

hostage rescue logic. Also log more about the troubled connection - for #17

stefanhendriks · 2019-09-06T18:45:15Z

Video of this at: https://www.youtube.com/watch?v=AmFJZURwoF4&feature=youtu.be

- remove wrong connection when detected, works fine as long there is no opportunity to jump/crouch - for #17

- bots still hang too much around invalid connections and dont decide fast enough that they should severe the connection - for #17

stefanhendriks · 2019-09-11T05:39:45Z

The logic has improved a bit, but not as much as I'd like. While working on this I broke bomb planting, hostage rescueing and bomb defusion.

Now those things seem to work fine again.

stefanhendriks · 2019-09-13T04:18:19Z

Playing in AS_OILRIG I noticed that bots are slow learners.

See this case:

A bit dark picture, but you can see 3 bots trying to get down. They don't duck and they are pretty close to each other.

Probably the canDuck function thinks it is not possible, due the bar being at a specific height? Perhaps this can piece should be removed and tried anyway when nothing else seems to work. Same goes for jumping. It could also be a combination of this and #22.

Regardless, the bots take their time removing connections and this takes too long.

Overitab · 2019-09-13T11:00:02Z

also please fix moment when bots try go up where no laders. I use plugin that add more spawn ponts. And i add 16 more spawns on iceworld above head. Bots fall in start and try go up. Maybe make one side connections or other fix

Overitab · 2019-09-13T11:00:36Z

can u give me last build dll ? i can test it

stefanhendriks · 2019-09-13T11:01:00Z

@Overitab could you tell me which map you use? Perhaps even record it (youtube video?) so I can see for myself?

Overitab · 2019-09-13T11:01:51Z

ok i make video, give me 30 min

stefanhendriks · 2019-09-13T11:03:52Z

The latest master is not really release-able, though I could probably create a DLL for you. But you'd have to wait for it for a while.

Overitab · 2019-09-13T11:18:53Z

I was wrong, I didn't use the spawn above head . But still bots behave strangely, look up, dont run.
https://youtu.be/EZ5kXZZXIZc Please give me last build dll, becouse i use old build . I asked to make me a dll of the author of yapb https://github.com/jeefo/yapb last yapb here https://yapb.ru/files/binaries/5707/release/. You have telegram or some contact ?

stefanhendriks · 2019-09-13T11:21:24Z

@Overitab just to be sure, there are nodes in the map? Looks like as if the bots have no clue where to go. It could also be that the map type is unknown and the bots wouldn't know what to do. Although.. in the most basic sense they would always go to the opponent spawn point.

So two things:

Before adding bots (but keep realbot dll loaded), walk around the map a bit.
- then re-add bots. Do they behave differently?
Question: which map is this? I can test locally then.

Overitab · 2019-09-13T11:24:10Z

fy_iceworld , but i add more spawns. Ok i can test , please upload dll

stefanhendriks · 2019-09-13T11:39:14Z

I can't create a new DLL now - I'm on a different OS. However, I did run a quick test and saw 2 things:

The spawn points in the map are pretty high up. So I can optimise for that. Perhaps make sure they are not floating too high. (Goal nodes should not float too high #25)
Once I walked around the bots usually went their ways and tried to shoot each other
Bots try to buy stuff, which is impossible

I created #24 for proper support of FY_ maps. And a different issue for better goal/spawn point plotting.

Do understand that the nodes are not created like waypoints in Podbot (manually). You create them on the fly by playing the level. Please play the level first (with realbot enabled) and add bots later, they should start moving. See also a bit more about this here: https://www.youtube.com/watch?v=j9CjnLd2nHU&t=201s

Overitab · 2019-09-13T11:57:54Z

ok good, i wait

- for #22 and #17 - also add convenient functions to draw beams more easily

stefanhendriks · 2019-09-16T13:05:18Z

realbot_mm.zip

@Overitab here you go. Latest version. (Windows DLL). Replace DLL with the current one. No warranties ;-)

- this is now a timed thing - we can now see when it gets < 20 or so, it usually means 'stuck'. Although I haven't tested with crouching yet, which probably results into distances of 20 by default. So the 'check' how much moved should also be done against the kind of movement (jumping, ducking, running, etc) - for #17

expected moved distance should be - for #17

stefanhendriks · 2019-09-20T08:16:53Z

The learn rate is improved significantly. As it now uses a shorter time window. Also with #22 fixed there is a lot less false positives: ie bots know when they are stuck by other bots with more accuracy.

The stairs in as_oilrig cause quite a lot of faulty connections, which have to be 'unlearned' by this. Another way would be to make connecting nodes a bit more strict.

… bad connection when we can't see it anymore. - for #17

stefanhendriks · 2019-09-20T18:36:59Z

I noticed the bots ignore func_illusionary. This is used at cs_italy for instance. As far as the bots concerned they can walk right over them. But since they are used as 'fences' the bots get stuck and think the connections are wrong.

Here is a wireframe of cs_italy, with a func_illusionary (orange):

stefanhendriks · 2019-09-21T06:02:17Z

More info at #29 while dealing with func_illusionary. This should be dealt with because this causes for wrong conclusions about wrong connections. Ie, in cs_italy bots think they cannot jump over the fence and hence remove the connections. While they can jump over them.

This is not perfect, and in fact should only be done when it is 'stuck' (after 0.1 ms decision). So we won't have these random jumps. But it is a step forward for #29 and improving on #17

…on and when to learn about bad connections - for #17 for instance - When considered stuck, it will only try a few things and bail immediately. Ie, either jumping, ducking or it just logs its findings (but there is still work to do to make bot behave) - When time is up to reach node, it will remove the connection. Even when not 'stuck'. - take freezetime into consideration so we don't mark spawn points as bad nodes - refactored Button/Door interaction and Stuck logic into their own functions. Making path_walk easier to read. Slow steps to a state machine at some day???

stefanhendriks added the bug label Sep 6, 2019

stefanhendriks self-assigned this Sep 6, 2019

stefanhendriks added a commit that referenced this issue Sep 6, 2019

Optimise for hostage detection, when no hostages found do not execute

34d99c8

hostage rescue logic. Also log more about the troubled connection - for #17

stefanhendriks changed the title ~~Learning path navigation broken?~~ When a bot detects a wrong connection it should remove it (learn) Sep 8, 2019

stefanhendriks added a commit that referenced this issue Sep 8, 2019

Improve troubled connection detection

b4b7c12

- remove wrong connection when detected, works fine as long there is no opportunity to jump/crouch - for #17

stefanhendriks added the pathfinding Everything regarding path finding, creating path but also walking/learning path label Sep 8, 2019

stefanhendriks added a commit that referenced this issue Sep 8, 2019

Small step forward refactoring, trying to get learning improved

19330a6

- bots still hang too much around invalid connections and dont decide fast enough that they should severe the connection - for #17

stefanhendriks mentioned this issue Sep 8, 2019

Use statemachine for bots #12

Open

stefanhendriks added the enhancement label Sep 8, 2019

This was referenced Sep 11, 2019

Combat of bots is stupid #10

Open

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

Open

Bots get stuck into other bots #22

Closed

This was referenced Sep 13, 2019

Support FY_ maps #24

Open

Goal nodes should not float too high #25

Open

stefanhendriks added a commit that referenced this issue Sep 13, 2019

Add more logging to figure out what causes stuck cases

57e98e4

- for #22 and #17 - also add convenient functions to draw beams more easily

stefanhendriks added a commit that referenced this issue Sep 17, 2019

Remove unused stuck timer, add logging to determine what a sensible

5ae98f6

expected moved distance should be - for #17

stefanhendriks added as_oilrig cs_italy path walking and removed pathfinding Everything regarding path finding, creating path but also walking/learning path labels Sep 20, 2019

stefanhendriks added a commit that referenced this issue Sep 20, 2019

When a node does not float and we cannot reach it, also learn it is a…

20cb264

… bad connection when we can't see it anymore. - for #17

This was referenced Oct 2, 2019

Improve the mechanism that creates node connections #32

Open

Pathfinder sometimes creates inefficient paths #33

Open

stefanhendriks added the navigation label Oct 3, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

stefanhendriks commented Sep 6, 2019 •

edited

stefanhendriks commented Sep 6, 2019

stefanhendriks commented Sep 11, 2019

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019

Overitab commented Sep 13, 2019 •

edited

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019 •

edited

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019 •

edited

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019

stefanhendriks commented Sep 16, 2019

stefanhendriks commented Sep 20, 2019

stefanhendriks commented Sep 20, 2019

stefanhendriks commented Sep 21, 2019

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

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

Comments

stefanhendriks commented Sep 6, 2019 • edited

stefanhendriks commented Sep 6, 2019

stefanhendriks commented Sep 11, 2019

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019

Overitab commented Sep 13, 2019 • edited

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019 • edited

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019 • edited

stefanhendriks commented Sep 13, 2019

Overitab commented Sep 13, 2019

stefanhendriks commented Sep 16, 2019

stefanhendriks commented Sep 20, 2019

stefanhendriks commented Sep 20, 2019

stefanhendriks commented Sep 21, 2019

stefanhendriks commented Sep 6, 2019 •

edited

Overitab commented Sep 13, 2019 •

edited

Overitab commented Sep 13, 2019 •

edited

Overitab commented Sep 13, 2019 •

edited