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

Inaccuracy movement #123

Open
OutsiderH opened this issue Feb 17, 2024 · 9 comments
Open

Inaccuracy movement #123

OutsiderH opened this issue Feb 17, 2024 · 9 comments

Comments

@OutsiderH
Copy link

When player's yaw is in (0 ~ 5) or (91 ~ 359), roll is 0. In that case, without any input, player will automatically yaw left until it gets 90
.
yaw 0 means north.

@enjarai
Copy link
Owner

enjarai commented Feb 17, 2024

Not sure what you mean by this. If yaw was being applied constantly, I think I'd have noticed by now.

@OutsiderH
Copy link
Author

Sorry for bad English.
Yes, the yaw is apply constantly when you facing all directions expect Northeast.
It surely will happen when roll is 0.

@enjarai
Copy link
Owner

enjarai commented Feb 18, 2024

What version of the mod and minecraft are you using?

@OutsiderH
Copy link
Author

1.19.2

@enjarai
Copy link
Owner

enjarai commented Feb 19, 2024

Are you perhaps using Optifabric?

@OutsiderH
Copy link
Author

No optfabric

@enjarai
Copy link
Owner

enjarai commented Feb 22, 2024

Can you send a video of the issue? Its hard to understand when its just words.

@OutsiderH
Copy link
Author

You can see it slightly yaw left when roll is negative even it is close to 0, this is not happening when roll is close to 0 but it positive or it facing Northeast (probably yaw 5 ~ 90 based on my test).
note that roll value at center of the screen is got by ElytraMath.getRoll(yaw, DoABarrelRollClient.left)
video link https://mega.nz/file/duMgQLzB#Ag8kWKyqJugvASrvF4bb1w5OPaS2ixnC0n14ZByyzJQ

@enjarai
Copy link
Owner

enjarai commented Feb 26, 2024

Thats quite strange... My best guess would be some kind of floating point precision error.

I've actually already significantly reworked internal math after DABR 3.0, so there's a good chance this issue is already fixed in newer versions. This wont be backported to 1.19.2 tho.

I'll try to recreate this issue on the latest version once I have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants