Update Updated XR Vessels for Orbiter 2016 Released

[Abloheet]

I think ummu is disabled in this version. For example, I was unable to eva from the xr2

 

[turtle91]

As far as I know, UMMU is not disabled.
You can do an EVA, but if doing this on the ground, the UMMU will be climb like a rocket into space. The reason might be, that UMMU does not (yet) take care about the new touch-down-point-logic and the new altitude-over-ground-logic.
If you still want todo EVA, you can do this in free-space.
But only use external view, BEFORE swichthing to the UMMU, otherwise the UMMU-HUD will cause Orbiter to crash.

So currently UMMU can only be used:
-in external view in space
-transfering from (i.e. docked) ship-to-ship
-UMMu can die if i.e. you de-comress the cabin in space, and (depends on your XR-config), could make the ship unflyable (no pilot=no interaction wth the ships controlls)

 

[JonnyBGoode]

Will the addon still work if ummu is not installed?

 

[dbeachy1]

As far as I know, UMMU is not disabled.
You can do an EVA, but if doing this on the ground, the UMMU will be climb like a rocket into space. The reason might be, that UMMU does not (yet) take care about the new touch-down-point-logic and the new altitude-over-ground-logic.
If you still want todo EVA, you can do this in free-space.
But only use external view, BEFORE swichthing to the UMMU, otherwise the UMMU-HUD will cause Orbiter to crash.

So currently UMMU can only be used:
-in external view in space
-transfering from (i.e. docked) ship-to-ship
-UMMu can die if i.e. you de-comress the cabin in space, and (depends on your XR-config), could make the ship unflyable (no pilot=no interaction wth the ships controlls)

turtle91 is correct; UMMu works enough for the XRs to load and show crew, but it does not work much beyond that. There's nothing we can do until if and when DanSteph updates UMMu for Orbiter 2016.

Will the addon still work if ummu is not installed?

No. If you try to load an XR vessel without UMMu installed, you will get an error message popup and it will exit.

 

[Ripley]

t...There's nothing we can do until if and when DanSteph updates UMMu for Orbiter 2016...

I'll requote myself:
http://www.orbiter-forum.com/showthread.php?p=540458&postcount=3

:tiphat:

 

[PeterRoss]

One more little thing about weird behaviour:

1) If you have external cooling online but APU is off and you save and quit, when starting the scenario external cooling will turn off at startup with the appropriate voice over.

2) If you have both external cooling and APU online and save and quit, you will have both of these working on startup, but

3) If you manage to turn APU off at scenario startup before the "External cooling online" voice over the external cooling will turn off.

I guess it is connected with wheel brakes working from APU and external cooling being cut off when movement begins.

 

[turtle91]

If you have external cooling online but APU is off and you save and quit, when starting the scenario external cooling will turn off at startup with the appropriate voice over.

1)

I have this here and then, depends on the underlying terrain/pad, the ext.cooling will be off if SCN-reload. (even that APU left on and the vessel was perfectly stopped before I left the scenario).

Because of that and other reasons, I made the suggestion to couple the i.e. air-speed-button to a "switch-to-maximum-wheel-friction-function".

This could be then seen as some kind of "wheel-chocks", and I don't need to set unrealistic-friction-levels within the XR2-config, just to be able to stop the vessel at some more bumpy areas like i.e. ascension-island.


Another idea might be, like MS2015 is workarounding the ground-handling:
-at least for XR2 and XR5: we could use a payload, which will be released after parking (means if you find a place to stop your vessel...)
-then release the paylad, which should come with an attachment-controll-feature, and attach the XR2/5 to this vessel
-this "payload-vessel" could then have a very high friction-value, to hold the ships in place.
I would call it "anchor-vessel"....

But I would prefer my first idea, to make it simple.

 

[Iacomus Maximus]

1)
This could be then seen as some kind of "wheel-chocks", and I don't need to set unrealistic-friction-levels

I like the idea of a "wheel-chocks"

They're always the first thing to set after parking an aircraft and the last thing to remove when departing.

 

[dbeachy1]

Thinking about this some more, what I will do for the next patch release is make the parking brakes no longer require the APU. So you will still need the APU to apply the brakes (and therefore, to engage the parking brakes when the ship reaches wheel-stop), but once the parking brakes are set they will remain engaged without the APU.

 

[turtle91]

The problem with the new parking-brake is, that in bumpy terrain (again...Ascension Island is a good test/playground), you will never reach the state(0.00 m/s) , to have a "parking-brake-can be-aplied=TRUE situation.
The only way I found to "force" the vessel to a full stop in some areas, is to use a very very high friction-setting in XR-config. But with such a high friction, you cannot do landings on a runway.(and you need cheated engines to take-off)
It's like landing with brakes full-aplied...
So we need "max-friction" instead of a "brake" (or the brake on top of the friction).

