Skip to content
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

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

Open
5 tasks done
mk-pmb opened this issue Oct 9, 2024 · 10 comments
Open
5 tasks done

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

mk-pmb opened this issue Oct 9, 2024 · 10 comments
Labels
status:accepted Will be fixed / added to WorldEdit, eventually type:feature-request Request for something new

Comments

@mk-pmb
Copy link

mk-pmb commented Oct 9, 2024

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

@mk-pmb mk-pmb added status:pending Pending acceptance or closure. type:bug Incorrect behavior, not working as intended labels Oct 9, 2024
@octylFractal
Copy link
Member

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
Copy link
Author

mk-pmb commented 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
Copy link
Member

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
Copy link
Author

mk-pmb commented Nov 4, 2024

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

@octylFractal
Copy link
Member

Why not just teleport inside with /thru?

@mk-pmb
Copy link
Author

mk-pmb commented 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
Copy link
Author

mk-pmb commented Nov 5, 2024

/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:

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
Copy link
Member

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.

@octylFractal octylFractal added type:feature-request Request for something new status:accepted Will be fixed / added to WorldEdit, eventually and removed type:bug Incorrect behavior, not working as intended status:pending Pending acceptance or closure. labels Nov 5, 2024
@mk-pmb
Copy link
Author

mk-pmb commented 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
Copy link
Author

mk-pmb commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:accepted Will be fixed / added to WorldEdit, eventually type:feature-request Request for something new
Projects
None yet
Development

No branches or pull requests

2 participants