Running bots on multiple game clients, input focus scheduling is showing an error.

[focabr]

Hi,

I used the guide https://github.com/Viir/bots/blob/main/guide/running-bots-on-multiple-game-clients.md to correctly configure the BOT and use 2 clients, for some reason the BOT is fighting each other for the cursor.

As soon as the BOT finishes starting it gives an error message "Failed to acquire input focus: Failed before entering volatile process." on both bots.

I will send the two sessions record to your support email.

Is there a way to enable some debug or trace to find out what might be happening?

[Viir]

Thank you for sharing your observation!

I received session-recording-2023-01-23T23-09-38.zip and session-recording-2023-01-23T23-09-50.zip and will look into these.

Is there a way to enable some debug or trace to find out what might be happening?

Yes, this log is enabled by default. You will find it in the file with the name ending in .jsonl at the root of the session recording directory.

This log contains the details of the input scheduling process and how messages were exchanged between the different instances of the BotLab client on your machine.

[focabr]

HI,

I was analyzing the logs and source code trying to understand how it works, and then I went to take a closer look at the execution of the BOTs.

What you could notice was that the "fight" it happens exactly when one of the BOTs is discovering the modules before finishing reading that module, the other BOT takes the task and when it returns the BOT has to start again analyze that module and keep doing it for as long as he can.

I can't say if this happens all the time, but the 2 times I followed it, it happened.

[Viir]

I was analyzing the logs and source code trying to understand how it works, and then I went to take a closer look at the execution of the BOTs.

What you could notice was that the "fight" it happens exactly when one of the BOTs is discovering the modules before finishing reading that module, the other BOT takes the task and when it returns the BOT has to start again analyze that module and keep doing it for as long as he can.

Thank you for the investigation. Your explanation makes it very clear what the problem is and where we can fix it.

This part of the program code gives a good hint about the problem:

bots/implement/applications/eve-online/eve-online-mining-bot/EveOnline/BotFramework.elm

Lines 234 to 245 in be99ee2

	{- To ensure robustness, we store a new tooltip only when the display texts match in two consecutive readings from the game client. -}
	tooltipAvailableToStore =
	case ( memoryBefore.lastReadingTooltip, currentReading.moduleButtonTooltip ) of
	( Just previousTooltip, Just currentTooltip ) ->
	if getTooltipDataForEqualityComparison previousTooltip == getTooltipDataForEqualityComparison currentTooltip then
	Just currentTooltip
	else
	Nothing
	_ ->
	Nothing

This comment found in the Elm module explains an assumption behind the bot program code, which contributes to the problem:

To ensure robustness, we store a new tooltip only when the display texts match in two consecutive readings from the game client.

When we have more than one bot running simultaneously, we can no longer rely on two consecutive readings showing the tooltip.

There is an additional problem with the current approach to reading the module button tooltips: As far as I understand the code, the reading is not synchronized with the effect that places the mouse over the module button.

It should work if the bot sends the effects to move the mouse and the command to get a new reading in a single reservation for input focus. However, the current bot program does not do that.

One improvement that will be relatively simple is to adapt the bot program to no anymore rely on 'two consecutive readings'
For example, we can just keep the previous reading of the module tooltip around, even if it wasn't from the last reading of the game client.

Fixing the 'consecutive' part might make it work in more than 99% of cases. It will be a very valuable improvement in itself for scenarios where we run more than one bot at the same time.
When we have implemented that improvement, we can see how often the (non-)synch for a single reading leads to a problem.

[focabr]

Viir,

Incredible, congratulations on the dedication. It will really make a big difference for anyone using more than one BOT.

He had one time where he was watching BOTs and the mining hold got full on one of them and he was still trying to read modules.

[Viir]

Thank you for discovering this issue. The synchronization challenge raised questions about whether the current interface available to bots is sufficient.
At the moment, I expect we will expand the interface for bots to package a sequence of tasks in a single input focus reservation to enable proper synchronization.

I will post in this issue thread when the new interface is ready. (The fix for the 'consecutive' part is independent and will probably land earlier)

[Viir]

@focabr

In alignment with our contributor reward program, I added one million credits to your BotLab account at https://reactor.botlab.org/billing
With these credits, you can run five hundred hours of online sessions.

Reward for the discovery and investigation of the issue 'Running bots on multiple game clients' as reported at #65

[Viir]

The problem of requiring consecutive readings of a module button tooltip is now resolved with commit 467d9cc: 467d9cc

[focabr]

Viir,

The reading of the modules really got faster, but when we put more BOTs the problem of "mouse fight" happens, the impression I have is that there is no time to read the tooltips as soon as it appears the other BOT already takes over and starts doing it something.

I'm going to send the session, this time he couldn't finish reading the modules of both ships.

session-recording-2023-01-30T23-05-07
session-recording-2023-01-30T23-05-18

[focabr]

Viir,

I tried to send a small video that I made to make it clearer how the BOT behaves.

[Viir]

Thank you for the recordings. I got these:

• session-recording-2023-01-30T23-05-18.zip
• session-recording-2023-01-30T23-05-07.zip
• EVE - FocaBB 2023-01-30 20-52-17.mp4

I will look into it 👍