New Release XR Vessel Updates for Orbiter 2010 (P1-compatible versions released)

Yestarday was Saturday, and tomorrow is Tuesday. What day is it?
TUESDAY of course!!

Excellent job. :thumbup:
 
Sorry, I've already lost an xr2:shrug:
 
Looks like its not a patch, but download all over again. By small pieces :download:.

But, anyway, it's a great news, XR2 is the most beautiful spaceplane in Orbiter. Thank you.

Just one question: does it support UMMU 2.0?
 
XR Flight Operations Manual said:
Universal MMU (UMmu) 2.0 or newer is mandatory; you cannot fly an XR
vessel unless UMmu 2.0 or newer is installed.
I think that answers your question pretty well :lol: , if you tried to use the old version of UMMU with it you'll probably get a nice warning / crash
 
Woo is correct; UMMu 2.0 is required for the new XR versions. If you try to run without UMMu or with a version prior to 2.0 installed you'll get an error message and Orbiter will exit.
 
That UMMu note on my Web page unfortunately slipped through the cracks last night during the update. I just updated it now.
 
Hi, Can this update be used on Orbiter 2006. ? or is there no need for it.?
 
It's hardly it an update to use Orbiter 2006 :lol: , I'd recommend you have both a Orbiter 2010 and Orbiter 2006 install, so you can use the update while also using 2006
 
Last edited:
Woo842. I do run both 2006 and 2010
 
Last edited:
Hi all,

I just released the next XR patch versions: XR1 1.6b, XR2 1.1b, XR5 1.3b, and XRVesselCtrlDemo 1.0a. These are minor bugfix/enhancement releases. [Special thanks to Woo482 for helping me test these builds before they were released.]

Changes include:

* Fixed bug where PayloadScreensUpdateInterval config option was not parsed for the XR5.

* Fixed bug where XR1 config file parser allowed MainFuelISP = 7 config option without display an error (option [correctly] did not work, however).

* Added the ability to specify a few XR configuration file overrides in the scenario file, which will allow you to change fuel and LOX consumption without editing the master configuration file each time. New parameters are:
CONFIG_OVERRIDE_MainFuelISP = 0 - 7 (XR2 & XR5), or 0 - 6 (XR1)
CONFIG_OVERRIDE_SCRAMFuelISP = 0 - 4
CONFIG_OVERRIDE_LOXConsumptionMultiplier = 0.0 - 10.0
CONFIG_OVERRIDE_APUFuelBurnRate = 0 - 5
CONFIG_OVERRIDE_CoolantHeatingRate = 0 - 2

To see a sample of how to use the above parameters in a scenario file, take a look at the new 'Configuration File Override Example.scn' XR scenario installed with each vessel.

* Exposed the XR vessel's UMMu object in the new XRVesselCtrl 2.01 version. [Requested by Xyon.]

* Fixed a typo in the XR temperature readouts: 0 K = -273.15 C, not -272.15 C. [Reported by Xyon.]

* Added workaround to prevent the 'PRPLEVEL 0:-1.#IND00' lines from appearing in the XRPayloadBay vessels in saved scenario files.
[Note that the line still occurs for any other Orbiter vessel that cannot carry fuel; the bug will be fixed in the next Orbiter patch version.]

* Fixed bug where the elevator trim still worked even when left and right ailerons (elevons) had failed. [Reported by Woo482.]

* Fixed bug where repairing elevators (via XRVesselCtrl API) fixed the warning but did not restore control of the craft.

* Fixed CTD on startup when the XR vessel was in payload grappling range of another vessel that installed its .cfg file to $ORBITER_HOME\Config instead of $ORBITER_HOME\Config\Vessel or below. [Reported by Tex.]

As always, they're available on my Orbiter site here.

Happy Orbiting! :cheers:
 
Quick question; would it perhaps be possible sometime in the future to expand the new XR Configuration File Override to include the "cheat codes" section? The 'scenario' I had in mind was the attempt a while ago that someone did to create a 'realistic' XR2 which used real-world fuel values and the like; most of that was done through the use of the Cheat-Code's section.

Right now I have a seperate install JUST for that XR2 :lol: It'd be nice to be able to make it a scenerio specific thing.

Just wondering if it was something 'possible', something 'unable to be done with the way the Cheat-code section is coded', or something 'unlikely to be done because it would require innumerable man-hours for almost no true benefit'.
 
The quick answer is that most of the cheatcode values are read and used very early in vessel construction and there are subsequent dependencies on those values. Changing them at scenario load time would take a fair amount of planning and refactoring; not impossible, just a lot of work for a relatively minor gain. In fact, it would be easier to just write an XR Config File Manager stand-alone GUI app that would let you select a config file from a drop-down list and then automatically copy that config file to $OrbiterHome\Config\. So you could:

1. Drop to the launchpad.
2. In the XR Config Selector GUI, select a configuration file to activate. The app would copy the selected config file to $OrbiterHome\Config\.
3. Launch your dessired scenario from the launchpad.

That wouldn't be quite as integrated as having all the overrides in the scenario file, but it would let you easily override all settings in the config file between scenario loads, plus you wouldn't have to edit 10 difference scenarios if you wanted to use the same config file settings for each -- the scenario files wouldn't need to change at all. I've thought about writing that but haven't gotten around to it, so if one of you guys want to write something like that, have at it. :)
 
Nice work Doug! :thumbup:
As for a GUI for loading+replacing the config, something like that exists. It's kind of old, so I'm not sure if it still works in 2010; it should, because it just replaces the config, but I haven't got a chance to test it:
[ame="http://orbithangar.com/searchid.php?ID=4381"]XR2 Configuration Utility[/ame]
 
Hi all,

The XR2 1.1c & XR5 1.3c update versions have just been released. The only fix in these versions is a resource leak fix on vessel startup: in technical terms, I had forgotten to call oapiCloseFile in the loop that parses all the Config\Vessel\*.cfg files on vessel startup. However, based on my testing here I believe that resource leak bug could result in overflowing the Orbiter core's internal 'oapiOpenFile' array, possibly causing a CTD or other odd behavior on Orbiter startup. [I tracked down the bug when I was able to reproduce a startup CTD with some complex test scenarios.] Because this is a CTD fix, I opted to release updated XR2 & XR5 versions with the fix right away rather than wait until the next scheduled patch.

So if any of you were getting CTDs on Orbiter startup in a complex installation with the XR2 or XR5, please download the updated versions and try it again. As always, you can get the new versions on my Web site.

Happy Orbiting! :cheers:
 
Sounds intresting, I'll give it a try.

Had a CTD with Orbiter 2010 and Descartes TotalImmersion docked to a XR2. I'll see if it fixes that, otherwise, I'll post a detailed error description.

Thanks!
 
Nice! Downloading right now. I suspect that will solve the crashing problem that I ran into with certain other addons installed. I'll let you know how it works out.

Edit: We have a winner! That perfectly solved my CTD problem. I found that with certain other addons installed, the XR series would CTD instantly on startup after loading all the meshes, etc. I'd hear the usual sound effects for about 1 second and then BOOM. Down it goes. Now it works perfectly! I had been running the XR series on it's own in a clean install but now I don't have to. Thanks a million.
 
Last edited:
Well, that patch seems to have solved the problems I had. I ran a complex "persistent" scenario at x10 for a few hours with a XR2 in it, then I was able to load it again without troubles. Good job ! :thumbup:
 
Back
Top