I found another index error. Fixed in 1.03 py.
2 Likes
Hi @Magneato ,
First of all, thank you so much for your original tool ā itās been incredibly useful.
Iāve been using it for personal projects, and over time, I ended up modifying and extending it quite a bit to better suit my needs. I wanted to share what Iāve changed and why, in case any part of it is helpful for future updates to your original version. Feel free to use any of the code or ideas if you find them useful!
Hereās a quick breakdown of what Iāve added or modified:
1. Improve Vibration Pattern Replacement
In previous versions, the vibration pattern replacement applied to the entire script, which sometimes altered parts that didnāt need changing.
I changed it so that vibration patterns are only adjusted in areas where timing points were actually removed. To do this, I added a smarter detection system that uses buffer zones around removed points to better identify which sections need replacement. This helps preserve the original feel of the script where it was already working well.
2. Improve Speed Correction
I implemented recursive checks to catch chain reactions ā for example, when fixing one low-speed point leads to another new low-speed transition nearby. The tool now detects and fixes these automatically.
I also improved the handling of edge cases where movement reaches the 0 or 100 position. Instead of forcing impossible movements, it now inserts a natural pause.
3. Minimum & Maximum Speed Handling
I updated the limit_speed function to handle both maximum and minimum speed constraints.
Additionally, I added a minimum speed parameter to prevent stuttering caused by extremely slow movements.
This can now also be set directly from the GUI, making it easier to fine-tune behavior without needing to edit code.
To improve motion accuracy, I reduced the default minimum interval from 60ms to 33ms.
This allows the tool to better capture high-frequency movement details without sacrificing device compatibility.
4. Detailed Speed Analysis & Debug Info
I added speed diagnostics and clearer messages explaining what changes are being made and why.
This has helped me a lot with debugging and understanding how scripts are being modified.
These changes were mainly made for personal use to help preserve the original intent of the scripts more accurately while still enforcing safe limits for devices like the Handy. I figured Iād pass this along in case anything here could help you in your development ā feel free to use, ignore, or build upon it however you like!
Thanks again for creating and sharing the original tool ā itās a solid foundation and has saved me a ton of time.
All the best,
Pigtarao
1 Like
Oh, by the way ā the modifications I made werenāt intended for Handy in Bluetooth mode!
I used this tool specifically to fix extremely fast or slow movements that even Handy in Wi-Fi mode struggles to handle.
(For example, on EroScripts there are many funscripts with speeds like 1000 units/s, made for devices like SR or OSR. I needed to adjust those.)
So my goals are quite different from yours.
Since I use Wi-Fi mode, I chose 33ms instead of 60ms, and my main focus was to preserve valid patterns that didnāt violate speed or interval constraints ā whether slow or fast.
In particular, I started modifying the code because acceleration patterns were being misidentified as vibrations, causing unwanted pos changes that ruined otherwise well-designed sequences.
In short, my modifications may not align with your original goals ā so please feel free to only take the ideas or code that you find useful!
Thanks for clarifying the part about lower intervals for WiFi. I donāt use WiFi with the Handy (firmware 3.x) for various reasons, so 60ms ish was the sweet spot for my tests. Your other changes sound interesting. Iāll try to check them out sometime.
1 Like
I wrote it quite grandly, but in fact, there is not much difference.
I created a āminimum speed limitā and updated the limit_speed variable accordingly.
Because of the āminimum speed limit,ā recursive search was needed, and also because I didnāt want to break the acceleration pattern, I made the āvibration detection and recovery functionā work only when the action was changed by the āminimum interval.ā
I made it easy for users to set the minimum and maximum speed through the GUI.
Andā¦ well, thereās not much else to it!
Thank you so much for the great tool! Thanks to you, Iāve saved about 100 billion seconds.
2 Likes
I wonder how does it compare to Bright - Funscript heatmap generator 's Handy converter (which I basically never tested myself because I donāt have Handy)
Could someone compare please?
Tell me if I need to fix something there
No, I donāt believe they are doing the same things.
From the link you mentioned (and your forum post), Iām not seeing a relation between the two. Your app appears to merge multi access scripts and generate thumbnail heatmaps. The python code here takes a lot of care to check for action patterns which are too much for Handy (in bluetooth mode) to replicate, and translate them into something which still appears to sync to the action.
However, Iām not sure what this statement in your forum post refers to since Handy is not multi-axis:
New feature: convert your funscripts for Handy!
I see that your app seems to have a speed limiter, which my python script also has, but thatās the only similarity Iām spotting.
Iāve been manually converting scripts for the Solace Pro, and Iāve been debating doing something like this! It took quiet a bit of testing to figure out what the operating parameters where, so this can really help speed up script conversions!
One of the things Iāve found myself implementing a lot is wave patterns. Iāll make the āVibrationā a movement of Ā±30u, and āwaveā it over a period. Is there any settings to be aware of to make sure the script doesnāt remove these sections?
Okay Iāve compared it, my implementation I linked is poor compared to the script
Speed limiter works fineā¦ but it is not allowed to change peak timing. Dunno it thatās good or bad thing.
(Itās ādownload for Handyā button below, no settings needed)
Gonna rethink it
Also do you have some great test cases?
Iād like to have some
If time between movements is very short (min_interval = 60 in the Python script), then the design of this script will modify them. If you want to reduce the vibration detection a bit, you could try lowering min_internal value.