Update XR Release Candidates (RC2) for Orbiter 2010

[dbeachy1]

Hello all,

In preparation for Orbiter 2010, I wanted to get the new XR release candidate builds out for public testing to work out any remaining kinks with the new Orbiter version. I am still working on finishing up the new XRVesselCtrl API 2.0, but that will be included in the next XR update versions a few weeks from now. In the meantime, please feel free to give the XRs a proper shakedown using the latest Orbiter beta, currently Beta 100503 (the Orbiter Beta download page is here) .

Here are the release notes for these builds:

XR1 1.6-RC1 / XR2 1.1-RC1 / XR5 1.3-RC1 Release Notes

* Added auto-detection of the current video mode's width and automatically load the optimum 2D panel for that width. The '2DPanelWidth' config file setting is still supported, but its default value is now '0' (Autodetect).

* CTRL-Z (Radiator) and CTRL-X (secondary HUD) shortcut keys changed to ALT-R and ALT-T, respectively, to avoid conflict with Orbiter 2010's new CTRL-Z/CTRL-X zoom jump keys.

* Modified hull heating code to be compatible with Orbiter 2010.

* Modified mach callouts to be compatible with Orbiter 2010 (they no longer occur at extremely low static pressures).

* Updated KSC launch scenarios to match the new (and correct!) location of KSC's runway in Orbiter 2010.

* Deleted obsolete "On final approach to KSC" scenarios since the location of KSC has changed. The scenarios may be re-added in the next patch release if and when I have time to recreate all of them.

* Added new XR payload option that specifies whether this payload module's fuel (if any) may be consumed and resupplied by the parent XR vessel. This allows you to carry other vessels that contain fuel without having the parent XR vessel consume its fuel, if desired. Option is:

; (OPTIONAL) set to 'true' if this payload contains fuel or LOX that is consumable by the parent XR vessel
XRConsumableTank = true

* Fixed "PRPLEVEL 0:-1.#IND00" line that could appear for XR payload vessels in saved XR2/XR5 scenarios.

* Updated XR payload logic to no longer require the 'AttachmentPointIndex' config parameter; it now looks for a payload bay slot with the name "XRCARGO".

* Linked using UMMu 2.0 (UMMu 2.0 is required to run these release candidates).

* Added new 'DefaultCrewComplement' parameter:

#--------------------------------------------------------------------------
# Number of crew members to add to the ship if there is no UMMu data in the scenario file.
# Crew will be added starting at [PASSENGER0]
#
# The default is 14 ( [PASSENGER0] through [PASSENGER13] )
#--------------------------------------------------------------------------
DefaultCrewComplement = 14

This is useful if you want your auto-created XR vessels to start with less than a full crew complement. (This feature was requested by Cairn.)

* External cooling line now supplies the ship with oxygen as well; i.e., onboard oxygen is not consumed while external cooling is active. This is nice when you want to accelerate time to wait for a launch window. (Feature requested by Urwumpe.)

* XR ships may now be refueled in-fight (e.g. via FuelMFD) regardless of the 'OrbiterAutoRefuelingEnabled' config file setting. In other words, 'OrbiterAutoRefuelingEnabled' only affects the XR vessel when it is landed.

* Various changes/tweaks to make XR vessels compatible with external graphics clients (i.e., Orbiter_NG). Currently XR vessels are still using Windows GDI calls, but a future version may be refactored to use Orbiter's new sketchpad interface if there is sufficient demand for it.

* Modified payload config file logic to scan all subdirectories underneath Config\Vessels in addition to the top-level Config\Vessels directory.

* XR vessels will no longer create a zero-length .cfg file in Config\Vessels for a vessel if no config file is present for that vessel; this is because the code now parses all .cfg files itself on startup rather than invoking oapiOpenFile(<vessel_classname>.cfg) for each vessel in the scenario.

* Modified XRVesselCtrl class to not require a separate CPP file (moved constructor to the .h file).

* Lots of internal refactoring to cleanly support the upcoming XR2 Mk II's glass virtual cockpit.

* Added new static bool XRVesselCtrl::IsXRVesselCtrl(const VESSEL *pVessel) method that lets external code determine whether a given vessel supports XRVesselCtrl instead of having to query the vessel's classname. (Lots more changes plus a cool demo module coming in XRVesselCtrl 2.0; stay tuned!)

* Fixed XR2 bug where nosewheel steering worked even if the APU was off.

* Fixed XR5 bug where nosewheel steering was incorrectly disabled if AF Ctrl mode was not set to "On".

* Added two missing warning callouts to the XR2: "Warning: Bay doors open" and "Warning: Bay door failure".

* Improved nosewheel steering response using a method similar to how Hielor's excellent "NoseWheelTurn" add-on works. (Many thanks to Hielor for coming up with the idea!)

