Then do you want to untie input settings from individual pilot files altogether? Then what about mods? Have different settings for each mod? Should they be stored in a user's data folder like a proper config file? Lots of stuff to think about for that.
pilot files have been slowing down progress on input code from day one and i think its high time it gits upgraded. my idea is to stick the input bindings in a seprate table like file, stored in the same folder as the pilot file with the same name but different extension. when a user clones a player, the config file is copied for that user, when a user creates a player, the
config file is created with defaults. when a user edits the controls through the configuration panel, the changes are stored in the file. these files would be editable just like any table, can be transferred between computers, users, mods, game dirs, ect.
there is really no reason to merge it back into the pilot file. separate files are easier to edit, easier to back up, can be moved around easily. you can also keep your pilot file synced between your desktop and laptop, each with a different config file for each system. it also provides a convenient way to set default inputs for mods, tcs, and fs2. mods and fs can include a default config file, which can be used when creating new pilots. also custom configs can be used with command line parameters.
once all that stuff is done then coders can begin working on adding new commands, such as better view controls, more axes, multiple jopystics/mice/keyboards, more control functions, possibly even be able to make scripted and freded functions bindable to controls though the games control options screen.
