Elytra in overworld #4698

babbaj · 2025-04-04T05:24:22Z

Started by @underscore-zi
nether-pathfinder changes have been merged in babbaj/nether-pathfinder#20
Closes #4187

This reverts commit 984c71e.

…ilize height map to save some cycles if player is flying above ground.

thelampgod

wow!

underscore-zi · 2025-04-05T17:54:14Z

I do have a couple minor commits over on https://github.com/underscore-zi/baritone

First is respecting the allowRoof setting when searching for a landing spot. I had left a TODO in for this but hadn't done so yet.

Second is adding Cobblestone and Obsidian to allowed landing blocks. In vanilla the current list is fine but I was using this around 2b's spawn and it had some issues finding landing spots.

ZacSharp · 2025-04-06T01:54:48Z

Can you please wait three days with merging? I'd like to properly read through and test this, but won't be able to do so before April 8.

babbaj · 2025-04-06T02:30:57Z

leijurv never merges my PRs anyways

leijurv · 2025-04-06T04:32:42Z

Can you please wait three days with merging?

say no more, i'll check back next month

ZacSharp

Ok, didn't expect quite as much breakage, but this adds at least two ways to crash the game.

Disabling elytraUseBaritoneCache unconditionally causes an NPE, crashing the game unless this happens inside a command
Disabling elytraAllowAboveRoof while flying above the nether roof and then causing recalculation crashes the game. I didn't even get a crash report, but no segfault either?
Enabling elytraPredictTerrain in the overworld leads to endless recalculation and chat spam. Actually not a crash though.

Some less severe points

The wall of text printed by #elytra unless elytraTermsAccepted is now outdated. It mentions elytra flight only being for the nether (now wrong) and also recommends elytraAutoJump, which has hardly any chance of working in the overworld, and should also mention that terrain prediction is nether-only.
The path is automatically recalculated when elytraNetherSeed changes, elytraAllowThighsSpaces does not have this effect. Not sure whether automatically recalculating is better.

I also really do not like how we are offsetting positions back and forth all across the code. Just look at how many times this went wrong with the existing chunk cache.
Can't we just use exactly one coordinate type (absolute world coordinates) in Baritone and shift to 0 based at the API boundary?
You didn't want to do this in nether-pathfinder itself, but maybe we can wrap the java side of the API to do the shifting?

src/api/java/baritone/api/Settings.java

src/main/java/baritone/process/elytra/BlockStateOctreeInterface.java

ZacSharp · 2025-04-09T13:39:47Z

src/main/java/baritone/process/elytra/NetherPathfinderContext.java

+        if (this.dimension == Level.NETHER) dim = NetherPathfinder.DIMENSION_NETHER;
+        else if (this.dimension == Level.END) dim = NetherPathfinder.DIMENSION_END;
+        else dim = NetherPathfinder.DIMENSION_END;
+        int height = Math.min(world.dimensionType().height(), 384);
+        if (!Baritone.settings().elytraAllowAboveRoof.value && dim == NetherPathfinder.DIMENSION_NETHER) height = Math.min(height, 128);


Ouch. Can you please autoformat your code with whatever formatting the rest of Baritone uses?

using properly formatted braces would make it take up more lines for no benefit

src/main/java/baritone/process/elytra/NetherPathfinderContext.java

ZacSharp · 2025-04-09T13:44:07Z

src/main/java/baritone/process/elytra/NetherPathfinderContext.java

-                boolean isSolid = pair.second() != AIR_BLOCK_STATE;
-                Octree.setBlock(ptr, pos.getX() & 15, pos.getY(), pos.getZ() & 15, isSolid);
-            });
+            // not inserting or deleting from the cache hashmap so we should be fine not being exclusive


Except iirc C++ considers any data race undefined behavior and doing this across an ffi boundary won't make things better.

It's undefined behavior if another thread is writing to the data at the same time we are reading it but that is not the case here.

We are the writing thread here, but since we only have the read lock another thread may do the reading required to trigger undefined behavior.

In case you forgot / didn't see it, there's an Octree.setBlock call in this block. The hashmap reading is hopefully fine, as the comment says.

The pathfinder racing with this would be inconsequential however multiple calls to this to nearby blocks could cause bad data to be written so i will change it to use a write lock. The read executor is still single threaded so there currently isn't a difference anyways.