I don't know, why the standard DG has not such problems. :hmm:
Friction-levels and brake-levels are looking similar to previous DG-versions....

 

[dbeachy1]

The problem with the new parking-brake is, that in bumpy terrain (again...Ascension Island is a good test/playground), you will never reach the state(0.00 m/s) , to have a "parking-brake-can be-aplied=TRUE situation.

XR vessels for Orbiter 2016 implement a velocity threshold for wheel-stop, which is currently 0.02 meter-per-second. I could increase that and/or make it configurable via a cheatcode setting, but TBH all this bounciness is getting messy.

The default DG doesn't have parking brakes, so this doesn't apply to it. In any case, you should have virtually identical braking performance between the XR1 and the default DG since they have virtually identical settings (the XR1 is basically a DG clone). The XR2 and XR5, of course, are much heavier and so will have different performance on bumpy terrain.

 

[Linguofreak]

As for Peter Ross's issue:

1) I can somewhat reproduce it in the XR-1, but the effect is minor enough to be corrected with joystick input.

2) The XR-2 seems to have the scaling on the hud wrong, so that the horizon line moves off the horizon if you have any pitch angle, and the velocity vector seems to be off from where it should be (vertically or horizontally) by a factor of two (so if the actual velocity vector is 1 degree off the nose, two degrees off the nose is shown). I'm not sure whether the actual drifting issue is worse in the XR-2, but the pilot's perception of such an issue existing is definitely enhanced, and the XR-2 is somewhat difficult to control at mid-speed on the runway, either due to an actual drift issue or due to pilot-induced-oscillation from the velocity vector error.

 

[turtle91]

The default DG doesn't have parking brakes, so this doesn't apply to it.

It does not need parking-brakes, because "somehow" it stays in position after wheel-stop.

Maybe a confusion. Here my steps to show the issue:
I have just downloaded the latest XR1 vessel and using standard-Orbiter2016-stable-release.
-No HIRES textures...all special features like complex-flightmodell, wind etc off.
-Only installed/active plugins= Orbiter-Sound and SCN-Editor.
-Tested with D3D9 and inline client.
-I have installed Ascension-Island2016 as a good test-playground. ([ame="http://orbithangar.com/searchid.php?ID=6991"]Ascension Island 2016[/ame])

Steps to reproduce the issue:

-load i.e. "Ready to take off to ISS" one of the XR1s defaults scenarious
-open SCN-Editor
-place the GL02 default DG (currently at Olympus on Mars) on Ascension Island Pad1.
-use forward RCS a bit
=GL02 starts to move...more and more caused by the bumpy terrain
-apply brakes
=GL02 slows down to 0, but you need to wait a couple of seconds, before you can release the brakes(watch i.e. surface MFD to calm down)
=GL02 stays on position

Then,put GL02 out of the way

-put XR1 on Ascension Island pad1
-apply forward RCS
=vessel starts to move
-apply brakes
=no way to brake down to 0.00...it stays allways at 0.12 m/s.

I used default XR1-settings....no friction-cheating this time.
When placed at Pad1 at Ascension-Island, my nose allways pointed into the north-direction.

...And...just for fun:
-spawn an Atlantis vessel
-lower gear
-place it on Ascension-Island Pad1
-use forward RCS or/and OMS
=Atlantis starts to move slowly
-apply brakes, again...for a couple of seconds
=Atlantis keeps on position

Maybe somebody else can confirm, that XR1/XR2 are not abe to stay on position at Ascension-Island Pad1..after the vessel has slightly moved ?
(at least with default XR settings)

---------- Post added at 02:09 PM ---------- Previous post was at 10:26 AM ----------

Hi again :facepalm:

I found another small cosmetical issue:
The ground-effect-particle-stream does not "look" for the new elevation-modell (altmode_ground).

Steps to reproduce:

-place a XR2 on a pad at Olympus/Mars (so we are below sea-level-alt)
-hover-up slowly, while using external view and SurfaceMFD via external MFD.
-as soon as SurfaceMFD reaches 0 altitude (so...sea-level...we are out of the hole), we can see the ground-particle-effect arround the XR2.

More funny:
-start to hover-up slowly and watch the hover-effect about 900 meters above your position.

So, in short words...the visual-ground-hover-effect does still uses mean-rad-altitude as a reference.

 

[jgrillo2002]

Wayback Machine still has the 2010 versions:
https://web.archive.org/web/20160313105120/http://alteaaerospace.com/index-3.html

We could upload them to OH. but we need permission from Doug first, though. Can we, Doug?

 

[dbeachy1]

I don't want old XR versions to be officially hosted on Orbit-Hanger since it can create confusion for users who just want to find the latest XRs. The other reason is that I do not provide support for old XR versions.

