OSR2/SR6 to Intiface Central connection unofficial rough guide

howto
,
1

Alright so for those whom are using version 2.6.0 (and newer) the method has been simplified…kinda…as no long do you need to go into the config files to do it. However it still only does single axis control so multi-axis does not yet work as of this version.
Anyway now to setup you just need to go to Device manager, find your COM port and then take the details shown in the port settings tab and copy and paste them over…EXCEPT FOR BauD as for that you want to use 115200 unless your device is changed in some way that results in a different bandwidth. Here’s an image to help:

Screenshot 2024-06-09 001337
Screenshot 2024-06-09 0013371282×737 35.9 KB

For users of 2.5.7 and older

WARNING DO NOT UPDATE TO 2.6.0 and beyond as it changes enough so this doesn’t work anymore.

Firstly I am reposting this as there isn’t an guide/confirmed method for this. The original post is on the Buttplug.io and Intiface® Support forums where Crispy found a way so that my SR6 (I don’t have an OSR2 to test on but I presume it should work) could be controlled via Intiface Central and also move as a result of a program using it ( I tested on Seal of Lutellaria - device integration to near perfect results after an adjustment) although simply turning on oscilaions allowed manual control of the device possible. That said…it only resulted in single axis movement (up and down strokes) so don’t expect multi axis stuff to work as this is a work around since OSR2/SR6 support isn’t in place yet but still in the works according to qdot.

Anyway now how to go about doing this, you’ll only need a program that can edit .json files like notepad++. (which is what I used) Since you just need to edit one file which is the buttplug-device-config.json. Now I’ll list quickly the steps for those who don’t want the fluff explanation and then have the explanation steps to follow.

Quick step list
  1. Find the file at C:\Users\$$$$\AppData\Roaming\com.nonpolynomial\intiface_central\config\buttplug-device-config.json and open it
  2. Use find function to find tcode-v03
  3. Change port’s default text to be whatever name is assigned to the port that your device connects through which should be something like COM random number. (find yours via multifunplayer)
  4. Do a test via Intiface Central to see if it moves device
  5. See if Intiface Central passes on information via seeing if TCode v0.3 (Single Linear Axis) appears on Seteria Player’s connected devices list
Fluff filled explanation

An quick way to get to it is to copy and paste the following (change the $$$$ to whatever your user account’s name is) C:\Users\$$$$\AppData\Roaming\com.nonpolynomial\intiface_central\config\buttplug-device-config.json into the open file function of the program or just remove file name from that and go into your file explorer to find the file.

Next you want to use the find function (CTRL+F) to search the file for tcode-v03, the first result should be what your looking for as you want to see the following text:

