@Yoooi @Khrull @Falafel @SomeoneRandom please check it out
1 Like
Building OFS is broken on Linux in the original repository as is the visualize wave form feature. I have been using this fork which fixes those issue. I am going try to merge it in to get it working on my local but I recommend checking it out and pulling it into your fork, Maybe via a pull request to keep the original author intact if they so wish?
Forgot the link GitHub - Deity-/OFS: A tool to create funscripts
@Dimava Shit, ya I missed this sorry. I set the sfma portion to tracks instead of channels. Looking for other differences. I can change it to channels and release a minor update. Should be fine
You may fill a draft PR to ES fork
Please explain what features does the fork add and Iāll cherry-pick or merge it
@Yoooi to you as well
There are like 3-4 different forks and I have no idea what stuff is good and what is wortless
Took me a bit as I had to remember all this from when I compiled OFS the first time. I had to apply most of that fork by Deity in order for OFS to be functional on Debian 13. Thereās not many changes in it. The only one thatās NOT required is the bug with the audio waveform visualizer but it should be included if it doesnāt affect windows or macOS. I use that wave form allot. The main issue here is this patch needs to be tested on other platforms. Its been working fine on debian 13. The last released AppImage broke for me when upgrading from 12 to 13 and I found that branch that fixed my issues. I recently bought an m4 mac. I may be able to test it there but Iām not promising anything and Iām trying to get rid of windows out of my life as much as I can.
So the fixes in that branch thats needed are:
- The wave form bug
- When launching OFS on Debian 13, multiple windows show up and just doesnt work very well if at all. Changes in that branch resolved that.
- Thereās a couple changes including a patch to one of the 3rd party libraries for what I think is an older version of c++ but im not sure. I could not build with out this patch and change to one file.
After going through all that again, I got your fork building on my system and I exported one of the existing MFS scripts as 2.0. Like I said above I had to patch XTP to get it to run but after that things seemed good.
I keep downloading the single file only to get the old format. There a hold up somewhere? Thought we was ready to deploy.
Have you tried pressing the question mark
Thatās not convoluted at all. One would assume the latest is default and roll back is optional.
Ah, you mean changing the default
No, didnāt do it yet
Might be a good idea to make the default be no merging with a banner asking users if they want the scripts to be merged for easier downloads etc. And with format selection in form of radio button list instead of dropdown list. This gives them a chance to choose the correct format for the software they use.
Having merging by default can be confusing when the downloaded script suddenly is not multiaxis because they use unsupported software.
I will make a banner for the first download then
..Also I need a banner for the Jesus group as most of people didnāt have the required choice on acc creation
The sfma format should load in any funscript software. Backwards compatibility was key right? This way, it doesnt matter if they download the sfma script or the stand alone single axis, it should work in all funscript players.
Adding clicks to a process is usually not a good idea. For ux, you want to reduce clicks where possible. Why not have ALL the links in the same place? If cleanly labeled, this shouldnāt cause an issue. This way I see the all links at a glance and only 1 click away to each.
I donāt see a reason to keep 1.0 around as fewer players support it. If absolutely needed, it can be hidden in more options or something. You want the majority of the users to experience the least amount of clicks and other general annoyance as possible.