hribek
Member
- Joined
- Jun 8, 2009
- Messages
- 217
- Reaction score
- 0
- Points
- 16
These two addons really are great, don't get me wrong. But there are some things that could be improved, I think. Today I went to test the UMmu 2.0 demo scenarios on Orbiter 2010 (100606).
Right in the first scenario "UMmu SDK EVA demo", which features a ShuttlePB in Earth orbit with 4 people on board:
Pressing "M" in cockpit mode (for some reason this didn't happen in external view) will not tell you that the ship is full and you can't add a crew member - that's what I'd expect to happen ... but instead, one crewmember gets ejected vertically/upwards at 2 m/s.
This situation can be hard to recover from, especially if you press M accidentally and don't immediately realize you lost a crewmember.
"C" key changes mesh to a NASA MMU (I think), but pressing "C" again does not do anything and I didn't find a way to revert to normal UMmu EVA meshes.
About the key assignments in general:
UMmu and UCGO are addons. As such, I believe it would be nice not to override default Orbiter key assignments. This poses a problem some er... actually any vessel with UMmu or UCGO support.
"H" key is normally used for changing HUD mode
CTRL + H is normally used for turning HUD off.
UMmu/UCGO overrides both. This is troublesome when controlling a UMmu or the UCGO ISS. The UCGO ISS is missing a "normal" forward view in glass cockpit mode, which makes station orientation problematic.
"A" key is used for HOLD ALT autopilot by default. UMmu overrides it and uses it for opening/closing the airlock.
"S" key is used to show info about number of crew on board, but this assignment blocks user from using Shift+S for selecting the surface MFD.
The Arrow Freighter (for instance) uses Shift+C to jettison cargo. This is unfortunate, because by default Shift+C is used for selecting the COM/NAV MFD. So in doing that, you accidentally drop a cargo crate and the MFD doesn't activate.
(there might be more ...)
Is there a way to allow the user to change the key assignments? If not, would it be possible to avoid these conflicts? Somehow I don't think having to reassign Orbiter's keymap because of addons is the right way to go - shouldn't it be the other way around instead?
Last but not least, I think UMMu and UCGO could look better by fixing the assorted grammar or typing errors. I'd love to help out with that.
Right in the first scenario "UMmu SDK EVA demo", which features a ShuttlePB in Earth orbit with 4 people on board:
Pressing "M" in cockpit mode (for some reason this didn't happen in external view) will not tell you that the ship is full and you can't add a crew member - that's what I'd expect to happen ... but instead, one crewmember gets ejected vertically/upwards at 2 m/s.
This situation can be hard to recover from, especially if you press M accidentally and don't immediately realize you lost a crewmember.
"C" key changes mesh to a NASA MMU (I think), but pressing "C" again does not do anything and I didn't find a way to revert to normal UMmu EVA meshes.
About the key assignments in general:
UMmu and UCGO are addons. As such, I believe it would be nice not to override default Orbiter key assignments. This poses a problem some er... actually any vessel with UMmu or UCGO support.
"H" key is normally used for changing HUD mode
CTRL + H is normally used for turning HUD off.
UMmu/UCGO overrides both. This is troublesome when controlling a UMmu or the UCGO ISS. The UCGO ISS is missing a "normal" forward view in glass cockpit mode, which makes station orientation problematic.
"A" key is used for HOLD ALT autopilot by default. UMmu overrides it and uses it for opening/closing the airlock.
"S" key is used to show info about number of crew on board, but this assignment blocks user from using Shift+S for selecting the surface MFD.
The Arrow Freighter (for instance) uses Shift+C to jettison cargo. This is unfortunate, because by default Shift+C is used for selecting the COM/NAV MFD. So in doing that, you accidentally drop a cargo crate and the MFD doesn't activate.
(there might be more ...)
Is there a way to allow the user to change the key assignments? If not, would it be possible to avoid these conflicts? Somehow I don't think having to reassign Orbiter's keymap because of addons is the right way to go - shouldn't it be the other way around instead?
Last but not least, I think UMMu and UCGO could look better by fixing the assorted grammar or typing errors. I'd love to help out with that.
Last edited:
