Repository navigation
Aim for //hpos{1,2} is off when you're tiny (scale base 0.1) #2642
Description
WorldEdit Version
7.3.6
Platform Version
fabric-0.16.5
Confirmations
- I am using the most recent Minecraft release.
- I am using a version of WorldEdit compatible with my Minecraft version.
- I am using the latest or recommended version of my platform software.
- I am NOT using a hybrid server, e.g. a server that combines Bukkit and Forge. Examples include Arclight, Mohist, and Cardboard.
- I am NOT using a fork of WorldEdit, such as FastAsyncWorldEdit (FAWE) or AsyncWorldEdit (AWE)
Bug Description
When I'm tiny (/attribute @s minecraft:generic.scale base set 0.1) and issue the command //hpos1 or //hpos2, it selects the wrong block, usually 1 to 3 blocks above what my crosshair points to.
Expected Behavior
It selects the block that my crosshair points to.
Reproduction Steps
/attribute @s minecraft:generic.scale base set 0.1- Stand in front of a wall.
- Point to a block somewhere in the middle of the wall.
//hpos1,//hpos2— both show wrong coordinates but usually I wouln't notice//set red— replaces wrong block
Anything Else?
No response
Activity
octylFractal commentedon Nov 4, 2024
What's the use case of doing this? This is probably non-trivial for us to support, as we do our own ray tracing for hit detection.
mk-pmb commentedon Nov 4, 2024
It allows me to stand inside the quarter block gap of the stairs block that protects players from the cave spiders, at the inner edge almost falling into the spider pit. From there, I can easily aim at relevant points inside the pit, of which most would be obstructed when I'm standing in front of the stairs block.
octylFractal commentedon Nov 4, 2024
I don't quite understand what you mean, you seem to be referring to something you've built but I don't know what that looks like.
It sounds like something survival-related, which we don't particularly care about?
mk-pmb commentedon Nov 4, 2024
In that scenario I was in creative mode building a spider trap.
octylFractal commentedon Nov 4, 2024
Why not just teleport inside with /thru?
mk-pmb commentedon Nov 4, 2024
Actually, I didn't try, because I had no intent of entering the chamber. It might have been that easy. I'll try later.
mk-pmb commentedon Nov 5, 2024
/thruseems a bit unreliable, often not finding a free position, or picking the far wall of the pit, teleporting me way beyond. Even when I'm standing in a full air block behind the stair, and even if I go even farther back to have multiple air blocks between me and the stair. In the few cases I managed to go into the pit, it's very picky about where I have to aim to go back into the player room. My guess is that/thrulooks for a two-block high space even though I'm smaller than half a block. It also doesn't like when I'm standing close to a wall, probably because being tiny implies automatic wall hack (probably a game bug).If you meant to reset the scale to 1.0 before every
/thru, that would be inconvenient and then it would even be justified in only allowing two-high spaces.It seems to be a general bug about assuming the eye position from player position without consideration of body shape. The effects are the same whether I'm tiny, or normal-sized but "swimming" in a 1-high space below a trap door:
If it's the same problem, we should probably change the bug to be about the swimming because that's a more common scenario.
Bonus: If I'm a giant (scale 3.0), //hpos{1,2} aims at the floor in front of the wool blocks rather than the red wool block.
octylFractal commentedon Nov 5, 2024
Yes, we assume that because otherwise we would need to wire API to expose such a thing from the platform, and also track that. I don't think we really have a huge desire to implement this, as it would be very time-consuming for little benefit to most players. You or anyone else who wants it is welcome to take a shot at implementing it and contribute back.
mk-pmb commentedon Nov 5, 2024
I have another patch pending for {,h}pos{1,2} that was deemed to small for a PR, so I'll try and use this opportunity.
mk-pmb commentedon Nov 12, 2024
No progress yet, but another use case: I'm in the middle of a sandwich with alternating layers of top slabs and air blocks. I'm trying to aim at the opposite corners of the floor, but all I manage to select with //hpos{1,2} are some of the top slabs above me.
LordChrom commentedon Oct 11, 2025
This is pretty impactful for tight redstone situations, because you're frequently in the crawl animating between wires, and this affects the selection as well as usage the compass, convenience or /j (which affects me pretty significantly as I have hotkeys for the hpos commands and /j that I use constantly).
For similar reasons, players might have resized hitboxes for redstone, which means the commands will never work without changing scale.
It was also very easy for me to implement this in my own worldedit fork, as it basically only needed the addition of a getEyeHeight to the player interface, which on every platform is just a wrapper of a provided getter function from that platform's player class.
Here's the commit in question, and it's +36 -2
octylFractal commentedon Oct 11, 2025
A PR would be welcome, but should be targeted to
masterand follow our formatting guidelines.me4502 commentedon Oct 11, 2025
Is the eye height really the only factor here though? If a player is scaled to 0.1, their "centre point" horizontally is going to be very different to what it would be at full size- it feels like it would need full model scale information. When I initially experimented with scale it didn't retain "player centre = player position," unless MC has fixed that in recent updates
octylFractal commentedon Oct 11, 2025
I don't think this is done incorrectly in current MC. Teleporting to 0,y,0 (which places you at 0.5, y, 0.5) correctly centers me.
LordChrom commentedon Oct 11, 2025
It works perfectly in my testing, even at max scale (16x), where the player is 29 blocks tall and 9.6 blocks wide (and so any deviations would be noticed). I tested using WeCUI and targetting with hpos at various positions. Looking straight down selects the block immediately centered below the player, and various tests in complex ingame scenarios like jungles and redstone computers show correct results.
The player's camera is always horizontally placed in the center of their hitbox, as is their foot position (which the coordinates represent), so I don't see why any factor other than eye height would need to be accounted for.
I can go make a PR targeting master at some point, but so far I've only tested on fabric, and this would need testing on every platform. It'll be a little bit of time before I'm free enough to go through the entire testing & contribution procedure.