Comments (10)
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.
from bots.
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.
from bots.
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
from bots.
Viir,
I tried to send a small video that I made to make it clearer how the BOT behaves.
from bots.
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.
from bots.
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:
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.
from bots.
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)
from bots.
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
from bots.
The problem of requiring consecutive readings of a module button tooltip is now resolved with commit 467d9cc: 467d9cc
from bots.
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 👍
from bots.
Related Issues (20)
- MiningBot just clicks on inventory HOT 2
- Configured bot crashes HOT 1
- Destroyed Asteroid locking bot. HOT 2
- Bot cant find the overview window even tho its open HOT 2
- getting the followwing issue, kindly help HOT 1
- BotLab is blank no content HOT 3
- Problem with message box using bot 7aec4c539e (Eve Online Mining) HOT 12
- BOTs do not detect message box "set quantity" HOT 6
- Search the address of the UI root in process 548 HOT 2
- bot error HOT 1
- The buttons don't show up on the shop repair screen, so I can't parse. HOT 13
- Tooltip reading stuck when containing text with time HOT 5
- 45402edb6d62a87b warping at 0 HOT 1
- Client lost connection to server, cannot detect the quit button. HOT 2
- Missing error details - Failed message to host: Bad status code: 500 HOT 1
- farm of ore anomalies HOT 7
- conditions for closing the bot process HOT 5
- Failed positioning of mouse cursor in environments with heterogeneous display scaling (DPI)
- Session length HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bots.