Cuz then there’s this one that didn’t sync well, I assume because the speed was changing, though the change in speed did match the speed on screen. So I guess animations with a constant speed and full stroke length work with any toy basically.
by working perfectly, i’m assuming that you found an action speed that produces a sweet spot within the overall control loop where it matches the overall response time lag and the machine’s inertia to give you the perfect thrust when telling the machine to do 0-100-0 power loops. But that obviously is quite lucky, while my approach tries to normalize scripts systematically so that you’re actually sending the correct motor speed percentage to your machine all the time. IMO that should be the right approach for stuff like this, although it’s not perfect, you will never have full synchronization without a way to complete the control feedback loop (i.e. getting the actual position of the machine at any given time). Hence why i’m now much more interested in getting a fully linear drive machine, where i don’t need to care about this conversion at all.
Also unrelated, but if you use my tool, when creating your machine profile for the hismith it’s better to give it speed commands via the intiface server, rather than relying on their hardwired remote. I found that the remote has a weird deadzone until about 10% on the dial, so i don’t trust their stated percentage when doing measurements.
Idk exactly how it worked, but I’m assuming from my experience using the script with my machine and now seeing it on OFS, the bottom point isn’t 0 and the top point isn’t 100, but rather the line in between them is what determines the speed. So the orange line is just a constant speed and then it switches to the red line which is a different constant speed. So the distance between each point is what determines the speed not the points themselves. So it wasn’t jittery or at 0 or 100 (unless red is 100) but swapping between two speeds, and it seemed like MFP smoothed the transition so it didn’t jitter between speeds which might be what caused the scene and script desynchronization.
That’s my take on the script that didn’t work.
For the script that did work, I assume that was crazy luck since (I assume MFP) smoothing the crests and troughs would’ve desynchronized it but the change in speed to smooth the wave coincided with the slight decrease in speed in the animation as the model also smoothly transitioned between upward and downward movements. So that means the script itself would be bad for a stroker though because it doesn’t account for the position where the model smoothly transitions between movements right? Like if it’s for a stroker it should’ve had a curve rather than an angle on the crests and troughs.
Hey, unfortunately no, I’ve been busy with other projects and general work/life stuff, and also I’m moving away from rotary machines as I’m much more interested in linear controlled ones. This project was mostly me trying to prototype a way to convert scripts so that they work nicely with rotary machines, and for the most part it does achieve that, albeit with some quirks/simplifications. At some point we wanted to improve the algorithm behind it, but nothing ultimately came of that. Nevertheless, the code is freely available so anyone can continue my work if they want to. I also never really liked working with Lua and the limitations of the OFS API tbh. I don’t like either scripting with or modding OFS, and I’d far rather prefer to work on FunGen if i had spare time. I naturally apologize for not pursuing this further. I don’t completely exclude the possibility of returning to this at some point, but it’s not among my priorities right now.
I know that OSSM has a branch for FS control, but has known issues such as position drift and the occasional maximum extension (yikes). Having a machine that actually fully works with FS out of the box would be amazing, still waiting for something tangible to show up somewhere that isn’t just theoretical.
The maximum extension issue did get fixed some time ago, also I heard that they’re getting things ready to migrate to the V3 board and update their connectivity stack to finally allow better API control through xtoys and intiface. The people working on intiface are aware of all this and hope to eventually support it properly. But yes as of now, there are no linear machines on the market that support funscripts safely out of the box.
On the other hand, this experiment I made definitely shows it’s possible to convert scripts meant for linear devices to be played by rotary ones. Just needs better handling of all the weird little quirks of your typical linear scripts found here. I made this in my quest to figure this out for myself and shared it here hoping it would help others and also incentivize further development to support fuck machines in this ecosystem that’s otherwise dominated by content intended for straight dick gooning.
