For me what worked was using Wine (more specifically Lutris) to install the software and run the windows version.
I also had the problem where after opening a video the screen starts flickering and everything becomes unresponsive (using the AppImage). I wasn’t able to compile the software either (it complains about a ‘:’ that should be a ‘::’ and fails, I didn’t look into it much as I don’t know C++)
All of this on Debian 13
@Dimava, proposal to close this thread and create a thread for OFS 4.0 instead, pointing people to that version instead, as well as the most viable alternative forks of 3.2.x which may individually contain QoL fixes or new features for specific use cases (e.g. Mac/Linux support, FunGen integration, etc.) until and unless these additions are later integrated into the 4.0 repository.
Reasoning: it’s been 3.5 years since OFS 3.2 officially released and subsequently became abandonware. Long term support now exists in an “unofficial-but-official” form through the OFS 4.0.x fork. As far as I am aware, compatibility isn’t technically broken, so my guess is it was called 4.0 to make the development transfer more obvious. I see no good reason why people shouldn’t upgrade to that version, or one of the alternative forks. The developer themselves would like this as well, as per quoted comment.
For those unaware, you can find all forks of OFS on the project’s Insights/Network page. The more prominent ones by number of contributions are the forks maintained by the following people:
Would be useful to add maybe explanations for the main updates on each fork for people to know what they’re getting. And otherwise to make it known and obvious that 4.0 is the new “main” and that people should be creating PRs and contribute to that one instead of forking the archived repo. Will take a while to make everyone aware, but i think it’s the only way this community could move on from this legacy.
I have some trouble with the “export clip” function. I want to cut a video+funscript by creating a chapter and setting the size and then export the clip. But it very rarely works and just nothing happens after clicking on “export clip”. Sometimes after a computer restart it seems to work, but I am unsure whats wrong exactly.
Does someone have any idea or encounter this themselves?
I’ve also never been able to get it to work. It’s annoying but the best method i’ve found is getting the timestamps for the chapters you want and using ffmpeg to split the clip instead.
Using ffmpeg works great for cutting the videos without reencoding, but cutting the scripts is tricky when you cut away parts at the beginning of a video.
100% agree, that’s usually while I revert to nuetral points for all scripts on the first/last frame for each chaptered section. It has the added benefit of making a looping script transition to a repeat seamlessly. It’s still a massive pain in the ass don’t get me wrong, but at least you have an easy reference point to select all points to the left/right of.
You can also write a quick script that parses the funscript array and duplicates the info between the specified times in the chapter metadata. It would be a lot more involved but it might be worth it if you’re planning to split many chaptered scripts.
There are other tools in the Software section.
Maybe this tool do what you want: Funscript&Video merger / splitter
Think you could post a breakdown of the differences? I’m interested to know. I’ve just been using the base OFS for a while now. No plugins either…
I tried this one ” GitHub - Eroscripts/OFS: A tool to create funscripts · GitHub “ but it looks like the scripts that are exported with that version don’t get heatmaps generated in XBVR. No idea if its an XBVR issue or this OFS version issue.
I’ve noticed this issue as well- it’s a problem with that version of OFS. Exported scripts seem to have times with decimal numbers which causes errors with some programs.
I haven’t looked much into them either tbh, from what i know though, the michael-mueler fork added NixOS support and better integrations with the MTFG plugin (developed by the same person), probably also some bugfixes. (There’s currently also a recently opened PR to merge the changes from this fork into the main 4.0 branch). Meanwhile the k00gar fork i believe contains a deeper integration with FunGen, so if you’re using that software you could ask k00gar about what they did there. The last one I have no idea about honestly. from the commit differences i can deduce they fixed some bugs and optimized the codebase a little. Could be worth looking into merging this stuff also into 4.0.
Feel free to report an issue on the 4.0 github :3
Can you clarify what happened with added decimal points? I went through the repo and it seems they largely handle positional data the same. The only changed variable type I could find is the metadata.duration attribute which is changed from type integer to a double. Maybe the heatmap generators fail to generate when the duration is a decimal?
OFS/OFS-lib/Funscript/Funscript.h
double rounded = std::round(metadata.duration * 1000.0) / 1000.0;
jsonMetadata["duration"] = rounded;
I’m not entirely sure myself, another user ( @Islanti ) pointed out the problem to me on one of my posts. They said the decimal time causes some software- xbvr specifically- to not generate heatmaps. I don’t personally use xbvr so I don’t really know.
I did confirm it was an issue with that specific version of OFS by exporting a funscript from the original 3.2.0 version, and then opening the same project file in the forked version and exporting it again.
3.2.0 script.funscript (310 Bytes)
4.0.8 script.funscript (381 Bytes)
Besides the metadata moving to the top of the file, the only other differences are the duration being in decimal and a new durationTime field.
Programs like Stash Interactive Tools, and XBVR likely were not built to read doubles for these values, but I can attest that if there is a decimal in the script, it will stop Stash and XBVR from generating a heatmap and, in some cases, from playing the script
I also have to remove the decimal in the duration field when I export from OFS 4.0. It breaks my funscript preview plugin and I think Stash heatmaps as well.
Edit:Also, the presence of DurationTime has not interfered with any of my uses (as expected from an additional json field that can be ignored).
I will do some more testing to see if the fix is as simple as removing the logic that was added to measure duration in milliseconds. I’ll also double check durationTime or the code that altered other metadata doesn’t mess with it.
Hi I just noticed comment on the fork I made. My fork is currently a non functioning copy.
I started out with a “nuke the world” approach thinking that updating all dependencies wouldn’t take too much time but quickly derailed into doing more than just that. I’m hardly done and currently doing too much overtime at work I barely have any free time. In hindsight, I should have patched things one by one while leaving it in a functional state. I am deciding whether to restart with smaller, incremental updates while keeping it functional, or continue the current approach when I have more time.
Ah, that’s fair haha. When i mentioned your fork, i didn’t look at it in detail, but that is good to know. Indeed, if you ever start working on it again, you could start from scratch with incremental updates as you said, but maybe on the V4 fork instead, so that you can add your updates via PRs and such.
I either the V4 fork or the original, I am able to use the appimage or build it myself and it seems to work well - except for generation and showing of the waveform which I would really like to use. I get a:
INFO: [error][MPV] (libmpv_render): after creating texture: OpenGL error INVALID_VALUE.
Error and afterwards I think it loads some waveform that is empte because it instantly says that the audio processing is complete. And guidance on how to fix this?
