Update XR Beta DLLs for Orbiter 2016 Release Candiates

[dbeachy1]

Another update: I just uploaded new XR vessel DLL builds -- these are XR release candidates for Orbiter 2016. Changes are:

• Fixed preexisting bug with distance-to-base being cropped on the VC HUD (applies to XR1 & XR2 only).
• Implemented automatic parking brake feature, which will be useful when landing on sloped ground. Behavior is: 1) auto-engage the parking brake if both wheel brakes are applied and the vessel reaches wheel-stop (<= 0.02 meters-per-second) and the APU is online, and 2) auto-disengage the parking brake if any thrust is applied (RCS, SCRAM, retro, hover, or mains) or if the APU goes offline. There is a new .cfg file setting for this feature:
  

  #--------------------------------------------------------------------------
  # Enable or disable the parking brake functionality.
  #
  #   0 = Disable parking brake functionality
  #   1 = Enable parking brake functionality (default)
  #--------------------------------------------------------------------------
  EnableParkingBrakes = 1

The download links are the same as before:

EDIT: links removed; obsolete now.

Note: these DLLs require Orbiter 2016 RC2 or newer. Do not try to use them with Orbiter 2010 P1.

To install them, just drop the DLLs in to your $ORBITER_HOME\modules folder overtop of the existing XR DLLs -- all the other files are the same.

Happy Flying!

 

[turtle91]

I have tried the new dll for the XR2, but it seems to be, that the dll might be the wrong one.
The file-stamp shows 1. August 2016 and when trying to load:

08.20.2016 15:11:19.844 - [] Loading XR2Ravenstar: Version 1.7 BETA-2, Build Date: Aug  1 2016
08.20.2016 15:11:19.898 - [XR2-01] Using configuration file(s): Config\XR2RavenstarPrefs.cfg (no override found [Config\XR2-01.xrcfg])
08.20.2016 15:11:19.898 - [XR2-01] Parsing config file 'Config\XR2RavenstarPrefs.cfg'
08.20.2016 15:11:19.900 - [XR2-01] Invalid property name: 'EnableParkingBrakes' in section [GENERAL]
08.20.2016 15:11:19.900 - [XR2-01] Name/Value error parsing line #599 of file 'Config\XR2RavenstarPrefs.cfg': Line='EnableParkingBrakes = 1'.  Check the above log message for details.

 

[dbeachy1]

I have tried the new dll for the XR2, but it seems to be, that the dll might be the wrong one.
The file-stamp shows 1. August 2016 and when trying to load:

08.20.2016 15:11:19.844 - [] Loading XR2Ravenstar: Version 1.7 BETA-2, Build Date: Aug  1 2016
08.20.2016 15:11:19.898 - [XR2-01] Using configuration file(s): Config\XR2RavenstarPrefs.cfg (no override found [Config\XR2-01.xrcfg])
08.20.2016 15:11:19.898 - [XR2-01] Parsing config file 'Config\XR2RavenstarPrefs.cfg'
08.20.2016 15:11:19.900 - [XR2-01] Invalid property name: 'EnableParkingBrakes' in section [GENERAL]
08.20.2016 15:11:19.900 - [XR2-01] Name/Value error parsing line #599 of file 'Config\XR2RavenstarPrefs.cfg': Line='EnableParkingBrakes = 1'.  Check the above log message for details.

Oops, good catch! :embarrassed: Turns out the new DLLs I uploaded had uppercase 'BETA' in their filenames instead of the correct case ('beta'), so that's why the Beta-2 DLLs were not overwritten. This has now been fixed, so if you re-download the DLLs now using the same links, they should be correct.

Also, I plan to upload the complete XR zip package versions soon that will include the updated .cfg files and tweaked flight manual. In the meantime, the new parking brake functionality is enabled by default, so you do not need to manually add that setting to your .cfg files (although you may, of course, if you wish).

 

[turtle91]

Thanks, the links are now pointing to the recent/updated files.
But have still issues to controll the XR2 on "bumpy" terrain.
I.e. there is a real bumpy base/runway at this base:

http://www.orbiter-forum.com/showthread.php?p=531780&postcount=17

When landed, the brakes have not much effect to slow down the XR2, so it overshoots the runway.
Maybe the gears need a bit more fraction ?

