Proposal to further fine tune bot physics

[TreeOfSelf]

So far mineflayer has worked beautifully on every server I have tried it on. Except for my favorite server, 2b2t.org. I have found that on 2b2t, my mineflayer bot gets rubber banded extremely hard, and can't get very far. It happens not just with mineflayer-pathfinder but also just with regular control states.

I noticed it had something to do with the bounding box of the player, so I tried to increase the bot.physics.playerHalfWidth, but this then caused the bot to rubber-band because he would be able to walk farther off the edge of a block without falling off. It seems that this server uses an EXTREMELY strict anti-cheat that is somehow detecting the slight discrepancies in the bot's physics. Furthermore, I noticed the bot getting rubber-banding when falling, seeming to fall and then teleport back over and over because of some slight differences in airdrag, velocity, what have you.

I am not certain what anti-cheat the server uses, I believe it may be AAC, but if I can find out exactly what it is I would be willing to purchase the anti-cheat and put up a test server for us to fine tune the bot's physics on. The more accurate we can get this to an actual Minecraft client the better.

So, what can we do other than that to improve this? Where would be a good place for me to look? If you need a video of what I am talking about I would be happy to provide it and once again- I only see this on 2b2t. No other server that I have found has such strict anti-cheat. The server itself often gives false positives for my normal client however with the bot it is virtually unusable.

Thanks for listening and all your hard work.

[TheDudeFromCI]

A video might be helpful, yes. But it is worth noting that replicating the vanilla physics engine is not a simple task. The majority of the task is decompiling Minecraft and comparing each physics calculation line by line.

This repo is also always available for PRs if you propose any changes to further increase the accuracy.

[rom1504]

I think something that could be useful is to write a script that would log the position of a player every tick to a file. Then use this script to log yourself doing a path in a server. Then build another script to log the bot position. Then use that script to log the position of the bot while it does that path. Once done you can compare the position and try to understand the difference.

Doing that logging in various situation could help a lot I bet.

One step further would be to automate the bot path using mineflayer pathfinder, so you can more easily do that logging.

On Tue, Oct 13, 2020, 19:21 TheDudeFromCI notifications@github.com wrote:

A video might be helpful, yes. But it is worth noting that replicating the vanilla physics engine is not a simple task. The majority of the task is decompiling Minecraft and comparing each physics calculation line by line.

This repo is also always available for PRs if you propose any changes to further increase the accuracy.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/prismarine-physics/issues/27#issuecomment-707892347, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437XKDLED4YEZHAXNE73SKSEDJANCNFSM4SPJB5VA .

[TheDudeFromCI]

I imagine it would be quite difficult for a player to mimic the bot's input controls perfectly, so there would be extreme diviations from that is pressing the button a single tick too late or too soon. It might be more practical to make a client mod for executing the path.

[TreeOfSelf]

For starters, I will work on getting a video example, and then I can create a very simple scenario. Me and the bot in the same exact position falling off and edge and logging each tick showing the difference in position as we simply walk forward off an edge.

[TreeOfSelf]

Sorry for the lack of updates for awhile, https://youtu.be/6subX0TuVIk Here is a video of me showing the default bot.physics.playerHalfWidth not working, I end up setting it to 0.35 but I found it actually worked perfectly fine at 0.301 as well. I am going to test it out more at spawn today since that is the area I was having most of my issues and using the pathfinding module. But already making progress.

I had an idea of having it sit at spawn and pathfind randomly, every time it gets 'forcedMoved' it would make a random adjustment to its physics, if it makes it farther it keeps the adjustment, if it doesn't then it reverts back to basically automatically fine tune the physics.

[TheDudeFromCI]

If it fails at 0.3 but works at 0.301, it sounds like an issue of > vs >=.

[TreeOfSelf]

for sure, ill see if theres anything else but it seems like that in itself has made it so so much better. Going to be messing around with it later.

[TreeOfSelf]

I am closing this because changing the playerHalfWidth up slightly fixes it entirely.

[rom1504]

Can you pr it ?

On Tue, Oct 20, 2020, 06:31 TreeOfSelf notifications@github.com wrote:

I am closing this because changing the playerHalfWidth up slightly fixes it entirely.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/prismarine-physics/issues/27#issuecomment-712581318, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437QYARBJLOCXRPUQFS3SLUHANANCNFSM4SPJB5VA .

[TreeOfSelf]

Sure, let me find the neater way of doing it and ill PR it.