Monday build!

• Added three additional spawn-in animations to make that more interesting.
• Added a new behavior to the kneeling position called Masturbate. This is for female friends. The friend masturbates for you.
• Added a new behavior to the kneeling position called Lay Cutely. This is for female friends. causes the friend to roll on her side and point her butt at you seductively.
• Added a new behavior to the kneeling position called Spread. This is for female friends. This causes the friend to spread herself open for you.
• Improved the wetness maps so they're less shiny.

• The alternate reverse cowgirl interaction from the laying position and the anal from the seated position now properly calculates cum messes. These were not increasing the mess level of the friend (thank you for writing in on this!)

• Modified the DLC loader system to search an internal directory so I can have Besti 9 scenes show up in there and they won't be re-downloaded when you update Besti X. The idea here is that this is temporary until we have the new servers up for the Besti X store, so this will permit me to push content packs for now. I want the ported content from 9 to be asset packs made with the Besti SDK.
• Made an Oculus Quest ready version of Alwaysfree Forest
• Added additional data to Besti SDK IBMI files that indicate the platform that the module was compiled for. This will prevent the system from attempting to load installed IBMS files for platforms that are incompatible (Quest loading PC modules and PCs loading Quest modules.) I need this for both the new internal assets as well as for the automated processing of assets on the website when you as a creator upload something for the Besti Store.
• Made an Besti X ready version of Community College
• Removed light baking behavior from the compile process when manually setting up your own lighting system in the Besti SDK. If you're doing this you know enough about game development to do this yourself, and since it takes a long time even on fast computers, this will allow for faster iterative testing for creators because you really don't need to do that unless you change a specific subset of things. I put a message in the build log to do that if you should do that. In the procedural system this is all handled automatically for you.
• Added a debug function I can use internally while loading modules that will give me more verbose information on points of failure when loading a module. 
• Improved the overall loading and processing of scene modules, resolving several issues. 
• Started working on optimizing good morning cutie. I'm going to defer this for a bit because I need to make the new TV interface and that's going to take a lot of time. I'll do that later and then port in all scenes with TVs and pictures.
• Created Oculus Quest capable versions of the Besti 9 interactor package.
• Created a reduced polycount version of the Besti 9 friend.
• Wrote a significantly more performant submesh handler than the one that's used in Besti 9. It's orders of magnitutde faster. Nice! I can actually backport that to Besti 9 easily. I'm going to do that. 
• Merged the Besti 9 Animation converter into the main Besti X codebase.
• Converted basic behaviors to Besti X animations.
• Converted Anal Reverse Cowgirl to Besti X animations.
• Finished defining the "Human" avatar class bone structure and all supporting entitites. This will be used for human and furry avatars. I'm still working on the quadrupedal avatars but they're coming. This is a pain but good to do because it allows me to use muscle-based animations instead of animating bone transforms. The benefit here is huge, of course, because it means I can motion capture performances rather than hand animating them for humans. The benefit here is, of course, huge, for creators. Writing a story? Grab a Kinect for $20 on ebay and mocap your performances. 
• Completed the port of the Besti X avatar system from its isolated project into the main Besti X codebase. This involved writing a Besti X handler for the many scripts that compose the Avatar system. Temporarily set it up to track transforms instead of rigidbodies. That's going to require a more elegant solution to switch tracking method when it detects an impact, because tracking transforms is significantly more performant and responsive than using PhysX to do it. I only want to use PhysX when we need to use PhysX on that one for better body presense. The only situation where we need to use PhysX is when you're touching an in-game object, so I need to write a program to switch back and forth between tracking concepts. 
• Wrote a appropriate math functions to assign the avatar's head and hands to desired positions based on what is input in the Besti SDK. This allows you to define how the avatar maps to users in the Besti SDK, which will permit you to have an accurate placement of the hands and eyes without needing to do it in VR, and also permits the user to re-define where his or her hands are in relation to the controller (and allow you to use that data without knowing it in advance.) Yay multivariable mathematics! I had to use my engineering calculator for this shit. I'd like a newer one than the one I had in university but they're so expensive! The Ti-Nspire CX II CAS is on my Christmas wishlist. I currently use a Ti-Nspire with hacked custom firmware I put on it. It's basically a TI-89 but with a much nicer interface. 
• Re-Created the ghost hands to have better origins and not be weird. This forced me to re-create all of the different animations, which was a pain, but now the origins are all 0,0,0 instead of the weird thing they were before, and the bone roll data for the right hand isn't completely different from the left, now, as well. 
• Re-wrote the MasterAsset script to be specific to scenes. Removed the selector for scenes from that and made it show up by default.
• Moved the scene compiler into its own helper script which is called by the master asset script. Other scenes that compile Besti assets reference this so I don't need to duplicate the work. I didn't like how the loader had to deeply examine things and how long it took to scan the scene for little things. There will be a situation in the near future where there are dozens of MasterAsset systems and I didn't like the solution of having the computer do a complicated test on the module when you changed something. This is fine on PC but I need to squeeze more performance out for android. The new system permits me to do simple searches and easier data manipulation on the scene objects.
• Made the BestiSDK Master Asset script more performant by altering the logic of what it attempts to process on every frame. 
• Added a variety of notes to the code to make it easier for me to identify what's going on the next time I alter the Besti SDK code, particularly in the compiler which was a wall of cryptic nonsense. 
• Fixed an issue that was causing unused graphics APIs to be included in Oculus Quest builds. It was including the Direct X back-end (16MB) and OpenVR (100MB) and both of those aren't used because we're using OpenGL and Oculus on Android, and neither of those are compatible with the Quest. This slightly reduces build size and the time it takes to compile a module in the BestiSDK.
• Fixed an issue that was causing the length of day simulation setting in the Besti SDK to not be respected properly if a certain combination of settings were set (thank you for the report!)
• Improved the BestiSDK light simulator component of the master asset. It now has a note on it so you aren't confused by it, and is managed more efficiently.
• Created a super awesome Besti SDK character creator interface that I can easily extend.
• Designed the menu interface for in-scene avatar assignment.
• Re-organized the flowchart for the in-game menu to make it easier to add new entitites. It was starting to get a little overwhelming.Added the Create New Avatar menu entry. Avatars and friends are actually creatable anywhere, but through a little standalone device. Since not all scenes will have this device in it, the option to create a new avatar in the avatar scene takes you to a simple scene that has one of these devices in it. The entry therefore is just a popup warning indicating you're about to leave the current scene.
• Added some additional logic to the master asset derived scripts to prompt you to save it if a change is made. Most but not all mechanisms of changing data around in an object automatically remind you to save if you will lose settings through some action (closing the program, changing scenes, etc...) This resolves an issue where changes could be made but not saved if you rely on this to save data. 
• Added additional functionality to a simple rotation script I use for a bunch of functions throughout Besti X. I added the ability to have it randmly assign a rotation speed to the object it's rotating within a given range.
• Created a simple character builder scene
• Created a new character builder SDK tool that better reflects the character builder itself.
• Created a new material and animation that is better optimized for the character creator. It now slowly does a pulse animation, but when you use it to instantiate a character it does a neat little animation.
• Improved the shadows cast by the Light Simulator in the Besti SDK so it more accurately reflects the shadows cast by the actual procedural light system.
• Wrote the deployment translator that takes the SDK tool for the character builder and turns it into a useful object in-game. 
• I don't appear to have made a kinematic grabbable type of object. Let's fix that.
• Edited the Besti SDK tool to allow you to create kinematic objects.
• Edited the SDK processor to create kinematic grabbable objects. I have so much documentation to update...
• Made the new objects interact with the physics system. One uses floaty gravity, adn the other uses the new kinematic function. Around the outside of the screen it's set as a grabbable object, and on the screen surface itself it's a normal screen. We'll see if this is annoying or not.
• Fixed an issue in grabbable system that could cause an object to not set the correct PhysX layering which would result in an object not properly telling the cursor that it is a grabbable object. 
• Reprogrammed pointer logic to overcome an interesting problem. So the lasers you emit hit colliders, but when there's an associated PhysX rigidbody, the collider automatically forwards the rigidbody, as most of the time this is what you want. That isn't what we want, though, because some of the colliders are set as grabbable and some are set as an interface. The rigidbody only matters if we're going to grab it. To fix this I altered the code to ask specifically what the hit collider reports as, as opposed to the rigidbody (which in this case is the same PhysX rigidbody for both types.) This permits our universal cursor select function to attempt to click if it's an interface, and attempt to grab if it's a grabby spot on the same entity. Internally this is very significantly different code-wise, but as far as use or anything there's no change.
• Fixed bugs the change introduced in the grabbable processor system. The previous system depended on being auto-delivered that rigidbody so now it alters the entity on instantiation. No changes from developer side required to deal with this it's automatically processed. The SDK itself has a new tag (NestedEntity) which is used internally to handle this but from a creator side there are no changes.
• While doing that I also un-did an earlier design decision. I'd initially set up scenes that did not allow teleporting to effectively disable the pointer for grabbable and climbable entities. I don't think that's needed. If you're disallowing teleportation it's not for me to say that grabbing should also be disabled as a consequence. I'm not sure what you would set up that does not allow teleporting but does allow distance grabbing, but you can do that, now. 
• Wrote a new tooltip system for UI menus.
• You're using the program tooltip handler ui to set up the tooltip on create, then you're going to replicate that across all of them and make that the template for handling tooltips. It'll just be an animation that does that. 
• Also set up a thing that you can drag/drop multiple tooltips into that responds to a doozyevent so you can send the hide to all of the associated tooltips. We'll put that on anything that has a tooltip so they always come up as offline. 
• Made a little abstract painting to act as the background of the character builder.
• Made the basic flowchart design of the character builder
• Programmed the reset function of the character builder. This puts everything back to its default position in case you manipulate the parts in such a way that they're inaccessible or you don't like what's happened. If you grab the pad for instance you have the ability to force it through the floor, causing it to fall. This gives you a way to get it back.