Update Orbiter-beta-compatible XR DLLs

[dbeachy1]

Hi all,

I have some Orbiter-beta-compatible XR versions available for download and testing if you want to try them out. Please remember, however, that it is still early in the Orbiter beta process and so some bugs are to be expected. Please be sure to use Orbiter beta 121025 or newer.

Known issues:

• OrbiterSound does not play custom wav files under the Orbiter beta, so custom XR voice callouts and sound effects will not play.
• XR vessel gear is sunk into the ground somewhat; this is purely a visual issue and will be fixed before new Orbiter version ships. It is occurring because the Orbiter core adjusts the touchdown points based on gear compression.
• The acceleration values displayed on the engine display panel for the X and Z axes are off when the ship is resting on the runway.

To install, just download the beta-compatible XR zip that you want and extract the DLL overtop of your existing XR DLL in your $ORBITER_HOME\modules folder:

EDIT:
See this post below for links to the newest Orbiter-Beta-compatible XR DLLs.

If you find a bug please follow these steps:

1) Retest in a clean Orbiter beta installation with only the XR vessel(s), UMMu, and optionally OrbiterSound installed.

2) If applicable, retest the behavior with the stock DG included with the Orbiter beta. If it exists in that vessel as well, please report the bug in the normal Orbiter beta thread (e.g., http://orbiter-forum.com/showthread.php?t=29346).

3) Otherwise, please report it either in this thread or to me via PM.

Thanks for testing, and happy flying! :tiphat:

 

[Charl_C]

Hi Doug,

Thank you so much for getting this out so quickly. Are you aware of any work-around for the sound effects, callouts etc. not playing? Would it be an issue dansteph would need to look at on the OrbiterSound side?

Regards and thanks again,

 

[Bonanza123d]

Hi Doug,

Thank you so much for getting this out so quickly. Are you aware of any work-around for the sound effects, callouts etc. not playing? Would it be an issue dansteph would need to look at on the OrbiterSound side?

Regards and thanks again,

It is a danspteph problem. They took out an obsolete function and he is working on it right now. Refer to this thread:

http://orbiter-forum.com/showthread.php?t=29098

 

[orb]

They took out an obsolete function and he is working on it right now.

Who took out an obsolete function, and from where? :shrug: A search for "obsolete" keyword in the thread you linked doesn't bring any results.

 

[Charl_C]

Ah, thank you. We wait patiently for OrbiterSound 4.0 then. Not having alarms and call-outs makes you appreciate the work he does, though.

 

[Marvin42]

He's probably referring to this:
http://orbiter-forum.com/showthread.php?p=388635&postcount=46
but Bonanza got some facts wrong.

 

[orb]

He's probably referring to this:
http://orbiter-forum.com/showthread.php?p=388635&postcount=46
but Bonanza got some facts wrong.

You know, if it's connected to the order of callbacks, then it can still be changed to what it was earlier. From the Orbiter Beta forum:

...there is already a new one available (121026) which restores the order of VESSEL::clbkPostCreation and VESSEL::clbkLoadPanel. This one may potentially have side effects, and I haven't thoroughly tested it yet, so no guarantees...

 

[dbeachy1]

Ah, thank you. We wait patiently for OrbiterSound 4.0 then. Not having alarms and call-outs makes you appreciate the work he does, though.

FWIW the problem still exists in OrbiterSound 4.0. Also, the new Orbiter beta that restores the order of the startup callbacks did not fix the problem, either. However, I'm sure Dansteph will sort it out. In answer to your question, there is no workaround that I am aware of.

 

[dansteph]

FWIW the problem still exists in OrbiterSound 4.0. Also, the new Orbiter beta that restores the order of the startup callbacks did not fix the problem, either. However, I'm sure Dansteph will sort it out. In answer to your question, there is no workaround that I am aware of.

That's not possible, even if I can find a workaround in the incoming SDK all the vessel compiled with the previous version
of OrbiterSound SDK would not work anyway. That would be a major compatibility break between version, something that
must be solved in Orbiter before final P2.

So Imho might still be a callback problem in Orbiter which might also break other things. (Os might certainly not be
the only addon relying on precise callback order which exist since almost 7 years to initialise things in a specific order)

As said Martin, Orbiter alpha is not stable in anyway yet. Better not hurry on it for users unless they know it's an alpha
and what this mean.