src/main/java/baritone/process/elytra/NetherPathfinderContext.java

babbaj · 2025-04-10T04:11:50Z

Disabling elytraUseBaritoneCache unconditionally causes an NPE, crashing the game unless this happens inside a command

fixed

Disabling elytraAllowAboveRoof while flying above the nether roof and then causing recalculation crashes the game. I didn't even get a crash report, but no segfault either?

I don't think this description is accurate. If elytraAllowAboveRoof is off and we put ourself above the roof then there is a crash (nether-pathfinder printing "retard" to stderr and calling std::terminate) but changing that setting while flying has no effect except possibly when it finds a landing spot.

I have not yet fixed this but I will probably fix it by pausing pathfinding until the player goes back below the roof.

Enabling elytraPredictTerrain in the overworld leads to endless recalculation and chat spam. Actually not a crash though.

fixed

The path is automatically recalculated when elytraNetherSeed changes, elytraAllowThighsSpaces does not have this effect. Not sure whether automatically recalculating is better.

fixed to behave the same

underscore-zi · 2025-05-08T07:44:43Z

Have nether-pathfinder generate a path to y=320, then on the java side, add a path point after that that's at like same x,z but y=350 or something. Then the next path point is the goal x,z at y=350.

I don't have much time to work on this at the moment, but I originally used an implementation kinda like that and was working on a less hacked together implementation more recently but haven't finished. So I'm just kinda dumping what I had for my future-self or if someone else gives it a stab:

To allow it to follow a path that goes outside of the pathfinders limits ElytraBehavior:clearView has to be patched to use ctx.world().clip(...) instead of the native pathfinder when above the y-limit. And ElytraBehavior:passable to use this.bsi like the ignoreLava path instead of this.boi.

Then for actually generating the path without pathfinder support for GoalY, I took advantage of the fact that it would attempt to pathFind again when near the end of an incomplete(finished=false) path.

When pathFinding it would check the source. If its above or near 320 and above the height map of the area it would just generate point path. If going far enough it would attempt to pathfind to 75%[0] the minimum distance with y=320, or it would just pathfind to the destination.

This allowed it to fly under a roof by just repeatedly creating incomplete paths going 75% the minimum distance and eventually switch to the point path whenever the route became clear.

Also its worth noting that the point path did need to be more detailed than just the destination point as it didn't like to fly if the next point wasn't loaded in. Though that might be fixable by patching clearView to be true when at elevation instead of using clip(...).

[0] 75% wasn't chosen for any particular reason, just giving some breathing room

lawnguy1201 · 2025-08-11T02:21:45Z

What has happened with this?

kittenvr · 2025-08-11T09:34:13Z

What has happened with this?

A random guy has commented on this 3 months later

lawnguy1201 · 2025-08-12T01:31:08Z

What has happened with this?

A random guy has commented on this 3 months later

no shit

kittenvr · 2025-08-12T10:24:40Z

What has happened with this?

A random guy has commented on this 3 months later

no shit

So why are you asking if you already know

underscore-zi · 2025-08-12T17:53:32Z

Still actively working on it.

I have something that generally works and goes above the build limit. Though I've been working out some bugs where it seems to get stuck momentarily as if it can't see the next node (despite clear raytraces to it).

Also some issues with generated the transitions between the different path generators since it usually tries to transition right at the edge of loaded chunks when it tries to pathfind right when a new chunk gets loaded.

lawnguy1201 · 2025-08-13T21:56:41Z

Still actively working on it.

I have something that generally works and goes above the build limit. Though I've been working out some bugs where it seems to get stuck momentarily as if it can't see the next node (despite clear raytraces to it).

Also some issues with generated the transitions between the different path generators since it usually tries to transition right at the edge of loaded chunks when it tries to pathfind right when a new chunk gets loaded.

Nice, would there be anyway I could get the .jar. working on a project and it need B to fly in the OW.

underscore-zi · 2025-08-22T18:04:06Z

I'm trying to troubleshoot some behavior and wondering if any of you all might be able to point me to where in code this behavior might be coming from.

2025-08-22-113218482-2c80a.webm

