Basically, it visualises the actual distance between the entrance of the sleeve and the base of the penis. Color changes to purple when the distance exceeds the vertical stroke length of the device, warning against potential hazard where the user disconnects.
Hopefully this saves you a few brain cells from having to do trigonometry during scripting.
Let me know if you think this will be a useful feature to have in the simulator, and if the UI elements could be better presented.
And sorry for the clickbait title. That’s not the intended usage of this feature.
This was exactly was I was talking about with another person, there is no “safety” structure for “accidents” with OSFS when it comes to scripting for a OSR2 device. Otherwise I just go in raw with testing
Any qol feature like this is greatly appreciated. Only comment on execution would be better clarity on the readout since it’s white on white atm for lower values.
The rotation point is only about an inch from the base of the case. Visually this is showing a middle point rotation with a lot more offset due to rotation than reality. Is the math correct?
True, but isn’t this a very per user specific scenario anyways? I always had the feeling, that each had to adjust their axis limits to their length anyways.
What would be good though, when OFS or better MFP had an option, so that when there is L0 up combined with Roll/Pitch for example, it would adjust the resulting height to match the expected height from just L0. This would be the only feasable approach imo and would also make the scripts univerally compatible.
Anyways, great job @Falafel this surely might help when scripting!
True, I’d say it is mostly user specific settings, but I feel like it would help with hardware limitations as well. Overall It would help with “weird angles” to not snap the cucumber.
I’m sure it does! Your tool is amazing, but honestly, I didn’t spent too much time yet with axis linking besides adding additional movement. But I will look into those!
@Falafel Thanks for that! Will try it out the next time I’m getting to scripting <3
Thanks @Falafel for this fork and the corrections and additions you’ve made. It helps immensely.
I came across another possible improvement: If the timestamp of an action is not exactly at a video frame, it seems that in the first fraction of a second it interpolates and shows the correct position only to then show the value at the frame afterwards. While the OFS-internal simulator shows the correct position. So small imprecision (or too much precision if using frame-rate override) or the loading of an alternate video file can lead to wrong readings.
Edit: I’ve made a short gif to show, what I mean. After skipping to the point at 95 (statistics-tab is open to verify), the initial length shown is the correct 95. But it then jumps to the value of the next point in the pitch axis, which is smaller than 95 (which shouldn’t be possible from a geometric perspective).
Now I’m not sure as to whether this problem stems from OFS internally and I’m not familiar with all the details of the API, but from what I gather from some of the code in the class definition (Funscript.cs) and Simulator3D.cs, it is possible to access the data of all actions of a funscript as well as the timestamp of the player. So, as long as those values don’t change unexpectedly, theoretically, there should be a possiblity to correct that. Unfortunately I haven’t figured out, what part of the code is responsible for that change. Everything I’ve had a look at looks correct to me, unexpected input behavior notwithstanding. Maybe you have a better idea on where to look further.
I’m pretty sure it has smth to do with OFS’s websocket API. When I try to hook up an OSR with it I got similar issues. I don’t know how to fix this unfortunately.
