OFS script converter extension for rotary fuck machines (Hismith, Lovense, etc)

Maybe this thread finds this interesting, I’ve converted my rotary machine to give absolute position control, meaning it can play any script without conversion.

I won’t bother with a full set of instructions but basically I’ve got a compass / magnetic sensor with a magnet on the arm to tell me what angle / depth it’s at. Then a PWM motor driver hooked up to an arduino running a simple PID script.

If that sounds doable to you, I’d recommend the BTS7960 driver board you can find on Aliexpress for cheap, it’s very easy to control speed + forward/reverse with.

Yeah, installing a Hall effect sensor on the motor and hooking up a microcontroller and a programmable motor driver to replace the proprietary control board of a machine is basically what you’re describing. And that’s fine. The problem is that 95% of people here will come with the expectation of buying a stock machine and then finding some ready-made solutions for their struggles. They don’t want to DIY, don’t know how to DIY or don’t have time to DIY. I made this script for these cases. My goal here is to allow people to download any motion-based script (or make one), click a button and instantly have something that works. And before that to do a couple easy measurements and get an instant calibration for their device.

If you’re DIY inclined, you can just build an OSSM and write a middleware layer so it can hook up to buttplug.io (assuming such a thing doesn’t already exist, i haven’t looked much into it specifically). IMO buying a rotary machine to then completely DIY overhaul it to turn it into a kinda-linear machine but without on-the-fly adjustable stroke depth makes no sense, unless you REALLY want something so powerful that the rotary torque is worth the tradeoff for you. But even then you could just buy a more powerful motor for the OSSM (or be an absolute chad and DIY a Linmot machine xD)

Not saying this to discourage you or anyone btw, just being a bit realistic as to the nature of what you’re saying.

1 Like

Hey, so yeah… we apologize for not providing an update for a few months, truth is life’s been quite hectic for both me and my friend who’s helping on this. I got a new job since November and i’m now in the process of moving to a new place. They also were very busy with their work for the past few months.

But we have not forgotten about this project. In fact, my friend will now have some more free time during April, and they’ll finish up the script they were working on. As soon as that’s done, i’ll start to convert it to Lua and Python. I don’t want to keep giving timeframe promises haha, but rest assured that we are still working on it. I hope to have more time also over the summer. So, bear with us for the time being :sweat_smile:

3 Likes

Hi! I’m Dr. Sirius, who’s behind the maths and base code of v2 of this convertor.

Sorry to have been so quiet in giving updates on the progress of this! To give a little more information about this, getting v2 ready has taken rather more time than I’d expected. I’m very much at fault here, not Rriik! Working the complexity of the code into a user-friendly format was a slightly larger task than I’d envisioned, and I’ve suffered from a couple of unhelpfully timed accidents this year which has had me working much slower than I would like.

The code for v2 is now fully functional, and works beautifully! What remains to be done is for me to put together documentation and examples, tidy up the wrapper code, and write up the maths formally (to allow other people to modify this in future if they want to, and since this maths doesn’t seem to have been done before). I finally have a decent slot of time to work on this coming up, so I’m hoping that will all be wrapped up in a few weeks. Then Rriik and I will work on converting it from Octave/Matlab to Lua. There are a few unsolved problems that will crop up in that conversion – such as patching in some polynomial fitting code – but I’m hoping the conversion process won’t take especially long.

I can’t yet provide a timescale for the completion of v2, since it depends on the available free time of both myself and Rriik, which isn’t always in ready supply! Not least with Rriik’s current move. But I would be surprised if this wasn’t ready in a couple of months at worst, and potentially a fair bit sooner!

That being said, once the Octave/Matlab side of the code is ready, I’m planning on making that release available as well. So that will be available to use much earlier than the Lua version!

I’m really excited to get this project out there, and the results really are beautiful – and produce lovely results on actual machines :slight_smile: – so I really want to get this all done and sorted sooner rather than later. Stay tuned for more info!

Also, I’m interested to hear about what you’ve done there, gettingfaster. I was thinking about the possibilities of doing something like that when writing the code, but never got much beyond the simple concept. I am more of a theory guy than a DIY guy, truth be told. I’d be interested to hear how your modified machine fares, though. How responsive is the machine to position changes, and what level of complexity of funcscripts can it track? From what you’ve said, it sounds like it might be doing pretty well?

3 Likes

I get you, I just wanted to put the possibility of a conversion like that in peoples heads without making a whole new thread about it. Not advocating for it over anything else, but maybe there are people out there like me who had one of these machines before even learning of scripting (and are into a bit of DIY).

And performance wise I find it works great. It is completely position controlled, just like a linear machine. It doesn’t perform a complete 360 degree rotation, just moves to any point between 0° and 180°, so it does have on the fly adjustable stroke length just as the OSSM does. (Also the OSSM kind of scares me. If something goes wrong in software or a connection and the thing flies to full depth at max speed, yikes… At least with a rotary machine you can set a max stroke length and be confident about it.)

I imagine it plays any script just fine, I mainly use it with my own scripts which are pretty smooth, so not sure how it holds up with rapid jerky motion.

