This site is really awesome. Thank you for making it public.
Agree. Looks way better. I like it when a site makes use of bigger monitors. Video player is also better. HandyFeeling’s player is too small.
Very handy and neat feature to have.
I also like this a lot:
Indeed very easy to use. Looking forward to use “coming soon” features. Especially the randomizer.
Looks really cool! Will definitely try it.
Yes, please!
I will use your site to play some scripts and give you feedback, if I find anything.
What I like about ScriptPlayer the most, is the playlist feature combined with the chapter mode. Is there any chance something like this could be added to funscript.io as well?
Thanks again for your effort and making the site public to us
So it’s not impossible but sounds like something we might see later down along the road. I kinda wished the video and funscript could be edited without the need to connect the device. Maybe another thing that could be added down long the road. Besides that this looks very promising.
I know you joke, but obsolete? never! HandyControl is very VR friendly. I am sure we will see some natural progression with Funscript.io as more features are added, but HandyControl isnt going anywhere soon. It has it niche carved The synergy here with Defucilis work is super awesome to have tho.
It is, but you’ll need to do the whole ‘request desktop site’ - the layouts I made don’t work with narrow screens. Technically, if your browser window is 900px wide or more, it’ll work.
That’s a great idea, I’ll add that with the next update since that’s super easy to do!
It’s kind of like…I add bits and pieces every so often. Most of the individual features are quite simple to do so over time it can grow to be something great. Kind of like HandyControl!
As for the multicontrol - they haven’t released API docs, but the multicontrol websites have the source…easily readable (I’m assuming that’s intentional) so it should be very easy to reverse-engineer!
But I definitely don’t expect this to make HandyControl obsolete any time soon. I kind of think about it as “HandyControl Lite” for the web, with a more limited feature set for most things, and a few things that are harder for HandyControl to do, like an integrated video player.
May…be? I’d definitely like to be able to support other devices, but I’d have to actually have one to test with, and I’m not really keen to spend hundreds of dollars on a device just for testing. For now, I’m mostly thinking of it as tools to modify funscripts that anyone can use, and an integrated player / controller for the Handy.
Oh yeah a playlist feature would be relatively easy to do, and quite fun. I haven’t tried the feature with ScriptPlayer, but it could even combine the funscripts into one ‘mega’ script so that there’s no delay in switching videos back and forth. Dunno if ScriptPlayer does that.
You can modify funscripts without a device connected, but yeah there’s no integrated funscript/video editing tool yet. I do kind of want to add one, but it would definitely be quite a lot of work so that’s down the line.
I love the way ScriptPlayer fades out and then fades in when going from one video to the next, but mostly I would like for the scripts themselves to transition like that. It may just not be possible with the way the Handy downloads scripts. A perfectly seamless transition with no delay would be awesome though.
Would you be able to add jitter to the manual and auto modes? And is there any solution for using the full dynamic range on random without the Handy inevitably going to a 2% stroke with 100% speed?
Is there any particular reason for overwriting the metadata in the original script (creator, license, etc.) when saving it after applying an offset to the script? Other tags like bookmarks remains unchanged.
Maybe I misunderstand. What do you mean by the ‘full dynamic range’? I smell a potential new feature!
Oops, thanks for the heads-up, fixed it!
Oh shit that’s definitely not good - just a bug. I’m going to fix that right now! D:
Yes, I actually have a design already in mind to do this. The cycler is designed to be procedural so that you can change the paramaters mid-session, which limits me to what the API provides (so no stroke minimum)
But I do have a plan to make a ‘funscript-generation’ version, which would allow for more complex patterns, more accurate timing changes, stroke length minimum, heatmap preview AND funscript saving. That’ll be coming reasonably soon
I’m not sure the best way for me to describe this situation.
Let’s say you’re in manual mode and you want to set it to random. In this example you want the stroke range to be anywhere between 0% to 100% stroke length and you want the longest strokes to be anywhere between medium to fast. This means that if you set it for this, at some point you’re going to have the shortest possible strokes with the fastest possible speeds. If you go the other way and optimize a medium speed for the shortest strokes, then the longest strokes, at some point, are going to take forever to go from 0 to 100. Another way to think of it is if you want an overall slow to medium experience and you want it stroking anywhere in the range between 0 and 100, then there would need to be some kind of bias that makes both the longest stroke slow to medium and the shortest stroke also slow to medium.
If I just made everything more confusing, then just let me know and I’ll try to make it even worse.
I think I understand. It sounds like rather than randomizing stroke length and stroke speed, you want to randomize stroke length and strokes-per-second?
This is actually a pretty good idea, and could just be a checkbox to choose between stroke-speed and stroke-per-second mode.
Obviously, not all stroke lengths support all stroke-per-second values (30% stroke length goes from 36 to 364 strokes per second, while 100% stroke length goes from 11 to 109 strokes per second), but I still think this would probably be useful.
If saying strokes/second is somehow easier to understand than my novella on how I can’t seem to
get stroked at medium speed at various points along my shaft, then yeah I guess so.
Well, “stroke speed” refers to the actual speed (in millimeters per second) that the Handy moves the ‘shuttle’ at. But when most people think of ‘stroke speed’, they’re thinking of how many strokes per second are happening.
Sorry, I was making a joke about how long winded and rambling my explanation was versus how clearly and succinctly you were able to state the situation. You got it right.
Please make it so that it is possible to keep the motion overlay (what you see on the video when hovering over the heat map) visible (perhaps a checkbox?) so that you can see expected motion with the video. It would require the overlay to scroll to keep the current motion point visible. Perhaps but a center line or ball that moves along the motion line to show the exact point in the script. This would be very helpful in figuring out offsets.
The synergy here with Defucilis work is super awesome to have tho.
