If the client changes the FOV to anything other than the minimum and the server sets the walk speed (with Packet202Abilities, bukkit uses this for example) to anything higher than normal the FOV totally messes up, starting with the image being upside-down and ending with a totally weird tunnel view.
As a side note I think the FOV setted by Packet202Abilities is to high anyway: You feel way faster then you actually are.
Comments 7
The bug is probably that the FOV isn't being verified against the maximum FOV, and is being applied to the game without checking if the value is valid. Then again, this isn't exactly vanilla behavior (bukkit is not treated as vanilla, as it modifies the server) but the client should be able to handle these kinds of things.
Yes, I also think this is the cause.
The problem with this is that Packet202Abilities is able to do it, no matter if vanilla uses it for that or not. Mojang coded this for a reason. Also as it's a client bug you can't tell it's bukkits fault.
It is both Mojang's and Bukkit's fault, as neither included any checks against the maximum FOV, which can be done on both the client and server.
Are you sure the server is able to see the clients FOV settings? I never saw any code nor any packet for that.
//EDIT: Also the packet sets the walk speed, not the FOV. The client maps speed to FOV. Do you really think it would be an option to reduce walk speed just to fix the FOV? What if the client has max. FOV? Then the packet couldn't modify the speed at all.
This is an issue with Bukkit. You are not able to do this without either modifying the vanilla client (NBT Edit included) or sending modified packets (Bukkit).
Actually I have to correct this, it only happens if the FOV setted in the client + the FOV from the packet is higher then the maximum FOV. Sorry for not being clear in the report.