The original OFS Simulator3D mixed up the surge and sway animation. So if you have been making SR6 scripts to it, you’ve likely have the two axis mixed up. This fork aims to address that issue.
Fixed surge and sway being animated incorrectly
Did some cosmetic changes to the model and UI.
– Reduced window outline’s alpha value.
– Colored one of the cubes purple for better twist visualization.
– Added proximity fade to the cylinder.
I am planning to send you a version that fixes the problem, but you have already solved the problem yourself. It seems that you also know some programming skills.
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.
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.
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.
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.
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°
