EroScripts is a community for scripts that sync interactive sex toys with porn. Learn more.
To find and download scripts, create an account.
I think what someonerandom meant is that the scripter will be able to define the shape of the curve used for the next movement.
For example at time 0, it gets pos +70, and a value that indicates the shape of the curve from time 0 to 1000.
At time 1000 it gets -70, and a indicator for the curve used between 1000 and 2000.
So there’s no need for the programme to deduce a curve itself. It’s just following the immediate command it received from the script.
Right, protocols like T-Code would have to be extended for device based interpolation. Now it’s only “move to pos x in time interval y”, you’d have to at least add the slope at the end of the interval (for a first approximation. With ease in / ease out, the slope at an intermediate point will be higher than with a linear motion).
Script players already must lookahead to the next point (in the example: at 0, the pos at 1000 already must be available to know at what speed to move to the next point. It would be easy to read two or three points ahead, and fit a smooth line through these points. When the script is static (read from a file) it can be done without introducing latency. I understand OSR2/SR6 are already doing this.
Sure, it’s easy from the file / for the player. Spline interpolation should be fine for easing, as it does not overshoot.
I just wanted to mention that interpolation can’t be done by a device as long as it, point by point, only gets the next position to move to.
i havent made many scripts but i just use the tracking addon to track movement for perfect tracking on movement because im lazy.
From an end user perspective, interpolating to simplify point-heavy scripts is a big painpoint for me. Some scripters’ style is to have a ton of points, and some scripting tools also just generate points at fixed intervals. My launch is not great at handling this.
I’ve tried using FunExpander to manually simplify scripts, but it does not consistently give good results. It can lead to missing strokes and jumpiness.
I don’t see why funscript files or similar couldn’t contain more complex curve data instead of just points, and then be able to simplify them down to something the end user’s toy can handle.
Shout out to scripters who also make a simplified version of their point-heavy scripts
Obviously it depends on how the device handles thing, if the device receives commands ahead in time (the handy does as far as i know), then it can do these calculations runtime as it knows when they become relevant. Bluetooth obviously wont be capable of doing this. But any device that can cache info and sync the timer and has a fast enough processor in it can do these things.
Note that calculating a curvature doesnt realy need that much info. For audio they only need double the Hz to make the audio resolve properly with quite some complexity. Sure, scripting does require a bit diffirent handling (audio doesnt require the point to be at its peak for example), but its not like it will need an entire script here, probably using just 5 points (2 ahead and 2 behind of the point you want to calculate) it can already interpolate things accurately on the fly (the 2 behind are there to consider the actual current position and adjust things if needed). And that means just 4 points ahead is technicaly already enough.
But the main issue is in its details, making everything smooth isnt always desired. Quick movement changes in otherwise slow paced action might end up distorted, while the uninterpolated script might have done this more accurately. Sure, this can be handled by using nodes at proper locations (a sharp peak can be created), but guiding the device here by simply stating it must be sharp saves some guessing effort (which still is calculation time).
So these things are very well capable to be done within the device. But again, its mostly about standardizing this, since when every device does it diffirent, it makes scripting unreliable.
Well, quick movement changes require high power and cause high forces and wear. So the motor control will inherently smoothen the curve. The knowledge of how to approach a point (with high speed, continuing in the same direction afterwards, or stopping in order to reverse direction) can only help the motor control to make the motion more accurate.
Sure, some few points ahead would be sufficient, but this requires changes in protocols that rely on the time a command / point is being sent. Just some short latency compensation does not help, as it won’t always cover the next few points.
When Raser1 was developing Joy-Funplayer one big item was the ability to program with a mouse “on the fly” which creates “raw script data” with a large file. It is very smooth with all the points it creates.
There are several interpolation methods. For an example look at the Ver 4 of this player and you will see the choice of Linear, raw, cubic, or cosine based interpolations. You can test what each does with different funscripts.
Thanks for the input, I think I should definitely look into that software more.
I have made one script with an incredible amount of action points before. It was generated with the motion tracking funscript generator. So I believe it’s possible to create silky smooth curves by adding more points.
However what I’m concerned about is the compatibility of these scripts. I’ve ran the script on the Handy (via wifi) and it went like a seizure. If devices like the Launch couldn’t handle the action-rich script we posted on this site, I doubt they can handle anything beyond…
When raser1 was talking about developing a new script format (like 2 years ago) I suggested adding tangent information to script points. That way you could use tangent handles in scripter software to create really accurate motions without having to add multiple points. I think the consensus was that it would be unnecessary and it would make scripting longer. It would also not work on most devices.
MFP wont mind if the script is already interpolation, it will just unnecessarily do some math but it will work fine.
Yea I suggested that a long time ago. The player would calculate tangents using multiple points on its side and then it would just send next point and next tangent for interpolation on OSR.
Next thing that I would add would be a command buffer in the firmware, this would require the firmware communication to be two way. OSR would send a request for a chunk of next commands to the player each time it is about to finish the last chunk, for example 1-2 seconds.
This way there would be no stuttering at all caused by player/OSR trying to synchronize the next script command, currently the player has to send a move command and time it just right to send the next one when it finishes on the firmware. Inaccuracies in this timing can cause micro stutters.
Personally, I think this stuff all comes up because robotics is really hard. If the devices cost 10x as much and we had top-of-the-line actuators and everything, then we’d be far closer to ‘the stroker moves exactly where the script says’. But in reality, there’s lots of slop, latency, inaccuracy, etc. The firmware is designed to do its best to create smooth, continuous motions around the hardware’s limitations, but that design is based on what ‘normal’ scripts look like. That is, a script is kind of an abstracted guide to what the stroker should do, rather than an explicit ‘you should be at this exact position at this exact time’.
So when we add tons of extra actions to try to ‘override’ what the firmware does to smooth things out, it just gets confused and we get jerky, inaccurate motions. I think the best thing to do is to keep scripts simple and accurate, and let the firmware do its job. It also means that our scripts are more likely to work with more kinds of devices, including devices that haven’t been invented yet 
I don’t think bidirectional communication is needed for this. It should be sufficient to transmit some commands ahead, a number enough to cover transmit delays but known to not exceed the devices buffer.
Synchronization can be done by adding two types of timestamps:
This way, the device firmware can synchronize it’s internal clock to the current time, ignoring or averaging out timestamps from delayed packets, and knows exactly when to execute the next command. Some additional “flush buffer” command could help when skipping or switching between scripts.
I think that’s a good mentality to have when making scripts. Thanks for your input.
In the case for the Handy, it doesn’t have a smoothing algorithm in its firmware (it feels “blunt” when changing direction). However is well capable of reflecting those manually interpolated points. I’ll keep adding them for that reason, but also makes a simple script for wider compatibility.
There’s perhaps some misunderstanding that needs to be cleared up, though. The interpolation I was talking about is not an overall optimization to the entire script (because smooth has many advantage, I guess?). It was done to emphasize the character of this particular motion, which ease-in and ease-out at both ends of a stroke.
Here’s another example, in which the strokes has a specific character to be dealt with:
Should we make a “simple” script that looked like this, and leave the rest to the firmware -
The firmware, which interpolates all actions based on a singular algorithm, will, probably, turn it into something like this. Which is not the correct dynamic for strong thrusts shown in the video.
(oh geez that’s a horribe choice of scene… Just imagine it’s a hot porn star smashing their hips on you okay???)
So in the end, even if the firmware is capable of interpolate between actions, it needs the script’s command to select the type of function appropriate to the scene. Scripters will be involved in the process, until the machine learns how to watch porn.
Another example where manual smoothing is needed is when you want the pitch and roll to make a circular rotation like grinding. You wil need sine waves for pitch and roll, 90 degrees out of sync. The result with simple funscript without manual interpolation is a jerky, not round, motion. Each interpolation algorithm provided in the firmware or software will make the motion different.
Oh yeah totally - I more meant that like, adding too much detail might add information that works against the way the motor controllers and stuff are designed to work. So in your example with the banana-beatdown, I’d definitely script it in the simpler way.
The more detailed one looks much better in the simulator, but the simulator is able to respond instantly and perfectly. The actual motor has weight and momentum and friction and stuff.
idk maybe people have had different experiences to me, but whenever I’ve tried to add those ‘smoothing’ actions into my funscript, I’ve noticed the Handy kind of stuttering at that point as the motor attempts to slow down the slider to match the more detailed script movements.
If my Handy wasn’t busted, I’d make a bunch of test scripts and record them with my phone camera’s slow-motion mode to see what the optimal rate is 
That high power is obviously something that the device can compensate for if the script requires excessive values. Again, if the device does the calculations of those curves, this can just be part of that. It can even use some extra logic to detect when a curve can no longer be followed and the max speed is desired anyway. No scriptplayer can does this reliably on the fly as everything is always delayed by the connection.
So a protocol change would indeed be needed, but do not thing that this is excessively difficult either (only its initial step would be). Firmware can be designed to handle this. For example, lets say the handy normaly expects full file uploads. Firmware now changed it so it can accept an emtpy script (but instead contains metadata), this metadata then can give feedback on which features are usable, its limitations etc. Or just ask for a certain version of a file. There is a massive amount of freedom as there is no true standard.
The hardest step is to make sure that unupdated devices can give the feedback it doesnt work reliably, so the program can fall back to an older version automaticly. Once the protocol includes a firmware version/script version that it can handle, programs can already act on that.
Its not like USB where due to global and excessive usage standards are a lot more strict. The current devices are still mostly driven by reading a file and loading it internaly. And this same behaviour makes it very much possible to add in extra handling.
Well I would hope that future devices will have better motors the launch, and better api than the handy.
I wouldnt make everything for the lowest common denominator device because we will be stuck with super simplified funscripts forever. Current scripts lack any acceleration and are just triangle waves.
Adding many points to achieve a smooth curve is currently just a solution to funscript limitation.
Thats why I suggested using tangents instead, because then you can send positions and tangents to the device and it can perform smooth moves, instead of having to send small linear steps. Kinda like spline moves (G5) in gcode.
Only problem is that all devices would have to support this kind of moves, but scripter software could save two versions of the script, one with tangents, and one where the splines are sampled to linear steps.
I think you’re overestimating the differences between that initial script and the smoothed version. The character of the strokes are going to feel the same. It’s still a relatively slow rise followed by a comparatively rapid drop. You’re not going to notice the subtle differences beyond possibly feeling a slightly less jarring change in direction at the top.
If the example is bad, I hope the idea is consistent
The interpolation I was talking about is not an overall optimization to the entire script - #24
making everything smooth isnt always desired. Quick movement changes in otherwise slow paced action might end up distorted - #17
smoothing actions can often be undesired and break immersion. - #4
