Funnily enough @FootFanatic514 is an irl friend of mine and I have introduced him into scripting - I have seen all his scripts before he published them and I gave critique on them lol - I understand what you’re saying and I definitely am confident enough to do more than 4 axis, the main question though is is it worth doing scripts for SR6 (especially since i personally own an osr2+ with twist) when 2 of the axis have to be different (see the comment above) for SR6 or should I just stick to OSR2+ (with twist as it doesnt interfere with SR6 nor OSR2+) which you can use both on OSR2+ as well as SR6? This will depend mainly on what the majority of users have - if the majority has the SR6 I might consider scripting for the SR6 with twist and literally sending it to the person you put a link for for testing (since i dont own an sr6 myself) and maybe building the SR6 down the line (but not rn due to 3 more servo servo cost) or should I just do it for the OSR2 if the majority has it.
Fair point on that one - the servos I currently have are pretty loud anyway and adding twist only increases the overall loudness by about 2 decibels which isn’t much - but in general it is pretty loud, the twist itself is a minor issue in my opinion as it’s as you mentioned - it is rarely used apart from what ive seen in a couple of handjob scenarios / blowjobs, other than that it is pretty useless - it is more of a question of seeing if people have the SR6 or OSR2 - whichever one it ends up on I will definitely add twist anyway since it only takes up an hour or so more (max) and it can add some immersion in some scenes and it is something that you can use on both machines - unlike a pitch + roll / surge + sway + twist + roll scenario which is different inputs for both machines
Basically what I’m getting to is this:
If lets say a girl is riding a toy and she is towards the left but leaning to the right, for OSR2 / OSR2+ I would go:
Roll to the right - to simulate her body leaning towards the right
With an SR6 I would go:
Sway to the left (as the body is to the left) with a more minor roll to the right so your “member” doesn’t slip out (its a simplified example) - you can use an OSR2 script on the SR6 with no issue, but the SR6 script won’t be as good on the OSR2 as it’s correlated to 2 other axis that I am scripting to - hence why the vote, what does the majority of users have so I know which device I could focus on. I would love to do it for the handy, osr2+ as well as the SR6 but I am in the end doing it for free just to contribute and I definitely don’t have enough free time to do each script for every device possible 
Honestly I’ve never had this concern before… I’ve always thought a set of multi-axis scripts should be compatible with both model, so that loading an SR6 script to the OSR2+ shouldn’t feel too off despite missing sway and surge (which unfortunately is a hardware limitation).
The way I work with my script is to script roll and pitch first, then add in sway and surge. There’s usually a correlation between sway and roll, surge and pitch, so it’ll be pretty easy to derive them from existing scripts. Adjust accordingly when the pattern changes.
I do notice that the SR6 might “overshoot” on the roll and pitch and that it might be better to reduce the range of motion on these two axes for it. I prefer to do this in the player software instead of making changes inside the script, so that the scripts won’t feel reduced on the OSR2+.
Yeah that is a fair and valid way of doing it - I guess I’m just trying too hard to “min-max” it by trying to make sure the user has to do the least work possible to make the script as accessible as possible.
I might consider this approach myself in the end if we end up with a 50/50 poll (± 15%) which is what we’re currently are at - which I’m not going to lie surprised me, I did not know so many people actually have the sr6 in comparison to osr2.
If this is what we end up with in the end I might end up saving some money for 3 more servos and upgrade as I don’t feel comfortable posting scripts that haven’t been tested before (user safety and comfort is number 1 priority). Thanks for your input 
Another reason for overshooting is that the length you observe is not the real length. Once there is an angle, what we see is the hypotenuse, so please shorten the up&down length appropriately to avoid danger to the user.
Many users don’t know how to limit output, so don’t be too exaggerated when setting roll and pitch points, and try to be as reasonable as possible.
Sure, the scripts should be kept at a reasonable range. I’ve never said you should exaggerate the motions as much as possible and leave everything to the user.
However, I’d rather encourage the user to learn how to limit output via some simple sliders, than teaching them how to open up the script in OFS and extend the range using MyTools plugin because what I’ve scripted isn’t enough.
The reasonable range I am referring to is very specific. For example, if pitch and roll reach an angle of 30 degrees, the maximum height of up&down cannot exceed 80, otherwise it will overshoot.
Hey, out of the same concern I tried to implement such a thing to the simulator which simulates a penis. I dropped it halfway as I couldn’t find a good way to animate the model.
Now you mentioned that, I think a “ruler” measuring the distance between the bottom of the model and the base of the penis would be enough for reference.
But - we’re going off topic now. OP’s concern is whether the same set of scripts can be used for both the SR6 and OSR2+, or they each require a different set tailored just for them.
The scale setting guide I made unifies SR6 and OSR2+. The premise is that the setting point and video must be 1:1. It is for reference only.
So SR6 doesn’t calculate the hypotenuse? I kept thinking about adding this to the math for Blender, but I only use this mode in forward/backward movements - since I try to specify the real aplitude for the single-axis script.
The pitch and roll angle designs of SR6 and OSR2+ are the same, both are 60 degrees, half of which is 30 degrees. However, the maximum stroke of SR6 is only 120mm, while the OSR2+ is 136mm.
I have post a pm to you about the angle and distance
I know what hypotenuse is, I just thought it was an SR6 concern and didn’t recalculate the Z movements when writing the multi-axis script.
For example we have Z movement 0-100, I add X rotation by 30 degrees, so 100 turns into Z 80 and Y 60 mathematically. But I don’t do this in the scripts, because I thought that the calculations are on the SR6 side. I write in the script Z 100/Y60 unit, X 30 degree (approximately - just so I write to explain my question).
Just confirm - I will redo the script math and release updated versions.
Example of movements taking into account the length of the vector (which is the Z movement).
“For example we have Z movement 0-100, I add X rotation by 30 degrees, so 100 turns into Z 80 and Y 60 mathematically”
In my experience you should do this. SR6 itself does not handle this automatically.
This seems to be affected by firmware. Which one are you using?
Tempest:
On stroke lengths, for reference the stroke length of the OSR2 is actually 112mm, although it is possible to make it longer with minimal changes to the firmware. The SR6 is designed to a stroke length of 120mm.
In the construction document of OSR2, it is stated that it is 136mm. In addition, I measured it with a ruler and it is indeed 136mm.
You can write scripts according to the video 1:1 and then set different Scale values for OSR2+ and SR6 to get a consistent experience. This is my experience.
Some running Khrull’s firmware (TCode ESP32) and reported 150mm. I’ll check again when I got back my OSR2+. But if it’s 136mm by default I think we could stick to that as a standard.
Yes, the original intention when funscript was created was to hope that the script creator would use precise proportional values to describe the actions in the video. For the device of different max stroke length, you can have a unified experience by setting the “scale”