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.
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).
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.
It seems that everyone is willing to contribute to the existing OFS so let’s get to it.
My post was creating after seeing a lot of comments from devs that would not touch c++/OFS because of lack of knowledge of the language or codebase. This is the only concern that made me propose the rewrite.
I will create a new post to centralize all the improvements that could be made to OFS to organize the work.
I am aware of the github project but in my opinion, not everyone is comfortable with the fact of creating a github account and creating an issue there.
For people who actually code the issue tracker would be better. For others discord might be an option even if I’m not a fan of discord when there are too many people. Hard to discuss on topic when there are dozens of other conversations in the same chat.
Anyways, what I meant with github was that there are bug reports and feature requests there already, which shouldn’t be forgotten if you decide for keeping all discussions in discord.
I’m the one who implemented/conributed that toggle in stash, maybe the wording might have been a little better I guess.
Like people earlier have inferred, it doesn’t bypass the handy servers for the handy control(like play, pause, seek, etc), it only serves the funscript (converted to CSV) directly to handy from the stash instance instead of going through the crowded handy servers (which does shave off a few seconds to load the script onto handy at the start of a video).
Like the documentation says, it would only work if the stash instance is accessible from the handy itself, which would mean it would only work if your stash instance and handy are connected to the same wifi/lan network.
Another thing to note for this to work is, you need to access the stash instance using the IP address (not localhost) or domain accessible from the handy. For example, if the stash instance is running on your laptop (connected to the same wifi as handy) which has the IP 192.168.0.69, then you should visit using the stash in your browser using http://192.168.0.69:9999 and not http://localhost:9999 or http://127.0.0.1:9999
Hmm maybe i am missing something but I cant seem to make it work. Both are connected to my wifi, i accessed stash with 127 0 0 1:9999. flipped the csv button to on and its giving me an error.
If you have time maybe one day can you go through the steps you take to get it to work by chance please?
Ive started learning cpp too. Mostly to try to work on OFS… So i feel you with the code base being intimidating. I only have taken classes for java, pytjom and javascript. So i am in the VERY early stages of cpp
.