* Now uses a smaller, thicker HUD font to better match the new HUD look in Orbiter 2010. In addition, XR messages on the HUD now use a different font size based on the width of the video mode.

* Fixed XR5 bug where external cooling switched off when you switched to another vessel and back.

* Fixed XR5 bug in the config file handling where MainFuelISP=7 did not work.

* Fixed XRVesselCtrl bug where GetCenterOfGravity() and ShiftCenterOfGravity() directions were reversed.

* Changed XRVesselCtrl GetStatusScreenText method signature to GetStatusScreenText(char *pLinesOut) for technical reasons (XR vessels use static linking).

* Updated XR Flight Operations Manual, now version 2.1.


KNOWN ISSUES:

* oapiIncHUDIntensity and oapiDecHUDIntensity do not work in the latest Orbiter beta, so the HUD brightness rocker switch only affects HUD data rendered by the XR vessels themselves. Selecting HUD color, however, works fine.

* Payload bay camera view does not work under Orbiter_NG: the ship's mesh is not rendered. This is due to an Orbiter external graphics client issue.


TODO for next release candidate builds:

* XRVesselCtrl 2.0 with more features, such as the ability to set/clear ship damage via the API as well as a cool new demo plug-in module that will let you play with the XRVesselCtrl API. Demo module will include the source code as well so developers will have lots of code samples for the XRVesselCtrl interface.

Please remember that since these are release candidate builds no new features will be added at this time. If you find a bug, please be sure to test it in a clean Orbiter 2010 beta installation first. Here are the installation instructions:

1. Install Orbiter 2010 Beta 100503 or later.
2. Install UMMu 2.0.
3. Install OrbiterSound 3.5 (optional, but highly recommended).
4. Install the XR1 and/or XR2 and/or XR5 release candidates.

Several files are necessarily duplicated in each XR package, such as the flight manual and the invisible payload bay vessel .cfg file; you may safely overwrite your existing version (or not) as you choose -- the files are identical in each release.

The zip download links are below:

EDIT:
The RC1 builds have been taken offline now that the RC2 builds are available. RC2 download details are here.

Please note that there are no RAR versions available for these release candidates; RAR versions will be available when Orbiter 2010 goes gold. Thanks for your help testing these release candidates!

 

[Hielor]

* Modified mach callouts to be compatible with Orbiter 2010 (they no longer occur at extremely low static pressures).

Is there any possibility you could update other callouts (such as V1 and Rotate) to be more accurate on other planets? On Mars, for example, these calls happen very early in the takeoff roll, when it can't actually take off until much later. I think the issue is that these speeds are in reality a result of indicated airspeed (or equivalent airspeed, or more directly, dynamic pressure), and Orbiter only gives you true airspeed.

* Improved nosewheel steering response using a method similar to how Hielor's excellent "NoseWheelTurn" add-on works. (Many thanks to Hielor for coming up with the idea!)

Glad to see that someone's found it useful! That was the original intent, too, that vessel developers could incorporate it into their ships and tweak the parameters to however they wanted, but someone asked for it as a plugin to take care of all the existing ships. You've probably already taken care of it, but it's worth pointing out anyway: if you're doing it yourself, you should probably have SetNosewheelSteering(false) set so that if someone has the addon it won't be trying to override what your ship is doing (or in case Orbiter's built-in implementation improves but you still want your custom one).

Excellent updates, though!

 

[dbeachy1]

Hmm, it never occurred to me to take off conventionally on Mars -- that's a lot of velocity! :lol: I'll add a note about it for a future version, but it could be tricky to calculate the optimum rotation velocity based on wing area, ship mass, and atmospheric density. Currently the callout threshold is just linked to a fixed velocity.

And thanks again for your excellent NoseWheelSteering add-on -- that was a brilliant idea!

 

[Hielor]

Hmm, it never occurred to me to take off conventionally on Mars -- that's a lot of velocity! :lol: I'll add a note about it for a future version, but it could be tricky to calculate the optimum rotation velocity based on wing area, ship mass, and atmospheric density. Currently the callout threshold is just linked to a fixed velocity.

You could probably "guesstimate" it by figuring out what dynamic pressure the current Vr on Earth arrive at, then having it play at that dynamic pressure instead of that airspeed. Might not be perfect, but it'll be a lot closer to correct than it is currently. Alternately, a quick equivalent airspeed calculation might lead to a more accurate result. For Mars it is a little odd, but one could imagine having a planet which is closer to Earth's atmosphere but still thin enough that trying to rotate at the "rotate" callout would be too early.

And thanks again for your excellent NoseWheelSteering add-on -- that was a brilliant idea!

No problem, and thanks! Ships like the XR series deserve to be able to be driven around an airport without driving off into the mountain because you can't make the turn onto the taxiway

 

[tl8]

