OpenFunscripter - a scripting tool - 3.2.0 release

Maybe we should greenfield it in Svelte or something. Read a json file, display a myriard of points, make them selectable, apply some operations on them… things like that…

Try running it as administrator. If it still doesn’t work just manually place ffmpeg.exe in: C:\Users\ your user \AppData\Roaming\OFS\OFS3_data\

I’m having the same issue, none of the versions work for me. 2.0 opens for a second then closes, 3.0+ versions don’t even open. Tried the ffmpeg.exe solution but no luck. The OFS.log file when opened just states “package failed updates, dependancy or conflict validation.” Did you happen to find a way?

There is one function I would need alot mainly after motion detection when the camera shifted or the actors change who is in motion. Then the recorded motion shifts height. This happens quite a lot.
I think many of us would like a function where you mark top/bottom points and press the keypadnumber to set all points to a value. The workaround atm is to move those points to the borders with shift/arrow up,down but that does just take too much time and gets boring fast.

Hey Everyone. I have a feeling that this project has been abandoned for quite some time, but does anyone know if this program works on ARM based CPU’s? A buddy of mine recently gifted me a M1 Macbook (which is obviously not Intel based) and I wanted to emulate the software in a windows virtual machine. Only downside is that since OFS is x86 based I feel like I may have already answered my own question. Thoughts? Solutions? Workarounds? I’m all ears.

Tricky.

Only real solution I know for running Windows ARM on M1 Macs is Parallels:

Will cost you $$$ and there is no guarantee it will work 100%.

An older Intel Mac would be WAY easier. Many you can install Windows 7, 10 (even 11) natively.

Only other solution would be to run it on a remote native Windows machine and control it remotely from the M1 Mac. That way you’d have several options:

There was one coder working on a version that ran on Apple M1 ARM processors via Rosetta and also had instructions in the thread if you wanted to compile your own:

Good luck!

1 Like

Looks like this project is no longer supported, completely understandable as the creator doesn’t profit from this.

If by any chance the creator reads this, I hope he can come up with a model where he sells each major release of OFS, like Adobe used to do with CS5, CS6 etc.

So for example OFS V2 will be $60, and if he releases V3 with more features down the line it will be another $60.

I do need the long term support and am more than willing to pay a fair price for it. I know there are plenty others just like me. I really don’t want this to fall into abandonware…

3 Likes

I have good news to report on that front. Considering the code is open source, I actually just contracted out a developer today to start working on an ARM version of this for Windows 11. Don’t know if that’s something you would be interested in, but if so shoot me a DM and maybe we could help each other out on that front.

1 Like

Have some question that jumped me while scripting:

  • is it possible to change the distance to a point that will be replaced by a point instead of a new one? I would like to make that distance a point is grabbed and moved, larger. There are too many close points I have to manually remove that I feel should be moved. It should also be of different height not only same height so only be checked horizontally. Maybe a button to enable/disable?

  • if an area is marked and you choose a point by double clicking logic says you want to do something to that point, not the marked area. Your intention for example of deleting that marked point will delete the marked area instead of the point. A double click on a point should unmark the selection. If you unmark unintentionally you can get back by ctrl-z and have it marked again. So marking is not lost.

The author’s discontinuation of support may not necessarily be a matter of money. I think he may have more important projects to do. In fact, I think paid subscriptions are good. There is no need to immediately solve the needs, but gradually implement them.

Given that you make money of selling scripts!
If you release scripts for free then a paid model may discourage to continue releasing scripts for free or you might even stop releasing scripts.

2 Likes

Pure open source is not a good thing, such like the issue with log4j author. My opinion is that the free scripts I publish are good and I carefully create them, while the paid scripts are better. For software, the free version is available, while the paid version has more advanced features

That may be true but I would not be willing to pay a monthly fee for OFS. Once, yes, around 20$ but not more. Scripting means you give the community something precious - your time. I think OFS was generated the same he gave his time to make the software.

1 Like

The benefit of a subscription system is to encourage creators to invest regularly and continuously,Software systems usually need to continuously collect reasonable requirements, and continuously improve and refactor them.

Theoretically yes, practically it wont work in this case. OFS is already 95% perfect, what do you want to pull out of the hat for the subscription?

Actually, there are still many details that need improvement, such as

  1. [feat] *Adding support for bezier curves and animation curves.
  2. [bug] Error when exporting chapters without full screen in windows 10
  3. [feat] Convenient operations for multi axis.
  4. [feat] Native support for ARM chips
    and so on

I don’t know if you saw my last message, but I actually hired someone to create an ARM version of this particular piece of software. If you would be interested in that, shoot me a DM.

Agreed. I’m fine with competition, but having an open source scripting tool is absolutely vital to the Funscript community and what gets new scripters into the game. OFS is the reason EroScripts can exist, frankly, because the alternative it was designed to replace was stopping with public updates and removing links that would allow new scripters access. OFS is aging and showing its limitations but it’s not like it can’t be forked and improved still and I don’t get this one guy’s weird drive to push for a subscription model. That already exists (in a form) with other software which probably can still be acquired, I’m more interested in improving OFS in this thread, and SubscriptionFunscripter could probably get its own thread once developed.

4 Likes

All of these features are valid needs. We also need to fix surge and sway axes so they don’t get flipped, update the visualizer to account for surge and sway, and allow for reordering Funscript tracks. Other fixes like better fine-control of points would also be helpful. There’s a lot that can still be made better and a ton of quality of life updates that would benefit scripters still to be made.

Curves are not suitable in the current funscripts since adding too much nodes causes problems.

Instead i would prefer if seperate curve values could be used. For which i can imagine 2 methods:

  • Relative values (1 for max upward, -1 max downward, 0 or omitted for off).
    of which i think these are the easiest to handle as 1 and -1 could be translated towards the maximum speed of a device. these values being floats should enable quick calculations by devices

  • Absolute values at static points as if they would be regular nodes, but instead marked as curve point. Curve points generate a curve at both sides of it. But for devices not supporting it, could be easily converted into regular points and still provide a curve effect.

The 2nd option to me would be optimal as in those cases the subpoints we have added can still be used as regular nodes and allow backward compatibility towards devices that do not know curve information (these nodes becomes regular nodes)
And is also relatively easy to be made.

Anyway, adding points in the current way is bad for devices that can easily manage it, as it just gives a very clear transition moment in speeds. For those devices a clean line would be better then. Hence enabling a method to which devices can adjust their own method is optimal to me.

All that is then needed is to pick a certain curve generation method that is open to be used and easy/low cost to implement/quick to calculate. Scriptplayers can then alway give the ability to adjust the output towards the devices.