"tcode-v03": {
      "serial": [
        {
          "port": "default",
          "baud-rate": 115200,
          "data-bits": 8,
          "parity": "N",
          "stop-bits": 1
        }
      ],

What you want to do now is change default text to be whatever name is assigned to the port that your device connects through which should be something like COM (then some random number) you can find this out via multifunplayer since it clearly displays it jut below the connect button.

All you need to do from there is just save the change and then run Intiface Central, start server, start scaning and it should connect to your device for you to then give it a test via toggling the oscillations on it. (one bar changes stroke limits while the other is the speed)

To make sure that Intiface Central is passing it all on you should see in the Seteria Player’s connected devices list something like TCode v0.3 (Single Linear Axis) appear. Below is an image showing the player with nothing in the connected devices.
image

Hope this helps as I had been scratching my head about this for a while and found this method that once again Crispy posted which I tested on Intiface Central’s version 2.5.6. Let me know if anything doesn’t make any sense with alteration suggestions and I’ll make changes to improve this.

Note: qdot posted here about the upcoming OSR2/SR6 support for the program status somewhat.

  • Worked for me
  • Didn’t work
0 voters
14 Likes
2

There are some games that uses built-in Intiface CLI for device synchronization, such as SuccubusReborn.

For these games to work with the OSR2/SR6, first configure intiface to look for your device following the steps in the OP. Then, look into the game’s folder for “IntifaceCLI.bat”. Open as text file and you should see something like:

intiface-engine.exe --websocket-port %1 --use-bluetooth-le

Append the following startup parameters:

--device-config-file C:\Users\[Your User ID]\AppData\Roaming\com.nonpolynomial\intiface_central\config\buttplug-device-config.json --use-serial

Save and reboot the game. The game’s built-in Intiface engine will now use the configuration you’ve set, and should find your OSR when searching for “Bluetooth” devices.

I learnt this from @hue04476.test1, wanted to share it here as well.

6 Likes
3

Note that as of v2.6.0 you should be able to add serial toys directly in intiface’s user intiface. Look under Devices → Serial Devices.

4

Ah yep…and it seems like it has broken the guide according to this post:

Sadly there change log has no suggestions of what information you need to provide, however just saying the COM port doesn’t work when I tried so I think it needs that and BauD whatever that means. I’m not the only one left a bit confused it seems though as someone asked for tutorial and this was the reply:

I tried going to device manager and finding the COM4 port connection and looked at the settings and copy and pasted them in basically which well…it said it found it but no movement occurred on my SR6.

Screenshot 2024-06-09 001337
Screenshot 2024-06-09 0013371283×737 36.1 KB

EDIT: Seems like this is now the actively read from config file: buttplug-user-device-config-v3.json
WHICH after checking the previous config json files I realized my mistake…as the BauD rate by default in those was 115200 and I had set it to be 9600. So quickly changed it to that and I got movement, still single axis though.

4 Likes
5

I added this command in Succubus Reborn but it doesn’t work. After searching for Bluetooth, it shows “not connected”. My Intiface Central is v2.6.0.

6

it’s really sad that buttplug io is not more custom friendly.
even after all this time i have had the osr it still not up to snuff.

i got a nipple clamper, buttplug with inflation, valve and vibrator and a 8 position 2 channel estim that could be so awesome to use in games, if it where only possible to integrate. i just made them now portable to be used in vr and working on the miniaturisation of the toys.

not even speaking of my ideas for the female side of pleasure, vacuum suction of the Clit, vibrator channels to simulate oral sex better, penetration via a diy dildo machine…

the lack of endeavour in the buttplug project however prevents this from actually making sense/happening to try to integrate. it would be so huge for vrchat and alike. at the moment my toys only work websocket based in Virtamate and this is not going to justify me making them public accessible at this time.

plus i am very bad in middleware implementation, i just can’t get my head around the protocoll buttplug uses, let alone how to declair the device propperly to expose it to it or the knowhow to script the cli interface for other games

7

You might want to forward your complaints and feedback directly to the Buttplug.io developers.

8

Hi. Buttplug.io developer here!

Congrats on being part of the 0.00002% of users with that kind of setup.

The thing to remember is that I’m a single developer trying to support around ~50k installs of the software across 5 platforms and 500+ toys.

If you really want to integrate that much special hardware together, do not expect me to support it fully unless you specifically pay me for doing the integration work.

80% of my users have just a vibrator. Maybe 10-19% have a stroker. 1% might have a fucking machine. Some percentage less than that will have DIY hardware like the OSR-2/SR-6.

Multi-machine installed dungeon setups are EXCEEDINGLY rare and require a ton of very specific integration. You can’t expect me to just handle that.

Also buttplug.io will most likely never support estim directly. It’s too different from how our current protocol system works and I’m not comfortable doing signal generation for systems I don’t know well, which estim definitely falls under.

1 Like
9

Right now Buttplug/Intiface defaults to single axis because we’re still figuring out how to deal with all of the possible exposed axes on the device. Not only that, it’s about the only device we have to worry about where there may be differing features from device to device, so building that functionality into the software would be specifically for OSR-2/SR-6 owners. While I’ve built multiple OSR-2s myself and have a FunSSR1, there just aren’t enough users compared to the rest of my userbase to push this functionality up my priority list right now.

That said, this is mostly a UI issue, and hand editing the user config can expose what you want. I just need to update the documentation to reflect the new state of things, and I do have that on my todo list, I’m just busy with other stuff right now.

(Also: I have no idea why you’re having to talk at 9600 baud, if you’re using USB serial baud rate really shouldn’t matter.)

1 Like
10

Yep yep, I made this rough guide to just try to help those trying to connect have an easier time while giving yourself space to work through what you needed to do so. Along with making sure that anyone looking to connect know that single axis is all they are going to get for now rather than start complaining.

The buad rate I mentioned since from what I could tell and it was required to hit the add button (and I am using USB). Where I got 9600 from was the device manager and so since all other information from it worked I thought that was the right amount however it did not as no movement occur so once I realized it should have been 115200 and tried that, it then moved.
I mentioned it as if I made the mistake then someone else might do so in the future. Since it wasn’t clear as day to me in hindsight either and made setup not exactly be an copy and paste job of what device manager showed. (I hadn’t changed any of the device manager settings, what was shown was the defaults)

11

point taken, apologies

12

Hi! Thank you for trying to help the community out! Im still very green in this space but im looking to upgrade my chepo single axis amazon auto stroker with something more sophisticated and after my research am most attracted to the SR6 due to the multi axis utility and feel like it might be future proof. With that being said i understand buttplug.io doesnt have any plans to provide direct interagtion for these DIY toys, does this thread/comments imply that through config mods we could have some kind of usability for multi axis mobility in games?

13

@Kapnik The only purpose of this thread is to show people it’s possible and how to connect an T-code device like the OSR2/SR6 to Intiface Central. (no idea if this works for SSR1) With the warning that it is not showing how to do anything more than single-axis.

That said I personally believe that if you have the skills you can make an mod or an program to make it possible for multi-axis to be done.

Additionally it hasn’t been confirmed that Intiface Central won’t in say…5-20 years time have gotten multi-axis intergration, just it won’t be anytime soon. At least that’s my personal view from what qdot said of these two things just above (with other posts in the past I’ve found):

and

PS I won’t qdot if it’s possible to put on Buttplug.io some place to see the market/usage share overview of toys so people can see if they are about to purchase (if they haven’t already) something that is not widely used or not. (As https://iostindex.com doesn’t show market/usage share)

1 Like
14

I have a FunSSR1 on my desk right now, works fine with Intiface Central.

I’ve needed to write a blog post about this for a while so I guess I’ll just throw the content here for now, feel free to point at this post whenever you need to make this point to someone:

Ok, so, let’s clarify what “multi-axis integration in Buttplug” means.

First off, multi-axis integration with Intiface/Buttplug is close to doable. We need to change the way our TCode implementation works to be slightly more robust, but that’s it on the code side.

The more difficult part is exposing a mechanism in Intiface that allows users that have basically no clue what they’re doing with this new complicated DIY device they cobbled together/bought to properly enter the required information that will define what their device can do. Not fun, and providing support is going to s u c k because honestly, while I love what has come from tcode based systems, as you can probably tell from my tone, I’m not super into being unpaid support for a community I’m not really even a part of. Especially with the demands I get from people thinking they’re entitled because they bought or built a device that they’re having to cargo cult info for to make it work anyways.

All that said, this task in terms of building device definitions in a user understandable way is difficult, not impossible.

Now comes the real problem: What exactly do you think “multi-axis integration” in Buttplug is going to DO for you? I’m not sure most people asking this properly understand what they’re going to get when this comes out.

“Multi-axis integration” just means that Buttplug provides developers of apps that use buttplug with ways to access all the possible movement configurations of an OSR-2/SR-6. We can define the translation/rotation axes, valve levels, etc. Those are presented in a fairly raw manner to developers of apps.

But that’s it. It’s just access to the possibility to control these things.

What I think people actually want, Buttplug integration or no, is to be able to use these devices in a way that is meaningful to their capabilities. That doesn’t intrinsically require Buttplug access. T-code works fine on its own, and developers have made interesting things lika Ayva and the Virt-A-Mate plugins. Buttplug exposing more control will not automatically make all of the software with Buttplug “just work” with the OSR-2/SR-6 in a meaningful way. It’s the same as if we integrated with the Syncbot (which almost happened many times but the company was being weird). The Syncbot also does a bunch of stuff that a large portion of the hardware we support does not, and that means that while we could expose controls, they may not match up to what’s expected by software that’s already written.

Multi-axis integration will not make developers care about OSR-2/SR-6 users, because most of our community can barely control vibrators with our library, much less know how to deal with simultaneous generic axis movements. While I’m not going to act like Buttplug is the easiest thing to use in the first place, there is no generic API that’s going to make programming for the OSR-2/SR-6 easy for someone who has no programming or controls knowledge, unless it’s just playing back prebuilt movement patterns (and, tbf, we do have pattern playback in the Buttplug dev pipeline, though it’s a ways out)

This is not just a problem in sex toys, it’s a problem in interactive hardware as a whole. Look up the Novint Falcon (which I wrote the open source drivers for) if you want an example of this going wrong in gaming.

A possible way to solve this is building translation/scripting systems to go “we’ve been told to make a device vibrate at a speed, turn that into another equivalent event of [multi-axis movement, stroking, whatever]”. This was originally part of the vision for Buttplug, to have a scripting layer between received event and output. We’re 7 years into the project right now and that’s been difficult to get to because we went breadth before depth, meaning we now support 500+ devices on 5 platforms of desktop/mobile, but there’s no way to do translation yet. It’s something I’d like to look at in the future, but it takes a lot of time just to manage what we have right now.

If someone wants to beat me to it: more power to you. I’m not the only one that can program, as much as everyone seems to act like it.

We don’t have hard numbers at the moment because I’m still figuring out how to do that telemetry without having my user base come at me with pitchforks. That said, anecdotally, I would probably say the largest amount of our users just have a lovense toy or two, and then the portion after that is buying cheaper vibrators (Joyhub/Satisfyer/etc). Strokers are a tiny fraction, multi-axis even tinier.

3 Likes
15

My apologies qdot, as somone who works in product operations i understand how cumbersome support can be espically for a small business where your rep matters and the user base reative. I didnt meant to suggest i could figure it out on my own with such limited knowledge and skill, but more so that i fi d this realm extremily excoting and trying to understand where my desires fall in the relm of possiblies/custom work.

  • ive perosnally worked on a few data mesh platforms and this seems like the ideal candidiate for the samw
16

I was able to get this working but now the problem I have is my sr1 is like skipping points and just not following the script properly. The device works fine with the same script on mtp. Did I do something wrong or is this normal?

17

When your using Intiface to play the script, is it as part of an game integration or something else? If it’s part of a game integration then I would suspect that it’s the integration as I had skipping occur with my SR6 that was solved when the integration I was using updated.

18

I am just using script player with intiface and just have a lot of skipping or just playing the script incorrectly.

19

As you said MFP with intiface works without issues then I presume it’s script player that has the problem and you should query them about it. I did check the github of it and see that it says:

If you want to use ScriptPlayer with Intiface/Buttplug, make sure to also install the Visual C Redistributables

Additionally in it’s troubleshooting section it says:

Movement is too fast or erratic

Try adjusting the settings for Speed, Range and Min Command Delay in the settings panel. By default they are pushing the limit and result in faster movement that other applications. The defaults of other applications are approximately:
Speed: 20 - 80
Range: 5 - 95

20

Sorry should have been more specific the device itself without intiface works with MFP. But when I try intiface with MFP the device doesn’t work and when I try it with script player it works just having problems with it playing the scripT properly I trying again right now and I am looking at the log on intiface and this is what I get on scriptplayer, On MFP the logs are fine but it doesn’t work.
Screenshot 2024-10-01 223014
Screenshot 2024-10-01 223003