Evolution engine mutating craft incorrectly

[themonthlydaily]

Describe the bug The evolution engine applies mutations to symmetry parts incorrectly:

• Mutation is applied to the wrong variant (V**) craft (typically, the first variant of the round does not actually contain the change)
• Positive pole mutation is undone by next sequential negative pole mutation instead of the negative pole mutation being subtracted from the baseline value
• Seed craft are not saved correctly in these cases

To Reproduce

1. Start an evolution process (need to enable this setting in the config file to be able to access the "EV" evolution window) and run using default settings for several rounds using a seed craft that has gimballed engines and/or control surfaces with authorityLimiter parameters. You may need to run for many rounds to wait for the right symmetry mutations to be selected by the random process
2. Look in the KSP.log file for authorityLimiter or gimbalLimiter being mutated. These are both attributes that apply mutations symmetrically
3. You can see the negative pole mutation undoing the positive pole mutation in the KSP.log file diagnostics
4. Examining the craft files shows that mutations are also being applied to the reference craft

Expected behaviour Mutations should be applied to the correct craft

Logs bug_report_files.zip

• KSP.log file (search for EngineGimbalNudgeMutation to see the mutation being applied incorrectly)
• Associated seed_craft.craft file used as the evolution seed
• Working directory craft files from the <KSP Directory>/AutoSpawn/evolutions directory created by the evolution engine that show the gimbalLimiter value being modified incorrectly in the variants

Screenshots N/A

Additional context

• Note: bugfix PR is in progress and will be attached to this bug report shortly

[themonthlydaily]

Proposed bugfix is here: https://github.com/BrettRyland/BDArmory/pull/639

[BrettRyland]

I'm fairly surprised that the evolution engine still mostly works. It was an experiment from a previous dev, which never worked particularly well and was superceded by the PID auto-tuner (which was it's original purpose). I don't see any issues with the PR to fix this, so I'll merge it after a bit more testing.

[themonthlydaily]

Yeah, I was also surprised it still worked as well as it does! Fully agree that the PID auto-tuner is a better choice for PID control tuning. I'm actually interested in resurrecting the evolution engine to add features that allow it to move parts around (offset, rotation, etc.) and resize them (if they are procedural parts) to see what kind of interesting design evolutionary algorithms can produce.