RC smoothing auto factor tooltip text for 4.3

[haslinghuis]

Fixes: #2711

[ctzsnooze]

This message will need version control.

The existing message is correct for 4.2. We will need a different message for 4.3.

Perhaps for 4.3 we could say:

"message": "Adjusts auto RC smoothing. 30 is the default.
Higher values smooth RC inputs more - e.g. 60 for HD freestyle or 90-120 for cinematic flying.
Note: Values over 50 will cause appreciable stick delay.
Lower values, eg 20-25, will transfer some of the RC control steps into the motor signals, slightly increasing motor heat, but will reduce RC delay slightly. This may be useful for racing."

[asizon]

No need to attr here the tootltip for version < 1.44 since it is already defined and named in the html part.

[haslinghuis]

Now changed the values to be defaults using version control to minimize translation work

[ctzsnooze]

The other numbers, where we mention higher values, won't be correct for 4.2.
I think it is better to have entirely separate tooltips for 4.2 and 4.3.
These situations arise from time to time.
We shouldn't change the 4.2 tooltip.
We probably have a similar issue with antigravity gain. In 4.2 it could be pushed to 9 or 10 and would only increase I. In 4.3 it increases P also, and has inherently higher gain, and typically should NOT be pushed to 9 or 10. I haven't had time to check all these tooltips but we will need separate tooltips, or a tooltip that explains "in 4.2, do X, in 4.3 do Y".

[haslinghuis]

We are free to add some extra defaults for those values too.

[asizon]

This need a lotof maintain @ctzsnooze , we should use generic tooltips for all versions

[ctzsnooze]

I agree, I think it would be simpler to just have the text for the tooltip. I don't think we need the code that pulls the default value by version. Just change the tooltip, if needed, by version.
If we think about antigravity, say, at one version we make a big change, then for many versions after, most likely no further change.
But when we do make a change, it is not just the default value that changes, but perhaps the way the code works, or the tuning information.
So my feeling is that we should keep tooltips as simple as possible, but version control them so that when they change significantly, we make a new tooltip for the newer version.
We can't have the same tooltip for all versions, it would just be useless in many settings. Eg transition. Now we have jitter reduction we don't recommend transition anymore, so we should change that tooltip to explain the new situation in 4.3, and that tooltip would be different from the tooltip for transition before 4.3

[ctzsnooze]

Tested, works correctly.
Maybe update the text itself to:

Adjusts the amount of auto RC smoothing.<br />The default is 30.<br /><br />Higher values, e.g. 60 for HD freestyle or 90-120 for cinematic flying, will smooth out sharp RC inputs, giving smoother video, but may cause noticeable stick delay.<br /><br />Lower values, eg 20-25, may be useful for racing, giving slightly less RC delay at the cost of slightly warmer motors.

[McGiverGim]

I have seen that we have a lot of "default" values in the tooltips for Betaflight 4.3. This that seems a good idea will be a nightmare of maintenance in the future, when something "changes" and we start recommending different values.
And any change in the text makes that all the translators of all the languages need to translate it again.

[haslinghuis]

@McGiverGim Agreed. We need more generic messages. Adding a defaults struct in fc.js we could make defaults independent from translated messages.

@ctzsnooze adapted your latest suggestion to use a variable for default firmware version. Is the message generic enough to use for 4.2 and later firmware?

[haslinghuis]

@chmelevskij please check as it's working but I don't like / understand the console output:

localization-04da3b28.js:132 i18next::interpolator: missed to pass in variable autoFactor for interpolating Adjusts the amount of auto RC smoothing.<br><br>The default is {{autoFactor}}.<br><br>Higher values, e.g. 60 for HD freestyle or 90-120 for cinematic flying, will smooth out sharp RC inputs, giving smoother video, but may cause noticeable stick delay.<br><br>Lower values, eg 20-25, may be useful for racing, giving slightly less RC delay at the cost of slightly warmer motors.

[ctzsnooze]

@McGiverGim tooltips will need to change when the a parameter becomes functionally different. By that I mean, when it works a differently, or needs to be adjusted in a different way, compared to earlier versions.

This is relatively infrequent, but when it happens, the user needs a tooltip that is relevant to the code they are running, and doesn't give them bad advice. Two examples in 4.3 are antigravity gain and rc smoothing auto factor.

We don't need explicitly to include default values in tooltips, but it is very helpful to include advice on how to set the parameter to a range that works effectively.

With Presets, a user may get parameter values that they did not enter, and may wonder if the value is at default or not.

I think it would be very helpful to be able to include the default value in tooltips, or to have some other generic means to show what the default value is, so the user can check if the value is default or not. There is no simple way, otherwise, of doing this.

Hence, having some method to easily display the default could be very useful. If the text for "Default: " could be referenced to a specific message, and the value derived cleverly, there would be no translation effort.

However in practice, when we do make changes that require different tooltips, we will need either a singe 'combined' tooltip in the form, "for firmware after N.N, our advice is P, for earlier firmware, our advice is Q", or, we provide separate tooltips so for 4.2 "our advice is P" and for 4.3 "our advice is Q".

The second seems better to me, especially where significant changes arise, and this will be the case in 4.3 for at least some parameters.

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> FAIL
• assigned to a milestone -> PASS
• cooling off period lapsed -> PASS
• commit count less or equal to three -> PASS
• Don't merge label NOT found -> PASS
• at least one RN: label found -> PASS
• Tested label found -> PASS
• assigned to an approver -> PASS
• approver count at least three -> FAIL

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication