EroScripts is a community for scripts that sync interactive sex toys with porn. Learn more.
To find and download scripts, create an account.
Really curious what are the reason of using funscript instead of JSON, XML or SRT.
With the recent Android updates it gets harder to work with Android unknown formats causing multiple issues. We are thinking to migrate SexLikeReal to more standard format. Should be little problem for script creators and users as funscripts could be easily converted and script editors can export to the new format.
OFS is one of the most widely used script programs on here for the masses. That is how the program exports the file, i’ve never heard of it exporting in other formats but I could be wrong. Also, translating funscirpts to other file formats has had problems. some things come out wonky or out of sync sometimes when using something like a converter. It has happened to me in the past. That would also be a huge ask of users to convert the scripts they have to another format. Im not sure all script players can use other file formats but I may be wrong in that aspect. Also this seems to be an android issue, so people who use only their PC to play scripts prob wouldnt want to change their format since its something that wasnt even affecting in the first place
Funscripts basically ARE JSON encoded timed positions.
Every single user with an OSR2 or SR6 use PC as far as I know.
Funscript should be the industry standard.
If format is just about file format encoding, and there are tools that can accurately convert back and forth, then this is nothing more than going from .doc to .odt or reverse.
It is not like there have not been other formats in the past, such as .meta.
Though it is important that any new format is open source/ license free, with no limitation to the community or other platforms, as well as any important tools to convert/ use them.
It would have to be a industry and community wide agreed decision, otherwise, one would risk fragmenting the standards, which is never a good thing. That mean the benefits will have to outweigh the disadvantages. (Free/ open-sourced/ non-licensed API etc. would help adoption into every maintained application.)
That’s the plan. Funscript just feels redundant in every way. Can’t make sense of it and now it starts giving us trouble with Android security
A funscript file is quite literally a JSON file with a different extension and a commonly-accepted schema.
If the question is ‘should funscripts use XML or some other common format’, then my personal opinion is ‘no’ just because JSON is so easy to work with in so many languages, and is so friendly to web technology.
If we’re just talking about file extensions, then I think moving to .json is a bad idea since it would make it much harder to do simple OS-level things like search by filetype etc.
IMO funscripts have a ton of room for improvement - I feel like they have been a great ‘first standard’, but as scripting and toy capabilities have evolved, the funscript format has started to become a little limiting. They’re like 5x bigger than they need to be, they don’t allow for multi-axis and other nice features, they allow for arbitrary junk data to be included, etc.
But I agree with @mixmox82 - a format change needs to be industry and community wide, and needs to be open-source and license-free. Otherwise it will only serve to fragment the community + ecosystem.
Edit: re-read your question and answered in the following post.
Original Response:
I don’t understand the question, and I’m not sure of your technical background, but this is a peculiar question in the context of the solutions that you’ve suggested. Previous responses have indicated that funscript is JSON. JSON is sooooo much friendlier than XML. JSON is also universal. SRT seems fine for subtitles, I’m just not sure how it is an improvement for our purposes here.
If we had to migrate, I like TOML as a more modern alternative as you can add comments, but most people don’t need comments in a funscript file. Like most others in this thread, I don’t see a reason to change yet.
Here is what I would change
One change that I’d consider is having a each axis be a key in a single .funscript file. Instead of having the following files:
video.funscript
video.twist.funscript
video.roll.funscript
video.suck.funscript
video.pitch.funscript
video.sway.funscript
… etc.
you could just have a JSON key for each axis. It would be easy to maintain backwards compatibility by keeping the main axis named “actions”. Your typical 1D stroker like The Handy the SSR1 could continue to use the data in the “actions” key as is, other keys could be added for all other axes.
I believe SLR may have done something to integrate all axes into a single file but I’m not aware of what was actually implemented.
A Brief Example of One Possible Implementation
"actions": [
{
"at": 1000,
"pos": 100
},
{
"at": 2500,
"pos": 75
}
],
"pitch": [
{
"at": 1000,
"pos": 50
},
{
"at": 2500,
"pos": 65
}
],
"twist": [
{
"at": 1000,
"pos": 50
},
{
"at": 2500,
"pos": 85
}
]
Other than the need to reduce multiple files into a single file, which can be done in the current JSON .funscript format, I haven’t seen a reason for a change. I think you could make a good argument for some standardization within the JSON keys, however. In addition to the keys that I’d mentioned above, OpenFunscripter adds metadata keys for things like bookmarks, chapters, license, author, etc. These are great, yet I find myself wanting to add more.
Adopting some additional standards would be nice
I’ll give you an example:
I’ve written a program that will generate animated gifs from bookmarks within funscripts that are generated by OpenFunscripter (or any program, it will work). OpenFunscripter writes keys for things like metadata (author, license, title, etc), and of particular importance to me are chapters, bookmarks. Chapters contain a start time and an end time, but bookmarks only contain a single time.
"metadata": {
"bookmarks": [
{
"name": "Intro ~5s",
"time": "00:03:38.000"
},
{
"name": "Measure Ass (Anastasia Brokelyn) ~4s",
"time": "00:08:13.900"
},
{
"name": "Blowjob (Anastasia Brokelyn) ~6s",
"time": "00:11:05.100"
}
],
"chapters": [
{
"endTime": "00:09:34.700",
"name": "Blowjob" ,
"startTime": "00:04:26.166"
},
{
"endTime": "00:12:45.133",
"name": "Close Up",
"startTime": "00:09:48.966"
},
{
"endTime": "00:18:09.633",
"name": "Missionary",
"startTime": "00:12:46.033"
},
{
"endTime": "00:23:18.033",
"name": "Missionary Close",
"startTime": "00:18:10.266"
}
]
}
However, my program creates animated gifs from bookmarks, so I want to add a duration or end-time to the bookmarks key.
Here is an example output for a moving bookmark gif which I generated with the following:
<snip>
{
"name": "Measure Ass (Anastasia Brokelyn) ~4s",
"time": "00:08:13.900"
},
... <snip>
My current options for non-standard animated bookmarks are…
Creating a better standard would be helpful for everyone, let’s just keep it open source and accessible for all. If you have a specific reason that JSON (funscript) isn’t a good format, I’d like to hear about it.
I wouldn’t love it, but naming a file like:
video.funscript.json
would probably be fine if the android thing really has legs. It would still allow for easy searching.
Hey, that is correct. We have implemented this by adding a new array to the funscript files called ‘axes’. Each axis has it’s own ID. Please check here for more information:
The advantage to this solution is that it’s dynamic. In the SLR app the ID is passed on directly to the OSR/SR toys. If someone comes up with a new type of axis then there’s no need to update the player to recognize it.
This is funny, in my original post I suggested that we preserve the “actions” key and then introduce a new key for all additional axes. Then I thought nested arrays of axes might get a little complicated for those just learning JSON and adjusted my post. Your thoughts match mine, and I am fine with the naming as @Tempest has been good about open sourcing and developing the TCode. My only quibble is it’s hard to remember what axis is what when things are named L1, R2, etc.
That’s good to hear. 
Hopefully scripting apps will support this multi-axis format soon. The app could keep track of the user friendly name / ID combinations and export them.
Whenever I start thinking about funscript file format changes I end up pulled in two directions.
On one hand, it’s like “what’s the smallest backwards-compatible change we could make to the format that would provide the most benefit”.
On the other hand, it’s like "if we’re going to argue for a format change (which is going to end up being confusing and disruptive to non-technical users no matter what you do), why not make as good a format as possible?
I lean towards the former though. Adding in additional axes would be a pretty big win.
However, I don’t think I personally like the idea of encoding chapters and bookmarks into a .funscript. IMO .funscripts are for controlling toys. Any metadata in the funscript should pertain to the funscript itself (i.e. who created it, which video is it for, etc.). Chapters and bookmarks are video metadata, not script metadata, and so they don’t belong in the script file (again, just in my opinion 
)
I don’t care if a new format is introduced as long as it supports the legacy devices without much effort on my part. That is easy to say but may be problematic in application. The Android is having their own problem so should we really solve that for them? Would the solution be final or will there be new issues?
Now that I got that out , I will admit I would like a script that could control smoothing with a command like “start qubic” and then “end cubic” later and change to another mode for a wile with another command.
It would seem to me that it would be interesting to be able to embed LUA like code inline to control whatever I want with a defined channel or whatever I think up.
Also user added channels to the script for my future imagination.
And, obviously, an AI input! 
I guess some of this would go into the player…
@defucilis, I think that this is a great discussion.
From a purist standpoint, I agree with you about the video metadata. Chapters and bookmarks relate to the video, so here are my pros and cons:
Cons (Why chapters/bookmarks/metadata shouldn’t be included)
Pros (Why chapters/bookmarks/metadata should be included)
As a matter of practicality, I believe that the pros heavily outweigh the cons, as information is far more likely to be lost if kept in separate files.
My main contention is that many creators and users won’t have any clue where the data is stored if we move the additional data to a second file, it is exceedingly likely that all of this useful additional data will be lost.
As an example, I’m working my a gif generator that generates gifs from bookmarks and optimizes them for the 8MB size maximum for ErosScripts. Since it’s trivial, I’m also going to also add the ability to export cuepoints from a funscript file so that they can be imported by XBVR, HereSphere, or any other software. This can also probably be done with a simple Lua extension in OFS. However, I think it’s very likely that we lose all of this cuepoint content if we start asking our creators–many of whom don’t know any of the technical details, to start sharing multiple files. People rarely share “.OFS” files as is. To me, an extra 3KB (see below for a screenshot of my heavily bookmarked/chaptered multi-axis funscript) is worth sacrificing a little purity in order to keep everything bundled within a single file.
Screenshot of File Sizes
I am willing to be convinced otherwise and am interested in other alternatives that foster easy collaboration. Thoughts?
I had a similar exchange with @Yoooi (MultiFunPlayer) & @gagax123 (OpenFunscripter) a while back. You can see our viewpoint at the time here:
MultiFunPlayer feature request #72.