About the "Scale" Slider in Multifunplayer

Yea, and this is how scale was designed to be used:

Assume red is now physical pitch/roll range, the green output range is set to 0%-100% but the script is very flat because the scripter assumed that the device will move way more then the device you are using.

So you can set the scale to more than 100% to boost the script, and in turn gain more physical movement.
Of course the script will be clipped to the output range if it gets scaled too much, which is why I plan to use different scaling methods in the future.

2 Likes

However, this method does not seem to work in XTPlayer, so how can we unify it?

Just let XTPlayer users find their range in XTPlayer. If the slider doesn’t update the position, they can use a dummy script that goes from 0-100.

This method is indeed more elegant. I think you can make an initial setup tutorial for the OSR series.

Scaling should be independant of a 50 centered script, or free positions. But as reference point using the 50 centered state as it is now is a good approach to at least test whether a diffirent algorithm works.

While i dont have exact formulas, or fix some edge cases, i do know things it should consider and in which ways. With at least example formulas.

We dont even need to know the center as we already do get scaling values from the positions alone!

Using the outer postions as a baseline for scaling we for example we have 10 remainder at the bottom and 70 at the top. This can easily be used as a ratio for extending: 10/70
And alternatively, using the center, this can also be a ratio like 20/80. But the reason i use 10/70 is because of the case where the stroke is at 100 or 0 (to which the resulting value remains 0 here. for rotations the center might work better though)

To use the ratios, you need a formula like [ratio] x [stroke length] x [factor]. (or 20/80 if using the center instead of remainder). Important note is that factor is the adjustment factor (not the real factor)! If we are doubling this means its a 1 as we want to add 1 factor. Reducing to 1/3 means ofcourse removing 2/3, so a factor of 2/3 (0.666…), and adding 50% means 0.5.

For the 20 length 10-30 stroke, this then would result in the following if we say a doubling in speed:
10/80 x 20 x 1 = 2.5. 10-2.5=7.5
70/80 x 20 x 1 = 17.5. 30+17.5=47.5
And yes, a 7.5-47.5 stroke does end up being 40 in length, meaning a proper doubling.

If the middle was near the 50 area, the ratios are also close to 50/50 giving a balanced spread in both directions.
But even then, if a rotation script is mostly near the 25 instead of 50. it will still do a 25/75 spread resulting in similar increases, and in this case bring it closer to (and potentialy even over) the 50 position.

I hope this does inspire into some other calculations that can be used, since none of these calculations require anything exotic this should even be quickly doable on the fly.

But we arent done here since this was just 1 stroke on its own. If we have a 30-10-50-30 pattern. the strokes will generate diffirent end positions.
Here we could just decide to average them out equaly if we want to be lazy, but that might not increase all strokes equaly in length as a result though.
But again, we can still decide a ratio for balancing to get around this. Now using the stroke before and after. For example the speed itself might be considered as part of the calculation (so a slow speed stroke wont adjust it as much as a fast stroke). This could require some trial end error to find some good parameters.

That last part is something i cant easily think of as it would require testing to find what works well. Speed is just 1 of the examples that i think could give a good result. You could also use the added distances and make a factor of those. Or even mix multiple parameters.
In the end you got all info that you need from the script itself with generaly easily calculated things. There is no need to use exponents, square roots or other fancy calculations as far as i know, and therefor it can remain fast.