Basically, as the Elytra crosses the build limit it starts to have trouble following the path. It'll follow the path, then seem to get stuck and start spinning. This is similar to the behavior that happens when about to enter an unloaded chunk though it is loaded in this case.

I suspect something sees it as unloaded (ctx.world().isLoaded returns false for y > build limit, but I've patched that already in ElytraBehavior). Though I'm not sure where this spin behavior comes from exactly. And if I reduce the flight level to be under the build limit, it works without issue. So I'm thinking there is some check buried away I've missed besides the one in attemptNextSegment

Edit: and for what its worth raytraces all come up green.

kittenvr · 2025-08-22T20:16:17Z

I'm trying to troubleshoot some behavior and wondering if any of you all might be able to point me to where in code this behavior might be coming from.
2025-08-22-113218482-2c80a.webm

Basically, as the Elytra crosses the build limit it starts to have trouble following the path. It'll follow the path, then seem to get stuck and start spinning. This is similar to the behavior that happens when about to enter an unloaded chunk though it is loaded in this case.

I suspect something sees it as unloaded (ctx.world().isLoaded returns false for y > build limit, but I've patched that already in ElytraBehavior). Though I'm not sure where this spin behavior comes from exactly. And if I reduce the flight level to be under the build limit, it works without issue. So I'm thinking there is some check buried away I've missed besides the one in attemptNextSegment

Edit: and for what its worth raytraces all come up green.

are you sure the chunks arent actually unloaded

underscore-zi · 2025-08-22T21:37:53Z

are you sure the chunks arent actually unloaded

Yes

ZacSharp · 2025-08-23T00:26:59Z

Having a short look at the solver it looks like isHitboxClear might also need patching to not use context.raytrace. Not sure why passable needs to use bsi instead of boi since boi.get returns false/air for out of bounds positions, which is what we need here.

leijurv · 2025-08-23T03:11:57Z

yeah looks like something messed up with the raytracer. out of bounds (above the ceiling) should return air

underscore-zi · 2025-08-23T07:56:34Z

Thanks! Fixed it. Was able to trace the bug down from isHitBoxClear.

It was indeed a raytracing bug, miscalculated when a target was in/out of bounds resulting in misusing the NetherPathfinder for OOB raytraces.

nonokirby · 2025-08-23T16:42:33Z

Is this pull stable enough to fork and run currently, or does it have major issues still? specifically looking to elytrafly in/around 2b's spawn if knowing terrain helps.

ZacSharp · 2025-08-24T21:30:16Z

As far as I know there are no known (new) bugs, so should definitely be usable.

(The reason this isn't merged is a pending functional change)

underscore-zi · 2025-08-29T03:57:16Z

I have some commits implementing flight above the build limit over on: https://github.com/underscore-zi/baritone

I do make one major structural change which might raise some eyebrows. I've extended the API with IElytraPathfinderContext and IElytraPathfinderContextFactory

So now, the NetherPathfinderContext basically already implemented the interface, and I've added a new SkyPathfinderContext which also implements the interface and wraps the NetherPathfinder to extend it adding support for flight above the build limit. ElytraBehavior uses the appropriate context for the dimension/settings, keeping the original performance if users want that.

In defense of having this in the API is does serve to implement a feature I've wanted, the ability to navigate between waypoints without doing the whole takeoff/fly/land process for every point or changing the destination when the flight gets close to each point. I made a nice like flight replayer for myself with this.

…s executed/finishes by adding a timeout

ZacSharp · 2025-09-04T16:51:18Z

Tried to come up with a funky way to review this. Wouldn't have expected that two people working on one pr is such a big problem on a "collaboration platform".

SkyPathfinderContext uses the wrong naming convention for it's private helpers.

underscore-zi/baritone@20c1631...94a466b#diff-aa0f9f28257c586978349ec09d0ec52c19858ebfc79ff63b56b498a69ca16d14R28
I don't like exposing nether-pathfinder API directly in our API. And UnpackedSegmend is imho a prime example of what's considered an implementation detail.

underscore-zi/baritone@20c1631...94a466b#diff-f881174eae586d93b19f8eb3f9c26af571c0ca278f7d9a108cba4d66a71f519fR397-R398
Aren't there fields caching these two values?

underscore-zi/baritone@20c1631...94a466b#diff-f881174eae586d93b19f8eb3f9c26af571c0ca278f7d9a108cba4d66a71f519fR443-R458
It looks weird to have both a special case when the field is null in the getter and a null-replacement in the setter.

underscore-zi/baritone@20c1631...94a466b#diff-eebf5e50d8fe55d39379412b51279851bba3a6f3019584be8ea2bfd36ce71fe1R85
I like how this is no longer being passed around. It uses the exact same internal storage and is fundamentally tied to the context, so might as well be part of it.

Honestly I'm not happy with the two new interfaces. IElytraPathfinderContextFactory feels like it's mostly boilerplate and IElytraPathfinderContext is just bad API. It is what netherpathfinder expects and using it internally makes sense, but it's a messy implementation detail.
There's also a concern about deadlocks here, because giving API users control of the context lock means the thing can lock and unlock in ways we do not expect. The thread "safety" in this part of Baritone is a mess already.

Flying around without landing sounds very reasonable though, so maybe there's a way to implement that feature without putting implementation details into the API package?

A somewhat unrelated idea I had is that iirc the pathfinder uses a symmetric movement set so there is no difference between going forwards or backwards. That means if the goal is already in render distance and we are still above the world we could run the pathfinder from the goal towards the build limit / our current position to determine where to transition down. Not sure whether that helps with anything.

# Conflicts: # src/main/java/baritone/process/ElytraProcess.java # src/main/java/baritone/process/elytra/ElytraBehavior.java # src/main/java/baritone/process/elytra/NetherPathfinderContext.java

babbaj · 2025-09-04T19:55:39Z

just merged his branch into mine. he was also a few commits behind so I had to merge and fix some conflicts.

underscore-zi · 2025-09-05T01:41:37Z

And UnpackedSegmend is imho a prime example of what's considered an implementation detail.

I feel like the Stream<BetterBLockPos> and boolean wrapper are what would be necessary to expose to allow someone else to provide a path. The name is a bit off though since the public side would have no knowledge of the "packed" segments.

Perhaps a simpler option would be to only allow the API user to provide waypoints and leave the path to Baritone. That perhaps fits better with Baritone more generally and would probably be the main usecase. One use-case I had for full pathing was flying down 2b diagonal highways where there was some active wither griefing so I couldn't bounce.

I don't like exposing nether-pathfinder API directly in our API.

Yeah, I wasn't the biggest fan of my own approach there though I mostly was just trying not to break anything outside of my own code. So isolated it via the abstraction. But yeah, I think I can clean that up quite a bit.

Raytracing stuff can be pulled back internal, no reason to have that overloadable if the base implementation supports OOB traces it handles all cases. Though it adds a bit of overhead as it needs to check which tracer to use. Chunk/block information can be obtained by any mod already so no point in providing that either; that also removes the locks.

Which would leave pathFindAsync, cancel and maybe destroy which feels much more sane. And I think that might remove the Factory too as there wouldn't be a need to provide the Baritone cache path into it.

underscore-zi · 2025-09-08T17:50:39Z

Committed to my fork again: https://github.com/underscore-zi/baritone

I pulled everything new out of the API, though I still use a simpler interface internally so the original Nether code can be swapped in depending on settings.

Murat65536 · 2025-09-14T12:50:21Z

Fixing a few of the things Codacy is mad about might also be a good idea. Mostly naming things. I wouldn't worry about the NPath complexity.

underscore-zi · 2025-09-16T19:12:22Z

I believe I've addressed all of the issues from Codacy that were still relevant. 👍

underscore-zi and others added 13 commits March 15, 2025 03:32

Add initial support for overworld/end flight

75a3acd

update to nether-pathfinder api/concurrency changes

dd2240a

Make usage of the Baritone cache optional for elytra flight

9d0a4cb

Set a better default Y for elytra GoalXZ

984c71e

Make sure player is in bounds before attempting elytra pathfinding

319aa58

Allow landing on bedrock (necessary for nether roof)

18a6899

Revert "Set a better default Y for elytra GoalXZ"

662ba65

This reverts commit 984c71e.

GoalXZ y-level will consider if player is above nether roof

c9aa9f7

Rework landing to be safed when descending from high y-levels, and ut…

b0ba8d3

…ilize height map to save some cycles if player is flying above ground.

Check negative y landing spots too

1a6c43e

Merge branch 'cabaletta:1.19.4' into 1.19.4

2004a1d

dynamically change destination y if the roof gets in the way

cf3260c

1.6

2290801

babbaj changed the title ~~Nether elytra update~~ Elytra in overworld Apr 4, 2025

memset if no air also cave air is real

3fb41ea

babbaj marked this pull request as ready for review April 4, 2025 07:29

thelampgod approved these changes Apr 4, 2025

View reviewed changes

ZacSharp mentioned this pull request Apr 4, 2025

Add support for auto-flight with Elytras in the overworld and the End. #4693

Closed

2 tasks

babbaj requested a review from leijurv April 5, 2025 03:59

babbaj and others added 3 commits April 5, 2025 00:05

custom allocator by default :^)

c7b76bc

Respect allowAboveRoof roof setting when looking for safe landing spots

094b3ef

Allow landing on cobblestone and obsidian

1ea67c2

ZacSharp requested changes Apr 9, 2025

View reviewed changes

babbaj added 2 commits April 10, 2025 00:12

elytra fixes

7feaa51

hold write lock in queueBlockUpdate

f3e6116

underscore-zi added 2 commits July 10, 2025 23:26

Create an interface for elytra pathfinding

a2784be

Add IElytraContextFactory

04c4ba2

Murat65536 mentioned this pull request Aug 4, 2025

Dependencies #4836

Draft

underscore-zi added 2 commits August 28, 2025 20:24

Implementation of flight above build limit for long distances

0f28075

Don't use the Sky pathfinder when in the nether and no roof allowed

6b3e5f3

underscore-zi added 2 commits August 29, 2025 17:35

Prevent races between destruction and creation of ElytraBehavior

248e644

Prevent deadlock when rapidly changing goals and the solver never get…

94a466b

…s executed/finishes by adding a timeout

Merge remote-tracking branch 'origin/1.19.4' into nether-elytra-update

cf91405

# Conflicts: # src/main/java/baritone/process/ElytraProcess.java # src/main/java/baritone/process/elytra/ElytraBehavior.java # src/main/java/baritone/process/elytra/NetherPathfinderContext.java

Elytra in overworld #4698

Are you sure you want to change the base?

Elytra in overworld #4698

Uh oh!

Conversation

babbaj commented Apr 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thelampgod left a comment

Choose a reason for hiding this comment

Uh oh!

underscore-zi commented Apr 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ZacSharp commented Apr 6, 2025

Uh oh!

babbaj commented Apr 6, 2025

Uh oh!

leijurv commented Apr 6, 2025

Uh oh!

ZacSharp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ZacSharp Apr 9, 2025

Choose a reason for hiding this comment

Uh oh!

babbaj Apr 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ZacSharp Apr 9, 2025

Choose a reason for hiding this comment

Uh oh!

babbaj Apr 10, 2025

Choose a reason for hiding this comment

Uh oh!

ZacSharp Apr 10, 2025

Choose a reason for hiding this comment

Uh oh!

ZacSharp Apr 10, 2025

Choose a reason for hiding this comment

Uh oh!

babbaj Apr 11, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

babbaj commented Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

underscore-zi commented May 8, 2025

Uh oh!

lawnguy1201 commented Aug 11, 2025

Uh oh!

kittenvr commented Aug 11, 2025

Uh oh!

lawnguy1201 commented Aug 12, 2025

Uh oh!

kittenvr commented Aug 12, 2025

Uh oh!

underscore-zi commented Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lawnguy1201 commented Aug 13, 2025

Uh oh!

underscore-zi commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kittenvr commented Aug 22, 2025

Uh oh!

underscore-zi commented Aug 22, 2025

Uh oh!

ZacSharp commented Aug 23, 2025

Uh oh!

leijurv commented Aug 23, 2025

Uh oh!

underscore-zi commented Aug 23, 2025

Uh oh!

nonokirby commented Aug 23, 2025

babbaj commented Apr 4, 2025 •

edited

Loading

underscore-zi commented Apr 5, 2025 •

edited

Loading

babbaj commented Apr 10, 2025 •

edited

Loading

underscore-zi commented Aug 12, 2025 •

edited

Loading

underscore-zi commented Aug 22, 2025 •

edited

Loading