-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Elytra in overworld #4698
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 1.19.4
Are you sure you want to change the base?
Elytra in overworld #4698
Conversation
This reverts commit 984c71e.
…ilize height map to save some cycles if player is flying above ground.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow!
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. |
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. |
leijurv never merges my PRs anyways |
say no more, i'll check back next month |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
unlesselytraTermsAccepted
is now outdated. It mentions elytra flight only being for the nether (now wrong) and also recommendselytraAutoJump
, 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?
@@ -39,16 +39,16 @@ public BlockStateOctreeInterface(final NetherPathfinderContext context) { | |||
} | |||
|
|||
public boolean get0(final int x, final int y, final int z) { | |||
if ((y | (127 - y)) < 0) { | |||
if (y < 0 || y > 383) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This always checks for the maximum chunk height, is that correct? i.e. does nether-pathfinder always allocate full-size chunks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch. Can you please autoformat your code with whatever formatting the rest of Baritone uses?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using properly formatted braces would make it take up more lines for no benefit
src/main/java/baritone/process/elytra/NetherPathfinderContext.java
Outdated
Show resolved
Hide resolved
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except iirc C++ considers any data race undefined behavior and doing this across an ffi boundary won't make things better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
writeChunkData(chunk, ptr); | ||
writeLock.lock(); | ||
try { | ||
long ptr = NetherPathfinder.allocateAndInsertChunk(this.context, chunk.getPos().x, chunk.getPos().z); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this always returns a completely zeroed chunk?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
fixed
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.
fixed
fixed to behave the same |
You want to fix the out-of-bounds crash before merging this or later? |
before. i also found another bug last night that's more important. |
I've added a commit on my branch (underscore-zi@d0c3aea) that pulls all those adjustments into the 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? |
Just fixed the rest of the known bugs in 75096e1
merged |
Still get a crash by these steps
|
@@ -1262,6 +1280,7 @@ private static Vec3 step(final Vec3 motion, final Vec3 lookDirection, final floa | |||
return new Vec3(motionX, motionY, motionZ); | |||
} | |||
|
|||
// any call to this must be done with the lock held |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you maybe apply this comment to all methods which require synchronization and specify that the readlock is required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only function run on the main thread that requires synchronization but i added a comment to solveAngles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell we have
passable called by simulate and pathFindAroundObstacles
simulate called by solvePitch called by the other solvePitch called by solveAngles
solveAngles called by onPostTick with synchronisation and by tick (and tick is public)
tick called by ElytraProcess.onTick with synchronization on the main thread
pathFindAroundObstacles called by PathManager.tick called by onTick0 called by onTick with synchronization on the main thread
At least tick
needing synchronization should be documented.
src/main/java/baritone/process/elytra/BlockStateOctreeInterface.java
Outdated
Show resolved
Hide resolved
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. |
fixed |
Replace |
fixed again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm out of crashes now. The only thing I managed to find is an "Unhandled exception" error message when you change to an invalid goal mid-flight, but that's not new. (e.g. #goal ~
).
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). |
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. |
This is amazing |
Started by @underscore-zi
nether-pathfinder changes have been merged in babbaj/nether-pathfinder#20
Closes #4187