I have no file/open existing option in OFS 2.0 was this feature removed? I see in the tutorial for 1.1.5 that its there. EDIT: I found it.
Guys, I canāt import in OFS a created script into another application.
If you look inside the file, everything seems fine, but it gives an error on import.
VRHush_From_The_Vault_Dani_Daniels.pitch.funscript (599.3 KB)
Project->Addā¦->Add existing
You canāt import it by itself. It requires a video.
In this case it would look for a video named VRHush_From_The_Vault_Dani_Daniels.pitch
1 Like
Thank you - it worked.
But how do you interpret the pitch roll, where the yaw and XY movements are?
Itās all relative to the device which has to playback the script.
Multi-axis players translate funscripts into TCode and it is specified like this.
I think this is how the channels are mapped.
L0: stroke
L1: surge
L2: sway
L3: suck, valve
R0: twist
R1: roll
R2: pitch
V0: vib
V1: pump
TCode is also relative to the device which interprets it.
1 Like
I understand correctly that there is a multi-axis device, your editor has the ability to create such scripts. But no one knows how it works. Okay - weāll figure it out 
thank you very much!
It would be nice if OpenFunscripter was able to access Scripts by discluding ā_i-framesā. So you can drag the i-frames Version and it will detect the fitting Script that matches the Name but not the ā_i-framesā at the end. I always check every Script i download with an i-frame Version of the Video to see if its accurate. ( Most of the time i need to move it 1 frame to the right. )
Currenty its like always rename the script with i-frames at the end, change the Script and then renaming it again by deleting the i-frames which gets a bit tideous.
Also Iād like to know if i can disable that OFS creates a new Project-file when i export the script ?
Iām not going to add any name hacks like that.
However using āExportā¦->Export active scriptā wonāt create a project file as well as giving you the opportunity to remove the ā_i-framesā from the filename.
I can remove the project saving from the āQuick exportā.
Thereās another thing you can do.
Donāt change the name open the script + regular video.
And then go āProject->Pick different mediaā pick the āi-frameā version of the video.
Looking at the code I see that āPick different mediaā also causes an implicit project save.
Maybe I should do a full sweep and get rid of all implicit project saving. 
1 Like
why not add name hacks like that ? I feel like it would be easy to implement and help everyone quite a bit since everyone works with i-frames version but uses a non i-frames as the final video. And Iād prefer if it doesnt autosave on quick export.
Hi,
Is there a way to output the position data in āreal timeā on the handy, or at least to test portions of the script without exporting and opening the video and script via an external player?
The best would be to have the mouse tracking or the 2d simulator drive the handy live.
If we could script and test at the same time, even if itās a bit out of sync, it would be more fun.
Maybe itās possible to do it with bluetooth via buttplug.io
2 Likes
I just updated after putting it off for months - one thing I noticed is that the look of the heatmaps has changed a bit between my old copy and the new version - they seem blurrier and less clear. What is the cause of this difference?
before:
after:
1 Like
I dialed the detail back because of performance concerns.
Iām not happy with the current implementation of the heatmap.
But I also havenāt heard any complaints (until now) despite it being so bad. 
It is possible to have a highly detailed one if I put some extra work into it to make it efficient.
I could add this to the ever increasing backlog.
1 Like
The main parts that i think would matter on the heatmap is a transition from a low to high speed area. And when the activity starts stops. In most cases i will use the more accurate view (which you work in) anyway as that not only shows speed, but also position.
Still, some idea for optimizing:
Put the video into chunks which you then render (ie. each minute, or 30 seconds. you can even decide this based on total length). Each chunk then can be worth for example 50 pixels in rendering (lets say 50 integers of color). On long videos you can even decide that instead of 50 pixels, only 40 or 25 will be enough.
When no editing takes place, this chunk doesnt need any recalculating. Only the part you edited will need a refresh, which on that will have a static time. Especialy on long videos, this means a lot of chunks wont need a refresh.
Upon editing the chunk (and maybe its surroundings) can be updated to fully reflect the changes.
Only in the end with the final render, you can read those chunks, and place them after each other. As the values are cached, this should remain relatively fast. It takes a bit more RAM for this, but its not like this is going to be an issue (as we cache the values, not the image).
1 Like
I added an issue #52 so it can be tracked.
I donāt lack imagination when it comes to solving this 
Just time 
2 Likes
thank you! Itās definitely low priority - I love the aesthetic of the high detailed ones and itās a definitely a nice benefit for people looking for at an at a glance idea of the script. Regardless I look forward to whatever fix eventually comes 
It would be nice if the heat map would also show the position range (similar to funscript.io), but I do not know if that would be difficult to add.
@quickfix Well Iām not sure if everyone would agree.
I was wondering if this is desirable.
Personally I think it looks crap but looks are not everything.
It does manage to convey more information.
Iām open for it but I would hate to put work into this and then have people tell they want the old one back.
Having multiple types of heatmaps that you can choose from is not something I want to support.
Given that the handy does support bluetooth these days.
I think buttplug integration would be interesting.
I donāt think the details of the heatmap make big difference, nor does it tell the whole story. I recently dl a script that had a few red sections that didnāt seem to match up what was on the video. After loading the script in to OFS I found that the red sections were vibrations, and not fast strokes.
1 Like
That is fully understandible. The heatmap as show while scripting works totally fine for me. I think I should be able to write a script that creates the āuglyā heatmap directly from the funscript file.
Hi, Iām working on my fist script and itās not behaving the way I would expect. Iām testing it with a vibrator toy (not a stroker). There are some points where nothing is happening and so I set the script value to 0. But when I run the script I still get vibration during those parts. Is there a setting I need to change? Thanks!