Another problem is, when taxing from the pad to the runway...and after reaching the runway, I have no chance for a wheel-stop. It drifts a bit sideways (like on ice) with about 0.19 meters/s, with both brakes aplied.

I agree, the base is really bumpy, but a good playground to test the new groundhandling in Orbiter2016.

At KSC, all is fine btw..the handbrake works (maybe an option to make it independend from running APU ?...like a mechnical hand-brake ?).

 

[dbeachy1]

Thanks, the links are now pointing to the recent/updated files.
But have still issues to controll the XR2 on "bumpy" terrain.
I.e. there is a real bumpy base/runway at this base:

http://www.orbiter-forum.com/showthread.php?p=531780&postcount=17

When landed, the brakes have not much effect to slow down the XR2, so it overshoots the runway.
Maybe the gears need a bit more fraction ?

Another problem is, when taxing from the pad to the runway...and after reaching the runway, I have no chance for a wheel-stop. It drifts a bit sideways (like on ice) with about 0.19 meters/s, with both brakes aplied.

I agree, the base is really bumpy, but a good playground to test the new groundhandling in Orbiter2016.

Hmm, the brake force and wheel traction has not changed from the public XR releases -- can you please test the default DG (and the XR1) at that base and see if the same behavior occurs? This may just be an artifact of the new Orbiter 2016 elevation physics and gear damping+rebound.

At KSC, all is fine btw..the handbrake works (maybe an option to make it independend from running APU ?...like a mechnical hand-brake ?).

When I was writing the parking brake feature I thought about not tying it to the APU, but the ships are so massive that I don't think a handbrake would have enough force to have much effect, let alone apply 100% braking force like it does now. What you can do while landed, though, is just connect the APU fuel resupply line to refill the fuel tank whenever it gets low. Or land on level ground so the ship doesn't want to roll away in the first place.

 

[turtle91]

Hmm, the brake force and wheel traction has not changed from the public XR releases -- can you please test the default DG (and the XR1) at that base and see if the same behavior occurs? This may just be an artifact of the new Orbiter 2016 elevation physics and gear damping+rebound.

I have tested the default DG so far.
My landing attempt ended in a desaster....but the brakes were fine.:lol:
I.e. I used the scenario which comes with th ascension-packet.
Here the DG is parked at the pad. So I toe-braked the DG to the runway and hold the brakes. As long as the brakes have been aplied,I got 0 m/s...so a complete wheel-stop, but no luck with the XR2 so far...i't still moving.

Will test the XR1 later.

Btw...a small glitch when using the XR2 1250 pixel-mode-cockpit.
The lower-cockpit shows XR1 (within the XR2), and the upper-part shows "stow/retract ladder button labels" instead of "bay-doors".

When I was writing the parking brake feature I thought about not tying it to the APU, but the ships are so massive that I don't think a handbrake would have enough force to have much effect

Maybe we could use wheel chocks.

The problem is, that every time I load-up a XR2-scenario, initially the vessels "jumps" a bit, so external-cooling is allways disabled after reload.

So the "wheel-stop" condition seems to be only available AFTER Orbiter comes up. But there seems to be no possibilty to load a XR vessel with "wheel-stop" at the very beginning of an Orbiter-session. (?)

 

[dbeachy1]

Btw...a small glitch when using the XR2 1250 pixel-mode-cockpit.
The lower-cockpit shows XR1 (within the XR2), and the upper-part shows "stow/retract ladder button labels" instead of "bay-doors".

That's a good catch! Turns out that bug has been there since day one -- I can't believe I never noticed it before or that it hasn't been reported before now. :lol: Anyway, that is now fixed in the next build.

Maybe we could use wheel chocks.

The problem is, that every time I load-up a XR2-scenario, initially the vessels "jumps" a bit, so external-cooling is allways disabled after reload.

So the "wheel-stop" condition seems to be only available AFTER Orbiter comes up. But there seems to be no possibilty to load a XR vessel with "wheel-stop" at the very beginning of an Orbiter-session. (?)

