ComradeOohAah
patreon
FBW devlog - Intiface Central Progress!
🕑 Added 2025-07-25 15:01:40 +0000 UTCYou do not even know the absolute hassle it took to get this screenshot on my Quest 2. What you're looking at is my Quest 2 connected to Intiface Central (via the official Buttplug.io C# client) which is running on my dev laptop which has The Handy connected via bluetooth and and an emulated Lovense Hush which is actually BuzzyBody running on my android phone.
Now, you might be thinking, "Comrade OohAah don't you already have BuzzyBody Android connecting to Intiface Central (via the official Buttplug.io C# client)? And since the Meta Quest runs android, shouldn't that be a pretty trivial thing for you to reuse your code? Wasn't that the whole point of working on that for the past few months?"
First of all, that's amazing that you would know that, I'm very impressed. And second, YES YOU WOULD THINK THAT, RIGHT?
But, it didn't work.
Instead, I've spent the last week and a half trying to figure out why the Buttplug C# client was failing silently on the Meta Quest. Intiface Central showed it connecting! But my code showed nothing on the Quest. Worked just fine on the PC Editor. So, I installed multiple versions of Unity, I copied my project repeatedly to try different settings, I copied random meta quest unity templates to finally find one that worked and then spent more hours figuring out what was the different setting in my project that was killing it. And I finally got it working last night.
When unity builds for Meta Quest, it optimizes the code by deleting code it thinks it is unused. This is called stripping. Unity strips for a living, yes. Remember: Sex Work is Real Work.
Not only does this setting have to be set to minimal, but there is a file you have to create in Unity (link.xml) that specifically tells Unity not to strip certain code and you have to specify the Buttplug Client and it's dependencies. Totally effortless and organic, right?
lol, what a pain. I'll write this up later to put on the Buttplug's C# Client github, but I just wanted to vent.
Now that I've got FBW connecting to Intiface Central I need to rework The Handy sandbox UI to be something I can swap between stroking based toys. That shouldn't be too hard. Fingers crossed. As long as I don't have anymore issues I'll hopefully still get the next FBW release out mid-august.
I'm not entirely sure how I'm going to handle vibrating toys just yet. Gonna have to think and experiment on that for a bit. Think that might need a separate post later.
Thanks for reading, and again thanks for your support! I can only imagine how long that would've taken me if I couldn't have afforded to lock in for hours at a time. Just copying a project and setting it up for a new Unity version ran almost an hour on my dinky laptop. lol, exhausting.
In solidarity,
Comrade Ooh Aah
Comments
ComradeOohAah
Thanks! Yea, I've got the filtering down. I can't imagine FBW will ever support more than linear and vibrate, but I don't know if I'll get vibrate out the door with this next update. We'll see. At the moment, I'm thinking I can clone the config UI and create options for a couple of waveform functions (sine, square, saw-tooth, steady +X.) Then the speed will just determine the length of the waveform... I'd really like to get to the point where the pump (sounds/animation) and toys are in sync, which is easier with Intiface Central (and a waveform) than The Handy API wrapper I'm using at the moment. I wrote that thing almost 3 years ago now and it needs updating. Plus, eventually I'd like to support multiple toys at once all in sync, but that's all scope creep again. One thing at a time for now. Focus: linear then vibrate! lol
none public
Well done! As for the vibration control.. Buttplug can tell you what the device is capable of, so you can just filter out / disable non-supported devices based on that for the time being. Or you can do something similar, that a scripting software does, and calculate how fast a certain move is (u/s), and convert that to the vibrator's 0-100 scale and use that for vibrating toys.. Or you can duplicate the config for vibrating toys as well. The left side is the same, you just do not have to set speed on the right side, and on the left it sets min-max intensity.. (0-50 Stroking, 50-80 edging, 80-90 release, since the 90+ is too high for the user...) Also, you can show the config based on connected device capabilities.. If there is linear, so linear config, if there is vibrating show that, rotating.. and whatnot. And then the control becomes a bit easier, I guess. You know your code, so I can not help you make this decision for you. But given the setup around you during the game, I think it is a valid decision, if only linear toys are supported for the time being.
