XR2 Public Release Candidate Testing

Followed Steve's advice about throttling back to 40% right after wheels up and maintained a 20 degree pitch angle when I engaged the SCRAM engines.
I use a slightly different technique. Set thrust to 90% and release brakes. After liftoff, continue rotation to 45 degrees to keep the airspeed between 200-210 while the gear comes up. Once up and locked, reduce pitch and begin the turn. This makes for a less hectic takeoff not having to do two things. It seems with the landing gear changes, rotations are much smoother and I haven't needed the control modifier, but I'm wondering if its simply too overpowered.
 
Currently we're testing without any payload, so it won't accelerate as hard on takeoff with 10.8 metric tons of payload in the bay. However, the XR2 does have a lot of engine power. I can reduce thrust somewhat if that is the consensus from the Beta team -- thoughts?

Here's how I like to take off:

1. Throttles to 100%.
2. When the "Rotate" callout occurs, hit ALT-S to engage Airspeed Hold at the current airspeed.
3. Rotate and turn to ascent heading.
4. Hit SPACE BAR to disengage autopilot and push throttles to full power. Climb at ~80 degrees pitch to 22 km or so.
5. Level out and accelerate to mach 3.5.
6. Engage SCRAM engines and follow normal SCRAM ascent.
 
I personally like the power... How many g's do you pull under full thrust though?

Also, not related to the power levels, if you want to takeoff with an even shorter run or perhaps with a fully laden craft, you can trim the elevators to push them further up past their usual position and get an earlier rotation.
 
That's a good idea about elevator trim -- I hadn't thought of that. As for max G's, without any cargo the ship can pull just over 5 peak G's with both the SCRAM and main engines at full throttle. An empty Vanguard can pull 3.8 peak G's, and the XR1 about 2.5 peak G's. Of course, the XR2 is designed to carry up to 10.8 metric tons of cargo. so its acceleration numbers will be lower with payload in the bay.
 
I too love the power available.
I tend to throttle back to 40% whilst STILL rolling down the runway. On climbout I alter the throttle to keep speed under Mach 0.8 whilst climbing at 40-50deg up to 20km+. Levelling off to a climb at 10deg I bring the throttles up to accelerate to Mach 3.5 at around 23km, where the SCRAMS become functional.

I have got into LEO with around 60% fuel remaining in about 10minutes as compared to 20mins for the XR5. This is a high performance vehicle. It is more SR-71 or XB-70 than B747, and I bet the Blackbird jockeys never complained about too much power.

On sub-orbital atmoshperic testing I got some amazing results. From Habana to the Cape (640km/400miles with 50% fuel load) I reached upto 7000mph and covered the distance in less than 10 minutes !

The hop from White Sands to the Cape (2400km/1500 miles with 50% Fuel load) I reached over Mach 11 and took around 15 mins. The Ravenstar is scorchingly fast and is more challenging to fly because of this.

I have flown the White Sands to Cape test several times, and it can get tricky. The speed builds up rapidly (Mach 13+ on one occasion), and I have screwed up the aerobraking to the point of overshooting the Cape by 350km.(I did nurse her back to a feather light landing at the Cape R33).

Testing of launch to orbit, rendezvous and Ummu operations have proceeded flawlessly.

Returning from 200 X 200km LEO aiming for re entry angle of 1.2 - 1.3 deg, the de-orbit burn at at around 8400km from Cape, I found AeroBrake MFD (Ver 0.95.2) displaying oddly fluctuating data. My solid trust in this MFD was being questioned, and I chased the guages a bit with the attitude auto pilot altering my rentry AOA around the 45deg mark by as much as + and - 5deg.

The re-entry seemed hotter than a similar descent profile in an XR1 or XR5. The temp guages reached over 2000deg on the nose cone with the hull and wings at around 1600deg. Maybe AeroBrake had "misguided" me into piling in at around 47.5deg causing the extra heating, but it was a hairy 90seconds or so as I watched helplessly as the nose cone temp rose and rose...I was carrying around 35% main fuel so maybe the extra weight contributed.