Hmm, I just tested that with the XR2 at both Brighton Beach and KSC and it works for me (external cooling remains enabled across scenario reloads). Are you landed on a slope and so the vessel ends up moving at > 0.02 meters-per-second on startup? If so, there's not much I can do about that except possible raise the maximum allowable velocity to assume the ship is at wheel-stop (or 'cheat' and force the ship's relative velocity to be zero via a custom PreStep handler -- but I'm not crazy about that idea). Does the same effect occur with the default DG? (You can check if your velocity on the surface MFD is > 0.02 meters-per-second right after the scenario loads.)

 

[turtle91]

I just loaded-up the "Landed at Brighton Beach" scenario.
As soon as Orbiter is up+runing, the vessel moves forward.
So started the APU and pressed both brakes.
Even that I pressed the brakes for more than 30 seconds, the vessel moved with 0.10 m/s forward....strange....


Correction:

when pressing both brakes, the vessel moves with 0.10 m/s sideways...to the right.

 

[dbeachy1]

Can you replicate the issue in a clean installation? I can't reproduce it here.

 

[turtle91]

Still the same issue on a "clean" install. :shrug:
Just Orbiter-Sound and the XR2.

**** Orbiter.log
000000.000: Build Aug 15 2016 [v.160815]
000000.000: Timer precision: 6.83879e-007 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 150906, API 150906]
000000.000: Module AtmConfig.dll ......... [Build 150906, API 150906]
000000.000: Module DGConfigurator.dll .... [Build 150906, API 150906]
000000.000: Module D3D9Client.dll ........ [Build 160729, API 160728]
000000.000: Module OrbiterSound.dll ...... [Build 121120, API 100830]
000000.000: Module ScnEditor.dll ......... [Build 160630, API 160630]
000000.000: 
000000.000: **** Creating simulation session
000000.000: D3D9: [DirectX 9 Initialized]
000000.000: D3D9: [3DDevice Initialized]
000000.000: D3D9: [Loading Constellations]
000000.000: D3D9: [D3D9Client Initialized]
000000.000: Module Sun.dll ............... [Build 150906, API 150906]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
000000.000: Module Mercury.dll ........... [Build 150906, API 150906]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
000000.000: Module Venus.dll ............. [Build 150906, API 150906]
000000.000: Module VenusAtm2006.dll ...... [Build 150906, API 150906]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
000000.000: Module Earth.dll ............. [Build 150906, API 150906]
000000.000: Module EarthAtmJ71G.dll ...... [Build 150906, API 150906]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
000000.000: Module Moon.dll .............. [Build 150906, API 150906]
ELP82: Precision 1e-005, Terms 116/829
000000.000: Module Mars.dll .............. [Build 150906, API 150906]
000000.000: Module MarsAtm2006.dll ....... [Build 150906, API 150906]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
000000.000: Module Phobos.dll ............ [Build ******, API 060425]
000000.000: Module Deimos.dll ............ [Build ******, API 060425]
000000.000: Module Galsat.dll ............ [Build 150906, API 150906]
000000.000: Module Jupiter.dll ........... [Build 150906, API 150906]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
000000.000: Module Io.dll ................ [Build 150906, API 150906]
000000.000: Module Europa.dll ............ [Build 150906, API 150906]
000000.000: Module Ganymede.dll .......... [Build 150906, API 150906]
000000.000: Module Callisto.dll .......... [Build 150906, API 150906]
000000.000: Module Satsat.dll ............ [Build 150906, API 150906]
000000.000: Module Saturn.dll ............ [Build 150906, API 150906]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
000000.000: Module Mimas.dll ............. [Build 150906, API 150906]
SATSAT Mimas: Terms 113
000000.000: Module Enceladus.dll ......... [Build 150906, API 150906]
SATSAT Enceladus: Terms 33
000000.000: Module Tethys.dll ............ [Build 150906, API 150906]
SATSAT Tethys: Terms 101
000000.000: Module Dione.dll ............. [Build 150906, API 150906]
SATSAT Dione: Terms 59
000000.000: Module Rhea.dll .............. [Build 150906, API 150906]
SATSAT Rhea: Terms 68
000000.000: Module Titan.dll ............. [Build 150906, API 150906]
SATSAT Titan: Terms 100
000000.000: Module Iapetus.dll ........... [Build 150906, API 150906]
SATSAT Iapetus: Terms 605
000000.000: Module Uranus.dll ............ [Build 150906, API 150906]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
000000.000: Module Miranda.dll ........... [Build ******, API 060425]
000000.000: Module Ariel.dll ............. [Build ******, API 060425]
000000.000: Module Umbriel.dll ........... [Build ******, API 060425]
000000.000: Module Titania.dll ........... [Build ******, API 060425]
000000.000: Module Oberon.dll ............ [Build ******, API 060425]
000000.000: Module Neptune.dll ........... [Build 150906, API 150906]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
000000.000: Finished initialising world
000000.000: Module XR2Ravenstar.dll ...... [Build 160820, API 160815]
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: VESSEL::CreateVariableDragElement
000000.000: At least one active module is accessing an obsolete interface function.
000000.000: Addons which rely on obsolete functions may not be compatible with
000000.000: future versions of Orbiter.
000000.000: ---------------------------------------------------------------
000000.000: Module ShuttleA.dll .......... [Build 160630, API 160630]
000000.000: Module ShuttlePB.dll ......... [Build 160122, API 160120]
000000.000: Module DeltaGlider.dll ....... [Build 160815, API 160815]
000000.000: Module LuaInline.dll ......... [Build 160806, API 160806]
000000.000: Finished initialising status
000000.000: Finished initialising camera
000000.000: Finished setting up render state
000000.000: D3D9: [Scene Initialized]
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: oapiTriggerPanelRedrawArea
000000.000: Replaced by VESSEL::TriggerPanelRedrawArea
000000.000: ---------------------------------------------------------------
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: oapiBlt
000000.000: Colour key argument not supported by graphics client
000000.000: ---------------------------------------------------------------
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: VESSEL::GetHorizonAirspeedVector
000000.000: At least one active module is accessing an obsolete interface function.
000000.000: Addons which rely on obsolete functions may not be compatible with
000000.000: future versions of Orbiter.
000000.000: ---------------------------------------------------------------
000000.000: Finished initialising panels
000039.432: D3D9: [Session Closed. Scene deleted.]
000039.432: D3D9: [Destroy Render Window Called]
000039.432: **** Respawning Orbiter process


**** Orbiter.log
000000.000: Build Aug 15 2016 [v.160815]
000000.000: Timer precision: 6.83879e-007 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 150906, API 150906]
000000.000: Module AtmConfig.dll ......... [Build 150906, API 150906]
000000.000: Module DGConfigurator.dll .... [Build 150906, API 150906]
000000.000: Module D3D9Client.dll ........ [Build 160729, API 160728]
000000.000: Module OrbiterSound.dll ...... [Build 121120, API 100830]
000000.000: Module ScnEditor.dll ......... [Build 160630, API 160630]

 

[dbeachy1]

Unfortunately I still can't dupe the issue. I did, however, fix the VESSEL::CreateVariableDragElement, oapiTriggerPanelRedrawArea, and VESSEL::GetHorizonAirspeedVector warnings in Orbiter.log on startup.

Note that there are still some warnings about VESSEL::GetHorizonAirspeedVector in orbiter.log on the included XR scenarios, but they are not coming from XR code -- I get the same warnings when loading the default Delta-glider/DG-S ready for takeoff scenario, so it must be some other module that is causing the issue (maybe OrbiterSound?).

Anyway, one thing you can try is to play around with uncommenting the following settings lines and setting different values for these two cheatcodes in your Config\XR2RavenstarPrefs.cfg file to see if changes how much your ship "slides around" at KSC or Brighton Beach:

#--------------------------------------------------------------------------
# Maximum wheelbrake force in newtons
#--------------------------------------------------------------------------
MaxWheelbrakeForce=1.0e5

#--------------------------------------------------------------------------
# Wheel friction coefficient (and resistance) when rolling on the ground; 
# also affects braking performance.
#--------------------------------------------------------------------------
WheelSurfaceFrictionCoeff=0.025

 

[turtle91]

That's realy strange, that you can't reproduce the problem.
What terrain/mesh-files you are using ? Maybe your mesh is more flat at BB.

I played with the values you have mentioned, unil a factor more of 30x more than default...just for testing.

08.21.2016 05:58:57.164 - [XR2-01] >>> CHEATCODE ENABLED: MaxWheelbrakeForce = 3300000.000000
08.21.2016 05:58:57.164 - [XR2-01] >>> CHEATCODE ENABLED: WheelSurfaceFrictionCoeff = 32.025000

