Is it possible to make max elevator deflection depend on dynamic pressure? Or will that screw up the AP?
That probably wouldn't affect the autopilot, but it wouldn't work because the ship needs more elevator force both at high dynamic pressure (e.g., rotation time) and at low dynamic pressure (e.g., keeping the nose up without using RCS fuel very high in the atmosphere).
In any case, I see two major issues with any kind of "automatic switching" of elevator performance: the first is the "jump" or "lurch" in performance the pilot would suddenly experience when the ship suddenly decreased elevator performance by X percent right after takeoff. The second issue is that there are times when you really want more elevator performance. Speaking personally, I like lots of elevator performance when I'm carrying a heavy payload and want to pull the nose up to vertical or when I'm very high in the atmosphere and want to pull the nose up using just elevators so I don't use any RCS fuel until I absolutely have to.
Therefore, since we can't have automatic settings that make every pilot happy, we either have to have "one size fits all" like pretty much all other Orbiter craft currently do, or we have to have a control the pilot can set to affect elevator performance. Given that the main panels are already full, I want to just re-purpose the seldom-used "Pitch" AF Ctrl setting: the pilot can set "AF Ctrl=Pitch" for takeoff and get all the elevator downforce he wants (the amount of which is set via a setting in the config file), and after takeoff he can set "AF Ctrl=On" to reduce elevator performance (the amount of which is also set in the config file). Then if and when the pilot wants more elevator performance (e.g., to pull the nose up at very high altitude), he can just set "AF Ctrl=Pitch" again to get lots of elevator performance: that setting will now affect the effective "elevator deflection amount" in addition to enabling/disabling roll control. The reason that cannot easily be reflected in the animation as well is because it is because the Obiter core drives the animation automatically; this is set by the CreateControlSurface API call. That is just a minor cosmetic issue, however -- what matters is that the pilot can tweak his elevator performance in flight if he wants to.
Thinking about this some more, I think just leaving "AF Ctrl=Pitch" only control the pitch makes sense. I will change the ModifiedAFControlPitchOption options from being in the cheatcodes section to being "real" config items that are fully supported. How about this:
# If 1 (enabled), 'AFCtrlPerformanceModifier' settings will be used. The default is 0 (disabled) so that novice pilots who don't know to set 'AF Ctrl=Pitch' for takeoff will still be able to rotate with full payload.
EnableAFCtrlPerformanceModifiers = 1
# The first number is 'AFCtrl=Pitch' mode (increase elevator performance by 20% in "Pitch" mode)
# The second number is 'AFCtrl=On' mode (decrease elevator performance by 40% in "On" mode)
AFCtrlPerformanceModifier = 1.20 0.60
Then we can as a group decide on what the best default AFCtrlPerformanceModifier settings should be. If EnableAFCtrlPerformanceModifiers=0 (the default), the ship will simply use the current elevator performance values. That will let novice pilots still "jump in the cockpit and go" without reading the manual, but advanced pilots will just set EnableAFCtrlPerformanceModifiers=1 in the config file and be able to have the best of both worlds -- high elevator performance when they want it and less elevator performance for smooth flight control when they want that, too. If we do this, it will also let me keep the current default elevator performance as-is so that novice pilots can fly without ever using "AFCtrl=Pitch."
What do you guys think? I think it's a win-win.
Anyway, the tertiary HUD lists the door actions twice every time.
Argh! I know what that is -- I must be calling the XR2's superclass, and so that also displays a door message. I'll fix that for Beta-2. Good catch.
Can any other testers confirm the following 2 possible problems I may have discovered?
1) On a clean installation, if "Particle streams" are turned off (unticked) in the Orbiter Launchpad "Visual effects" section, then a CTD results when loading any of the included XR2 scenarios (I tried "Ready for takeoff to ISS" and "Landed at Brighton Beach").
When particle streams are turned back on, the scenario will load and run OK.
That's a good catch; I'll fix that for Beta-2.
2) On a clean install,
Load the "Ready for take off to ISS".
Hit Ctrl F1 to call up the "Orbiter Camera" page.
Select the "Spaceports" option.
Try and swith view to Habana, Brighton or Olympus. You may have to switch views between them 2 or 3 times.
I get a CTD. This happens with every XR2 scenario I tested, but does NOT when I load and run the stock Deltaglider scenario "Dg-S ready for takeoff", or any other of the stock scenarios supplied with Orbiter.
I just tested that here, and it happens in external view when I switch. I'll investigate it here. This is the same CTD that other members have reported as well. Good catch, all.
In Rotation mode I found myself using the Ctrl key (fine thrust control option) because the full thrusters induce an uncomfortably fast rate of change of Pitch/Roll/Yaw.
This is in an unladen ship. I see from the cfg file that the payload capacity is 10795kg so I should test with a full payload simulated before I can accurately assess the RCS systems.
I had tuned the RCS jets to work with full payload, but they still may be too high for a typical payload. I'm OK with the ship feeling "sluggish" with heavy payload, so I'll look into tweaking that for Beta-2.
I've done the same thing, and I've moved ISS so you will not have to chase it for a long time. You can actually dock before you're over KSC again.
Thanks for the updated scenario! I will test this and bundle it with Beta-2.
Doug, can you actually tell where the COG is in the ship, is it about where i suggested it should be?
As computed by Orbiter's Shipedit utility after 83,000 samples, the Center of Mass is as follows:
These numbers are distance in meters from the center of the ship's mesh, so after checking in 3dsmax, the COG is just aft of the payload bay between the back of the bay and the LOX and Fuel hatches. XR ships do not alter the center-of-gravity based on payload mass, so these numbers assume a full payload bay. Note that the reason XR vessels do not alter the center-of-mass based on payload is because the autopilots are calibrated to work with a "balanced" ship, and so they work on an "idealized" model in order to keep the ship as stable as possible under time acceleration.
I see that the default crew names are the same of XR5...
If, when its released, I want to use a scenario with both ships, thats gonna be a minor issue...
I would have to change the names.. and thinking about names its not something I like to do.
But thats just because the crew are supposed to be the same.. Arent there anymore pilots available in Altea Aerospace?
Well, I am open to suggestions.
The current crew names are a homage to Stargate and BSG, two of my favorite TV shows. You can just alter them to your liking by editing the scenario files right after you install the ship.
Doug, There may be some tweaks, but I would hate to see all the XR vessels fly the same - they each have their own personality. I don't think we have a controversy, just normal test pilot/engineer debriefing sessions. What doesn't kill us. . .
I agree with you there. I think the custom "AF Ctrl" settings will work well for this, and the ship certainly flies differently from the XR1 and XR5, even in Beta-1. I'll get the new AF Ctrl config settings into Beta-1a so the team can try them out.
Heh I tried that too, but all that smoke would have Greenpeace on your back in 10 sec. flat.
Why can't we just use the RCS to help out at low speeds? I've been nailing deadstick landings all afternoon. Just keep the speed above 280 m/s untill you can dive at 20° for the PAPI lights. When you're aligned, extend brakes and turn RCS on. Preflare at 600 m and drop gear at 200 m.
You should be able to kiss the RWY at around 120 m/s.
Well, that certainly works, too. However, after the new 'AFCtrlPerformanceModifier ' is in place for Beta-1a we won't have to use RCS anymore.
[EDIT: although, I do like to use "killrot" to hold the nose steady right before touchdown. I was thinking more about not having to use RCS at takeoff.]
Would it be possible to disable the fuel- and LOX hatch anims, while the XR2 is docked?
Yes, that's easy enough. I'll add a config option for that. By default, however, animations will remain enabled so that I don't get "bug reports" from users complaining that the fuel hatches don't work when docked.
