Attempting my first script using OFS in the software all stroke timing looked perfect for the most part and every alternation was at least 200ms apart but while testing the script the actual stroke time was significantly different. I.E if it was supposed to take 3 seconds it would only take one kind of thing? is there something I’m missing while making the script? Could it be something with the encoding of the video? This has probably been addressed somewhere else but I was able to find it. If it has a link would be appreciated. Thank you all in advance.
What toy are you using it with? Handy or Kiiroo? Or something else?
Can you elaborate what you mean because I don’t follow you when you write (the last part):
What happens on the device when you run the script?
Usually you only need to keep track of the following from a technical point of view:
- Not having points to close, i.e. too little time in between.
- Not moving the sleeve too fast (i.e. move too long in too short time).
- Avoid too small movements since they may be experienced as stuttering (or little to no movement at all if done over a longer period of time).
Even if device firmware handles most of the above it usually results in a bad experience when it occurs.
Some device firmware have had bugs during the years, but most scripters don’t deal with such things (most are not aware of them).
I’m using the Kiioo.
I’ll try to think of a better way to explain it, but offhand if a travel distance for 100 to 0 was suppose to take place over 10 seconds (random numbers used for example) the same travel distance would be covered however it would only take a fraction of the time it was suppose to. although in a replay in funscriptor the travel time matched frames correctly.
If it’s very long stroke than it’s a normal thing. Every stroker has two limits: minimum and maximum speed, so if you will go too low the device will shorten the interval between points in script - it’s to prevent the mechanism of getting stuck. Same goes with the maximum speed, if you exceed it the strokes will be shorter than they look in the program.
the kiirroo used to crash (i havent used it since i got the handy 6 months ago,so no idea if it still does that) if the length of the line is too long it could stop working and needed to be reconnected or started making little movements of its own (keep it below 2000ms but the kiiroo might need less then 1500ms).
With long lines its better to not go for 100 to 10 but for example 50 to 50 so make the last movement befor the long line shorter and also the make the one that comes after it shorter. Or if there is very slow movement on screen divide the long line in parts with slightly different speeds.
Thank you both for the information. I’ll see what happens after a few adjustments and post what I come up with if anyone is interested. Again I appreciate the information.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.