betaflight / firmware-presets

Configuration Snippets for the Betaflight Flight Controller Firmware
GNU General Public License v3.0
103 stars 570 forks source link

Push UAV Tech Presets to 4.5 #418

Closed spatzengr closed 11 months ago

spatzengr commented 11 months ago

YouKnowWhatItIs

spatzengr commented 11 months ago

@limonspb , do we really want to have 4.5, 5.0, etc... presets spread out all over the place in the 4.3, 4.4, and 4.5 folders?

Seems confusing to me. If it is up to the Author's preference, I would prefer to copy mine into each new version's folder. If others prefer to keep it in an older release folder, by all means, have at it. But for me, if I want to edit, I would first need to find where the file exists, and then if I'm adding something new to it that is only supported in the latest release, I would have to copy it to the new folder and take that version out of the old file's header.

For example: I may add new things to my 4.5 presets for the extra filter options that come with BF 4.5. Just not doing it now.

Also, in the far future, if you have all the presets in the version folders for each release as a hard rule, you can clear out old release presets eventually pretty easily (delete the old release folder). E.g.: In 10 years, we should not need any 4.X presets and can clear those out. However, if some of the fields in the 4.3 folders keep getting future release header tags added, you cannot do that quite as easily.

spatzengr commented 11 months ago

@SupaflyFPV , lets get @limonspb thoughts on the above.

limonspb commented 11 months ago

@limonspb , do we really want to have 4.5, 5.0, etc... presets spread out all over the place in the 4.3, 4.4, and 4.5 folders?

Seems confusing to me. If it is up to the Author's preference, I would prefer to copy mine into each new version's folder. If others prefer to keep it in an older release folder, by all means, have at it. But for me, if I want to edit, I would first need to find where the file exists, and then if I'm adding something new to it that is only supported in the latest release, I would have to copy it to the new folder and take that version out of the old file's header.

For example: I may add new things to my 4.5 presets for the extra filter options that come with BF 4.5. Just not doing it now.

Also, in the far future, if you have all the presets in the version folders for each release as a hard rule, you can clear out old release presets eventually pretty easily (delete the old release folder). E.g.: In 10 years, we should not need any 4.X presets and can clear those out. However, if some of the fields in the 4.3 folders keep getting future release header tags added, you cannot do that quite as easily.

So i'd like to treat the folder with the file as the earliest version it supports. This has a practical side also: Let's say you decided to slightly change the tune in one of the presets. Having many files for the same presets making you modify multiple files of the same content.

So unless you really want to have different VALUES for different firmwares, let's keep them in one file. Code repetition is bad :) At some point in future firmwares (4.6 or 5.0) the tune will change, parameters will be renamed, or something like that. And that's when the new files will be necessary.

SupaflyFPV commented 11 months ago

@limonspb , do we really want to have 4.5, 5.0, etc... presets spread out all over the place in the 4.3, 4.4, and 4.5 folders? Seems confusing to me. If it is up to the Author's preference, I would prefer to copy mine into each new version's folder. If others prefer to keep it in an older release folder, by all means, have at it. But for me, if I want to edit, I would first need to find where the file exists, and then if I'm adding something new to it that is only supported in the latest release, I would have to copy it to the new folder and take that version out of the old file's header. For example: I may add new things to my 4.5 presets for the extra filter options that come with BF 4.5. Just not doing it now. Also, in the far future, if you have all the presets in the version folders for each release as a hard rule, you can clear out old release presets eventually pretty easily (delete the old release folder). E.g.: In 10 years, we should not need any 4.X presets and can clear those out. However, if some of the fields in the 4.3 folders keep getting future release header tags added, you cannot do that quite as easily.

So i'd like to treat the folder with the file as the earliest version it supports. This has a practical side also: Let's say you decided to slightly change the tune in one of the presets. Having many files for the same presets making you modify multiple files of the same content.

So unless you really want to have different VALUES for different firmwares, let's keep them in one file. Code repetition is bad :)

I did consider what you suggested, ie just updating the version of the file, but then the defaults also had to be changed, and I also chose to tweak my tune with some new learnings/preferences...

So I agree with Mark @spatzengr ...for me, code repetitions are a tolerable cost to a consistent and simple approach for broader preset management. Even with no CLI changes, as preset designers its worth considering tweaking presets based on user feedback for version updates...

I'm happy to work with whatever method is decided tho...

limonspb commented 11 months ago

@limonspb , do we really want to have 4.5, 5.0, etc... presets spread out all over the place in the 4.3, 4.4, and 4.5 folders? Seems confusing to me. If it is up to the Author's preference, I would prefer to copy mine into each new version's folder. If others prefer to keep it in an older release folder, by all means, have at it. But for me, if I want to edit, I would first need to find where the file exists, and then if I'm adding something new to it that is only supported in the latest release, I would have to copy it to the new folder and take that version out of the old file's header. For example: I may add new things to my 4.5 presets for the extra filter options that come with BF 4.5. Just not doing it now. Also, in the far future, if you have all the presets in the version folders for each release as a hard rule, you can clear out old release presets eventually pretty easily (delete the old release folder). E.g.: In 10 years, we should not need any 4.X presets and can clear those out. However, if some of the fields in the 4.3 folders keep getting future release header tags added, you cannot do that quite as easily.