A quick test indicates everything seems to be working, I will test the know issues and the new feature more thoroughly now

Could the Gear indicator have the thicker style lines? it sort of stands out too much.

 

[Cairan]

You could probably "guesstimate" it by figuring out what dynamic pressure the current Vr on Earth arrive at, then having it play at that dynamic pressure instead of that airspeed. Might not be perfect, but it'll be a lot closer to correct than it is currently. Alternately, a quick equivalent airspeed calculation might lead to a more accurate result. For Mars it is a little odd, but one could imagine having a planet which is closer to Earth's atmosphere but still thin enough that trying to rotate at the "rotate" callout would be too early.

I second that, given that take-off on Titan is the exact opposite problem, V1 and Vr are a fraction of what they are on Earth...

To throw in my 2 cents, you can finetune it even more in 2 ways: 1) by using a linear function of lift versus dynamic pressure at rotation and 2) using the vessel weight by taking the actual weight resulting from local gravity into account, not merely mass.

It should be possible to guesstimate experimentaly to avert complex calculations by doing 2 test runs to serve as a basis for a linear equation:
1) take-off with barely enough main fuel and APU fuel for the takeoff roll, no RCS or scram, no cargo and no passengers except for the pilot and copilot and a few kg of oxygen and note the takeoff mass and dynamic pressure at Vr, then compute the takeoff weight in newtons. That's the low end of your takeoff Vr call function.
2) same as 1, but packed with full complement, maximum takeoff mass, think lead or gold in the cargo bay, and that's the high end of the Vr call weight/dynamic pressure relation.

When appropriate, call up the linear relationship function thus created with these two datapoints, with vessel mass and local gravity (combined into vessel weight) as parameters returning the callout dynamic pressure.

 

[Xyon]

I forgot to install UMMU before I started testing. It spits up the error message, but since I was loading fullscreen I didn't see it, it just hung there and didn't look like it was doing anything. Just a note.

Also, while in fullscreen at 1024x768 the "data hud" display disappears off the bottom of the screen.

 

[dbeachy1]

Could the Gear indicator have the thicker style lines? it sort of stands out too much.

That's a good catch. I hadn't noticed, but now that you mention it, yes. That change will be in the next RC build.

I forgot to install UMMU before I started testing. It spits up the error message, but since I was loading fullscreen I didn't see it, it just hung there and didn't look like it was doing anything. Just a note.

Also, while in fullscreen at 1024x768 the "data hud" display disappears off the bottom of the screen.

Hmm, it I'm not sure what more I can do to force that message box to appear in full-screen modes -- the MessageBox is already created with style MB_SETFOREGROUND. I'll have to play around with that some more.

As for the data HUD running out of space at 768 lines, sorry mate, nothing I could do there except perhaps jam it down to a smaller font for shorter displays.

Anyway, I want to give a big shout-out thanks to Xyon and the rest of the #orbiterradio crew for providing me with excellent tunes and/or talk shows (sometimes all night long!) as I finished up the XR RC releases these past few weeks!

EDIT:
An update regarding this:

I forgot to install UMMU before I started testing. It spits up the error message, but since I was loading fullscreen I didn't see it, it just hung there and didn't look like it was doing anything. Just a note.

After investigation I was able to fix that, so the fix will be in the next build. That was great catch, mate! :thumbup:

 

[Evil_Onyx]

The HUD is not displaying in the VC on my system, i know there was an issue with ATI video cards and the VC HUD in previous betas but that seems to be fixed with the default DG.

I have tried with lots of different video settings and it still is not displaying the HUD. Any ideas?

 

[dbeachy1]

Which ships? Both the XR1 and XR2? And under both Orbiter.exe and Orbiter_NG.exe using the DX7 client? I'm not sure what to think -- works on my test systems here. Most of the HUD is rendered by the Orbiter core.

You'll want to make sure your antialiasing is off as well.

 

[Evil_Onyx]

Ive only tested the XR2 under Orbiter.exe so far (ill try the rest tomorrow)

AA is off.

 

[supersonic]

When your ailerons fail shouldn't the air brakes fail too? The only reason I noticed this is because I go over the wing stress limit all the the time.

 

[Evil_Onyx]

Found it, It was LaunchMFD messing with the HUD.

Have tested with clean install and works fine in both Orbiter.exe and Orbiter_ng.exe with both XR1 and XR2.

Sorry for any inconvenience caused.

 

[dbeachy1]

When your ailerons fail shouldn't the air brakes fail too? The only reason I noticed this is because I go over the wing stress limit all the the time.

That's a good catch! :thumbup: That fix will be in the next build.

 

[tl8]

I don't know if you intend to support OGLA but you might find this interesting

 

[dbeachy1]

It looks like OGLA apparently doesn't support hiding/showing mesh groups at runtime yet, and so the heating mesh remains visible after it is loaded. Nothing I can do on this end, mate, sorry, except possibly add an option to disable the heating mesh feature.

 

