Getpos result is offset 64 units vertically

[vrad-exe]

Describe the bug

When running the getpos command, the resulting Z position is 64 units higher than your actual position. This often results in the following setpos command getting you stuck in ceilings, or just teleporting into midair.

One of P2CE's changelogs claims to have fixed this, but this doesn't seem to actually be the case.

To Reproduce

1. Open any map
2. Turn on noclip
3. Run getpos and copy the resulting setpos command
4. Paste the command in and run it
5. You get teleported 64 units up

Expected Behavior

The result of getpos should not be offset 64 units up.

Operating System

Tested on Windows 10

[hexaflexahexagon]

this is intentional to avoid people getting stuck in the ground or something like that, so getpos_exact and setpos_exact exist. we could probably just consolidate the two i dont think there's a good reason it should be two separate commands

[vrad-exe]

I assumed the _exact versions just had a higher decimal precision or something. Not sure why getting stuck in the floor would be an issue if you're teleporting to the exact position you were in before, which wouldn't have been stuck...

[lvaness]

getpos returns you view vector while setpos sets your origin, which is where the mismatch comes from. Probably not ideal

[lvaness]

And getpos and getpos_exact are the exact same command funnily enough

[hexaflexahexagon]

Yeah, the exact version just returns setpos_exact instead of normal setpos

[vrad-exe]

How useless.

[vrad-exe]

Should probably remove the exact versions, and make the command return your actual origin.

[hexaflexahexagon]

Maybe we can also make it reset velocity by default too while we're at it? idk if anybody uses that but it can be annoying. much less noticeable when the 64u upwards shift is gone though so maybe not a big deal

[vrad-exe]

Still an issue

[vrad-exe]

Still an issue, surely this can't be that hard to fix?