XR2 Public Release Candidate Testing

First and foremost did Doug clearly say no feature requests, but meh... :@
It would be completely irresponsible to include such a limiter. One would only fly with one engine in case of emergency. You as a Pilot should be trained to actualy be able to fly the ship and handle it in an emergency. That means beeing so smart to either bank and sideslip, maybe gimbal the engine and/or throttle down the remaining engine.
Some keen pilots even adjust the throttles and gimbals individualy in order to perform extreme maneuveres. It would be a pitty if that would not be possible any more.

Happy Orbiting

Hey cut it on the rudeness please... :huh:

Smartness has nothing to do with it, neither does training... If that were the case, all these two-engine aircraft outthere with auto-feather, thrust imbalance compensation and auto-yaw wouldn't have these features.

It's a great ship, but it is a flaw in my opinion, just as it is with it's look-alike, the SR-71. Loss of an engine just after roll should not result in immediate loss of control. That being said, it does happen from time to time out there.

The flaw I see in this design is that with full yaw input, and full gimballing, it still results in a loss of control under most circumstances in flight if full thrust is maintained on the remaining engine. Thus, the suggestion, not request that it should have a thrust limiter.

That's not feature request, that's critical input from test flying it a couple of hours.:dry:

Other than that, it's flawless... It's really a wonderful craft to take out in Titan's atmoshere, great handling on glides... Congratulations to the developpment team.:cheers:

-EDIT-

Actually, to be precise, loss of control occurs with full yaw rudder input and yaw auto gimbal on a single engine at full thrust when the dynamic pressure is less that 8 to 10kPa, right smack in the range of takeoff or slow flight. At the very least, this info should be in the POH...
 
However, the attitude and AoA hold APs seem to totally ignore yaw/sideslip. Was this intentional? S-turns while re-entering are fairly tricky as I have to set the bank in the AP, and manually yaw to keep the sideslip low.

Isn't be whole point of banking to sideslip in the one and later in the other direction and thus traveling a further distance along your path to the target?
Isn't that a S-turn?


-----Posted Added-----


Hey cut it on the rudeness please... :huh:

Smartness has nothing to do with it, neither does training... If that were the case, all these two-engine aircraft outthere with auto-feather, thrust imbalance compensation and auto-yaw wouldn't have these features.

It's a great ship, but it is a flaw in my opinion, just as it is with it's look-alike, the SR-71. Loss of an engine just after roll should not result in immediate loss of control. That being said, it does happen from time to time out there.

The flaw I see in this design is that with full yaw input, and full gimballing, it still results in a loss of control under most circumstances in flight if full thrust is maintained on the remaining engine. Thus, the suggestion, not request that it should have a thrust limiter.

That's not feature request, that's critical input from test flying it a couple of hours.:dry:

Other than that, it's flawless... It's really a wonderful craft to take out in Titan's atmoshere, great handling on glides... Congratulations to the developpment team.:cheers:

-EDIT-

Actually, to be precise, loss of control occurs with full yaw rudder input and yaw auto gimbal on a single engine at full thrust when the dynamic pressure is less that 8 to 10kPa, right smack in the range of takeoff or slow flight. At the very least, this info should be in the POH...

I am sorry, if I offended you. I did not mean to come on as strong as you felt I did.
It is just my oppinion, that all those things are nice and usefull in aircraft where you usaly have to land with engines. In a spaceship that usaly lands without engines these things are not so needed.
But you have a valid point about not beeing able to correct the slip with gimbaling and yaw, a maximum thrust value should be determined which enables you to fly straight and that value should be put in the flight manual.
Maybe even marked on the panel.
 
But you have a valid point about not beeing able to correct the slip with gimbaling and yaw, a maximum thrust value should be determined which enables you to fly straight and that value should be put in the flight manual.
Maybe even marked on the panel.