Happily the Ravenstar delivered and returned safely for an uneventful approach and landing.

The engrossing complexity of the XR spacecraft has meant that I have spent most of the time happily inside the cockpit, missing out on the sumptious graphics. During my slightly panicky re-entry I almost missed the glowing hull effects.. Wow!

This is an amazing package. Performance, versatility, capability and stunning good looks.
 
As for max G's, without any cargo the ship can pull just over 5 peak G's with both the SCRAM and main engines at full throttle.

"In thrust we trust"

Considering that you have no need to use both scrams and mains at the same time, apart from having fun, that sounds reasonable to me:) It's power definately makes it challenging to fly correctly... It is stonkingly fast too, max speed i've reached in the upper atmosphere with all 4 engines on full is mach 36... which i did without really paying attention and burned up because i didn't watch my temps. I wonder if someone who's better at navigation than me could transfer directly from the earths atmosphere to the moon, using the scrams and mains to build your escape velocity before leaving the atmosphere... yknow, do it all in one burn from the tarmac to the moon.:)
 
Regarding reentry heating, the algorithm has been tweaked for the XR2 as well as the next versions of the XR1 and XR5, so that's why the temps are different from what people are used to with current XR vessels. It may still need some tweaking, though, so if the hull heating rate is too high (or too low), please let me know. I usually perform my reentries at a one-degree slope at 40 degrees AOA, so a steeper slope and/or AOA will heat up the hull accordingly.
 
Last edited:
I hate doing this plus more

So i hate doing this because you said not to have new suggestions but i think these are very crucial.

Things needed

1. An ejection system for the ummu like on the dg4
2. The inclusion of turbo packs may be helpful. Also like they can be deployed on the dg4

Bugs

1. When taking off with gear down and continiung until brekage. ( alarm goes off) But the gear is just shown as still down on the external view not broken.
 
Well... I managed to avoid posting in the Beta thread this long...

Things needed

1. An ejection system for the ummu like on the dg4

I think that oft-repeated request calls for some sort of standard snappy reply, such as "It had one, but it worked too well and wouldn't stay in the vessel," or "REJECT! REJECT! REJECT!" or "Will it be UMMu compatible?" but better and more "spontaneous". All right, someone plan on being spontaneous the next time the subject rolls around. :)
 
Returning from 200 X 200km LEO aiming for re entry angle of 1.2 - 1.3 deg, the de-orbit burn at at around 8400km from Cape, I found AeroBrake MFD (Ver 0.95.2) displaying oddly fluctuating data. My solid trust in this MFD was being questioned, and I chased the guages a bit with the attitude auto pilot altering my rentry AOA around the 45deg mark by as much as + and - 5deg.

Since you use AeroBrakeMFD frequently, I'd like to assume that you've done this already...but just in case... Have you trained AeroBrake for the XR2 yet? My understanding is that on craft with flight profiles it doesn't know you have to run the MFD, fly around a bit (possibly do a test reentry, ascent, etc) making sure to hit differrent AoAs and speeds, etc, then save that data with Shift + S (it saves the data to a file with a .ld extension). As to what to do with the created file, I'm not exactly certain (the documentation seems a bit unclear on this). It contains the flight profile the MFD would need, plus the PID algorithms for the MFDs autopilot. Perhaps it will use it automatically. :shrug: Just some food for thought...

So i hate doing this because you said not to have new suggestions but i think these are very crucial.

Things needed

1. An ejection system for the ummu like on the dg4
2. The inclusion of turbo packs may be helpful. Also like they can be deployed on the dg4

Bugs

1. When taking off with gear down and continiung until brekage. ( alarm goes off) But the gear is just shown as still down on the external view not broken.

As for Things Needed: #1 has been covered in many other XR series threads. Doug doesn't like the idea of having an ejection system on a civillian spacecraft, and as such, will not implement one. As for #2, I think Doug may implement these in a later version of the beta, though I'm not certain.
 
