Elytra in overworld

[babbaj]

trafficstars

Started by @underscore-zi nether-pathfinder changes have been merged in https://github.com/babbaj/nether-pathfinder/pull/20 Closes #4187

[underscore-zi]

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]

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]

leijurv never merges my PRs anyways

[leijurv]

Can you please wait three days with merging?

say no more, i'll check back next month

[babbaj]

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

[ZacSharp]

You want to fix the out-of-bounds crash before merging this or later?

[babbaj]

before. i also found another bug last night that's more important.

[underscore-zi]

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?

I've added a commit on my branch (https://github.com/underscore-zi/baritone/commit/d0c3aeac783d8d97c859553849d1da8c888900db) that pulls all those adjustments into the NetherPathfinderContext methods that make the pathfinder calls along with one Octree usage in BlockStateOctreeInterface.

On a related note, is there a better way for me to share commits? Or would you just prefer I left it all over to Babbaj now since its not my PR?

[babbaj]

Just fixed the rest of the known bugs in https://github.com/cabaletta/baritone/pull/4698/commits/75096e1d352d0cc208d1f1be471ecf8f0e82259d

I've added a commit on my branch (https://github.com/underscore-zi/baritone/commit/d0c3aeac783d8d97c859553849d1da8c888900db)

merged

[ZacSharp]

Still get a crash by these steps

1. Stand on the nether roof with some firework rockets and an elytra
2. Run #settings reset all, #elytraAllowAboveRoof true, #thisway 1000, #elytra
3. Start flying
4. Run #elytraAllowAboveRoof false, #elytra reset

[ZacSharp]

On a related note, is there a better way for me to share commits? Or would you just prefer I left it all over to Babbaj now since its not my PR?

You could open pull requests against babbaj's pull request branch, but I'm not sure whether that's better than a writing a comment.

[babbaj]

Still get a crash by these steps

fixed

[ZacSharp]

Still get a crash by these steps

fixed

Replace #elytra reset with changing elytraNetherSeed/elytraPredictTerrain/elytraAllowTightSpaces and it crashes once again.

[babbaj]

fixed again

[leijurv]

I will merge this..... on one condition........

When you #elytra to a goal in the overworld that is at least some distance away (configurable setting, defaults to, let's say 1000 blocks), it should fly upwards (if it cannot fly upwards it'll go towards the goal of course). Once it gets above y=320, it will have a single target point that is simply the goal (ignoring the Y of the goal). I think this will work fine in the code because raytraces in minecraft have a maximum number of blocks they visit so it won't be too laggy? If it is laggy just add partial points at fractions along the way. Then once it is near the goal it dips back down below 320 and does landing or whatever at the goal

I think this would be a compromise that would allow it to fly through interesting overworld terrain like 2b2t spawn, while still going straight any-angle diagonal towards the goal (rather than the straight + 45° thing that I just think is low quality).

[babbaj]

It is currently not possible to fly above y 320 without increasing the height in nether-pathfinder even more. That should be an easy change.

[kittenvr]

This is amazing

[leijurv]

It is currently not possible to fly above y 320 without increasing the height in nether-pathfinder even more. That should be an easy change.

No the whole point is to not use nether-pathfinder above the ceiling. When above y=320, you point in a straight line to the goal, without any pathfinding. Don't increase the height of nether-pathfinder's chunks

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.

Might need to edit nether-pathfinder to support GoalYLevel

[leijurv]

(and it should only do this if the destination is at least, e.g., 1000 blocks away. configurable setting)

[underscore-zi]

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]

What has happened with this?

[kittenvr]

What has happened with this?

A random guy has commented on this 3 months later

[lawnguy1201]

What has happened with this?

A random guy has commented on this 3 months later

no shit

[kittenvr]

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]

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]

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]

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]

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]

are you sure the chunks arent actually unloaded

Yes

[ZacSharp]

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.