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.
2 Likes
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.