This plugin is ment to convert linear motion to a smooth one by adding addional nodes
As this is the first version only 1 method of smoothing is currently supported. While its generaly a good method, its not the only method that can work. Im planning on adding more options here.
Plugin
Install this in the folder: <user>\AppData\Roaming\OFS\OFS3_data\extensions
or for OFS2 (untested, but should work): <user>\AppData\Roaming\OFS\OFS2_data\extensions
(the zip contains the plugin folder so you dont have to make that yourself).
To use:
Select the nodes where between you want to smooth the movement.
The number of nodes added does what it says. The current method applies the nodes equaly spread over time, while verticaly uses a sine wave. The middle node is skipped as it would otherwise be the both on each sides.
The plugin is aware of skipped nodes and will not apply the curves there!
That one just adds 1 node to the start and end of each node with a fixed offset. Which would appear very similar to setting just 2 added nodes in my tool. My tool adjust for the node positions and distance while that one doesnt. Both have their own function, and its up to the scripter which he prefers.
Good you mention it, as it could in some cases be a bit cleaner than my script. Especialy if the top section itself must be consistent. My script adjusts for many things, and can face rounding issues.
One thing i forgot to place in the images my tool achieves is that it can handle midpoints as if its a sudden stop:
This is great! Thanks so much for the work on this. Messing around with it a bit today and seems incredibly useful, especially for tuning some of the Auto Generators based on music/beats.
This neat. I want to see what level of smoothness this might add to song scripts and such. My handy was at a capped speed so I was never getting the benefits of detailed scripts before (they were basically causing the machine to skip, but I think it’s a good bit better now).
Actually, one suggestion I have if you want, is to maybe have it exclude points that starts at the beginning of the video, because it throws an error and the extension has to be reloaded.
Curious how this works in relation to interpolation that players utilize. From my (basic) understanding, even if a script looks linear, players/toys are applying smoothing to those movements to avoid jerky playback. I know in MFP there are several different interpolation types available including Makima and pchip.
@Yoooi - is this duplicative, or would it further enhance interpolation/smoothing in MFP?
Only players that do interpolation are MFP and JFP. I dont know of any device that does interpolation itself.
Interpolating an already interpolated script in MFP wont do/add anything. Maybe it would be marginally smoother but you wouldnt be able to tell.
Thanks for the confirmation, I was dumb and had the extension in a file inside another file so it wouldn’t run. I kinda assumed I had made a mistake on my part being a scripting beginner and I was right. Thanks regardless
Just wanted to ask is it generally better to smooth out scripts or have them be more linear, when would one be better than the other? I assume quick thrusts would benefit more from linear due to the speed and intensity and smoothing out would work better if it’s like a slower thrust?
EDIT: I tested it out on the Handy, basically makes the script skip/jitter a lot so its choppy. Not sure why.
In BLE mode the Handy takes actions one by one and therefore producing a microstutter before each point. Over Wi-Fi it caches all actions beforehand and is therefore more smoother.
Fast actions, one that exceeeds 380unit/s, should be kept untouched imo, as the sudden acceleration feels rather abrupt and unnatural.
Simple script also has better compatibility, and will thus play out better on older toys such as the Launch and A10 Piston.
It’s worth adding middle points purposefully to represent significant speed changes in the video. Don’t select all actions and perform the function just for the sake of “smoothing” out the strokes, as it may not.
The only device that is completely unaffected by this is the OSRs. And there’s no need to do this for them because MultiFunPlayer takes care of overall interpolation.
My observation is smooting is needed only one sided of top bottom points. I rarely see a decelerate to stop but a delay at accelerating. So if you could do the plugin also onesided of top and bottom that would be cool. To me this would seem the natural interpolation that’s how movement forces me to script if I replicate it.