First Post of September! Video! New Builds! Fun!

• 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.
• Wrote a ton of little functions to make the in-game character creator work more smoothly.
• Added a date/time reference to the processed asset handler to pull the install date of all assets so you can sort it that way when making a new character. I'll put that into scenes, too, which gives you the ability to filter it by install date. I'm not going to do that right now though I'm not working on that system. This data is stored as a .NET datetime variable which should be a serializable format(I'll change it to an int array if it bitches at me later about that. JSON might not know how to process a datetime.)
• Wrote the base picker system, which processes loaded character bases and allows you to choose a character base to deploy and customize.
• Wrote the help system for the base picker system, just in case you get stuck. One of the primary feedback letters I get relates to unclear or nonexistant documentation, so this type of thing helps with that.
• Made further improvements to the pointer system. This time it related to the UI system. When you used the menu universe UI, which can sometimes be physically farther away than a normal universe ui, the pointer would still hit the closer entity even though the menu universe should override that. Now the pointer will pass through non menu universe UI entities when the menu is up, and hit those when the menu is not up regardless of distance.
• Created the appropriate events to notify other systems/players when a new character has entered the scene.
• Friend spawning now functions. Friends are invisible, but they function, dammit. Let's fix that.
• Simplified the internal processing of the binding position data to make it sigificantly faster than the original design. Four lines of code to make a huge improvement. I didn't do a comparison on performance but I'm betting this algorithm is around 3000% faster. That sounds like a lot but a 3000% improvement on .04ms... well 3000% sounds better :P String enough of those things together and you get what people call 'Well Optimized' instead of 'Poorly Optimized' so I try to do those whenever I can.
• Added some meta data to the character spawn request system so I don't need to do any searching if there's some other system looking for a specific character to spawn. Now anything that spawns a character is assigned a unique spawnerID so the newly arrived avatar/friend reports its arrival or failure to arrive to the corret requester.
• Added a running tally of spawned characters so I can append that to the name of the spawned character so each spawned instance gets a unique name in the heirarchy. I'm not sure what the use is for this right now but it seems like a good idea.
• Wrote the conditional spawning mechanic that handles positioning avatars, friends, and multiplayer avatars in their own unique ways before they become visible. Conceptually they spawn differently in that avatars spawn on the floor beneath your head, friends spawn where you say they should spawn, and multiplayer characters spawn at the scene entry point. I had to put in contingencies so we can avoid having everyone spawn in at 0,0,0 in a T-pose and then warp to your location like they do in some games. Looking at you, Ubisoft!
• Created a basic version of the material generator. Materials are generated at instantiation so we can use nicer materials for faster computers, or simpler materials for slower ones.
• Wired up the appearance profile system.
• Wrote a centralized communication system in the MCP to handle changing character FSM states. Instead of managing that in separate locations, all requests to change the FSM state of a given character go to the MCP, which then indirectly messages all characters with the instructions on what to do. Any entity that cares about the current FSM state just needs to subscribe to these events and then have local logic on how to process the event. This follows the overall design paradigm for Besti X to have a minimal amount of direct communication between entities.
• Set up the highlighters to communicate with that system to visually indicate to the user whether the new character is currently being displayed as an avatar or a friend.
• Wrote a height analysis system to update the avatar system with the same data that is available from PhysX. This is used to calculate foot placement in situations where foot location data is not provided by a VR SDK. Most people will not have foot tracking and will use this feature, so it needs to work well.
• Wired this system into the character controller.
• Wrote a really neat height calculation system to figure out your height that isn't dependent on your in-game scale. In Besti X you can affect your perceived height relationship with the world, but this affects other areas mathematically. To counter this I just wrote the arithmatic to calculate your height properly regardless of how tall you say you want to be.
• Added a global option to change your units. Imperial or metric. Unity natively uses metric, but Americans that don't have a background in science or in the military don't usually have a good sense of distance in metric. I'm setting the default to imperial just to drive you crazy <3
• Added an entry in the menu system to display this option to you in the settings system.
• Wrote a little program to convert a given numerical distance in meters into a string of that measurement in centimeters.
• Wrote a little program to convert a given numerical distance in meters into a string of that measurement in feet and inches.
• Set up an avatar options page in the avatar menu. This is where you'll go to adjust aspects of how all avatars work on you.
• Added buttons for starting the hand orientation wizard and the height calibration wizard.
• Wrote a trigger that auto-configures menus on its own without being put into the overall menu heirarchy.
• Set up rough versions of all the new interfaces we'll need for setting everything up like hand adjustment, real height settings, and virtual height settings.
• Identified and fixed a practical issue in using vectors to determine head offset. It depends on your character's bone roll direction to be set up properly, whereas we don't really need to require that if we use the relative relationships between the bones. Mechanim is what actually drives around humanoids rather than the bones, so since Mechanim doesn't care if your character is backwards, I can't care, either. Reprogrammed this to use the relative direction so if it looks correct in the SDK, it will behave correctly, too.
• Fixed movement in VR. What I programmed worked perfectly in 2D, but in VR, it caused you to do the liu kang kick when you move at all from the origin position. The way 2D works essentially locks you in place and you only move on two axis. In VR you can do whatever the hell you want and that broke the math.
• Wrote an extremely accurate height measurement system that works way better than Besti 9's.
• Reworked the trigonometry that handles 2D neck bending. This needs some more love in that I need to write a handler that has behavioral thresholds. Mathematically this is a bear because the output of a function is the input for another function, so basically, f(f(x)). I don't know how good you are at math but these are very hard to intuit so I'm going to need to sit here with my calculator and paper on that one, and that'll take hours and since it's like, almost perfect after what I just did (math-wise I essentially kept the same formula was using I just reworked the y intercept), it's fine for now. I'll backburner that improvement because now's not the time to spend the majority of a day on something somewhat insignificant.
• Wrote a new handler for automatically adjusting avatar binding points when yours or your character's scale changes.
• Wrote some additional logic into the character builder that prevents you from asking a friend only character into an avatar.
• Spent 30 hours fighting with mechanim about the hands, and it is actively fighting me every step of the way. Going to need to rethink how finger bending on avatars is going to work.
• Added an additional error check to the BestiSDK to make sure your configuration is correct.
• Added an additional function to the Besti SDK that makes it easier to set up characters as avatars. No more bone drag/drop now it's automatic for most situations when you push the Try to Auto Configure Bones button. It can't set up twist bones on their own because this is a function that Unity doesn't understand, but you can drag/drop them in.
• Finally solved the most complicated mathematical puzzle I've encountered while developing software. Huzzah! Now I need to write code against the way I modeled this.
• Removed the option to make an "Avatar Only" character. There's no situation in which you are putting in the data for an avatar that does not also provide the data needed for a friend character. Friends require virutally nothing. If there's at some point extentions that make this make sense we can put it back in, but for now its just making the logic more complicated.
• Reduced processing required for hand animation data interpretation by 50%. I did this by combining the hand data into a single processing step rather than individual processing steps for each hand. Because we can't update the avatar system on a per-muscle basis due to limitations in Unity, we always need to update everything at the same time. Might as well process everything at the same time, too.
• Put more optimizations in. There's an expensive calculation (interpolating a value between two values) that we used to do if any finger changed. Now we calculate that on a per-finger basis. If it changed, do the calculation. If it didn't change, send the last frame's data.
• Added a neutral value feature so the fingers can extend to their maximum muscle opening level, but don't just default to that if they detect the fingers are not curled at all. Not curled is conceptually different than completely extended, so I set these as different things. We might want to expose this value as a setting instead of having it be hard-coded into the hand system. That feels like something you might want to adjust per-avatar in some cases. We'll see what people want on this one.
• Made some improvements to the ghost hand so they work with the new neutral value setting and will more closely align with the way the avatar hands align (If your avatar has humanoid fingers.)
• Wrote a UI to make it easier to create new hand data animations without needing to directly move muscles around. Now I can do it with the Unity state machine system.
• Changed the update time of when we recheck positions on the VR SDK entities. In VR this was interfering with smoothly moving around.
• Added additional code for the menu universe so that stays synchronized with the real camera. Changing the timing of events was causing the menu universe camera to be out of sync.
• Set up the hand proximity detector to activate your ghost hands if they're out of range of your avatar hands. Because this isn't something we need to do very often, I just have it check the distance every 30 frames.
• Messed with the way the animation of showing/hiding works so it looks nicer when transitioning.
• Added a startup function to calculate the radius/unlna twist behavior if your character is set up with twist bones. If there aren't any twist bones, this is not done.
• Temporarily disabled the internal IBMI search function on Oculus Quest. I have a replacement for this system that is ready to go I just need to implement it.