So i hate doing this because you said not to have new suggestions but i think these are very crucial.

Things needed

1. An ejection system for the ummu like on the dg4

The topic of crew "ejection" has already been beaten to death multiple times for the past year or so. :) But to summarize, an ejection system in a spacecraft is highly unrealistic and will never be implemented in any XR vessels. However, in the XR2 and the upcoming new versions of the XR1 and XR5 you will be able to bail out and each astronaut's chute will auto-deploy.

2. The inclusion of turbo packs may be helpful. Also like they can be deployed on the dg4

Turbopacks will be in an upcoming Beta; there will be a button on the bottom panel to deploy a turbopack next to the ship (as many as you need). We are considering adding a turbopack "access panel" to the exterior of the ship, but that may or may not be implemented: the panel would probably not be reachable from the ground anyway, plus it's basically just eye candy over having the turbopack just deploy next to the ship.

1. When taking off with gear down and continiung until brekage. ( alarm goes off) But the gear is just shown as still down on the external view not broken.

The actual message is "Warning: gear failure." When the gear fails it is not ripped off, but freezes in its current position because its hydraulics and/or mechanical parts fail. This is also how other surfaces work when they fail. In other words, what you are seeing is by design.
 
Currently we're testing without any payload, so it won't accelerate as hard on takeoff with 10.8 metric tons of payload in the bay. However, the XR2 does have a lot of engine power. I can reduce thrust somewhat if that is the consensus from the Beta team -- thoughts?
Yes, but we can use the cargo mass cheatcode set to max payload (CargoMass=10795):)
it is definitely more manageable fully loaded.
Here's how I like to take off:

1. Throttles to 100%.
2. When the "Rotate" callout occurs, hit ALT-S to engage Airspeed Hold at the current airspeed.
3. Rotate and turn to ascent heading.
4. Hit SPACE BAR to disengage autopilot and push throttles to full power. Climb at ~80 degrees pitch to 22 km or so.
Or replace steps 1 and 2 with : set airspeed hold to 200 and. . . engage! :)
Didn't you say somewhere the Vr call should change to a higher a/s with more weight? I still get 130 with max payload.
 
1. An ejection system for the ummu like on the dg4

Here's a stick you can use when beating this dead horse. *hands stick*


Onto other matters, I'm not sure if this has come up already, but the HUD is still misaligned, just a little. When I am coming in with Airbrakes deployed, the message on the HUD cuts off and carry's over to the other side. It's just a little, but I've tested on my machine at work, and at home, and it happens on a clean install with both. Both machines are running different resolutions too, so it's not a res issue AFAIK.

Screenie is attached.

Doug, the gear compression just blew my mind. Twice.

_O.K._
 

Attachments

  • hudscroll.JPG
    hudscroll.JPG
    65.3 KB · Views: 62
Yes, but we can use the cargo mass cheatcode set to max payload (CargoMass=10795):)
it is definitely more manageable fully loaded.

Yes, I concur. The consensus seems to be to leave the thrust level as-is, so that's what I'll do.

Didn't you say somewhere the Vr call should change to a higher a/s with more weight? I still get 130 with max payload.

I had raised the Vr call slightly to 130 m/s from 110 m/s, but for Beta-1b the Vr callout does not change based on cargo weight. The thing is, if 'EnableAFCtrlPerformanceModifier=1' in the config file then the actual Vr will be different depending on how 'AFCtrlPerformanceModifier' is set. However, what I can do for Beta-1c is just assume from a Vr callout standpoint that the user is still using the default EnableAFCtrlPerformanceModifier setting and then vary the Vr callout accordingly -- so the Vr callout will vary linearly depending on payload mass. It still won't be perfect, but it should be OK. This enhancement will also be in the next XR5 release since the ships share a common codebase.

Here's a stick you can use when beating this dead horse. *hands stick*

Thank you! Now please remove said dead horse from the hangar. :lol:

