BetterFPS breaks elytras

[makamys]

Originally reported on Discord by nikonh#8594, reposting here for visibility with further research.

Please check any boxes that apply to you and your issue

• I use a translator application to post this issue.

• This is a crash. Please upload, Pastebin, Gist or copypaste the whole crash report along with this issue.

• This is a mod incompatibility. If I do this in vanilla Forge with only Et Futurum Requiem installed, it works normally.

Version number of Et-Futurum-Requiem (IMPORTANT)

2.4.6, 2.5.1

Describe the issue (IMPORTANT)

If you look straight upwards while gliding with an elytra, you will seemingly fall through the ground. Running a /tp command with relative coordinates at this point will fail with the message 'NaN' is not a valid number.. After relogging, your X and Z coordinates will be NaN, effectively bricking your save.

Edit: /tp commands with absolute coordinates can still be used to recover yourself, but doing anything after relogging is made difficult by the framerate being extremely low due to constant LWJGL error spam.

elytra_bug.mp4

Mod list (OPTIONAL)

• Et Futurum Requiem 2.4.6 or 2.5.1
• BetterFPS 1.0.1

Additional Context (OPTIONAL)

BetterFPS replaces the implementations of MathHelper#sin and MathHelper#cos with ones that may produce different results.

After some brief testing, I observed the following results when landing while looking straight up:

Algorithm	Result
rivens-half (default)	Players coordinates get set to NaN
java	No problems
libgdx	No problems
rivens-full	No problems
rivens	No problems
taylors	Camera spins wildly upon landing
vanilla	No problems (obviously)

[DarianLStephens]

Oh dang, it's BetterFPS causing this?
It's been a problem since Backlytra, and made me disable elytras for the longest time.
Good to know there are ways to work around the issue!

[GregoriusT]

Hey uhm, if i was a Modpack Maker, what config would you recommend for BetterFPS regarding sin/cos algorithm to keep the optimizations and not screw up the everything? That Table shows quite a lot of options, but without much info on what they actually are, so I wouldn't know what to choose.

[makamys]

I would recommend not using BetterFPS at all since it's clearly not safe. I'm also unsure how much of a performance concern trigonometry functions are in the first place, vanilla uses a lookup table which seems pretty optimal. The tester you get when you run the jar seems pretty useless too, it keeps giving very different results and uses reflection to invoke the methods to be tested for some reason.

If someone really wanted to experiment with it, well, taylors and rivens-half are out of the question, and vanilla is the same as not having the mod installed. java is the naive method so it's unlikely to be fast. That leaves libgdx, rivens-full and rivens as the candidates. But it's entirely possible they're unsafe too, all I can say is they don't seem to break Et Futurum Requiem's elytras.

By the way, the implementations of all the different algorithms can be checked here.

[Roadhog360]

Thanks for the comprehensive breakdown, I'll pin this for clarification

[Roadhog360]

I may be willing to give some workaround that throws a warning in the chat if someone is using BetterFPS with the bad trig injections, if possible. I think it's ideal to warn people since god knows what else this rivens-half functionality breaks

The question is; how to detect it? Perhaps I could "prime" the sin/cos functionalities with an intentionally weird value during startup that looking up with the elytra produces, and if a bad value is found, disable elytra flight and warn user?

[makamys]

From the looks of it you can just check BetterFpsHelper.ALGORITHM_NAME. And it may be worth putting a warning in the elytra tooltip too, chat can be pretty noisy in bigger packs.

[Roadhog360]

From the looks of it you can just check BetterFpsHelper.ALGORITHM_NAME. And it may be worth putting a warning in the elytra tooltip too, chat can be pretty noisy in bigger packs.

What would be a good way to get this through reflection so I don't need to add it as a jar dep? I can check BetterFPS source later, but rn I'm busy so may as well ask here

[makamys]

Class.forName("me.guichaguri.betterfps.BetterFpsHelper").getField("ALGORITHM_NAME").get(null) should work. It looks like it will always load the config at the end of Minecraft#startGame if not earlier, so any time after that method call should be safe.

[Roadhog360]

Ok. When does startGame happen? Is this after postInit?

[Roadhog360]

Upon further testing, rivens is the default, not rivens-half.

[makamys]

Ok. When does startGame happen? Is this after postInit?

The LoadComplete event gets dispatched inside startGame, so even that is too early. You could use the server start event instead.

Upon further testing, rivens is the default, not rivens-half.

Are you sure?

[Roadhog360]

Despite the code there which I saw, I loaded BetterFPS into an instance and it generated with the rivens value by default. I'm not sure what exactly is causing this to be the default, but that's what was there for me.

[Roadhog360]

Blocked elytra functionality when rivens-half or taylors is used in f9f29bb.

[Roadhog360]

Turns out Taylor just has the spinning issue in general, lol, and appears to be far more problematic. I'm gonna post a PSA on Legacy Modding that BetterFPS shouldn't be used at all
In fact, searching taylor on BetterFPS' issue tracker seems to bring up 14 results of people complaining about it. Rivens-half is not mentioned in any issues so I'm assuming its bugginess is more obscure and has a weak spot the elytra happens to hit.