[flyer]

Hi there everyone, first time posting!

Firstly, congratulations to Doug and everyone involved with creating the XR series!

Maybe this isn't the perfect place for feature requests but I thought I'd give it a go!

I was wondering if it is possible to add the possibility to automatically deploy the speedbrake on landing. Perhaps this could take the form of an 'armed' position of the speedbrakes?

Continuing in the same theme, would an autobrake system be possible to include? In real life autobrake systems (the Boeing 737 at least!) there are several levels of autobrake that can be selected. The different levels represent an overall deceleration rate, for example if on landing the pilot chose to use reverse thrust, then the autobrake system would reduce the pressure being applied to the brakes to achieve the same deceleration rate as without the reverse thrust.

I guess these are just my personal requests but I feel that if the XR1/2/5 were to be operated in real life then these systems would probably be included.

Coming back to the "if the XR1/2/5 were to be operated in real life" way of thinking, I have also thought that some way of "de-rating" the engines for atmospheric flight could be a good idea when considering take off performance.
In real life, aircraft takeoff performance is predicated on losing an engine. I realise it is not possible to easily simulate this within orbiter, but IF the worst did happen and you were to try and take off with 100% thrust operating on only one engine (I'm thinking XR2 specifically here) then it would not be possible to control the resulting yaw after leaving the ground due to the unbalanced thrust line. One simple way to reduce this would be to reduce the amount of thrust from the operating engine.

Following the above idea, I don't know if V1 is a fixed value? Would it be possible for a dynamic value of V1 to be calculated based on runway length, weight etc?

Also, I think you have spoken about this before but I would also make a request for an altitude hold and heading hold autopilot. I realise you want to keep the XR craft to be "pilots aircraft", but again thinking of real life operations, I don't think that these functions would detract from the experience. They would simply be used as a workload reduction tool, which is one of the reasons autopilots are used. Also, there is no requirement for anybody to use them! I just think that for those atmospheric flights (maybe delivery flights etc) it would make the process of fitting in with the existing air traffic routes an easier and safer prospect.

Anyway, sorry that was such a long post, if you need me to explain any of my requests then give me a shout. They make sense in my own mind, but that's a wierd place!

Thanks again!


Flyer

 

[Artlav]

It looks like OGLA apparently doesn't support hiding/showing mesh groups at runtime yet, and so the heating mesh remains visible after it is loaded.

It would help me fix it if you could tell me which calls does XR2 use to change the meshes.
I can't seem to run a debugger on OGLA with XR2 in the scenario, it intercepts some internally handled exception and refuses to continue.

 

[dbeachy1]

Hmm...I don't know what to think -- there are no try...catch blocks anywhere in the XR codebase. In any case, here is the method the XR framework uses to show or hide mesh groups. In this case, hMesh is the handle to the heating mesh and dwMeshGroup = 0 (the only group in the heating mesh):

// Set a mesh group visible or invisible
// Note: dwMeshGroup is 0-based
void VESSEL2_EXT::SetMeshGroupVisible(DEVMESHHANDLE hMesh, DWORD dwMeshGroup, bool isVisible)
{
    // Note: for details on mesh group flags, refer to page 7 of 3DModel.pdf.
    /*
        Mesh type   Flag        Interpretation
        ---------   ----------  ----------------------------------------------------
        Vessel      0x00000001  Do not use this group to render ground shadows
        Vessel      0x00000002  Do not render this group
        Vessel      0x00000004  Do not apply lighting when rendering this group
        Vessel      0x00000008  Texture blending directive: additive with background
    */

    GROUPEDITSPEC geSpec;
    memset(&geSpec, 0, sizeof(GROUPEDITSPEC));  // init all to zero
    geSpec.UsrFlag = 0x00000003;    // toggle shadows as well; this will be ANDed or ORd with the group's flags

    if (isVisible)  // assignment separated for clarity
        geSpec.flags = GRPEDIT_DELUSERFLAG;  // clear the "do not render" bits
    else
        geSpec.flags = GRPEDIT_ADDUSERFLAG;  // set the "do not render" bits

    oapiEditMeshGroup(hMesh, dwMeshGroup, &geSpec);
}

Also, if the heating mesh is visible (which is not the case when the ship is landed, of course), the code invokes oapiSetMaterial to vary the alpha channel of the heating mesh. However, that call isn't invoked unless the hull is beyond a certain temperature threshold and the heating mesh is made visible first.

 

[computerex]

Hmm...I don't know what to think -- there are no try...catch blocks anywhere in the XR codebase.

Doug, for some reason the XR2 has trouble with debuggers on some people's ends. Remember how when I was trying to debug the RackerCheckpoint MFD, and it kept crashing? You concluded it was compiler incompatibility.