Onto other matters, I'm not sure if this has come up already, but the HUD is still misaligned, just a little. When I am coming in with Airbrakes deployed, the message on the HUD cuts off and carry's over to the other side. It's just a little, but I've tested on my machine at work, and at home, and it happens on a clean install with both. Both machines are running different resolutions too, so it's not a res issue AFAIK.

That's a good catch. The "Airbrake Deployed" HUD needs to be updated to be aware that it's rendering on a VC HUD and adjust the coordinates accordingly. This will be fixed in the next Beta.

Doug, the gear compression just blew my mind. Twice.

_O.K._

Thanks, mate. Please schedule an appointment with our resident shrink at Altea Aerospace headquarters for a free therapy session. :)
 
That's a good catch. The "Airbrake Deployed" HUD needs to be updated to be aware that it's rendering on a VC HUD and adjust the coordinates accordingly. This will be fixed in the next Beta.
Since only one bar of the pitch ladder shows, I figured this was a "size" issue with the entire HUD rather than individual bits. What is already on the 'todo' list for the HUD so I'll know what to report?
 
Well, the size of the VC HUD is pretty much locked since it already fills the frame. It's always tricky rendering on a VC HUD because it is much smaller than the 2D HUD. So it's hard to get "perfect," but I'd like it to be as good as we can get it. I'll take a closer look at it tonight.

If you're talking about why the pitch ladder is so small, unfortunately that is unavoidable.

[EDIT]

OK, I made a few tweaks to the VC HUD for the next build:

1) Moved the "Airbrake Deployed" message so it doesn't get clipped.
2) Moved the wheek brake messages to the bottom of the HUD and abbreviated the text so the messages don't get clipped.

The 2D and glass cockpit HUDs are unchanged. If there's anything else I missed, please let me know.
 
Last edited:
Since you use AeroBrakeMFD frequently, I'd like to assume that you've done this already...but just in case... Have you trained AeroBrake for the XR2 yet? My understanding is that on craft with flight profiles it doesn't know you have to run the MFD, fly around a bit (possibly do a test reentry, ascent, etc) making sure to hit differrent AoAs and speeds, etc, then save that data with Shift + S (it saves the data to a file with a .ld extension). As to what to do with the created file, I'm not exactly certain (the documentation seems a bit unclear on this). It contains the flight profile the MFD would need, plus the PID algorithms for the MFDs autopilot. Perhaps it will use it automatically. :shrug: Just some food for thought...

I use AeroBrakeMFD with the XR2, and have used it for around 50 re-entries so far, and it's been right on the money. I haven't gone through this madness with saving profile data... it just works.
 
If you're talking about why the pitch ladder is so small, unfortunately that is unavoidable.
No, actually I was thinking it was too big/too close - I was expecting at least 3 bars (20deg spread) to be on the screen at a time rather than just the one.
 
No, actually I was thinking it was too big/too close - I was expecting at least 3 bars (20deg spread) to be on the screen at a time rather than just the one.

The distance between VC HUD pitch bars is greater than on the XR1's VC HUD. The reason is because the XR2's cockpit is farther forward from the ship's center-of-mass (rotation point) than the XR1's and so the cockpit itself must "rotate farther" as the nose pitches up or down before reaching the next pitch ladder -- and so the distance between the ladders on the VC HUD is greater.

If you switch HUD views from VC -> 2D and back again the HUD pitch ladders match as expected (i.e., 10 degrees pitch on 2D HUD also shows as 10 degrees pitch on VC HUD), so the VC HUD is being rendered correctly.
 
No, actually I was thinking it was too big/too close - I was expecting at least 3 bars (20deg spread) to be on the screen at a time rather than just the one.

yeah there does seem to be something wierd going on with the hud, the bars and other tracking information, docking overlays and so on seem to be stretched out on the vertical axis for some reason. so if for example you're looking at the ISS and 'locked on' in docking mode the lockon box will be centred on the station if you put it in the middle of the hud, if you change pitch so it's in the upper or lower part then the box will actually be further up or down than it should be, like it's being offset somehow and the offset increases the further it is away from centre.
 
Back
Top