[Update] XR1 1.10 / XR2 1.5 / XR5 1.8 Versions Released

[dbeachy1]

Hi all,

The new XR patch versions have been released. These versions are relatively minor upgrades that include the following changes and bug fixes:

• Disabled APU auto-shutdown during replays. This allows the APU setting to always track what the pilot originally recorded instead of turning itself off during playback when the person viewing the replay switches the view to a different vessel.

• Fixed a minor memory leak in the payload grapple management code.

• Fixed CTD when you engaged Attitude Hold immediately after starting the XR simulation in glass cockpit mode. [Reported by jrobert]

• Fixed a typo in the XR2's length statistic in the XR Flight Operations Manual. [Reported by Epsilon]

• Fixed XR2/XR5 bug where adding a bay fuel tank caused the fuel to disappear when a) landed on a landing pad, b) main fuel tanks not full, and c) OrbiterAutoRefuelingEnabled was disabled (set to zero) in the XR vessel's config file. [Reported by Pipcard]

• Fixed "Warning: nosecone is closed" audio callout warnings with UCD (Universal Cargo Deck) installed with vessels attached to it. The warning is now only played if the XR's closing rate on a nearby vessel is >= 0.02 m/s over the last one second. This prevents tiny "jitters" in the distance of vessels attached to UCD from trigging the warning.

• Fixed typo on page 50 of the XR Flight Operations Manual in the A NOTE ABOUT TIME ACCELERATION section. [Reported by blixel]

• Fixed CTD when you engaged auto-land mode in the Descent Hold autopilot when the hover engines could not provide enough acceleration to hover the vessel (e.g., while flying low in the Earth's atmosphere with a full load of fuel). [Reported by Matrix Aran]

• Added new XRVesselCtrl method GetCustomSkinName() and bumped XRVesselCtrl version to 2.2. [New API method requested by Xyon]:
  
  

  // Returns the name of the custom skin loaded for this vessel, if any.  NULL = no custom skin loaded.  
  const char *GetCustomSkinName() const;

  e.g., if SKIN foobar is in the scenario file, GetCustomSkinName() returns a pointer to the string "foobar".

Note that there are no changes to the XR configuration files for this release.

As always, you can get the latest XR releases from my Web page. Happy flying!

[Xyon]

Thank you for my call, mate! :D I'll have to bump up XRRR's version dependencies to keep up with you!

---------- Post added at 08:28 ---------- Previous post was at 07:56 ----------

Wait, I spoke too soon. Did you forget to include the new API in your release? I don't have a new header here

[dbeachy1]

Ah, sorry mate, I need to package up a new version of XRVesselCtrlDemo tonight. Sorry I missed that last night.

[EndeavourCmdr]

Quick question Doug, and maybe I missed this in the documentation, but I've been playing with the XR5 quite a bit and I haven't stumbled upon the answer yet. Is there a way for me to see how much fuel / scram fuel / lox etc are remaining in each of the cargo bay slots? During launch, I get messages that the "bay tank 29...24.....31.... etc" or whatever is empty, but a good amount of things happen inbetween, and then I don't seem to have a way to recall which tanks are empty. So I'm just wondering if there is a way for me to verify the quantity or mass of each remaining tank, so that I can jettison the empty ones, and not jettison ones that still have fuel remaining.

[dbeachy1]

You can check the mass of any payload attached in the bay by looking at the Deploy Payload screen on the payload panel (see page 65 of the flight manual for details). The empty mass of an XR5 bay tank as defined in $ORBITER_ROOT\Config\Vessels\CSA_XR5_ER_MainFuel.c fg is 4000 kg, so any mass over that is fuel remaining in that tank.

If you have other, non-standard tanks in the bay, just look in that tank's .cfg file in the Config\Vessels folder to find out its empty mass; any mass over that is fuel mass.

[dbeachy1]

Quote:

Originally Posted by Xyon

 Wait, I spoke too soon. Did you forget to include the new API in your release? I don't have a new header here

Quote:

Originally Posted by dbeachy1

 Ah, sorry mate, I need to package up a new version of XRVesselCtrlDemo tonight. Sorry I missed that last night.

OK, I put the new XRVesselCtrlDemo 2.2 package up on my Web site.

[Xyon]

Yay, thanks Doug! *snatches five copies just in case and huggles the new header*

[Interceptor]

Hey Doug,I noticed that in the XR5's scenarios theres a line that says ladder,yet the Vanguard has no ladder that I know of,is this a typo?Thanks

[dbeachy1]

It's a (harmless) typo; that scenario was probably originally cloned from a similar XR1 scenario.

[Interceptor]

Hi Doug,I have been trying to get my the XR''s panel to work in the D3d9 client in 1600x1200,but when its"displayed the panel is too big,and I have to scroll to see everything,this does not happen in the default orbiter,is there any way to remedy this?BTW I am running the D3d9 in full screen,not true full screen.Thanks

[dbeachy1]

First, make sure your Panel Scale setting is set to 1.0 in the Video Parameters tab of the Orbiter Launchpad. If that is already the case, then something odd must be going on because the XR code automatically detects the video resolution and selects the optimum 2D instrument panel to load. If it's selecting the 1920-pixel-wide panel for your 1600x1200 monitor you can manually select your preferred panel by setting this in your XR configuration file(s):

#--------------------------------------------------------------------------
# Define the 2D panel resolution that the XR2 should use.
#
#  0 = Autodetect (default)
#  1 = Use 1280-pixel-wide panels
#  2 = Use 1600-pixel-wide panels
#  3 = Use 1920-pixel-wide panels
#
# The default value is 0 (autodetect).
#--------------------------------------------------------------------------
2DPanelWidth=2

[Keatah]

Do these releases have the updated heating code that was made available in this thread -- http://www.orbiter-forum.com/showthr...7&postcount=18 -- my guess is not yet.

[orb]

The thread would be titled XR1 1.11 / XR2 1.6 / XR5 1.9 if they were updated with the new heating code.

[Keatah]

Ohh my bad. Serious bad! I just assumed these were new versions. I first, now, recognized the first post in this thread was from May of 2012. Do you have a desk I can crawl under and hide?

[kwan3217]

Is this the right place for bug reports? Anyway, here goes.

I am running a scenario with two XR2s, and it seems that they interfere with each other. For instance, I have two sitting on the runway at Canaveral. I am planning on launching one into a safe orbit, then launching the second to follow. In order to do this, I need the following spacecraft to be safe on the ground. So, I turned on external cooling and started opening the radiators on the following spacecraft, then switched to the leading spacecraft to ready it for takeoff. When I did so, I then hopped to the external view to have a look at both planes, and the radiator stopped on the following plane. When I switched back to it, the APU had shut off. The APU was off the whole time in the leading spacecraft.

It seems like the APU state is global across all XR2s, or somehow the state of one is contaminating the state of another.

I haven't tried the January 2013 update yet, that's what I will do next.

Edit: Same issue appears in the new update...