But there was no different.

The only way to force a wheel-stop at default-BB-scenario I found so far:
-loaded the scenario...the vessel slightly moves to the right (0.08 - 0.10 m/s)
-started APU...pressed brakes
=able to maintain a stable 0.10 m/s right-move (no more accelerating to > 0.10 m/s
but no wheel stop

-used the RCS-yank commands (numpad 1 and 3) to force a "RCS-brake"
=after some RCS-bursts, the wheels finaly stopped, and I was able to aply the parking-brake

Then I enabled external-cooling, before I quick-saved the scenario

However, after reloading the scenario, the problem is back:
=
-external cooling offline
-vessel moving again to the left...starting with 0.08 m/s

I also tried different Orbiter-difficult settings (like complex-flight-modell etc.), but got allways the same result. (tested in DX7 and DX9 client btw).

I am running out of ideas....

 

[dbeachy1]

One thing that may be different is that I am using the high-resolution textures and mesh -- maybe that has a different effect with the Orbiter core?

 

[turtle91]

This would make sense, I am using the low-res meshes/textures.
Forced by my ISP, who gives me 5 GB per month..before reducing my bandwith to 5k/s :facepalm:

 

[dbeachy1]

I just tried it in a clean Orbiter 2016 RC4 install at KSC with OrbiterSound, UMMu, and the XRs, using both the inline and D3D9 clients, both with and without vertical sync, and it works fine for me -- external cooling is restored and the parking brakes remain engaged when the scenario reloads. The ship does not move.

Maybe it has something to do with framerates? What framerate are you getting?

 

[turtle91]

When using the default "1 - Ready for Takeoff to ISS" scenario, all went fine.
I aplied ext cooling, saved and reloaded the scn.
Ext cooling has been restored an parking brake is still active...no more bounces or moves...at least at KSC.

My FPS is initially at 67 FPS...which should be fine.

 

[dbeachy1]

I also retested it with the default XR2 Landed at Brighton Beach scenario and it works for me -- the ship does not move and external cooling is restored when the scenario reloads with the parking brakes on. Unfortunately, I'm out of ideas here...

 

[turtle91]

I tried again with the "Landed at Brighton Beach" scenario.
Here I have 74 FPS, but the problem persits.

However, this time I have not touched the keyboard and waited until the vessel performed a wheel-stop (took about 20 seconds).
Then I enabled ext. cooling and saved.

After reload, the ext-cooling was disconnecetd caused by a slight right-move.
After about 3-5 seconds the vessel stopped an I was able to re-enable the ext. cooling again.

So I saved again, but everytime after loading the scn, it took a couple of seconds to stop the vessel (by itself...still not touched the keyboard).

Maybe we have still a diffrent terrain/mesh (I used SVN to keep Orbiter up-to-date...caused by my bandwith limit).

But at least it shows, that on a not perfect-flat pad, the XR-vessels have more problems to establish a wheel-stop compared to default vessels. (at least in my case)

I.e. I replaced the XR2 wit a stock DG, and here the DG was stable...not moving/sliding after scn-reloads.

Maybe somebody else could do some testing ? Maybe at different bases/pads ?

 

[Ripley]

As far as I understood, dbeachy1 is testing on RC4 + HiRes texture and turtle91 is testing on latest rev 61 on SVN + LoRes texture.
I'm sure you are aware of how difficult it can be to get a common outcome with such different starting situations (on such a delicate issue, BTW).

Just my 2 cents.

 

[turtle91]

Thanks Ripley,

you might be correct, the main differenece could be the terrain-data.
But from the code-side, both RC4 and rev60+ SVN should behave similar, I believe:

Revision: 60
Author: martins
Date: Samstag, 6. August 2016 05:02:18
Message:
VESSEL::SetTouchdownPoints: old 3-point interface now sets stiffness and damping parameters according to vessel empty mass (warning: this introduces a race condition: vessel mass must be set before touchdown points)

As far a I know, the latest XR-dlls are taking care about this change.
But again, you might be correct and there are differents in both Orbiter releases/snaps, which could cause some confusions.

I would start the RC4 download right away, if my ISP would not limit me to 5GB per month. So I am currently stuck at SVN-updates.

Maybe you can test this with a "pure" RC4 ?