Put the mineflayer bot in a worker

[Karang]

After doing some profiling, I've seen that the main thread spend too much time in the network. This is what is causing the drop of fps and stuttering.
This is best shown when loading chunks but even sending the position packet every tick is affecting the fps.
The only way to fix it is to put the websocket connection in a worker thread and the easiest way to do it is to put the bot in it.
This will require a big refactor and a change of project design because the bot functions would have to be accessed through messages.
This should be done ASAP (because of the project design change).

Alternative design is to do like prismarine-viewer or web-minecraft and have the bot on the server side, but that raise the same design issues (communicating with server instead of the worker) and is less portable, so I think the worker is the best solution.

[rom1504]

Makes sense. Maybe we could do a bot-like api that would actually use messages ? So from the user point of view, he's using the same API as now.

…

On Sun, Mar 7, 2021, 02:53 Karang ***@***.***> wrote: After doing some profiling, I've seen that the main thread spend too much time in the network. This is what is causing the drop of fps and stuttering. This is best shown when loading chunks but even sending the position packet every tick is affecting the fps. The only way to fix it is to put the websocket connection in a worker thread and the easiest way to do it is to put the bot in it. This will require a big refactor and a change of project design because the bot functions would have to be accessed through messages. This should be done ASAP (because of the project design change). Alternative design is to do like prismarine-viewer or web-minecraft and have the bot on the server side, but that raise the same design issues (communicating with server instead of the worker) and is less portable, so I think the worker is the best solution. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#64>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR437TFFHKLAIJ4EWRZGZDTCLMA7ANCNFSM4YXKPVAQ> .

[rom1504]

Looking at the code, it's mostly about doing that for pworld.
The rest is mostly about passing events per messages, and a few mineflayer functions

Putting most of the remaining state will help on this.

[Karang]

Yes the first steps of the work are in pworld. We also need a modification of pviewer to allow this kind of data transfer:
server => bot worker => pviewer worker(s) => main thread (render thread)

Alternatively we could also do:
server => bot worker => pviewer worker(s) => bot worker => main thread

That would require less modifications put will do 1 extra transfer (shouldn't cost much as arraybuffer can be transfered instead of copied).

Reproducing the mineflayer api with messages would be painful to maintain so we have to find a way to automate this. Do you have some ideas ?

[Karang]

That's probably not needed anymore as we fixed the issue with the network.

[rom1504]

yeah it's lower priority at least

let's let it open and we'll see if we think we need it later

[rom1504]

seems webmc does that https://github.com/michaljaz/web-minecraft/blob/threejs-javascript/src/scripts/proxy/Proxy.worker.js

maybe we should still do this issue

[Karang]

Do we have evidences that the mineflayer bot is causing some issues ? Having it in a worker would be way less convenient for everything so i don't think we should do it unless we have to.
Btw, webmc doesn't have the fixes we have on the network, so they have to use a worker to not slow the main thread. Also its not faster than what we have, they only have a shorter render distance and less complex rendering.

[rom1504]

I do see that fps are lower at the beginning when mineflayer is highly active

I agree about convenience. If we were to do it, it should be made as convenient as currently by using js proxy (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) and some looping over all methods/attributes , so the fake bot object behaves the same as the normal one.

Until we have a solution that is as convenient as the current thing, or that we are forced to do it due to performance, let's keep things like this