I think you'd need to be more specific with your control complaints. The ONLY two specific complaints I've ever heard is that it didn't follow the dedicated "press key to toggle fly" like BFP/ESF/SOS/etc., but rather went with an alternatively intuitive "press move up to move up". The other bit I've heard is that the jump key wasn't used for moving up while in the air (which wouldn't make much sense due to move up/down being cardinal direction buttons while jump is a action/response button).
I agree, however, that clarifications need to be made in the UI concerning altering power level up/down and transforming up/down. Most of the UI control labels are still the same as they were made in 2004.
The point, when making multiplayer games, is to make them easy to play, but hard to master. Meaning that anyone can play the game, but you need to spend some time playing to compete with good players. So you should consider taking a look at your control scheme.
"Simple, but with depth" is essentially my design credence. My own meandering in the codebase was mostly just an extension on the existing one (RiO's), thus I haven't touched every facet of design to apply this practice. Regardless of that, I don't think you can really dismiss the basic movement controls as being overly complex for the user since they are almost entirely based off of Descent's control scheme -- a scheme that garnered much success/praise for it's movement flexibility albeit challenging spatial awareness.
Might be. But adding truly new control capabilities probably qualifies as cheating. If it's even compatible with the "real" version after the changes.
You could add new controls via code, yes. You could just as easily build a very basic Quake 3 script and bind it to a key press to do the same controls. No, this doesn't qualify as cheating either as a lot of people built their own control schemas from scripts back in the day.
