I’m an experienced JS dev so I could offer some help.
Haven’t looked at C++ for 20 years so can’t help much in that department.
1 Like
That is also my understanding.
The toggle only changes to location from where the script is downloaded. Everything else still goes through the Handy servers.
Stash always makes a CSV from the funscript since the handy can’t read funscripts but only CSVs
Yeah except it says this literally on stash
Theyre saying direct serving is possible when the Handy is on the same local network as the Stash server, or if the Stash server is accessible over the internet. Possible incorrect
They talk about adding A new setting use-stash-hosted-funscript to toggle between the original method of uploading to Handy servers vs the new direct serving method
it seems the original upload method was retained as an option, likely for compatibility reasons
so it appears that while this change allows bypassing the Handy servers in certain network setups, the Handy server upload functionality was still retained, indicating the Handy servers cannot be fully eliminated at this time. The direct serving is an opt-in alternative when the network allows it.
I think maybe there is still some conflicting info on their UI
Hello everyone, thanks for all the answers in this post (even though some of them were just about handy support).
From all I read, I clearly see two camps : one for maintaining the existing OFS and one for rewriting the app since CPP is difficult for them. Both view are legit and my only concern is to determine whether there will still be developers willing to maintain OFS after us.
I briefly checked the OFS repository and while the codebase is relatively clear and bugfix should be possible, adding new feature could be pretty hard.
The main point now is to determine if there are new features that are heavily requested by the community and if it is possible to implement them in OFS.
Now regarding a rewrite, I would like to keep the great performances OFS have so I would not rewrite it in interpreted languages such as JS/TS or python.
I explored the possibility of doing it in rust (which has excellent performance and memory model) with tauri as the UI renderer.
It would allow us to create a much more modern UI but the point which is currently blocking is the video player. I’ll keep this post updated if I found any solution.
For now, let’s simply make a poll to see what will be our next step.
Thanks again everyone for participating in this conversation and being motivated to develop/maintain the tools the community needs
5 Likes
Since there is no poll ad-don on this forum please answer what would be your favorite way, given the requirements listed above
@IIEleven11
it literally says “funscripts will be served (hosted) from stash”, it does not say “bypass handy servers and send commands from stash”. It only makes the handy download the funscript from stash, but the command to even do that still goes thru handy servers.
All commands go thru handy servers.
The only way for the handy to be usable with OFS is to use bluetooth, otherwise the delays will be too big for live editing.
@phenixmaster
C# with Avalonia or Flutter might be other popular options. I think rust deviates from c++ like syntax a lot so it might be harder for people to contribute.
But imo imgui is perfect for what a scripting tool needs. You can quickly add new ui elements without knowing some intricate gui framework.
1 Like
i dunno man i just read what it says here. not like it matters either way
If youre so unwilling to accept whats impossible youll never be the one discovering what is possible.
There is language pointing towards it being served directly without the servers. I am sure thats a mistake. I have stated this several fucking times. Why you feel the need to reiterate that, I do not know. But again for the 4th time. I get it. That does NOT negate the existence of the language nor do we know if said language is a mistake or not.
Those of you discussing Stash support, can you please move that discussion to another thread. It’s off topic now even if it might have been on topic in the beginning regarding missing functionality in OFS.
1 Like
C# with Avalonia or Flutter might be other popular options. I think rust deviates from c++ like syntax a lot so it might be harder for people to contribute.
But imo imgui is perfect for what a scripting tool needs. You can quickly add new ui elements without knowing some intricate gui framework.
To me C# is a pain in the ass (excuse me for the wording) for cross platform distribution and Flutter is not really efficient as it is transpiled into multiple languages and not made in the core design to make desktop apps.
I understand your point about the rust adoption but in my opinion rust is z simple yet really fast language to make programs. I am however curious about other recommendation that anyone would have.
My two cents.
OFS in its current state does exactly what it needs to do - an easy entry point to start writing your own scripts. Adding a couple of tools from this forum (MTFG + MakeVibration and others), creating a couple of your own plugins or making keyboard/keypad macros - nothing else is needed to create simple scripts (both mono and multi-axis). The creator of OFS did very right - let his brainchild go free swimming.
I even stayed on version 2.0, I don’t see the point in upgrading to a new version - what can it give me?
If you want some more professional features/macros, consider using ready-made tools/software - a script is just a json file. I’m not going to advertise my favorite software - but you can already use a really huge number of features there.
3 Likes
I’m not a programmer but a frequent user of the software… Just things that I think could be fixed / added in OFS:
Bugs:
QoL:
- When an navigation key is pressed, pause playback. #84
- Edit funscript without media #51
- Option to deselect when dragging with middle click. #66
- Customizable script suffix in the “add…” shortcuts. Pic
- Threshold to highlight slow strokes. So people don’t have to do this
- Gradually accelerating navigation with keys. So people don’t have to do this
- Vertical selection box. Something like this.
- Better handling of project window (prevent opening two instances of the same project, nesting multiple projects in the same window as tabs etc, allowing copying between projects etc.)
- Rearrange-able UI for plugins.
3 Likes
Might sound harsh, but its not as big of a problem as you think it is. While a lot of programmers say linux is the better platform, most will still say that if you refuse to use windows, you are just hurting yourself.
Cross platform is a nice to have, but for functionality, forcing linux to use something like wine to run the program is a perfectly fine solution. Its not like a game where high framerates etc are realy required. Some performance cost is fine.
Otherwise, i would have said java would actualy have been a better language (dont underestimate how much java is being used). Java has proven itself as language, which rust hasnt yet.
These projects however are again a nice thing to truly test rust on that. Its not like its suddenly going to need a lot of updates to fix things. As long as its ment to stay offline or in a lan situation only, the chances of hacks remain low.
So i would say just go with rust. There is no way to know what is needed in 5y. Just avoid using too much rust specific features and keep in mind the coding styles of for example C# and java to ensure it remains readable and reworkable if needed (yes, if there is a power function in rust, use that. by the time its needed someone most likely will already have rewritten those for other languages).
In the end, its more important that you use a language you like to work with, so maintenace is more likely to happen. And rust has an advantage that because its new and a high level language, its easier for others to take over if its needed.
How is it pain in the ass? You literally just do dotnet publish and it builds for each platform. C# is fully cross platform for a while now.
I dont think speed really matters here, the app literally is just a video player and some controls. You can make C# really really fast too if you want while having an easier time writing it and having way better tooling.
But like I said, imo OFS is perfectly fine using C++ with imgui and mpv as video player. Unless you want to do some insane gui I dont see the need for anything more.
I think you should just do what you want instead of asking people on what language to use.
I think my previous messages sounded too biased. I originally created this post for people to join the journey of improving the scripting experience. I have no specific choice regarding maintaining OFS or build from scratch. I just wanted to know what you guys were thinking of it and allow we can align the devs interest with the community’s one.
If everyone is ok for maintaining OFS or rewrite it in a specific language/framework/whatever let’s start !
Please correct me if I’m wrong, I only have a vague understanding of Rust and am new to the community 
.
But as far as I know, Rust works pretty well together with c++.
And they should be able to be both used in the same codebase.
At least this is what my quick googling gave me.
So another option instead of a complete rewrite or starting from scratch could be to introduce new features in Rust and over time migrate the code base to fully be in Rust.
As flowerstrample and Falafel mentioned, OFS in it’s current state works and does what it should so I feel like it would be a waste of all the time and effort that went into OFS to start from scratch.
Just my two cents though.
On the note of working on OFS.
I’d love to help with OFS at some point.
But I’m fresh out of uni and I want to get some more experience before I would feel comfortable working on such a big project.
Just gonna throw this on the bugs and QoL pile:
- Need the ability to reorder the tracks
- Need to be able to maintain multiple tracks for the same axis, to be able to view them simultaneously, and to enable/disable them (this is needed, for instance, to make dumbed down scripts for the handy because it can’t move slow, but not gimp out the multi-axis devices that can move both slower and faster. Also, this is used to separate single axis strokers that may have parts interpreted as up down – think grinding – whereas multi-axis devices may have nothing goin on in the main axis but have the near/far axis moving).
I sorta provided a workaround in:
This may work until we get things patched in OFS itself, thanks!
1 Like
If its possible to write new features in Rust in the current codebase, I would go with that.
For myself I see this as an opportunity to learn Rust and hopefully be able to help out.
This is a great initiative, i’m glad there’s been several people so far indicating they are willing to collaborate on it!
Personally I’m an embedded software engineer (recently graduated though so still young), mainly worked with C/C++ (embedded work, so not so much app development) and Python. I also have a bit of experience with C# from stuff like Windows Forms apps and also a bit of Unity school work. Rust’s something i’ve been interested in learning more about but haven’t started diving into it yet, for now Python’s what i’m using a ton both at work and in my hobby stuff, but i’m interested in learning.
It’s tough because there’s already a codebase there and also a “standard” developed around OFS where it’s kinda become the de facto scripter for most people. I’ve seen other scripter apps being worked on around these forums but none have anywhere near the traction OFS has had over the years. And it’s easy to see why, it’s a clear-cut program that does (mostly) what it says on the tin, with just enough features out of the box to get you started and hooked on scripting while allowing for a ton of modability. It’s essentially more of a platform these days rather than a simple app, and it’s all because the OG dev had the brilliant foresight to create an Lua API for people to mod the fuck out of it. I myself have written two extensions for it so far, you can find them if you click on my profile here or visit my github (same username) if interested.
So whatever decision is made on this, I’d say one of the main requirements is to allow at least the same level of modability as OFS currently does. And hopefully with more than just Lua, but also Python and other popular script languages. Because Lua’s not exactly my first choice for scripting stuff in 2024 xD
Other than that, I think if you genuinely want to start up an effort for this, it would be wise to setup a group outside of this platform, say a Discord server, open to everyone who wishes to help out. Eroscripts may be nice as a forum but it’s certainly garbage for proper communication.
Also yeah, you can count me in for helping out with things whenever I get some time for it. I’ve gotten hooked up on the fuck machine kool-aid and never going back xD so solutions like OFS are what I want to keep using and contributing to over time.