Conflict with Wizardry & LibrarianLib
SaadArdati opened this issue ยท 3 comments
- Minecraft Version: 1.12.2
- BetterFps Version: Latest
- Other Mods (if any): LibrarianLib/Wizardry
Hello, I'm one of the devs from TeamWizardry, we've found that multiple people have had issues in our GUIs and it was just confirmed to be BetterFPS causing it today.
LibrarianLib has a GUI system that wraps around vanilla's and Wizardry uses it.
LibLib utilizes mouse input from GuiScreen here: https://github.com/TeamWizardry/LibrarianLib/blob/1.12/src/main/java/com/teamwizardry/librarianlib/features/gui/GuiBase.kt#L115-L177
to trigger gui component events.
What happens when betterfps is installed is when a spell component in the magician's worktable gui is clicked, it's supposed to open a modifier list, but the click doesn't register properly. It requires actually spam clicking for a random chance to get it to click properly... And I mean RANDOM.
https://gfycat.com/SlimColorfulAllosaurus
So BetterFPS is interfering with this somehow. What are you doing to interfere with vanilla's mouse input system?
Another issue is that it seems like betterFPS is interfering with the hand and gui model transforms somehow. The magician's worktable (coincidentally) is the only block that is affected. I would like to note that this is a multiblock table. It has 2 connecting blocks when placed.
https://i.imgur.com/DGARjQo.png
The middle one. It's supposed to show the whole table.
And this is what it looks like in my hand:
https://i.imgur.com/reldeSJ.png
We're not doing anything special with the rendering. It's pure vanilla blockstate and model handling and transforming.
These are the model files:
left side model:
https://github.com/TeamWizardry/Wizardry/blob/master/src/main/resources/assets/wizardry/models/block/research_table_left.json
right side model:
https://github.com/TeamWizardry/Wizardry/blob/master/src/main/resources/assets/wizardry/models/block/research_table_right.json
Actually fixed in TeamWizardry/LibrarianLib@1b2f1fe9
For future reference, it was caused by most of these fancy algorithms not respecting sin(x) == -sin(-x)
for most values.
In our case, it only happened with Riven Half because it doesn't respect it with an angle of 0 either (which Riven Full and the others do) -- giving sin(0) != -sin(-0)
(which should result exactly 0 in both cases but whatever, imprecision et al).
After further investigation, the gui issue is tied to Riven Half, other algorithms don't break it.
I haven't been able to figure out why yet, especially as Riven Half passes my unit tests (I made them cover a thousand possible values instead of the single one tested in the default tests, I can PR the change in unit tests if you want), as opposed to Taylor (which fails on quite a few values, especially on the cosine side).