That is a hard to fix, known bug from Tkinter 
There are warnings on the console output window that runs in the back. I’ll add a pop-up message instead. Thanks.
Give it a second test. It works a lot better when you scroll all the way down on the “component editor” window, like explained in bold on the top of the window and on the documentation 
Yes, that is also my experience, the tuning results are crisp, and the vehicles move nicely with no overshoot.
If it needs explaining, it probably needs fixing. Ux should be intuitive. This is far from it.
I fully agree. It needs to be intuitive.
How to make it clear that there is a scroll bar and that users need to scroll down?
Don’t have a scroll bar. Put all elements on screen. Have some interactive elements and warnings. Maybe a library of hardware from which to choose. Less typing. More clicking.
At some point, the user shouldn’t even have to care that they are modifying hundreds of parameters. They should just be able to select behaviors.
I had 5 windows open. One with the configurator (that I had to keep closing and opening, apparently by design). One for MP. One for the documentation. And two text editors to ensure I was getting what I wanted in the params. That’s 4 too many.
@Yuri_Rage I added this BR thanks.
You can not have configurator and MP open at the same time, both want to access the same hardware, it will not work.
No, per design you:
You only need AMC and a browser window. All the parameter documentation in inside the AMC in mouse over pop-up.
My point is that I didn’t feel I could trust the configurator alone, so I double and triple checked often. And you can keep MP open if you disconnect.
I understand what I did wasn’t the design intent. But it was what I felt necessary to get proper results.
Also, auto connect kept trying to connect to a different COM device. So I had to close and reopen after:
Well, yes. As long as they first explain which hardware they are using and how each component is interconnected to each other. 
To do what you want you need a tool were you select behaviors and it will:
The current tool only does step 3. You need to feed it with information from steps 1 and 2.
That is an annoying pymavlink bug on windows. I did not have time yet to go after it, sorry.
This is almost certainly a step too far.
But this is perhaps doable in a slightly different way:
Via a library of supported hardware, when generating the template, the user could be presented with dropdown lists. For example (and not limited to):
Future stuff for sure (and not easy!). I know it’s a work in progress, but I think this is the general direction we should take.
The hardware information in the “component editor” window is already user to automate parameters in multiple locations, Making some parameters disappear, appear or change their value. And it is all editable in a .json file. No python code changes necessary.
It automatically edits the files as you go, there is no need to generate a perfect template!
But yes, these “hardware dependent automated parameter changes” are far from complete and must be improved and extended with input from you and other users. Thanks for your input!
In your double and tripple checking in mission planner did you find any instance where a parameter was unexpectedly changed by AMC?
Some of this can be automated by parsing things like hwdef files, such that a bespoke hardware library doesn’t have to be maintained.
Already mentioned the niggling issues regarding add/delete along the way. I’ll add that any *ENABLE parameter can have the side effect of forcing “N/A” params to show up until that feature is actually enabled.
I didn’t see any bugs in that regard, though I did a lot of back-and-forth because of my initial mistake regarding template setup.
I did somewhat frequently notice this: I’d make changes to the displayed params without actually advancing to the next step, in expectation of doing that soon. But if I had to close and reopen (the reason for which was already mentioned), those changes weren’t saved. It only saves on step advancement (or writing params to hardware), but not on live changes. So there was duplicate work (which was part of my rationale for having text editors open).
Is there a way to “remember” the COM port and poll for that port’s existence when disconnected?
Or like MP, make it a menu selectable item that is always available to the user?
It is usually better to have an almost stateless software. It prevents bugs and is considered good design. So I do not store for now. On linux the issue does not exist. My guess is that @tridge and other pymavlink developers do not use windows often enough to notice this autoconnect bug.
I had that in the first couple of versions of the software, but abandoned it to make the software interface less cluttered and simpler to use. This was a good decision, once that pymavlink bug is fixed
I strive to make the interface easier to use, with no hidden menus. So far looks like I have not done a good job at intuitiveness, but I feel I did a good job at minimalism
Of course best to fix the root cause, but a “force reconnect” option, even if just a temporary hot key (and not a permanently hidden “feature” like MP has so many of…) might work for now.
There is value in both, of course! I used to write a lot of mission planning and execution tools when I managed an austere flying operation. I’d start by writing something for myself - sometimes as simple as an Excel spreadsheet with a bunch of formulas and no formatting. Either someone else would notice my use of it, or I would find some value in sharing it. I’d seek out the least computer-savvy team member and hand it to him or her with only a description of what it was supposed to do. If he struggled, I knew I either had more work to do or had to abandon the tool entirely. On the other hand, if he immediately caught on and enjoyed the newfound efficiency, I knew I was onto something and would spend more time refining it.
That is by design, to give the users full control over when the files get saved. Saving only happens when the user selects “write” or “skip” buttons. I was hopping that would be an intuitive way of doing it.
Alternatives:
Or a save changes dialog on app close.
Might be worth highlighting unsaved params with a flag or different color.
There is already a “show only changed parameters” checkbox.