I'll try the latest alpha and let you know.

---------- Post added 11-02-12 at 04:52 AM ---------- Previous post was 11-01-12 at 04:30 PM ----------



Checked. Found.

The "sound" problem is also due to a callback order change in Orbiter,
see Beta forum about 121102, I've posted the report to Martin.

(and thanks for the link)

Dan

 

[dbeachy1]

Hi all,

I had a report that the Orbiter-beta-compatible XR DLLs were CTDing in the latest Orbiter beta version, and upon investigation it turned out I needed to rebuild the XR DLLs against the latest Orbiter beta SDK. While I was at it I also fixed the following two deprecation warnings in Orbiter.log:

---------------------------------------------------------------
>>> WARNING: Obsolete API function used: VESSEL::GetHorizonAirspeedVector
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: VESSEL::GetShipAirspeedVector
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.

Known issues:

• OrbiterSound does not play custom wav files under the Orbiter beta, so custom XR voice callouts and sound effects will not play. [More information is in Dansteph's post above this one.]
• XR vessel gear is sunk into the ground somewhat; this is purely a visual issue and will be fixed before new Orbiter version ships. It is occurring because the Orbiter core adjusts the touchdown points based on gear compression.

To install, just download the beta-compatible XR zip that you want and extract the DLL overtop of your existing XR DLL in your $ORBITER_HOME\modules folder:

• XR1 1.12 Beta-1
• XR2 1.7 Beta-1
• XR5 1.10 Beta-1

Happy flying! :tiphat:

 

[turtle91]

Sorry for necro-posting, but it seems to be that more and more people are trying the new Orbiter-Beta with the XR2.

I found a workaround to have all custom sounds enabled again. including APU, alerts, doors etc.
-When loading the XR2 switch off APU (at this point, there are no custom sounds, even not the APU sound)
-switch to a default vessel like i.e. ShuttlePB
-switch back to XR2, and all sounds custom sounds are working (at least for me using latest Orbiter Beta )

However, I can only use the XR2 in D3D9 client, the inline client crashes as soon as loaded the XR2.
But this this seems to be a known issue.

 

[jroly]

Deleted post got it all fixed

 

[jarmonik]

In XR1-XR5 2D cockpit, the MFDs do not display, in the 3D they are working fine thou.
Did more testing and the display works in dx7 client, just not displaying in dx9 sorry.

The difference between DX7 and DX9 is likely due to different MFD size settings used in DX7 and DX9 like 'Forced pow2' and 'Auto'.

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

 

[jroly]

Thanks jarmonik, I think my configurations in dx7 & dx9 were different therefor giving different result.

Now onto a another matter, I tried to land the XR1 at brighton beach but XR1 ground crashes when Orbit MFD displays altittude of below 0 but still 3km above the real surface. I finally got the XR1 working on my computer, I flew all the way from KSC a 4 day journey and I crash 3km from Brighton Beach

 

[GZR_Ranger]

Jroly,

I've been searching for a solution, other than setting the HardLandingsDamageEnabled and CrashDamageEnabled in the XR2RavenstarPrefs.cfg to "0". However, the auto hover will still turn off when you reach the "Orbiter 2010 'Surface.'" My work around for that has been to find a mountain to land on instead!

I've searched the forums but haven't had any luck. I hope one of you guys who's smarter than me can figure it out!

PS: I like the Motie avatar. I've always been a big Niven fan!

 

[jroly]

Jroly,

I've been searching for a solution, other than setting the HardLandingsDamageEnabled and CrashDamageEnabled in the XR2RavenstarPrefs.cfg to "0". However, the auto hover will still turn off when you reach the "Orbiter 2010 'Surface.'" My work around for that has been to find a mountain to land on instead!

I've searched the forums but haven't had any luck. I hope one of you guys who's smarter than me can figure it out!

PS: I like the Motie avatar. I've always been a big Niven fan!

Yes I did not change the xr cfg file, but I copied another brighton beach base to the apollo 15 mountains, it has a really nice view there.

 

[Abloheet]

ok, few bug reports for XR 2 ravenstar running in orbiter beta r50.
It more or less runs fine. But when on the ground, its wheels keep spinning eternally, and thus, I am unable to refuel it. Any solution? As if its never at rest.