My understanding is that the Handy omits most movement beyond ~500 units/s. With that in mind, whenever I find a script I like I have to check that the scripted movements are within range and, if not, decide if it’s worth modifying the script manually in OpenFunscripter. If I find it worthwhile, I’ll make a more Handy-friendly version to avoid having lots of random pauses and jerky motions and usually upload it to the original scripter’s post. That work involves me looking at the heatmap for red, navigating to that section and reviewing each point’s movement speed and then shrinking the height of each point (or groups of points) towards center manually.
I’m wondering if there’s an easier way to accomplish the same result. Is there some scripting app that can identify sections which are over 500u/s and shrink the height of the top and bottom points until they are under a certain value?
I’m open to other thoughts to solve this problem (other than getting new hardware). It seems like a common mistake by scripters where they think their scripts are Handy-compatible, but actually not. I mean they still work, but I don’t think they realize they are scripting things which won’t actually happen. I also know that other devices really can do those movements, but a lot of scripters fail to even post what device they’ve scripted and/or tested with. My assumption is that most are using the Handy, but that’s another problem, I guess.
Someone might have a script, so could be worth checking back here.
Off the top off my head, the ‘Util_Eng’ has a search function based on speed but that’s single points and can’t select all based on speed as the criteria.
What you could do in OFS is Options > Preferences > under Scripting you could set the ‘Max speed highlight’ to your desired max, that at least would highlight strokes which are too fast as blue and it would make manually picking them easier.
Which connection method are you using? Because if you are using Wi-Fi it shouldn’t be omitted. The Handy’s firmware will shrink the stroke so it can be executed on time. The stroke will still be played but at a reduced length.
I’m using bluetooth. Maybe my description is lacking a bit; motion doesn’t stop completely for extended periods. Put another way, when scripts are too fast, I get a general sense that the Handy isn’t tracking movements properly. Maybe it’s doing what you describe and just limiting motion and compensating best it can, but that’s not nearly as good as script which has been modified. I like the way funscript.io modded it, so thanks for that.
The behavior I described only works on Wi-Fi, where the entire script is cached before playback. Handy’s Bluetooth protocol is very basic and plays action as they are received without doing any post-processing. I imagine things go wrong when the speed goes beyond its hardware capability.
Try Wi-Fi if you can. It’s entirely different compared to BLE. If it’s taking long for to download the script try hosting it locally.
Ok, makes sense. Thanks for the suggestions. However, I’ve built up my library thus far using bluetooth and it’s all working well. I think I’d rather keep using/testing with BT and that way, scripts will always work well on either WiFi or BT. Though, it might be nice to be able to start a video+script without having to hold the connect button to switch to BT mode…
