Ok sorry I should have been more specific.
I meant how many degrees the osr2 can pitch/roll ignoring twist for know.
I am rebuilding my OSR2 right now so take these values with a grain of salt, and remember that many users will limit the ranges so it will vary. But I would say the pitch is about a 90 degree range, so +/- 45 and the roll is maybe a 60 degree range? Roll limits kinda depend on how much you are willing to work out your servos and allow the arms to flex.
Ok thank you. Still won’t tell what this is for but I can experiment with this 
1 Like
@Hydra, this follows the discussion you were involved in on the Tempest Discord lately. I am following this but don’t understand quite all the details. Seems that the movement was designed between the limits of the hardware and is controlled by the Tcode. The scripting software could go from one extreme to the other matched to the T-code and then the scriptwriters would script to the known limitations.
@gagax123, you have me thinking you are trying to be very clever and I can’t wait. There is one basic reason I can guess that you would want to know the preferred ranges! Hope I am right!
Uhh you probably not. 
But I’m curious what you’re hoping for.
1 Like
@hosenguy To be honest I am mostly just spitballing and still trying to wrap my head around the implications of Tcode and what I do and don’t need to worry about when scripting to devices with significantly varying hardware. Basically, I don’t necessarily know what the “known limitations” are because people customize their own setups and use servos with different angular ranges. You are correct though that most of that is handled in the software/user settings and so it may not be worth worrying about too much for now.
@gagax123 I would like to change the behavior of the statistics panel. When you stand on a point it shows 0ms, which is not any relevant data in my opinion. What I would like to see is the distance to the previous point, i.e. you will never see 0ms after the suggested change (maybe for the first point in the script that has no previous point).
The reasoning behind this change is that as a scripter you need to be careful of not putting points to close to each other. Therefore you want the total distance from the current point to the previous when you stand on a point. You don’t want to move back one frame and then another and do an estimation in your head what the distance is. This is not a big issue, it is more convenience, but hopefully it is not a big issue to change.
1 Like
That’s definitely not correct thanks for pointing this out.
I’ve made it now more consistent.
You can test my change if you want AppVeyor
Perfect! That build works like a charm and the issue is resolved!
I was thinking that their could be a way to generate a set of scripts for the OSR’s other axis by a formula to use as a starting point. If so you would not want them to be too strong and have some relevance to the main stroking by a set of rules. I know A.I. based on a generic Willey does not exist!
I am patiently waiting for the multi axis features. In the meantime I play the video with it’s main script using JFS while use my gaming capture app to record it, and then script the other axis using that as the video to allow me to see the main script while doing so. It works pretty well but I am just learning how additional scripts feel when used together!
I’ll have to leave that to someone else. 
In generall I’m not really interested in the whole multi-axis stuff which is why I’m trying to keep everything fairly generic and not tailor it to much to just multi-axis scriptiing.
That being said the thing I’m experimenting with is a simulator for multi-axis scripts.
@gagax123 Got some more tiny details that would be nice to have fixed.
- Would you mind changing so that the last saved timer doesn’t start measure time until you actually do your first change after the last save?
- Can you make the timer flash a bit when it changes to red so that you see it in the corner of your eye? A flash every 5 min would also be nice (5, 10 15, …). I’ve got an ultrawide monitor and I script in full screen mode so the timer is far away from the center of the screen.
I can do that but honestly I could also just get rid of the rolling backup feature which I think has proven to be not that great and just replace it with a simple autosave with a configurable time interval.
Seems to me that that would solve the “forgetting to save” issue best.
@gagax123 Not necessarily. Sometimes you mess around with things and in difficult sections and want to revert to your last save. If OFS save continuously then you loose control. It is not often I need to revert, but it has happened. Sometimes I just open a finished script to look around and I don’t want accidental changes to suddenly be saved. Autosave in a backup file is ok, but not in your master file so to speak.
1 Like
I agree with sentinel. I like the rolling backup feature I’d prefer if you don’t do away with it.
1 Like
Yes you’re right this was the reasoning I had as well for not doing an autosave feature.
I still don’t like the rolling backup and might simplify it to just be a single backup.
Too many issues. Like for some reason finding the oldest file in a directory and deleting it is hard. 
@gagax123 Why not just use the original file name + something, e.g. foo.funscript.autosave, and just overwrite it for every autosave. Delete all other .funscript.autosave files to keep the folder clean.
I prefer this idea over how it currently works. 
I implemented these things. AppVeyor
I already had the infractucture to track funscript changes so that wasn’t much work. I’ve made it so that the whole main menu bar flashes red after 5 minutes at a 3.14159265359 second interval (sine wave 
). Also the “last saved X minutes ago” starts shaking which looks silly.
Sure. Do you have a preferred default key for this?
Also where should this mirrored stroke be inserted at the white line in the center or always at the last point?
Thanks I got it.
It will be part of the next release which should be this weekend.
1 Like