Problem
Stopping a bow attack during draw sends a release-use-item packet and fires an undercharged arrow. Applications that stop/restart the controller to change targets or retreat can therefore fire weak arrows into the ground instead of canceling the shot.
Environment: minecrafthawkeye 1.3.9, mineflayer 4.39.0, Minecraft Java 1.20.6, Node.js 24.18.0. The symptom was observed during live play; the release behavior was also reproduced in an isolated test with the real inventory and HawkEye plugins, simulated time, and captured outgoing packets. The isolated test does not simulate a complete server.
Minimal scenario
With the plugin loaded, a bow equipped, arrows available, and a valid visible target around 18 blocks away:
bot.hawkEye.autoAttack(target, 'bow')
// Wait until drawing has started, but less than a full bow charge.
setTimeout(() => bot.hawkEye.stop(), 300)
Capture outgoing use_item and block_dig packets. stop() emits block_dig with status 5 before the normal charge interval. Calling autoAttack(nextTarget, 'bow') after stop reproduces this on each retarget. In our integration test a mid-draw retarget released after 450 ms; an uninterrupted draw released after 1250 ms.
Expected / actual
- Expected: a way to cancel a pending draw without releasing an arrow; changing the target with the same bow should be able to preserve draw progress.
- Actual: stop() calls bot.deactivateItem(), which means RELEASE_USE_ITEM, not cancellation. It releases a partially drawn bow.
The relevant implementation is src/hawkEye.ts, stop(). If releasing is intentional for the current stop API, a distinct cancel API would make the contract explicit.
Suggested direction
Separate aim retargeting, intentional firing, and cancellation. On Java 1.20.6, a main-hand carried-slot change stops item use without releasing the bow, unlike RELEASE_USE_ITEM. A cancellation implementation using that mechanism must track ownership of the active draw/slot and must not restore an old slot over a replacement controller. Server plugins can veto carried-slot changes, so that limitation should be documented.
Regression cases: cancel a partial draw without a release packet; retarget the same bow without resetting charge; complete normal repeated shots; switch to melee/retreat; start a new attack after cancellation. This is distinct from #25's aim/rotation packet issue.
Problem
Stopping a bow attack during draw sends a release-use-item packet and fires an undercharged arrow. Applications that stop/restart the controller to change targets or retreat can therefore fire weak arrows into the ground instead of canceling the shot.
Environment: minecrafthawkeye 1.3.9, mineflayer 4.39.0, Minecraft Java 1.20.6, Node.js 24.18.0. The symptom was observed during live play; the release behavior was also reproduced in an isolated test with the real inventory and HawkEye plugins, simulated time, and captured outgoing packets. The isolated test does not simulate a complete server.
Minimal scenario
With the plugin loaded, a bow equipped, arrows available, and a valid visible target around 18 blocks away:
Capture outgoing use_item and block_dig packets. stop() emits block_dig with status 5 before the normal charge interval. Calling autoAttack(nextTarget, 'bow') after stop reproduces this on each retarget. In our integration test a mid-draw retarget released after 450 ms; an uninterrupted draw released after 1250 ms.
Expected / actual
The relevant implementation is src/hawkEye.ts, stop(). If releasing is intentional for the current stop API, a distinct cancel API would make the contract explicit.
Suggested direction
Separate aim retargeting, intentional firing, and cancellation. On Java 1.20.6, a main-hand carried-slot change stops item use without releasing the bow, unlike RELEASE_USE_ITEM. A cancellation implementation using that mechanism must track ownership of the active draw/slot and must not restore an old slot over a replacement controller. Server plugins can veto carried-slot changes, so that limitation should be documented.
Regression cases: cancel a partial draw without a release packet; retarget the same bow without resetting charge; complete normal repeated shots; switch to melee/retreat; start a new attack after cancellation. This is distinct from #25's aim/rotation packet issue.