included an example but going to update it to a gif.
1 Like
well this is a forum. people need to read.
Btw, I don’t think the parenthesis should be added after the link text for the Always on option.
Messes with the formatting, which the option is meant to prevent 
That information should be within the pop-up imo
I think Dimava’s funlib is what does that.
would need to be changed there.
1 Like
Feel free to link an action based topic you’d like to see rendered.
The examples of the new design(s) have been based on music and animated action.
I think that this is a very good start to something that will be very convent for scripter’s post. Keep up the good work!
My options on this.
The Good
- Makes it simple for people to post without having to grab an image for their heatmap
- Saves time
- Optional on/off
- Users can see what the script will look like as well as high and low spots
The Bad
- UI is a bit cluttered and can be spaced out a bit more
- The text on top (1.Funscript, Duration, etc) is very hard to read, probably can make it a solid color so it is more visible
- Color coordination (green, orange, red, purple) may be different depending on different devices depending on max speed
Overall it can definitely can be improved, but it is a great start.
1 Like
My today’s conclusions:
- rendering 2h script takes 1s not because rendering is slow but because the lib is slow. Rendering takes like 100ms.
I’m considering to migrate out of the SVGs for everything, so there’ll be a graph, a heatmap, and an average color and HTML/CSS does the rest. So the text will be actual text.
It won’t. Color shows speed with 500 as red as it was since OFS. Purple just means Handy won’t support that high speed. I may add a speed limiter in options so you can DL a script that was limited down do eg 800 or 500 or handy
More then that, it’s optional graph/heatmap, I personally prefer both at once
1 Like
If you want to follow the colors from OFS for consistency, it becomes fully red at 400, not 500.
1 Like
I have considered that but that makes Handy 500-550 go to the purple area, and keeping it red was my priority
Hm, why would changing the speed of the red also change the speed where it becomes purple?
This TS code should be able to make it really flexible to compute the color map without any color threshold affecting any other (it computes the color the same way OFS does, but with an optional upper limit added to change the color after some arbitrary point):
This example should make it use the same colors as OFS (white to red between 0 and 400), but with an upper limit where it becomes magenta:
Line color output from 0 to 800 speed, 1 pixel per integer speed value:
It becomes magenta at 600 in this example, but the all the values for everything are easily replaceable.
It’s oklch(0.8, 0.4, 210 - speed/2.4)
I don’t use interpolation myself
As such, values are not replaceable at all
Currently 200 is pure grass, 300 is pure orange, 400 is pure red, and 500 is pure pink, which seems fine for me
So if you see the graph is gray it’s because scripted didnt care about speeds and they are over 1k
This scale looks good IMHO.
IMO a sudden transition at some upper limit is a good way to show that the script is not being played 1-to-1 at that point.
That would change from device to device, of course, but since it’ll be rendered on the client, there could be an option for the user to select which device they want to see heatmaps for (e.g.: heatmaps for the Handy suddenly becoming another color above 500 speed).
1 Like
IMAO it’s bad, just leave colors as is. Device speed depends on too much stuff.
Just knowing “my device can’t play faster then red” is generally enough
If the user has speed limit, script should be speed limited to it, not recolored
Ugh… yeah.
put that in the test discourse.
Heatmaps are now in all themes excluding minima
Any way to remove that for oneself?