search

cabaletta / baritone

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

AT_GOAL PathEvent never triggered #2794

Open big-lip-bob opened 3 years ago

big-lip-bob commented 3 years ago

Some information

Operating system: Linux Manjaro 5.12.8-1 x64 Java version: 8u252 x64 Minecraft version: 1.12.2 Forge 2847 Baritone version: 1.2.15 (With API) Mods

Expectations and Reality

AT_GOAL from PathEvent is never given despite arriving at the goal, which does against my expectations or is at least named counter intuitively then. Despite receiving all other Baritone events successfully, trough the set listener, this elusive one which is also the most important one doesn't seem to trigger at all (all the rest trigger so i don't see where would i blame myself on this one)?

How to reproduce

Register a listener, (in my case done trough LuaJava for AM), #goto somewhere easy and reacheable, expected to receive an AT_GOAL event, but didn't (did get CALC_STARTED and CALC_FINISHED_NOW_EXECUTING) Can send the AM snippet on demand. essentially calling registerEventListener on the primary Baritone instance gotten trough the provider, with my listener that dumbly prints the received events on the primary baritone instance from the provider, it works for all, but just this one missing.

Modified settings

None, but for the registered Event Listener (consequences ?)

Final checklist

ZacSharp commented 3 years ago

This is specifically about AT_GOAL not being fired when the CustomGoalProcess finishes. Apparently it explicitly requests canceling the current segment, resulting in AT_GOAL only being fired when the last movement reports not being safe to cancel (e.g. parkour or water bucket falls)

big-lip-bob commented 3 years ago

Well then apparently i am forced to wait aren't i, thanks for the explanation, ill see what can i do about it when ill be free

MajsterTynek commented 2 years ago

The issue is still persistent. Is waiting for the CANCELLED event a reasonable workaround?

ZacSharp commented 2 years ago

Sounds reasonable, if you don't care about #cancel (and any other command activating a nontemporary process) being interpreted as a success. I think a more complete workaround using a helper process might be possible but unless you really need it it's probably unreasonably complex.

Matt-MX commented 3 months ago

Issue is still persistent in 1.10.2