Bots: bots keep camping on opponents team lolly position

[kai-li-wop]

Ever since 1.5, bots have often struggled to play Capture the Lolly correctly. They get the correct lolly, then walk to their own teams base and walk right past where they should capture it - then they just go back to the other teams base to the exact spot where they collected grabbed it, and then camp there until they get killed. Although when i test it on my local server, this didn't seem to happen and they could capture it, although they still constantly walk off the map (colorstage) at a specific place. I may need to spend some time figuring out what causes them to do this, as on my network servers, they usually do. ~Ben the PadKing

[kai-li-wop]

This issue is related to an far too high item weight for the lolly in CTL. I got this info:

So, konnte rausfinden woran es lag. Hatte immer einen Bug im Kopf, tatsächlich handelt es sich aber einfach nur um ungeschickte Verteilung der Itemprioritäten. Die Itemprioritäten für alle Bots werden in der "fw_items.c" festgelegt. Der Wert für die Lollies liegt bei 4000 welcher in meinen Augen VIEL zu hoch ist. Die Bots kleben am Lolly Spawn wie die Fliegen am Dreck. Ich hab den Wert testweise mal auf 50 reduziert und die Bots haben bei einem ersten Testspiel relativ vernünftig agiert. ~Hectic

[seldomU]

I'm pretty sure there is a bug that has nothing to do with balancing. While carrying the lolly or even while their team carries it, bots should ignore the lolly in their item target selection. I think we tried to reproduce/fix this with no success. One symptom was that the carrier bot "forgot" that it was carrying.

Hectics item weight change might only mask the problem, which could be a good enough solution for now. That absurd high 4000 item weight is meant to keep the bot on a straight and narrow path home: don't go for any items even if they are nearby.

In general, balancing tasks are 90% about playtesting. So they should be done by people who play a lot vs bots, and that's not me. I can advise on how the system works (if I remember).

[mgerhardy]

I can not reproduce this. For me the LTG always looks right (bot_developer 1) - and the bots are doing the right things. What exactly do you mean with "my local server"? A local listen server? A local running dedicated server?

[kai-li-wop]

OK, this I found also in my old bug ticket from 2011-11-26 12:33:

1. Issue: "As soon as the bot in your team has the lolly, it runs back and forth between the bases several times with the lolly until it comes to a stop on the lolly spawn in the opponent's base. There he can't be removed and you have to wait for the opponent to attack him so that the game can continue."
2. Steps to reproduction: "Start a server with PadBase and a total of 3 bots and assign 2 to the red team and one to the blue team. Join the blue team."
3. Comment: The bot must want to get the lolly from the enemy base and bring it back. Maybe it helps to observe the bots a bit longer. Maybe my instructions for reproducibility are not quite correct, but I was able to reproduce it exactly this way.

I also have a demo file from back then showing the behaviour: 20111218123652-194.153.87.21.27961-wop_padbaseCTL.dm_71.zip

I have now tried to reproduce this again locally and have started a match directly in the client, but was not yet successful, neither in the old 1.6 client, nor in the current dev client. But as you can see in the demo, the match was running for a very long time, over 4 hours. I simply joined the PadWorld server via internet back then, so no local server in my own LAN nor directly via the client.

In addition, I have discovered yesterday when testing a several times briefly a very similar behavior with the bots, which carried just no lolly. If their own lolly was not in place, the bots sometimes camped in their own base at the lolly spawn. This behavior ended immediately as soon as their own lolly reappeared at the lolly spawn in their own base and they started moving again.

In the following screenshot, the bot with the lolly ran into another bot from his own team shortly before and was briefly blocked by it. After that he didn't know anything any more. He just stood there and looked around several times in all directions and did nothing else until he was shot down.

[kai-li-wop]

I can see the issue right now at PadWorld server. Both teams still have 0 points after nearly 18 hours of having a match. Some bots going for the opponents lolly and if they have it, they commute back and forth between bases but are not delivering it to the own base. Also bot team mates are camping at their own lolly spawn point, even if their own lolly is there. So they are not carrying any lolly.

So the problem doesn't seem to be related to having the lolly, but simply camping on the own or the opponents lolly spawn point. So two status are critical:

1. camping at the opponents lolly spawn point while carrying the opponent's lolly
2. camping at the own lolly spawn point while not carrying the opponent's lolly

Looks like something is mixed up here which leads to endless matches. It's also a serious problem for human players because they can't finish the match because they can't take over the lolly. The only workaround is to join the other team and shoot the lolly carrier, then finish the match with a point when the time limit is reached.

[kai-li-wop]

Still an issue in WoP 1.6.1 beta like expected. I will try to investigate more.

[kai-li-wop]

Hmm, funny. When I see all the screenshots it is always the blue team camping with the red lolly.

[mgerhardy]

It would help to see this in spectactor mode with bot_developer set to 1

I've found one problem with gametype_t being different in botlib and the game code. that definitely produces problems for team based games.

[kai-li-wop]

With the implementation of bot support for 1LCTL (https://github.com/PadWorld-Entertainment/worldofpadman/pull/261) some changes and fixes were made, which could probably also solve the issue with camping at lolly spawn points. We need some long term dedicated server test if this issue still appears.

To quote @mgerhardy: "There were definitely id problems in the bot files. There was an off-by-one with the flags. If it (this issue) was about the bot forgetting that it was the carrier, then 99% of the time it was due to the inventory."