What do you need help with?

Why does when i try to run
find end_portal_frame
it tells the correct X and Z but not Y?

Final checklist

• I know how to properly use check boxes
• I have not used any OwO's or UwU's in this issue.

Looks like #find was overlooked when adjusting things for the new (variable) coordinate range.
It's always off by the how deep below y 0 you world reaches because the chunk cache still uses y coordinates from 0 up and obviously #find outputs that unchanged.

fuuuuuuuuuu....

well...

and

they need to be ints to not overflow, as well as these 2 actually + minY

From what I can tell the chunk packer fills specialBlockLocations with chunk local coordinates (starting at 0,0,0 and ending at 16,totalHeight,16), which seems to be intended. However getAbsoluteBlocks offsets only x and y by the chunks position, leaving y starting from 0 even if the chunk is at x,-32,z. getAbsoluteBlocks is then used by some chained getLocationsOf methods and ultimately by FindCommand.execute.

Yeah, just showing that there's a second problem to fix as well.

what you stated was a consequence of the other issues... and actually. it is 59 because ChunkPacker turns -64 (or the minY) into 0

(((byte) -5) & 0xff) == 251 but the screenshot shows -5 becoming 59. We are at two bugs now.

So specialBlockLocations is not supposed to be 0,0,0 upwards but 0,minY,0 upwards?

yeah, specialBlockLocations should be stored/retrieved as the actual BlockPos's not the offset value it currently is

Doesn't make sense to me since x and z are definitely supposed to be chunk local but ok.
Local xz and global y then

I had concluded that getLocalBlocks was supposed to be 0,0,0 up (and hence speciaBlockLocations as well) with all local->global transformations being done in getAbsoluteBlocks.
If that's wrong my point about not doing necessary adjustments is obviously wrong and there's one less problem to fix.

I guess y could be stored/retrieved either way, it just has to be consistently accessed/used, and either way its data type needs to be bumped to at least a short or it'll overflow the max of 4098 blocks tall. I don't think it should be in a BlockPos as 0 up because the blockpos format can't be used that way, ie. with local chunk x/z Chunk.getBlockState(pos) still works, but the Y needs to be correct for that (and so minY up).

so I just remembered, this is a known issue #3375, and I forced that merged in some newer versions, which mc version is this...