This is a good idea for a V2 implementation.
for now we should stick to what we have.
This was an idea I had in the back of my mind. Right now im more focussed on ways to help scripters and the forum make more money. Trying to get high availability going.
If anyone has PHP/wordpress expertise that would be great.
based on my testing and experimentation I may have to make something bespoke.
I think it might be a chicken-and-egg problem. Since there wasn’t an easy way to make a heatmap with the chapter, besides the ‘basic’ heatmap in OFS, people might have stopped using them. Personally, I’m not sure if I took the time to do it in my latest script for that reason. But if it’s included in the heatmap generation, I’ll include chapters in all my future scripts for sure (and may update my old one).
Sorry forgot “/j” in that line
Starting to make 2.0 backlog then
I believe that’s the case right now.
Since I’ve been testing it hasn’t been incrementing. Am I wrong?
Personally I hate change, lol. And this seems, to me, to be a classic case of “if it ain’t broke don’t fix it”
If somebody is capable of creating a script I would assume making the heatmap was straightforward enough? Perhaps I’m missing the point of this being done?
If it is a must, then keep the colour scheme and look the same as ofs or very similar.
It’s very hard
We have five different standards and all are bad
Many scripters don’t even bother to make them cuz it’s that hard
cyan = 7
lightgreen = 158
yellow = 241
orange = 334
red = 434
pink = 487
purple = 580
blue = 734
Its same as OFS just with higher limits
(colors may be not perfect but we can change that later)
How so? you go to generate heatmap in ofs, click it, and you have a heatmap? Where is the difficulty? Genuine question.
If you want to make a crappy screenshot for one script it’s fine
If you want to make a clickable high quality SVG for Handy, OSR and SR6 variants it took me half an hour when I knew what I was doing
Ah ok I didn’t realise there was any difference in the quality. Saying that I’ve never used a heatmap per se, as I’m sure I’m like many others who just put on a vid they like the look of and cross their fingers for a good time, lol.
Just my two cents on a couple of these issues.
First I’ve found that heatmaps can be deceptive as I’ve made more intense versions of scripts as well as limited the speed as necessary for handy (and SSR1) which then makes the heatmap appear less intense than the original. I’m looking forward to the new style you’ve got going on as it shows the actual graph, but adding the heatmap is kinda ‘whatever’. I don’t mind the ‘marathon’ combo, but the solid graph is honestly the best at conveying useful information.
When it comes to automatically optimizing and limiting speed for the Handy, I’ve not been satisfied with any of the automated tools I’ve found. I find they’ll often “park” the stroker at the top of the stroke instead of the bottom during slow periods and that’s worse than using the limiters built-in to Multi Fun Player or Script Player.
Would be nice if there was a good automated optimizer, but when I do conversions myself while a lot of the work is routine and would be nice if automated, you’re occasionally met with dilemma on where to “park” the handy during these slower moments. It’s also only easy on scripts where each stroke ends on the bottom. If there’s sections that don’t, there’s some decision making there too on where the top and bottom of a shorter stroke should be.
I use different algos for heatmap and graph
I plan to use
Thoughts?
If anyone knows topic designs THAT COULD BREAK WITH THE NEW HEATMAPS PLEASE SEND THEM TO ME so I add conditions when to use “append” rather then “inline”
So far I only know @SIDM aaaaaand that’s it ¯\_(ツ)_/¯
The heatmaps I don’t have an immediate opinion about how they’re being computed. The graph I think is far more informative, so I’m looking towards that and combining it with some kind of heatmap in the current presentation doesn’t make the graph all that much harder to read, so it’s not a big deal no matter how the heatmap is computed.
When it comes to the optimizations, as I said, it’s more complex. For the slower scripts, where the upstroke is can depend on what’s going on with the video and music. As the default though I think the bottom of the downstroke should not change from its original point, the top of the down stroke should be wherever it needs to be so the downstroke is at the max speed, and at all possible the top of the upstroke and the top of the downstroke should be the same. The Handy should never be “parked” on the top.
I’ll also mention that if there’s a gap between the bottom of the previous downstroke and the beginning of the next upstroke that I put the bottom of the upstroke at 10% instead of 0%. This is because if it’s put at 0% the Handy will try to “correct” its position before the upstroke and make a little jitter before the stroke. (I hope that makes sense.)
As far as it comes to decreasing the peaks I think that the top of the stroke should be decreased. NOT the bottom. Really the primary problem with playing a script too fast for the Handy is that it’ll sort of walk away from the bottom of the stroke, so optimized scrips are made to keep the handy towards the bottom.
Also worth mentioning, The Handy has more torque moving down than moving up, so its maximum upward speed is slower than the downward speed. Kinda off topic here, but I’d love a dual motor Handy. One that pulls up and the other that pulls down. Would overall increase the speed of the device and make upstrokes just as strong as downstrokes.
Finally this is generally what I do to convert cock/fap-hero scripts. Action scripts generally don’t need a conversion, but for music scripts it can be a lot more complex when the bottom of the downstrokes aren’t always at the bottom, so… I don’t know if I can think of a logic set on what to do… 
I’d be very thankful if you could measure IRL handy up and down speed
And the min/max uncorrected as well
And the minimal speed, what it was, 20?, so I can add a requirement that Handy “cannot have speed of 0 for <1s” or something
I always thought 45KG SSR1 is basically this, no?
I don’t think it’s quite that straight forward. Having drag on the motor affects it differently when moving down than when moving up. I’m pretty sure it’s a worse effect on the upstroke than it is on the downstroke; which is why I give more time (lower speed) on the upstroke.
I have a FunOSR1, I’m pretty sure it’s the same. Without getting into it too much the device operates a bit differently. The Handy has a bit of give to it. You can push it around while it goes through the routine. The SR1 is more ridged. Also the FunOSR1 only has one motor. I broke mine 
Still need to take time to repair it, but I’ve disassembled it and taken out the motor.
I like how The Handy can be pushed around a bit, but ya know more power and equal power would be appreciated.
In my personal opinion the best heatmap coloring was done by earlier OFS versions, in my case (1.4.3) everything else just feels terribly inaccurate unless its from funscript.io or HandyControl
I script the majority of things in older OFS versions because of this.
This for example I find very inaccurate.. red for 430? Orange 330?
I avoid this mapping whenever I can, honestly keeps me from using newer versions.
This is from 1.4.3:
I’ve scripted so much in this version of OFS for multiple devices, that I script audio by color… Orange 390-425 Speed is about the same as a 1/4 beat (maybe a bit faster) and with this formula you proposed it would make every audio script (and even continuous action scripts) have a ton of “noise”, and make it seem a lot faster than they really are.
Personally I think all heatmaps should just come from funscript.io.
This is perhaps worth a separate discussion in its own right, but what other helpful metrics could potentially be calculated directly from funscripts? This would be useful for longer scripts where a heatmap can’t show as much detail.
BPM and BPS would be nice for audio/fap hero style scripts, and in general for helping determine the overall speed of a script on a more understandable level.
Its json with mostly 3 digit precision decimals. This is that highly compressible that kolmogoro complexity is a useless standard. Even for fap hero there is too much of variety possible that for users isnt noticed, yet allows compressing further. More accurate aligned positions would allow a simple formula to be used, while manualy placed less accurate ones most likely wont.
1ms of a difference on 1 position can easily add 1% of total size on a script with 2000 positions. Its meaningless to measure this.
But i do have an idea what you are looking for, and that is wether a script does 0-100 a lot, or when its more balanced movement. But i think a normal distribution graph does better here.
(for some reason the images here for me are taking a few pixels from the left and moved it towards the right, which makes the 100 have an up/down line, while the down part was ment for the left side.)
For example a fap hero then would look like:
Yet a normal video then looks a lot more like this:
This could even be a 2 color system where bottom is red and top is blue:
If the lines arent smoothened and show a more relative position, then it would show peaks at each 10 interval, making it much easier to see which are generated/handcrafted etc. But i think its is meaningless for quality measurement (generated isnt necessarily beter).
The advantage it shows is whether scripts are tip or base focussed, which sometimes in heatmaps can be harder to see (depends on generated method).
This sort of graph could also be used for stroke lengths.
Vibration pattern recognition is a good one and technicaly not that difficult either: many short (VERY) fast strokes, with intervals within the 80ms range. On heatmaps usualy shown as a thin line at max speed.
I would say this should only be shown on scripts where this is relevant though. And usualy a grayscale based line works best here as you only need to show a slight indication of strength. on/off is far more important and black/white is most clear here.
Actions per second is a quite meaningless standard unless its exceeding device tresholds. OSR2 optimized scripts often will have too many points for a handy. But it otherwise doesnt realy tell anything about a script. I would simply aim towards detecting scripts that exceed clear device limits (ie. if most strokes exceed 600 or go below 40 you can warn that its not handy optimized).
Thanks for taking the time to think about this. You seem to be heading towards something like a gini coefficient for stroke length / stroke speed / stroke starting point? That would capture the evenness of the distributions, and could be a useful measure.
I think Gini might not distinguish so well between random noise (more typical of auto-generated scripts) and repeating patterns with different speeds and lengths (most likely hand-scripted). I will do a bit of analysis with some funscript files and see whether there is much variation in Kolmogorov complexity. I agree that the json structure and metadata would distort this quite a bit, so I will look at just the position data within the scripts.
