Reduction of sensitivity after lean forward.
In the current state there is a problem when I try to zoom a view with a lean forward (eg. in Arma 3, where bare lean forward is rather useless). After zoom, camera became too sensitive and especially any rotation cause unwanted big changes of view position. My proposition is to introduce some kind of "zoom-dependent-soft-factor". Initially such factor should impact mainly on rotation of view. Leans and rolls are not so annoying and can be even ommited. In case of implementation also leans and rolls, when zoom occurs during current lean/roll, probably easiest way will be calculation of raw lean/roll and use it as reference.
This feature was mentioned several times. A few alternatives do have this.
See https://github.com/opentrack/opentrack/issues/292 for previous discussions about this.
Would you like to use the function like a mapping or like a slider? I think a mapping is better here.
Think I agree with you now and it should be implemented.
What should be the maximum "reduction", zero?
I have no preference in case of slider or mapping. In my opinion reduction should be linear, then slider is enough. In case of slider maximum "reduction" absolutely shouldn't be a zero because it may lead to misunderstoods. I think "0.1" will be better to preserve any movement of the head. In case of mapping 0-1 range is good because user clearly see, there is possibility of total reduction of head movement.
An option to reduce to zero would be welcome I think, I think in some cases when I really zoom in to the full extend it could come in handy to lock all other axes. If the default isn't zero I think this won't be a real problem.
Slider for the effect strength. But what about the range? A selector for the max mapped Z value? Some games have max zoom at a mapped value of 10, others at 75. So this is necessary also.
If you base the reduced sensitivity of other axes just on the set up Z axis range of the profile in opentrack, then you don't need any game info.
No, I need to know which Z value is the max reduction. For some games Z of 10 is really close, for others it takes 75.
Unless I let the user select "zero rotation at Z position ...", and "start reducing at Z position ...". How is it?
@MathijsG see <https://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5>. Search for the keyword adaptive.start. It should work like this. Any comments?
adaptive.start
When the number of state entries exceeds this value, adaptive
scaling begins. All timeout values are scaled linearly with
factor (adaptive.end - number of states) / (adaptive.end -
adaptive.start).
adaptive.end
When reaching this number of state entries, all timeout val-
ues become zero, effectively purging all state entries imme-
diately. This value is used to define the scale factor, it
should not actually be reached (set a lower state limit, see
below).
Maybe we can check how it's supposed to work in FreeTrack and in the commercial TrackIR? I have no experience using the feature yet, but I did had times in games where I would really have liked the feature.
Please do. I don't use competing software.
About max Z value I see two options: a) arbitrary - eg. highest value of game axis on Z mapping graph, b) user dependant - lets give to the user ability to put on graph "max reduction point" (just like "curve" points).
Also question is: where to put slider? Good place would be mapping window. It would be convenient because of easy access.
And would it be fixed bound to the Z axis or would it be possible to select one axis which value can be used to reduce other axes?
I'll see about making the options dialog less cramped while still making sense.
@MathijsG I'd rather bind it to movement along the Z axis, especially given that the user can remap input to whichever other DOF they prefer.
I think, maybe we should have a test box for how much reduction applies for a particular rotation value, given the "reduction" sliders' positioning at the given moment.
[removed, bad idea]
As a side note, can we ever use the term "axis" correctly in the software?
It's also funny how movement along the X axis corresponds to the pitch DOF, not the yaw DOF. FML. :-1:
How many sliders with what semantics? Do we need a "Z start" slider? Definitely we need a coefficient slider and a box for testing at least.
For this function in the future :) he was very happy.
Missed this while being busy unfortunately.
I think we should have a slider for the reduced movement factor, and by what amount.
Or maybe a single axis which is drawn over the Z graph, so you can finetune your own weird setup. Maybe someone wants the reduced responsiveness of other axes be in effect at the top end of their Z-graph, wil another one wants it lineairly along the whole Z axis from zero to their setup end.
Not until extension support hits.
Very much please carry out the reduction of the sensitivity.