Actually that could be very clearly and simply marked on the engine thrust quadrant with a red line, a tick, the words "SINGLE ENGINE" or any combination of these. On many aircraft that's the case... For the XR2, from experimentation, that's about 75-80% at sea level during takeoff.

Apologies accepted... ;)
 
Isn't be whole point of banking to sideslip in the one and later in the other direction and thus traveling a further distance along your path to the target?
Isn't that a S-turn?

Sideslip is, essentially, a ship's yaw angle of attack. When manually performing an S-turn, you have to use both bank and yaw input to keep the ship in a safe attitude. Having excessive sideslip during re-entry means you're exposing the side of the airframe to the airflow; a problem during heating.

In the XR-2, when I input a new bank angle, the AP starts to roll the ship, but doesn't yaw it. It only appears to be 'looking at' pitch AoA and bank. When both of those criterea are met, the AP holds. However the XR-2 will have inherited massive sideslip after the turn as it has not been yawed to keep the heatshield facing into the airflow.

For instance (I won't make a habbit on frequent comparisons :P) the DGIV's attitude hold AP ensures that sideslip is always at 0 deg; so you only have to input the bank change, and the computer will keep the heatshield facing into the airflow with yaw.
 
Everything I was expecting .... it truly is a work of art ... both in visuals and coding. :cheers: :clap: Hats off to you both Doug and Steve…. You have made Martin proud !

Now - on to the purpose of release candidate …
(verified as per the rules of testing)

1) switch to the CHM > internal view > reported fuel is -1.$ (expected?)
2) working on a undocking/docking issue where when you undock from ISS - the docking port you just left is no longer in the docking MFD ... I'm looking for the reproduce steps.
3) On any planet ro body with gravity - open hatch with cockpit pressurized and [cool] vapor effect falls quickly to the ground - it there a way to give that effect immunity from gravity or is that orbiter code.
4) Do we get extra credit for finding Easter eggs? Well sort of - like:
a. Don't press it unless you really mean it ! which btw is backwards on Kara's side.
b. the credits on the hand holds (?) by each of the pilots butt cheeks. And again I think the one on Kara's side it facing the wrong way. Writing is foreword - just oriented the opposite way compared to Lee (?)
c. internal texture for the retro thruster nozzles include the center nozzle that is visible in the main engine area. Same texture, shrunk but not edited for that nozzle. (ok that one was a nit pick) :)
d. all the marker lights are very believable except the white tail light. It's completely isolated from the fuselage. Tighter to the body would/could make it look as perfect as the rest.

... and my wife doesn't like you for creating this ..... something about not expecting to see me for a week or so. :P
 
Just to add a little on the dynamics of a single engine full thrust loss of control... The faster the ship goes, the more easily it is kept aligned in the airflow, as the air stream will exert more force on the sides if the ship yaws and ends up with a slip angle. The faster you go, the lower the slip angle on a single engine. Above Mach 1, the ship is actually not that hard to control on a single engine at full thrust.

As I indicated above, the "death zone" is when flying at low dynamic forces, such as takeoff or subsonic cruise (less than 15 kPa).

As for flight on Titan, be advised that a full thrust, you can exceed the maximum dynamic pressure easily, even if you point the ship strait up. Care must thus be taken in dense atmospheres.
 
I think the landing gear and hover doors when closed shouldn't take damage except at a certain impact velocity when XR2 detects that it's on the ground. It's a problem when on certain launchers like Energia upon loading a scenario. Orbiter registers XR2 as a payload as being landed and thus causes it damage.
 
Make sure the XR2 is in orbit before attaching to Kulch Payload manager ;)
 
That is exactly what I always do and works, But that changes upon loading a scenario. DGIV as an example doesn't have that issue as it checks whether or not it's gear is up and hover doors are closed to determine if it will take damage.
 
