EroScripts is a community for scripts that sync interactive sex toys with porn. Learn more.
To find and download scripts, create an account.
I’ll do my best to explain this, forgive me if I use the wrong terminology. Don’t worry, I have picture aids.
When scripting a motion like this:
Is it better to script in a PAUSE
Or script in a slight BEND to slow the speed
I’m sure a lot of the boils down to personal preference, was just wondering what the communities thoughts and opinions were.
Cheers fellas 
I’m no expert and am pretty basic with my scripting skills but I generally just do pauses…I had no idea you could do a bend in there…maybe try it with both and see how you like it/poll people and see how they like it on the forum?
When I script something like this where her mouth reaches the top of the head I mark it as a 10 on the number scale and when she reaches the corona I mark it as 9 so it will be one fluid down stroke but the speed changes based on how fast she reaches the corona. Now you can substitute 10 for a 9 or 8 if you don’t want the machine to go that high of course. I think it’s safe to say that the more points you put in the more accurate your script will be, but if you want to script faster I would recommend trying the method I use and the program kind of does the rest. It sort of sling shots all the way up and all the way down and has some give as the stroke goes back up. I hope I explained that well enough.
First off you need to know what your device capabilities are.
If you’re using a commercial device (launch/keon/handy) then the EACH POINT will feel like a little jerky motion. You can’t script curves, a curve is an infinity of points, working out the most efficient way of scripting a curve is a holy cow of scripting.
The device firmware will need special coding in order to increase smoothing of curves, at present for the launch (what i script for) its a straight vector until the velocity changes, and each change has a microdelay as the device works out what the next section’s going to be.
Leads to microstutters…
So best of to stick to either pauses, or (what I prefer) pick the top point of your arc and extend the stroke to that point and ignore the velocity changes on either side. Its not perfect but the end feel is, I think, the best you’re going to get.
Yeah I used to add more velocity points in to increase accuracy, but I’ve found in practice that it just introduces more jerkiness into the script when it’s played back on-device.
I think as few points as possible (while maintaining cadence accuracy) is the ideal - the brain fills in those little details when the script is actually being uh…enjoyed. 
Better firmware could solve this issue, but I suppose we should be making scripts that can be enjoyed on as wide a variety of devices as possible.
For this specific example I would just script the apex at the top and then continue to the bottom of the stroke (so maybe points 10-3 or a 10-2 as opposed to going 10-9-2)
From my experience scripting I find that you’ll want to use as few points as possible to maintain a smooth motion. As mentioned in other posts: more points can introduce some jerk or stutter into the motion. There are times where herky-jerky works (and I’ll occasionally use it for effect), but just from a lot of scripting experience (and trying everything under the sun) I generally find the smoother motions less distracting in use. As you mentioned yourself, it does boil down to personal preference at the end of the day (make these scripts for yourself and hopefully others will enjoy them too). IMO, play around with it a bit and see which one you prefer.
For example, this is a link to a BJ script I made several years ago where I tried to match trajectory due to the slow speed + Launch’s limited capabilities handling slow speed. So if a stroke lasts 2 seconds, the first second would be 10-5 where point number 2 would go down to 0 instead of just one long 10-0 stroke. While I think it’s still enjoyable, it doesn’t quite work the way I intended it (though some of this may be due to me miscalculating the script points a bit). Since there are other more capable machines out there now, I’ve thought about going back and redoing this one with slower strokes.
Thanks for the input fellas, going to dedicate a night to research and development on this. I totally agree on less point to keep the smoothness, I have a few scripts that are not synced and don’t have a lot of small change-ups. Lately I found that I enjoy those more than the synced scripts.
I’m thinking this will be my next script and I will implement what was discussed on this topic, cheers fellas
https://www.pornhub.com/view_video.php?viewkey=ph60199d7ec31ad
I’ve done a bunch of testing of this too and there’s definitely a limit. in these cases where there’s a smooth motion but with a changing speed I’ve found its best to try match the fastest speed. in your clip she seems to be going faster as she goes down than when she goes up. even though if you script from the very last frame she stops moving up/down they may be the same distance and end up with a script that has the same speed up and down. so adjusting the points slightly so it doesn’t match the exact frame, but matches the speed on the way down better then it should feel more accurate.
The exception I’ve found to this is with very slow speeds or with very large changes in speed where the change in speed is supposed to be highlighted. Like to simulate resistance or tightness. It still results in a judder from the toy as the speed changes but that adds to the effect rather than ruins the smooth motion.
One example from one of my scripts,
that section at the start, where there’s a quick movement, then it slows a lot but still continues, and then suddenly goes fast again.
or this one, where there is a whole bunch of different moments where it is drastically slowing down at the bottom of the moment at a moment when she is reacting and then bottoms out at another moment when she is reacting. These scenes they are actually just touching themselves, so there’s no penetration but the reaction is what sells it as if they are tightening up or reacting to “you” changing speed, changing direction. If a scene was filmed like that then this sort of scripting with speed changes would work. So some edging videos possibly have such a drastic slow down of movement in hj/bj scenes, but if its a subtle change of speed you’re better off like i said, trying to match the fastest movement.
You also have to factor in the way application smooth out the points. Like in openfunscripter most software now seems to project a quadratic or cosine curve through the points, with that method in picture one those changes of speed points can have the opposite effect. i think even though the OFS is doing a sort of point to point calculation for the speed that it give on the side panel and represents with the colour of the line. the actual curve might be very different. If you look at the middle section on your first photo the white section at the top would ideally be a smooth shallow curve up to the very top and only reach the very top right on the second point. but projecting a curve and it just peaks right up to the top within the first couple of frames, flat lines for the next dozen frames and actually looks like the movement of those first few frames is actually faster then the curve before it even though its white.
I think ideally vectors could be used in scripting to get smoothly changing rates of speed, but like one of the other guys mentioned its also hardware and firmware limitations. Like the handy needs a 100ms gap between commands. Ideally with vectors you wouldn’t need to send more commands than a top and bottom point but the hardware would have to be capable of taking vector commands and converting them to very high rates of variable speeds
Now that is some community shit right there boy! Once again thanks for the info fellas
I have real fast strokes in all of my scripted work. I know long really fast strokes are not comfortable with my OSR so it is likely they will have issues with other machines as well, so I usually shorten these strokes. No matter how I input real fast strokes I always have slight differences in the timing of one stroke to the next and sometimes the actor makes variations. Variable and fast stroke timing causes my OSR to shake or jerk so when a section is fast I equalize all the stroke lengths in the area. With fast strokes you cannot really tell if they are dead on or not as long as none are missing or there are no extras. Rhythmic strokes feel better to me.
This has been informative, I’ve been wondering how to make my scripts more accessible to other toys, since I only test on the Handy, and certain things I do on my scripts seems to get the effect I want for myself, but may result in stutters and jerks in other toys.
Will review and sort out my scripting style to see if there are more areas of improvements.
Thanks for all the viewpoints, has helped out alot!