Aim for //hpos{1,2} is off when you're tiny (scale base 0.1)

[mk-pmb]

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

1. /attribute @s minecraft:generic.scale base set 0.1
2. Stand in front of a wall.
3. Point to a block somewhere in the middle of the wall.
4. //hpos1, //hpos2 — both show wrong coordinates but usually I wouln't notice
5. //set red — replaces wrong block

Anything Else?

No response

[octylFractal]

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]

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]

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]

In that scenario I was in creative mode building a spider trap.

[octylFractal]

Why not just teleport inside with /thru?

[mk-pmb]

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]

/thru seems 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 /thru looks 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:

• Screenshot: Aiming at the upper half of cyan wool floor
• Screenshot: Aiming at the lower half of cyan wool floor
• Screenshot: Aiming at the floor

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]

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]

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.