EroScripts is a community for scripts that sync interactive sex toys with porn. Learn more.
To find and download scripts, create an account.
Well I don’t know how funscript players interpret .funscript for vibrators.
There’s nothing you can do in OFS.
It’s up the player that you’re using to translate the positions into something sensible for the toy you’re using.
What player are you using?
Thanks for the quick reply. Yes, it was the player. I was using script player. I just tried it with MultiFunPlayer and it worked great (once I got everything configured).
Apparently there are multiple conversion modes you can choose from.
I found an interesting interaction between OFS and MFP.
If you place an mpv.conf in you’re %appdata%/OFS/OFS2_data/ directory with the following content.
input-ipc-server=multifunplayer-mpv
MFP will be able to connect to OFS embedded mpv player. 
I don’t necessarily recommend doing this but could be used to do quality assurance.
You can even combine it with MFPs Axis::ReloadScript shortcut.
Make edits in OFS save as funscript and quickly reload in MFP.
Hah, yea one benefit of having mpv integration is that it works with everything that uses mpv, it also works with plex and emby this way, tho they dont return a useful video path.
But is there a reason to have such interaction since OFS can already send TCode to osr?
This could be a MFP/OFS plugin if it is somehow beneficial, have OFS side send the internal funscripts on edits and video position/duration/state on playback, and have MFP side just generate correct events.
I was thinking about devices other than the OSR using Buttplug.
Given the chance I would remove T-Code support…
I don’t even know if it still works. 
It’s times like these I wish I had telemetry, it’s such a mystery to me how people use OFS.
I was considering adding Buttplug support to OFS but that would mean I still would have to implement a funscript player inside of OFS and I don’t want to do that.
It would be much nicer to use an existing player like MFP. 
I’ll try to write those plugins as a proof of concept.
The only issue would be that MFP is windows only.
It’s times like these I wish I had telemetry, it’s such a mystery to me how people use OFS.
Same with MFP 
Well you can’t have everything.
I don’t know what you have in mind but when it comes pushing edits,
I’d like to be able to just push the funscript json object as a string to MFP without it touching the filesystem.
Obviously not an elegant solution but easy and a very low risk for bugs to occur. 
Yea that’s what I was thinking, send the whole serialized funscript:
{
"scripts": {
"L0": { ..serialized funscript.. },
"R0": { ..serialized funscript.. },
}
}
Obviously only changed scripts would be sent (all on first load).
Events would also be needed for isPlaying, time, duration, speed change.
I tried to write the plugin for OFS but I dont know if its currently possible.
The server/client code for whatever communication type needs to be blocking (waiting for connection, waiting for reading data, etc) and from what I understand plugins run on the same thread as OFS.
Also there needs to be an event for script changes, otherwise it would have to serialize each update tick.
I wonder if this would be better as an internal tcp server with some simple api events/commands so that other player could use it too.
I would then add it as an actual media player in MFP instead of a plugin.
There actually is a script change callback in the Lua API.
You don’t know what changed but you know something did.
function scriptChange(scriptIdx)
-- is called when a funscript gets changed in some way
local s = ofs.Script(scriptIdx)
end
However the communication part is the hard part.
I don’t think it’s possible with the OFS Lua API in it’s current state.
Not because of the blocking but because there’s no way to communicate from a Lua extension.
Unless you’ve discovered something?
I could probably add a websocket based interface on the C++ side.
And then just send json messages over that.
I actually prefer this.
Doh, reading documentation is hard.
I thought you could use full lua in extensions? (I spent like 5 minutes on it)
So you could create a tcp socket and listen for connections.
Or use namedpipes/whatever.
Yea I think this would the best solution instead of getting limited by extensions.
Is there a way to add a leapmotion tracking controller as a input device for on-the-fly scripting? Kinda like a mouse or joystick scripting?
You won’t see me adding that anytime soon. no.
understood. thanks!
Just to give a bit more context.
It’s probably possible but I lack the hardware.
I probably don’t want their C++ SDK or whatever they have in my source tree.
A more likely addition would be supporting VR controllers using OpenVR.
However I still a have a lot of technical debt which needs cleaning up, so big new features are currently not possible.
Guys, trouble. The script project for the hour-long video, after the emergency shutdown of the PC does not open.
Is it possible to try to save a week’s work?
There should be backups in %appdata%/OFS/OFS2_data/backup or %appdata%/OFS/OFS_data/backup if you’re not using version 2.0.
Before using them copy them out of the directory and remove the .backup extension.
I’m going to try.
Man, you saved me!!!
I’m ready to give you 100 hearts.
I’m glad the backup feature does it’s job.
The next iteration of OFS will have a websocket api.
This means other applications can connect to to OFS via websocket and receive events (and potentially send commands).
Based on that built this 3D simulator in Godot as a separate application.
Edits made in OFS are automatically pushed via the websocket and unlike the current 3d simulator this one supports sway and surge. (Script for the demo by Dimebag 
)
So this will be my excuse to cut the current 3D simulator as well as the built in T-Code support.
Both of these I don’t want to maintain anymore on the C++ side.