Should we migrate from Funscript to JSON, XML or SRT?

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

4 Likes

Funscripts basically ARE JSON encoded timed positions.

8 Likes

Every single user with an OSR2 or SR6 use PC as far as I know.

Funscript should be the industry standard.

7 Likes

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.)

1 Like

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.

14 Likes

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>

virtualtaboo-butt-expert-is-here-files - Measure - Brokelyn - 00m58s-01m02s (4s) - 400x400 - 30fps

My current options for non-standard animated bookmarks areā€¦

  • use the hack Iā€™m currently using to embed the duration in the bookmarkā€™s ā€œnameā€ key (by using a the ā€œ~ā€ character followed by the number of seconds. This at least preserves compatibility with OpenFunscripter in its current form.
  • add a key to each object in the bookmarks array named ā€œendTimeā€ with an end time
  • possibly also change ā€œtimeā€ in the bookmarks objects to ā€œstartTimeā€, which follows the chapters naming convention, but wouldnā€™t be compatible with OpenFunscripter
  • or just use chapters for everything (though causes a ton of clutter in OpenFunscripter and 5 second chapters seem like a terrible idea)

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.

2 Likes

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.

1 Like

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.

1 Like

Thatā€™s good to hear. :muscle:

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 :stuck_out_tongue: )

4 Likes

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! :smiley: :smiley:

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)

  • the extra data takes up extra bytes
  • the data could easily be moved to a separate file
  • I canā€™t think of anything else, please give more suggestions

Pros (Why chapters/bookmarks/metadata should be included)

  • the data doesnā€™t take up much space relative to the funscript itself (about ~3KB)
  • keeping the data in a single file makes for easy sharing
  • keeping the data in a single file makes it less likely that the metadata is lost
  • keeping the data in funscript file makes collaboration easier between different software (e.g. OFS and whatever SLR / @raser1 is using these days). A lack of support of a feature (e.g. bookmarks with a duration) can still be preserved between software (so long as the metadata is not stripped from the funscript)
  • keeping chapters/bookmarks in the funscript file means that software like Heresphere, DeoVR/SLR, even XBVR and Stash can automatically import cuepoints more easily
  • fewer files cluttering up a folder. Iā€™d much rather have two files per video (video plus funscript) than three (or more if we donā€™t consolidate multi-axis).

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
image

I am willing to be convinced otherwise and am interested in other alternatives that foster easy collaboration. Thoughts?

1 Like

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.

2 Likes