UPDATE
Well, I've done some more noodling around and poking about, and found that my installation is working for 2010; in fact it is working so well that I haven't found a way to break it again. The only thing is I now realize I have to assign a different key to toggle the nosecone, or else it will keep opening and closing every time I want to pitch up.
In a nutshell, this has happened:
- I opened PowerShell and pasted in the commands given by Heilor; fired up Orbiter from the PS window and it worked fine.
- I then tried running Orbiter from both the Windows app icon and from Windows Explorer, and it worked fine in both cases.
- Heilor suggested that the PS commands might only work in conjnction with the DirtyHand keyboard app I mentioned in post #8. I confirmed that wasn't the case, but thought the DHM background service on the PC, which exists to serve the connection to the Android device, might still be needed. I stopped that process, and Orbiter 2010 still works fine.
- Thinking that there might be some sort of persistence with regard to what I did in the Powershell session, I restarted the computer, thinking this would cancel whatever happened in the PowerShell session. I fired up Orbiter 2010 one more time, from Internet Explorer. And once again, Orbiter worked fine. (It might be interesting to see what would happen if I popped the battery before rebooting, but I can't do that on this machine.)
So, in a nutshell...I'm confused! I can only assume that I was concentrating so much on Orbiter 2006 the other day that I missed all this. I do tend to use 2006 a lot because I like the Project Mercury addon, but when I first thought the PS fix was working, I might have been in 2010 without realizing it. I've been using the "DG-S Ready For Takeoff" scenario for testing and it looks much the same in both versions in Orbiter.
---------- Post added 04-19-15 at 04:49 AM ---------- Previous post was 04-18-15 at 11:10 PM ----------
Was the comma/period the only thing you changed, or did you also change the keyboard mappings for the numpad stuff, possibly to correspond to the letters on the keyboard where they would be?
I missed this before.
As a matter of fact, I did assign the 3x3 block of keys bounded by "7" at the upper left and "L" at lower left. So for example where the stock keymap.cfg had RCSUp = NUMPAD2, I changed it to RCSUp = K. LPRCSPitchUp = NUMPAD2 CTRL got changed to K CTRL, and so on. I see that my changes incur a number of conflicts with stock setup, like the nose cone control I mentioned above, but I'm sure I figure out some other reassignments that will eliminate the problem.
Every computer I've seen that has the "hidden" numpad uses those same keys, so I assume it's a standard thing.
---------- Post added at 10:33 PM ---------- Previous post was at 04:49 AM ----------
ETA: The hidden numpad may be standard, but at this point I don't know if it has anything to do with the improvement. I simply thought those keys would be the most logical reassignments.
Another thing I forgot to mention is now all the GUI-based shortcut attitude controls now seem to work by mouseclick, thought not by touch screen. I'm not sure why that is, but am wondering if whether this behavior will change if I fold the screen all the way around and use the computer in touchscreen only mode.
