mineflayer
mineflayer copied to clipboard
PrismarineJS
Mineflayer physics refactor
This PR will have some physics refactors to be more like vanilla client.
I will try to make each commit readable and add a comment explaining what each commit does.
Issues that PR does not fix: lastSentYaw and lastSentPitch not be accounted for in prismarine-physics
https://github.com/PrismarineJS/mineflayer/pull/2492/commits/fbc8c9fec26aa23213e89c6aa698d6ca2a3082cd
position_look should be sent 1000ms if we are looking around - looks every tick, should send a position_look instead of a position packet if we are sending a look update
absolute position & relative position (velocity) reproducing vanilla client gimmicks
absolute position sets the velocity to 0
relative position keeps the current velocity
position is sent every 1000ms - send a position packet every second if idle, no skipping ticks
falling check (position is sent every 50ms) - self explanatory, no skipping ticks
https://github.com/PrismarineJS/mineflayer/pull/2492/commits/24dc6b761349bd5eb131a6e43d10c08f747abf89 anticheats can pick this up for some odd reason especially when lagging you back
https://github.com/PrismarineJS/mineflayer/pull/2492/commits/6bfd1c20dedbc6dcfcbfa5528a21f145e9cbc4f3 this is needed to prevent skipping ticks in the future since a setInterval loop at 50ms sometimes skips ticks a limiter is necessary in-case the bot tries to play physics catch-up and lag even more
https://github.com/PrismarineJS/mineflayer/pull/2492/commits/4e5fb70e2f9fe659e4841a473c139f0f222ce052 This is the big fix.
The variable positionUpdated now checks if 1000ms has passed since the last position packet was sent
It rounds lastSent.time to the nearest 50ms when checking to ensure that it does not skip a tick even if lastSent.time is 999 or 998
This changes the functions of sendPacketPositionAndLook, sendPacketPosition and sendPacketLook to not set lastSent.
Instead, lastSent is updated in lastSentPosition (if positionUpdated is true) and lastSentLook (if lookUpdated is true)
lastSent.onGround is always set (since it is always sent)
Still need to figure out a reliable way for checking if a chunk is currently loaded where the bot is standing and a more reliable way to determine that the bot is "alive".
https://github.com/PrismarineJS/mineflayer/issues/2402 Vanilla client only requires a login packet > map_chunk packet > position packet in order to start sending packets.
what's the status here ? is this ready ?
Waiting for more comments, since this is a pretty big change. I also want to figure out a reliable way to for physics to wait until the bot's chunk is loaded like vanilla.
I also want to figure out a reliable way to for physics to wait until the bot's chunk is loaded like vanilla.
What's wrong with bot.waitForChunksToLoad()?
I also want to figure out a reliable way to for physics to wait until the bot's chunk is loaded like vanilla.
What's wrong with
bot.waitForChunksToLoad()?
I just want to check if the chunk that the bot is in is loaded. bot.waitForChunksToLoad() has issues if the server doesn't send the other chunks.
I have a solution taken from minecraft's source, to use bot.blockAt with the current position and check if it returns null.
what's the status here ? is this ready ?
This is now ready, just waiting for comments on it.
I just want to check if the chunk that the bot is in is loaded. bot.waitForChunksToLoad() has issues if the server doesn't send the other chunks.
Someone could refactor waitForChunksToLoad() to take a radius off chunks to wait for. Setting this to something like 0 or 1 would then make it possible to wait until the chunk the bot is standing in is loaded.
Completely forgot about this PR.
Tests are failing because the delay between position packets is sometimes 100ms. @Karang any suggestions on fixing this delay? @IceTank says I shouldn't remove the offending test.
Completely forgot about this PR.
Tests are failing because the delay between position packets is sometimes 100ms. @Karang any suggestions on fixing this delay? @IceTank says I shouldn't remove the offending test.
Testing that something should happen within 50ms in the test environment is not reasonable. Don't add this test.
Alright, removed the test. The reason that it was testing for within 50ms, is because Minecraft sends a position packet every 50ms or tick if it is falling.
This will not pass some falling checks if their timing threshold is extremely strict.
I'll look into why tests are failing later. It probably is related to the setInterval change.
I will resolve these comments later (hopefully tommorow) Feel free to ping me if I forgot. I am almost done with my travel.
To summarize: This PR tweaks a bit how position updates are sent to the server to more closely align it with how vanilla sends packets. It also limits the amount of updates that are calculated when the bot is lagging behind the tick timer to prevent the bot from sending to many packets at once. It also fixes an issue where the bot does not correctly apply velocity updates from velocity update packets.