cabaletta / baritone

google maps for block game
GNU Lesser General Public License v3.0
7.17k stars 1.44k forks source link

Constant sneaking that results in block missplacemnt #3466

Open maxsupermanhd opened 2 years ago

maxsupermanhd commented 2 years ago

How do I disable sneak from baritone

Problem is very clear to me: due to lag (network or local aka fps) while sneak is performed cursor shifts to different block and it results in block being placed in different spot, sometimes sneaking gets rapid and messes even more.

From few issues there were suggestions that it might be caused by mod incompatibility, server interference or allowSprint option. I've tested in singleplayer and on server with high and low ping, with clear installation of just baritone alone and while toggling allowSprint while it was running - results are the same.

Switch that disables sneak would solve this issue. More than this, I don't understand why baritone decides to sneak in the first place, is this because it is moving on 1-wide bridge or near high-fall edge?

Result of trying to fill a plane (partially): image

Final checklist

ZacSharp commented 2 years ago

Baritone sneaks whenever it places a block because there's no way to tell whether rightclicking without sneaking would cause some other action (e.g. open a chest). Without sneaking every time it would mess up every time it has to place against a chest, hopper, furnace, fence gate, door, enchanting table, crating table, noteblock, lectern, etc.

maxsupermanhd commented 2 years ago

Baritone sneaks whenever it places a block because there's no way to tell whether rightclicking without sneaking would cause some other action (e.g. open a chest). Without sneaking every time it would mess up every time it has to place against a chest, hopper, furnace, fence gate, door, enchanting table, crating table, noteblock, lectern, etc.

It messes it up with sneak sometimes too. How about a setting with blocks that it has to sneak on that will default to all blocks/block entities that have rightclick action? Outsource this problem to a configuration if impossible to detect automagically...

ZacSharp commented 2 years ago

So there are four possible solutions I know (two of them some dark magic)

  1. Outsource it to a setting like you said. Easy and efficient but for some reason I don't like it. For me it feels like asking for people opening issues either because "Baritone does not handle block x from mod y correctly" (in case we use the correct default for vanilla blocks) or because "Baritone sneaks for every block" (in case the default is the current behaviour; yes I expect enough people to not find the setting or this issue on their own).
  2. If block.getClass().getMethod("onBlockActivated").getDeclaringClass() == Block.class, don't sneak. Obfuscation nightmare, horrible smell, not going to happen.
  3. Simulate the right click to check whether sneaking is not required. Probably unreliable with mods, slooow, effort comparable to writing a little schematic mod, not going to happen
  4. Make block placement reliable by e.g. by looking at the block for a tick before triggering the rightclick. Works with any mod (that doesn't break the convention of not intercepting shift+rightclick), low effort.
maxsupermanhd commented 2 years ago

I really like last one, seems like a proper fix. Sadly my java + minecraft client codebase knowledge is not nearly enough to do it myself. I think only solution that I am capable of is a list of blocks. I don't exactly know what is causing it but probably some frame/pos&look inconsistency. One of the things that might help is to force send pos&look packet before placing the block so there is no way for crouch to screw angle/ray.

If it will be a setting then it is a user error of not adjusting it properly, right now it does not work and there is no user way to fix it but with solution 1 it will be at least fixable by user.