So i'd like to treat the folder with the file as the earliest version it supports. This has a practical side also: Let's say you decided to slightly change the tune in one of the presets. Having many files for the same presets making you modify multiple files of the same content. So unless you really want to have different VALUES for different firmwares, let's keep them in one file. Code repetition is bad :)

I did consider what you suggested, ie just updating the version of the file, but then the defaults also had to be changed, and I also chose to tweak my tune with some new learnings/preferences...

So I agree with Mark @spatzengr ...for me, code repetitions are a tolerable cost to a consistent and simple approach for broader preset management. Even with no CLI changes, as preset designers its worth considering tweaking presets based on user feedback for version updates...

I'm happy to work with whatever method is decided tho...

The defaults have changed due to a couple of new parameters from KarateBrot. I will be rewriting defaults to use PG groups for resetting, so that shouldn't be a problem.

The tweaks in regular parameters should be identical between 4.3-4.5. When you decide to use new parameters - that's when you will need a new file, and that can be done at any time: before or after 4.5 release.

spatzengr commented 11 months ago

@limonspb , I don't look backward. If you want the latest hotness then be on the latest hotness. Otherwise, presets for old versions can stagnate and die. Who really flies a version of BF after it is a year to two old? Only folks who don't care about the latest hotness anyway even consider applying a preset again or caring about such things so much (performance).

I would be too scared too to make a preset change and try to think about how the change would affect 2, 3, or 4 versions deep. Hands full with just making sure a preset is good for 1 version. I would prefer a clear line of differential.

I can understand that for RX preset those, folks want to compile them up. Maybe in that case a folder that is call MULTI VERSION should be made in the director with sub-folders for RX, OSD, etc... to house presets that folks author and want them to span multiple versions. Good option for others I can see, just not what I would prefer for tunes personally.

spatzengr commented 11 months ago

parameters should be identical between 4.3-4.5

@limonspb not always true. i.e.: Anti-gravity. Or was that just a change from 4.2 to 4.3? I don't recall.

limonspb commented 11 months ago

parameters should be identical between 4.3-4.5

@limonspb not always true. i.e.: Anti-gravity. Or was that just a change from 4.2 to 4.3? I don't recall.

that is true, so if you want to have some different values for different firmware versions, then the new files are justified. But if your preset file is just copy-paste from the previous version, let's not copy-paste. And if its not a copy-paste, i want to know why it's not :)

4.4 -> 4.5 tho have the same AG as far as I can see. As for the #$include defaults.txt - i will take care of making defaults.txt work for all firmwares 4.3->4.5

One small advantage of keeping same preset file - users who have added presets to favorites will still have them there in 4.5. But that shouldn't hold from making new files IF some values changes are justified for the new FW version only

spatzengr commented 11 months ago

@limonspb , I changed but am seeing some inconsistencies.

The Karate tunes did not follow this process. They were copied over with no changes outside calling the 4.5 default files.

[Note: for the below, I just overrite the karate 4.5 preset with the copies from the 4.4 folder quick to compare] image

From the above, I'm assuming you do NOT want us to call the 4..5 default file? Let @SupaflyFPV and I know if otherwise.

Hope this helps, mspatz

haslinghuis commented 11 months ago

Using @SupaflyFPV 6" 4.5 preset I got about 5 warnings :smirk:

SupaflyFPV commented 11 months ago

Using @SupaflyFPV 6" 4.5 preset I got about 5 warnings 😏

what warnings?

haslinghuis commented 11 months ago

image

SupaflyFPV commented 11 months ago

image

none of thats in my preset unless I've put in the wrong defaults reference... @limonspb ?

sugaarK commented 11 months ago

image

none of thats in my preset unless I've put in the wrong defaults reference... @limonspb ?

might be the issue

haslinghuis commented 11 months ago

Did not look but maybe includes needs updates?

limonspb commented 11 months ago

@limonspb , I changed but am seeing some inconsistencies.

The Karate tunes did not follow this process. They were copied over with no changes outside calling the 4.5 default files.

[Note: for the below, I just overrite the karate 4.5 preset with the copies from the 4.4 folder quick to compare] image

From the above, I'm assuming you do NOT want us to call the 4..5 default file? Let @SupaflyFPV and I know if otherwise.

Hope this helps, mspatz

That was an overlook by me with karate preset :) As of now you can call defaults from whatever FW. One we have updated defaults, I'll make sure to put them in all presets.

limonspb commented 11 months ago

Did not look but maybe includes needs updates?

They do need update. Replace direct parameter names with resetting pg groups. For that need also my PR with ignoring errors after "defaults nosave"

spatzengr commented 11 months ago

@limonspb @haslinghuis , isn't this something outside the scope of this PR? Is there anything I need to change for my presets?

limonspb commented 11 months ago

sorry for the delay lol as for the errors - we will get them sorted out. Discussion in discord skunk now