Improvements to boat eye and related features

[ExeRSolver]

Main changes:

1. Added the option to default to green boat (with a boat angle of 0).
2. Altered the behavior of the "Indicate boat angle reset on next F3+C" hotkey to clear the boat angle.
3. Support maintaining green boat through a mod 360 operation (for example: travelling through nether portals or using ender pearls). This is done by using a hotkey to indicate that the next F3+C contains the player's angle immediately before being reduced modulo 360, so that the boat angle can be adjusted to account for it. Also added an icon to indicate when the hotkey is pressed.
4. Allow getting boat angle in the nether.
5. Split tall res and boat eye settings into separate tabs. Boat eye can now be used without tall res.
6. Added the option of using a custom pixel adjustment amount.
7. Added support for boat eye with manual eye throws (defaulting to green boat is required for this).
8. If the player includes decimals for the coordinates of a manual eye throw, then 0.5 will no longer be added.
9. Applied the correction for yaw-based angle error to manual eye throws.

Some information justifying the changes: For some sensitivities, the boat angle is still valid if the player's angle gets reduced mod 360. Also for these sensitivities, if the boat angle is 0, then the player can get a valid angle by entering a boat (without needing to update the boat angle with F3+C). The option of defaulting to green boat makes it more convenient to use these sensitivities. A slight catch with this option is that there's currently no good way of removing a boat angle, which is why I've adjusted the behavior of the "Indicate boat angle reset on next F3+C" hotkey. I don't believe the behavior being removed with this change had any use. Since there are very few of these sensitivities, I've added features (3) and (4) to allow for similar gameplay with other sensitivities. These sensitivities make boat eye easier, which strengthens the case it's use among players that don't want to/can't use a zoom macro. This is the reason for (5). For players that can't use a good zoom macro (macOS for example) and aren't on 1080p, the option of custom pixel adjustment amounts makes it easier to use subpixel-based measurement methods where the ideal pixel adjustment amount is not 0.01. Most boat eye tech would work fine in 1.9-1.12, at least for some sensitivities. This means that the current position imprecision with 1.9-1.12 measurements is a significant source of error, which is why I've added (8). I added (9) since the yaw-based angle error exists at least as far back as 1.9.

[tildejustin]

closes #74

[Ninjabrain1]

Just in general, how much have you tested these changes? There are quite a lot of behavioural changes relating to boat throws and I want to make sure everything works as it should with all possible combinations of settings (boat on/off, tall res on/off).

[Ninjabrain1]

Also, why is (6) useful?

[ExeRSolver]

Just in general, how much have you tested these changes? There are quite a lot of behavioural changes relating to boat throws and I want to make sure everything works as it should with all possible combinations of settings (boat on/off, tall res on/off).

I've tested pretty much all combinations of new/affected settings at least a bit, confirming for each that predictions, certainty, errors, etc are as expected. I've done more extensive playtesting on my usual settings.

Also, why is (6) useful?

The pixel adjustment amount for subpixel on non-1080p monitors typically isn't close to 0.01. Since Apple laptops & monitors are rarely 1080p and we don't have good resize macros for macOS, this issue is particularly prevalent for macOS players. This option also adds support for alternate subpixel variants for users with good monitor sizes and resizing capabilities. For instance there's a nice 5-pixel method on 1080p that allows for improved accuracy with little additional effort compared to the standard 3-pixel method. With more effort, using all 13 pixels allows for accuracy similar to 16384 zoom while using relatively small window sizes. I should note that it's usually possible to get a similar effect without custom pixel adjustment amounts by enabling tall res and inputting a resolution height that results in the desired adjustment amount. However, the hackyness of this method makes it undesirable, and this introduces an additional source of error (albeit a small one) since the vertical angle impacts the adjustment amount in ways that it shouldn't for subpixel. Also, the 16384 limit in the resolution height preference results in a minimum adjustment amount around 0.0022, which is insufficient for some of the above use cases. Zooming above 16384 is against the src rules, so an increase to the resolution height preference limit would only serve to benefit this hacky method.

[Ninjabrain1]

For (3), why is it necessary to press a hotkey before reducing mod 360? Why can it not just reduce it mod 360 every time automatically?

[Ninjabrain1]

I need to look at how the changed options tabs look and test the changes a bit myself, but other than that I am done with my review for the moment

[ExeRSolver]

For (3), why is it necessary to press a hotkey before reducing mod 360? Why can it not just reduce it mod 360 every time automatically?

The calculator needs to know the amount your angle is being changed by. Say your minimum angle increment is 0.011, your boat angle is 0, you go through a nether portal at some point before measuring, and your angle when you measure (to 2 decimals) is 3.00. If your angle was between -360 and 360 when you went through the portal, then going through the portal didn't change your angle, so the actual angle when you measured was 0.011*273=3.003. If your angle was between 360 and 720 when you went through the portal, then going through the portal changed your angle by -360, so the actual angle when you measured was -360+0.011*33000=3. If your angle was between 720 and 1080 when you went through the portal, then going through the portal changed your angle by -720, so the actual angle when you measured was -720+0.011*65727=2.997.

The simplest way I see of dealing with this is to read an f3+c immediately before the mod 360 operation. The hotkey is used to specify when an f3+c is being used to indicate a reduction mod 360. If an f3+c were falsely assumed to immediately precede a reduction mod 360, then the computed angle would be wrong.

[Ninjabrain1]

I made the conditional angle adjustment settings visible/invisible instead of enabled/disabled, seemed clearer to me. Other than that it looks good.

I think the boat measurement section is very complicated and the addition of this mod360 makes it more confusing, but it will only be used by advanced users so I think it is acceptable.