Adds user configurable arc scale (proportion of fov) to replace actual scale for UI, crosshair, and menu#114
Draft
slipperfish wants to merge 1 commit intoLivingFray:masterfrom
Draft
Adds user configurable arc scale (proportion of fov) to replace actual scale for UI, crosshair, and menu#114slipperfish wants to merge 1 commit intoLivingFray:masterfrom
slipperfish wants to merge 1 commit intoLivingFray:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First time pushing from visual studio, I just clicked things until it worked, I hope everything went ok
This PR has users configure the desired UI, crosshair, and menu sizes in degrees as a proportion of FOV rather than adjusting the actual sizes of the UI elements. This means if the user just wants to change the distance on any of these, they don't have to adjust the size afterwards to compensate, which requires trig to do accurately as far as I can tell.
In my testing the only thing that might not work as expected is 100 degrees was outside my quest 2's fov more than my expectation, this is with the face gasket off. But that's a complicated topic so I have no real reason to suspect something is amiss there.
What I don't like about this PR is I couldn't figure out how to not require a restart for these changes like the distance settings currently work, which would cut down the user time waste on trial and error. Even if I made this a function and ran this somewhere such as after a VR settings menu config change, it would just update uiOverlayScale, crosshairScale, and menuOverlayScale and they wouldn't be put into use until after the game is restarted right?
I also had a question about defaults because I'm making new config variables. If we decided on different defaults in the future, do users still have to delete their config.txt to activate the new defaults? Say they generated a config file for c_UIOverlayArcScale=45.0 in the next release, then for a release after that we decide 55 is better. How do we tell the difference between a user preference and old defaults?
Thanks