Anyway, we could also make a freeze of the devel branch (in another branch for instance), test it, and doing only bug fixing for targeting a release?
That is the plan. My current commits are mainly adding benchmark tests (scenarios), fixing small bugs and suppressing errors which trigger on init and are just confusing. It just seems to emerge that the FDM / display changes have a rather profound effect - things need to be re-tuned etc,
I guess the main issue is - we all have habits. And we test inside our habits, so we implicitly assume some things. But someone else has different habits. For instance, it never occurred to me before @eatdirt tried the really elliptic orbit with multiple aerobraking phases that we'd need logic to get out of the atmosphere during the entry phase.
I'm doing a stab in the dark here, but I frequently use the option to init only three displays when I need to re-start the simulation frequently - that restricts operations quite a bit and displays which would 'usually' be open simply are not (for instance, I might not have an PFD open at all).
So the test case that works perfectly well for one person simply can do weird things for another person because of the different habits. I remember the weird case of the fuel cell purge that worked fine for me (because I always tested in the GUI) - but it didn't work using the 3d-model buttons - because of a subtle issue with one of the bindings.
Which is why we really need to get to the bottom of the oddities which happen now, because... the changes to the FDM are good, but affect things in a lot of places.
Maybe the manual throttle creates a condition to escape the MECO logic?
Yes, MECO is only commanded when under auto-throttle - though you have the cutoff pushbuttons for that purpose... I'm not sure whether this is the real behavior or whether it's a relic of the times when you could simply blast off with the rocket as you liked (as long as the propellant lasted)...
But eventually, when TAEM came, all pitch/roll controls were frozen. Unless we have coded damages due to funny -G, we could have some transiting logic at TAEM that get skipped if NO Y-JET is selected?
Strange that you didn't get destroyed, probably we simply don't check for negative g, but the frozen controls might be actuator stall - usually a highly irregular entry gets you there.
***
Okay, I have two new ones - starting an APU seems to trigger an APU underspeed alarm while it spins up - this seems excessive and we need to suppress that I guess, we can't worry people with alarms triggering all the time...
And - long-standing issue - the Aerojet DAP is very good at holding zero beta, but it leads to an undamped yaw oscillation with no chance to fix this when not engaged at small beta (I lost another Shuttle as I tried to work my way from a de-orbit burn to an entry) - so I guess this eventually needs to be addressed as well.