However, I have given Face permission to host the old XR versions on his OMP site since OMP (for now) only works under the old Orbiter 2010 P1 release. Or users can use the Wayback Machine links above.

 

[dbeachy1]

Steps to reproduce the issue:

-load i.e. "Ready to take off to ISS" one of the XR1s defaults scenarious
-open SCN-Editor
-place the GL02 default DG (currently at Olympus on Mars) on Ascension Island Pad1.
-use forward RCS a bit
=GL02 starts to move...more and more caused by the bumpy terrain
-apply brakes
=GL02 slows down to 0, but you need to wait a couple of seconds, before you can release the brakes(watch i.e. surface MFD to calm down)
=GL02 stays on position

Then,put GL02 out of the way

-put XR1 on Ascension Island pad1
-apply forward RCS
=vessel starts to move
-apply brakes
=no way to brake down to 0.00...it stays allways at 0.12 m/s.

I used default XR1-settings....no friction-cheating this time.

That is quite odd since the XR1 and the DG have virtually identical settings. Is there some torque acting on the XR1? (I thought that Orbiter 2016 core bug was fixed, though?) This looks more like an Orbiter core bug to me. Does the same thing happen with other third-party vessels?

When placed at Pad1 at Ascension-Island, my nose allways pointed into the north-direction.

The scenario editor / spawning the vessel is all handled by the Orbiter core. Do you mean that the default DG is spawned in a different direction?

.I found another small cosmetical issue:
The ground-effect-particle-stream does not "look" for the new elevation-modell (altmode_ground).

Steps to reproduce:

-place a XR2 on a pad at Olympus/Mars (so we are below sea-level-alt)
-hover-up slowly, while using external view and SurfaceMFD via external MFD.
-as soon as SurfaceMFD reaches 0 altitude (so...sea-level...we are out of the hole), we can see the ground-particle-effect arround the XR2.

More funny:
-start to hover-up slowly and watch the hover-effect about 900 meters above your position.

So, in short words...the visual-ground-hover-effect does still uses mean-rad-altitude as a reference.

Those effects are all handled by the Orbiter core. Do you mean that the effects are different for the default DG?

 

[turtle91]

That is quite odd since the XR1 and the DG have virtually identical settings. Is there some torque acting on the XR1? (I thought that Orbiter 2016 core bug was fixed, though?) This looks more like an Orbiter core bug to me. Does the same thing happen with other third-party vessels?

I don't have any other non-default vessels installed so far (beside XR1/XR2).
So, I had the idea to test this even with the default Atlantis (friction vs weight factor). There are still angular-torque-foces on all vessels, but very small. However, after XR1 starts moving, there is no way back to have a "IDLE/landed" status. The brakes just don't have any effect when moving slowly(i.e 0.12m/s forced by terrain-alt-difference)

Originally Posted by turtle91 View Post
When placed at Pad1 at Ascension-Island, my nose allways pointed into the north-direction.
The scenario editor / spawning the vessel is all handled by the Orbiter core. Do you mean that the default DG is spawned in a different direction?

No,...confusion...I just mentioned the northbound-direction to avoid confusions (i.e. in which direction the vessel might "move-forever", after forward RCS-thrust has been aplied. Just to make sure, that in case you are trying to replicate, we are using same start-up setup).

Regarding hover-smoke-ground-effects:

hose effects are all handled by the Orbiter core. Do you mean that the effects are different for the default DG?

You are right, I can replicate this issue even with the default-DG at Olympus.
(apply some hover-thrust and look above your vessel, there is smoke about 900 meters above the vessel (where SurfaceMFD reports "0" alt)).
Will submit this issue as a bug later to Martin.

 

[SpaceCowboyJoe]

I have the same issue about the XR2.
I just can't stop it. Increasing the "velocity threshold for wheel-stop" sounds a great idea.
Actually the brakes seems in general be very weak (but maybe it's more realistic than I'm assuming)
I've tried change following parameter in the XR2 CFG

#MaxWheelbrakeForce=1.0e5

I've changed several values but nothing seem to happen

 

[turtle91]

You can increase WheelSurfaceFrictionCoeff to something like this "0.825".
But you will not be able to take-off a runway using default/realistic engine-settings.
Landing is nearly impossible, too (=landing with brakes+chute+anchor allready aplied before touchdown...).
At least on the Moon, you will have a wheel-stop without any issues using unrealistic 0.825-value.

 

[dbeachy1]

The unable-to-wheel-stop issue appears to be an Orbiter core bug -- see the Restless Spacecraft in Orbiter 2016 thread:

This is particularly evident with the XR2 but it happens the same to me with the Shuttle-A.

If holding the brakes can't stop the vessel, then modifying the XR vessels' parking brake wheel-stop threshold won't help, either, since that simply keeps the wheel brakes applied at 100% for you. I believe we will need to wait until Martin can investigate and fix the core issue.