It’s very responsive (depending on the weight attached of course), but that was the trickiest part. Tuning the PID to act quickly enough without becoming oversensitive/shaky or being so quick that the gears get chewed up.

Just to reiterate, I’m not trying to take over this thread :sweat_smile:

2 Likes

Can you make a github with instructions and documentation ? I’m well versed in programming but not so much the electronics side, I can use a soldering iron etc, but in no way can i put together this solution based on your brief description alone.

And to the geniuses making this. Perfection takes time, just makes it all the better when releasing!

and gz on the new job!

There already is a Github with all that info, it’s one of the links in the original post! I’ll paste it here for convenience:
https://github.com/Rriik/OFS-FM-script-converter

was reffering to @gettingfaster modification, but thanks for the reply ! :slight_smile:

@Rriik , first of all. Thank you for your awesome work!

One issue I have run into a few times is this error and I couldn’t find a workaround yet.
image
Is this something that can be fixed in the code? Maybe just skipping the action point if it has the same timestamp as the previous. Or is there some other workaround?

Could you share the script you were trying to convert? Just so i can see if i can reproduce the issue

sure here you go.
Vote Ash Hollywood - Tushy - Sexy Blonde Escort Gives Up Her Ass for her Client flat.funscript (138.7 KB)

I think it’s how the script is written at the start of the video. the error seems to stop at the 00:05:27.483 mark. One of the errors is located between 00:05:25.644 - 00:05:27.483. If I delete everything before 00:05:27.483 it is able to convert.

Hey any news to the v2? Maybe i can help too I’m SWE.

1 Like

Heya! First of all i should start by saying i apologize for the lack of activity and communication on this. Both me and Sirius are still here and we still have a plan to continue working on the upgraded version of the converter. 2024 for me was literally a huge leap in my personal life, i moved from a student room to a proper apartment and completed my first year as a career embedded dev after graduation. (Also i spent most of my free time after the move personally soft-renovating the apartment even though i’m renting it, because landlords/housing agencies are garbage, and getting my partner moved in with me, and other stuff), so it was as packed a year as it got. And i believe Sirius also had a ton of personal stuff to get to this year.

All of which means the current state of the v2 transition is right about where we left off at the start of last year… I know, disappointing. However, I am feeling much more comfortable with the amount of time i can dedicate to hobbies in 2025 (in fact i even plan to focus on them more greatly). And this project is among the list of things i want to get done.

Now, given that you’re even offering to help out with it (thank you so much btw!), it would be reasonable to give at least a broad idea for what we were planning to do with this:

  • First of all, obviously finalize the v2 converter engine. Sirius may explain more about it, but basically it currently is written in octave and somewhat still broken into many script pieces and full of debugging overhead. That needs to be cleaned up and documented a little.
  • We then are faced with a decision: do we continue to support what admittedly is a useful and widely used but slowly dying funscripting platform (scripting Lua for OFS which is abandonware for a while now), or do we pivot and make this into it’s whole new standalone Python GUI app? (Not to say the converter code may never be backported to OFS after it has been fleshed out, but focus would be placed on the python code until it reaches maturity).

Assuming the transition to Python, we would have much more freedom to experiment and iterate, which i find harder to do with the constraints of Lua and the OFS API.

The new converter would introduce what we like to call “difficulty modes”, because the challenge of physically simulating the machine’s oscillation behavior, motor response and communication limitations without real-time feedback has also led to us finding different ways to optimize the script generation to tailor the user experience to be more gentle/rough by adjusting the degree to which we allow the simulation to deviate positionally from the intended action. So in short, trying to control the uncontrollable (and unmeasurable, because let’s be real, literally nobody wants to make embedded mods and contraptions to communicate rotary encoding in real time on chinesium fuck machines and try to PID control the power delivery to get that thing marginally more accurate than this simulation would) xD

And if this is done, why stop here? I have a more moonshot idea to build an entire funscripting IDE in as much as possible Python PyQt, with maybe some C++ if really needed for stuff where Python may bottleneck. I want to analyze and take the best parts of OFS and other funscripting tools, make it super easy to extend with community Python plugins and hopefully easy enough to contribute to with good documentation and code architecture. And by extensions i mean I’d love to see if someone can make DL funscript copiloting plugin right into this bitch as well as this here extension and more, and to hopefully make it easy for other python projects that have been popping up lately on this forum to integrate with it too. Again, very moonshot, and i don’t know if there’s already a project that attempts this, but i personally dream of a future where i can open up a scripting tool and script a huge video in no time with user-friendly or maybe even fully automatic motion extraction and post processing. This whole ecosystem of pre-computed sex tech sync to content is just a deep learning video motion/context tracking problem in my view and it shouldn’t require manual slavery of hours per minute of video depending on action complexity.

Anyway, moonshot aside, the main objective remains clear, so what do you think?

1 Like

could be great to have a standalone python cli at first that can convert a script while keeping the same features the extension has currently.
and wrapping up that v2 from @ SiriusCavern

Nice! I sent you a DM to see if we can connect on Discord/Telegram.