How I fixed the problem with programming skill:
3 Likes
Meme lord hits again
v1.3
- Added distance meter. Toggle using D.
- Added line visualisation. Toggle using L.
- Added tongue model. Toggle using T.
2 Likes
v1.4 - Accept “.raw” script as MainStroke
Now if you load a .raw script into your OFS project it will be used as the L0 (up-down) for the 3D model.
The only reason I’m using .raw is because it’s included as a shortcut in OFS’s “add…” menu and can be quickly added alongside other axes.
As a result of this change does that mean it only move L0 if the script is marked at .raw or is it just meant as an alternative to make it clear that it’s the L0 script?
Also I do find the .raw to be not what I would want it to be named by default…I see no reason to have it just be more like .main if needs be instead of just have nothing as that makes it easily transferable between multi-axis and single devices.
Finally with the distance meter is it based on how much distance the L0 has on it or something else? As that’s not made clear to myself as to tell if numbers beyond 100% mean that slipping out is certain or just that it’s longer than normal.
PS I suggest adding to the read me how to get it working with OFS as I was confused till I saw the post saying how on another topic although it didn’t mention that v3+ only worked. (Yes that meant I had an v2)
If there’s no .raw script, the unnamed script is used as L0.
If you add a .raw script to OFS, that script will be used to animate L0 instead of the unnamed script (it has higher priority).
This could be convenient in situations where you need different versions of L0, for example, you can script for OSR2/SR6 on .raw where it will be visualised on the model alongside other axis, and script for the Handy / SSR1 on the unnamed script where you can use the 2D simulator for reference.
I actually don’t know what the .raw suffix is for. It just exists in OFS’s shortcut menu and I was just trying to to make some use of it.
It’s based on the distance between the bottom of the cylinder and the theoretically penis base. For more info see this topic: Measuring Penis Length In OFS's Simulator3D
I’ve never used this feature after I’ve implemented it. It’s pretty much a meme response to someone’s yaps on the need for trigonometry during scripting.
If slipping out due to angled receiver is a concern one should consider using the “smart limiter” feature in MFP.
Interesting…I plugged in my 3 scripts (baseline, half, full speed versions) and had only one active yet no movement occurred, none of them had .raw or anything. Movement only occurred when I did add a .raw and copy the points over to it.
Same here as the only answer I know of is in relation to AI generated stuff where this answer was given about it:
Ah I see, I think it will be useful for novices such as myself till we get an rough idea/feeling of doing multi-axis though yep…if the user is slipping out then their first port of call should be the limitations they set on MFP.
That’s odd. Try to open the video in OFS alongside a unnamed funscript (eg. video.mp4 with video.funscript), see if it works that way.
Then, if you add video.raw.funscript, it should prioritise the raw script instead.
Okay I think I figured out what caused it to not work or at least the trigger since I restarted OFS, added media and then the script I had made in the past (not yet deleting the pre-generated blank script track) and the mod worked fine. Then when I deleted/removed the pre-generated blank script track it just stopped.
The script that I added didn’t match the media’s name via having it being marked as the “full speed version”.
I did attempt to add back in the pre-generated blank script track via doing “add new” option but nope, stayed broken till I used the “add shortcuts raw” and copied the points over to that one.
1 Like
FYI, since it appears various programs are now using “.raw” as L0 axis for some reason, my multi-axis script output now uses naming “.tracking” instead of “.raw” for the tracking axis name to avoid this being mistakenly used as L0 by other programs.
I felt responsible for this, apologies for the mess.
About MFP priotising “.raw”, that was my suggestion. There is some story to it which I won’t cover here. I think it’s fair to default to the unnamed script as L0 and not priotising “.raw”.
About the behavior with my Simulator3D fork, I’m still thinking where it should go. The reason for using “.raw” is just because it is the only axis left in the shortcut that is undefined, so I found it easier to use.
1 Like
Yes, the distance meter shows more than 100% means that it is about to slide out, especially in the blowjob because the blowjob is at a higher position. If you want to test, set a higher value in *.funscript, such as 80, 90, and then set 100 in *.pitch.funscript, and observe carefully. You will find the reason.
Raw, in my understanding, is unprocessed data, such as the data I get through motion tracking or AI tools. Usually the points in raw are very dense. Dense points are difficult to use on all devices. It would be better to read *.funscript by default. Raw data can be used to observe speed changes and make references for creating *.funscript.
First of all thx a lot for the fix.
I saw the problem with surge and sway when i started scripting, but I don’t get godot running on my machine and i can’t figure out why.
I have a request and maybe someone will fix it for me and can then send me a stand alone .exe of it. Here is the request:
The angles of the visualisation is to big for the SR6 (for.ex. the roll is shown as 45 degree but in reality the machine only makes 30 degree max. I measured the real angles of the SR6 Movements:
up/down: -6cm to +6cm
left/right:-4cm to +4cm
forward/backward: -3cm to +3cm
pitch: -35° to +35°
roll: -30° to +30°
twist: -80°to +80°
Is there someone who would fix that for me?
1 Like
I don’t have a capable PC to do this atm but I think it should be as easy as changing these lines in Simulator3D.cs.
I too felt that the simulator weren’t as accurate. Might have to calibrate it with an actual SR6 one day.
I just gave it another try and i got it running… I had the wrong godot version …
The values I posted for pitch, roll and twist are looking fine now.
Thanks Falafel. If I should measure some SR6 movements for you feel free to ask.
1 Like
If your measurements are correct, apply the following code in Simulator3D.cs, starting line 250.
strokerMesh.GlobalRotate(Vector3.Right,
Mathf.Deg2Rad(
Mathf.Lerp(35.0f, -35.0f, pitch)
)
);
strokerMesh.GlobalRotate(Vector3.Forward,
Mathf.Deg2Rad(
Mathf.Lerp(-30.0f, 30.0f, roll)
)
);
strokerMesh.RotateObjectLocal(Vector3.Up,
Mathf.Deg2Rad(
Mathf.Lerp(-120.0f, 120.0f, twist)
)
);
strokerMesh.Translation = new Vector3(
Mathf.Lerp(0.667f, -0.667f, sway),
Mathf.Lerp(-1.0f, 1.0f, mainStroke),
Mathf.Lerp(0.5f, -0.5f, surge)
);
}
}
About the twist, it varies according to the servo.
I measured mine but got different results.
up/down: -6cm to +6cm (12cm)
left/right: -4cm to +4cm (8cm)
forward/backward: +2.75cm to +2.75cm (5.5cm)
pitch: -28.5° to +28.5° (57°)
roll: -19° to 19° (28°)
Mine is the customized SR6 with metal bearing arms from FunOSR.
@Tempest May I ask what’s the roll and pitch range for a default SR6? Is it the same as the OSR2+?