New builds! Fun!

• Created an easier to use test environment for myself to rapidly test new things that are part of the VR environments. The older one was written before the various TSRs were written to extend the MCP, and a variety of systems rely upon this. The new one starts these TSRs. It's all automated too so all I need to do to test anything in particular is to set a dropdown.
• Working on the 'Fast Menu' system. This is a fast way to make in-game selections without having a shit ton of buttons mapped. It also drives the interaction and conversation systems.
• Added additional input: fastmenu_c. This is a fastmenu option to make a mouse-driven menu appear in VR or 2D depending on your current system.
• Wrote required code to add that input to the control remapper system.
• Wrote required code to generate the fastmenu_c event
• Wrote a handler to interpret and care about that event
• Wrote a test for the handler. 
• Ran test: Works! Nice!
• Wrote the center position identification and scale matcher code (requires the scale matcher because you'll be able to modify your own size shortly)
• Wrote a test for the position identification and scale matcher.
• Ran test: Works, but I hate it. Let's write that... completely differently. Let's instead use positional mathematics and also use the follower at the same time. Doing it this way will make it work better in controllerless VR mode.
• Wrote an extension to the follower to make it take fewer resources for this specific use case. CPU intensive anything is bad for Quest.
• Wrote an extension to the follower to make it take fewer resources for the smoothed pointer use case. Same rationale. The derived version takes about 10% fewer resources. This is realistically a pretty small amount, but good performance is a collection of small decisions. 
• Replaced the smoothed pointer handlers. Let's assume this works and fix it later if it's broken. I'm not particularly worried about it.
• Wrote a test for the rewritten center position identification and scale matcher.
• Modified the MCP so I don't need to bind Fastmenu every time I start in Debug mode. Let's see if I remeember to unbind this later because it's an undesirable default (keypad period.) 
• Ran Test: Muuuuuuuuuuuuuch better.
• Added additional functionality to the event. In 2D the fast menu disables rotation, because the mouse handles that. We can't have you rotating and interacting with the fast menu at the same time because that's very confusing.
• Damn the proper way to do this is to have PlayerControl handle that instead of a standalone entity. Let's fix that. Added an enable/disable function for that into PlayerControl. This is a 'right' way vs. the 'easy' way situation and why Besti X is taking forever, but it will also keep it from turning into pasta like Besti 9 did. Additional information if you're reading these: So PlayerControl is a primary control system. It doesn't do a lot on its own, but it manages a variety of submodules and interfaces that are indirectly connected to it. When I want a program to interact with the player in any way, the correct way is to make a direct request of PlayerControl, which then connects to an interface to handle that request. The way it manages this is via scripted boolean values that are rigged up to emit an event when the value is changed. That way, things that care about what playercontrol's settings will listen for these events and react accordingly to what the boolean value is on Playercontrol without needing to check it nor be notified when it is changed, because the event on change that is emitted notifies these entities that the value has been changed and then, and only then, does it check what it's supposed to do. This design pattern is one of many reasons why Besti X takes so much less CPU effort than Besti 9.
• I'm going to need one of these for the laser pointers, too. Let's make that, and make it hand specific.
• Lord that took forever. Pointers had wires going all over the place and required a very complicated chain of events. Now PlayerControl can manage them with simplified interfaces and I don't need to address the specific entities involved.
• Ran test: Needs a couple more things. Small race condition between the follower and the manual positioning behavior. 
• Wrote that fix.
• Ran test: There we go. Now all that's sorted. Let's move on. Let's set an objective of getting useful position data. I have some ideas that seem like they would feel good. Let's make it and see if it does.
• Created prototype interface to check the feel of this concept. I've never used one like it so it's either going to be good or bad.
• 40 minutes later: Let's try the prototype
• OK the prototype's awesome. This will work perfectly for the various permutations of the fast menu. Hyper low overhead, too, and ideal for Oculus Quest use as well as the higher-end VR solutions and 2D. Let's call it... the Communications Field Reactor. CFR.
• The first step is to automate the organization of it. Let's worth out the arithmetic of that. Fortunately, it's basic trigonometry. 
• Second let's work out how entitites participate in a comm field. OK I have this now.
• Third let's start coding:
• Created a new assistive class in the Besti SDK called CFREntity. This is a class to hold data about a given CFR menu option. It's in the Besti SDK so you can define your own comm fields in the Besti SDK. A friend asking a question, a light switch you can turn on or off, etc... Possibilities are infinite because this will allow you to get unique inputs from users for your use case.
• Let's make a static instance of the handler so it doesn't need to be searched for by everything that can talk to the CFR.
• Let's set up the subscription system so entities can add their own selections to the menu only when needed. 
• Let's set up the generic string event so that SDK derived entities can react to user input.
• Modified PlayerControl to have a good referential transform for where the non-handed center menu should appear. 
• Wrote a world-space to local-space converter for PlayerControl so I can do rapid mathematics relative to the player's head position and orientation
• Wired the handed fast menu systems into the control remapper output.
• Wrote the unexpectedly completed mathematics to handle placement. I find that when I play VR games I tend to have my hands pidgeoned in a little bit, so using the rotation data from your hand is not useful and causes the menu to spawn in sideways, prompting me to redeploy the menu after reorienting my hand. I'd rather it deployed as expected, and also remove the need for your hand to be in any specific rotation to use the menu in VR. This is also an accessibility concern for users who do not have command over the angle of their hands. The solution in this case was to calculate a directional vector to the player's hands (or central position) and then add that vector (multiplied against the desired distance scalar) to the position of the player's head. What this does is conjure up a menu in the direction of the player's hand relative to the player's head at a fixed distance.
• Broke out the scan analysis code into its own method so I don't need to understand how it works the next time I look at it. I find that updating anything mathematically complex is a very slow process, so breaking out the math into its own thing allows me to have an easier time looking at the overall logic of the program. Besti X's design standard is to move complex maths into their own methods and then write notes about what the math does. By following this design behavior I can update Besti X faster in the future. 
• Tested that. Looks/feels great. 
• Added your local communication field and hooked it into Player Control. Your local communication field lets you do some self-generated things like bringing up the menu or setting a VR controller job.
• Added additional functionality to the automatically managing text fields to be able to automatically address non GUI text fields.
• Created an appropriate BestiSDK tool so this can be used in the Besti SDK to script things.
• Created an appropriate BestiSDK processor for the new tool.
• Created an example in the Besti SDK on how to use the tool.
• Streamlined the mathematics of positioning/rotating.
• VR looks and feels great. Now for 2D mode.
• Reactivated the systems I disabled earlier that related to 2D mode. 
• Created a new project to write a new mouse mover system for this. I've never quite had a situation like this so I'm going to have to invent a solution. I have a pretty good idea what to do with the math.
• Wrote a test for the math. Looks and feels great. Outstanding.
• Created the graphics for the 2D interface.
• Implemented systems
• Ran test
• Altered the mathematics a bit to set correct points for my guesses on what the variable values should be. 
• Altered the way the system placed the sensor origin to fix a behavior revealed during testing that could prevent the user from making no selection on the menu. I need to account for the relative movement that the center menu has that the VR mode does not.
• Actually... I should use that same relative movement code in VR, too. Damn. Let's write that in it's a good idea.
• Test 2D works good. Let's port that to VR.
• Made some polymorphic adjustments to the code. I had too many unitaskers in the menu manager that was making the code feel confusing. I'll test that in a minute. Shame it's a fucking mess even when I make it more polymorphic. Too many switches to operate that need to be different for all kinds of situations. Oh well.
• Let's add 2D mode to the animation data.
• Test 2D again: Nope I fucked something up severely. Let's figure that out.
• Fixed. Test 2D again: 
• Mmmmmmm. Not quite. Let's alter the schedule of where that line of code executes. It's moving it before I move in 2D mode resulting in a jittery behavior. I want it to move after I move.
• Test 2D again: Nice! 
• Test VR with mouse: Works but I"m not satisfied with it. Let's manipulate that a little. 
• Test VR with mouse: Muuuuch better. 
• Test VR with remotes: Also works. Lovely!
• I need an event reactor and and on-enable checker to see what the active universe is, and I need that device to switch whatever renderer it's associated with to the correct universe. Let's program that.
• Welp looks like I need a bunch of prerequisites. Fuck it let's make MenuControl static so I don't need to worry about wiring this/what's connected to what. The way I was programming this was screaming "I'm going to become a race condition that's going to cost you a day of work." I don't need that static reference for what I'm doing right now, but let's do it anyway so I don't need to sit here thinking of how to wire something in for 45 minutes again and that is just an available option. 
• Programmed in a boolean value into Player Control that anyone can request a value from to get a quick true/false report of whether or not the menu universe is active
• Let's have MenuControl forward its management events to Player Control so I don't need to remember that the progenitor of the menu activation event happens in MenuControl. Stick with the pattern and send references to PlayerControl. 
• Finished the universe switcher. Applied to fast menu.
• Testing that: Not working. Why's that?
• FFS I forgot to type an 's'... getcomponentS not getcomponent. There's 20 minutes I don't get back.
• Audio now. Audio editing.
• Coded in audio events. Sounding good.
• Let's manipulate the particle effects a little bit on Potato mode.
• Let's add the main menu entry to the fast menu.
• Doing final build checks. We need an AOT shader for the fast menu. Writing.
• Test: Looks good and saves draw calls. Let's make a couple more adjustments.
• Return all settings that were messed with to normal settings.