Wow thats one damn fast ship. I could only fly it a little last night (I'm at school right now) and ... just fast :P.
And very very cool :speakcool:

Cant wait to fly it some more...

How fast can you reach orbit in the default settings? I think I did it in... 650 s. more or less... Using both scram and main engines, and riding on the edge of burning the ship....
 
Last edited:
This is odd. No one reported this before and the drop itself seems pretty unlikely.
Please answer the following questions:

Does this occur on a clean install?
Does this happen on the ground, in the air, in LEO, in space or everywhere?
Do you have any similar drops in framerates with any other ship?

I haven't tried it yet on a clean install, but there is a frame rate drop in space, not as bad, it goes from ~80 FPS to ~60 FPS. I theorize that the problem is with the SCRAM heating algorithm... or something like that.
 
I haven't tried it yet on a clean install, but there is a frame rate drop in space, not as bad, it goes from ~80 FPS to ~60 FPS. I theorize that the problem is with the SCRAM heating algorithm... or something like that.

The heating algorithm code's impact to framerate is negligible. If you are seeing a framerate hit of 30% when the SCRAM doors open it is very likely due to a video driver issue of some sort or a buggy third-party add-on. The very first thing is to re-test in a clean installation. The key to troubleshooting is to eliminate possible causes to narrow things down.

If it still happens in a clean install, as a test try turning down the video options in the Orbiter launchpad and see if that fixes it. Also, can you post your detailed system specs?

Is it corret that the gear collapses at -3 m/s?

Not exactly; the gear collapses based on impact energy, so the higher your ship's mass the lower the vertical velocity threshold at which the gear will collapse. At a typical landing weight on Earth, however, 3 m/s is in the ballpark.
 
I have found a bug with the skin
xr2_skin_problem.jpg
 
I have found a bug with the skin

Can you reproduce it?
Can you reproduce it on a clean install?
if you can, give instructions.

This really looks like a local error with your graphics card.
 
WOOOOOOOO!!! :cheers:
Seriously, im beyond impressed. I flew it around the atmosphere. Handles BEAUTIFULLY, it is so easy to control, much easier than the XR1/XR5. Being in the VC for the first time almost made me cry (not really :P).
Reentry is also not a problem. I came in very hard (200m/s, i usually do like 60) and it didnt overheat. Detail is EXTRAORDINARY. For example, did anyone notice that the mat under the pilot's feet says ravenstar? Did anyone notice that there is a sticker that you can see from the front left passenger seat that credits the creators? Well I think i have a new favorite ship...:beach:
Thanks so much Doug and Steve for all your hard work!!!
 
I have not had that bug again so I think it was just that time
 
Impressive work all around. Took a little getting used to since I'm so used to flying slow lumbering beasts like the XR5 and DG-EX. On my first attempt I climbed out too steep and immediately overshot my intended vertical velocity. I ended up at 70km at mach 5. I thought it'd be ok to just run the scrams until I lost enough altitude for them to pick up some air, but before I knew it I was falling like a rock, hull temps soaring, and ended up at 38km before the scrams stopped my descent. The nose indicator was visibly shaking as the atitude autopilot struggled to maintain control and the computer was screaming "wing stress" and then "wing damage" (I think that's what it said - I panicked when I heard it). I finally made it to orbit after expending every ounce of scram fuel and ripping off my left aileron. I was hoping I could survive the delicate trip home, but orbiter crashed before I could try (not because of any XR bug, just pebkac). Since I didn't get to find out for myself I have to ask, do the XRs have a lower maximum safe hull temp after taking wing damage like that?
 
There is a known Orbiter core bug with applying custom skins and vessel focus switching or zooming out so the visual is destroyed and then zooming back in to recreate the visual; the same bug occurs with the default DG. In a nutshell, weird problems can occur anytime you use a custom skin and the ship's visual is destroyed and recreated.

Since I didn't get to find out for myself I have to ask, do the XRs have a lower maximum safe hull temp after taking wing damage like that?

Wing stress damage does not lower the hull temperature limits. However, wing damage will reduce that wing's performance, resulting in the ship tending to roll to one side, which can make it more difficult to hold a stable reentry attitude.
 
Back
Top