Baritone Tick Phases
ZeroMemes opened this issue ยท 0 comments
Currently, event priority is done through the order that behaviors are registered in. As a result, PathingControlManager
relies on PathingBehavior
to call its preTick
method, and postTick
is called by registering an event listener after all behaviors have been created and registered.
I think a much better solution to this problem would be to outline the phases in which Baritone needs to execute its code every tick. I'm proposing something like:
- PreTick
- Called at same time as existing PRE TickEvent
- Used for setup that may be required in multiple different places
- LookBehavior AimProcessor tick
- InventoryBehavior lastTickRequested
- PathingBehavior queued event dispatch
- ElytraBehavior solver fetch
- etc.
- Incrementing count-down/up tick counters
- SetupPath
- Process is selected for this tick and asked what to do
- PreparePath
- InputOverrideHandler can modify the player's movement input if needed
- PostPath
- Equivalent to PathingBehavior's
postTick
which does the re-validation stuff. Arguably this phase doesn't need to exist and could just go in the PostTick described below.
- Equivalent to PathingBehavior's
The actual game tick is executed here, between PostPath and PostTick. The world entities are ticked, starting with the player, and all the player input/rotation changes we've made up to this point will be applied.
- PostTick
- Called at the very end of the game tick.
- Used for actions that need to be executed after the game's world tick has completed.
- ElytraBehavior already uses this for queuing async calculation between game ticks.