Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addons
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addons A repository for Orbiter addons contributed by users. Developers & members may announce new releases here and discuss any Orbiter addon.

Reply
 
Thread Tools
Old 09-14-2016, 01:50 AM   #31
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

Quote:
Originally Posted by turtle91 View Post
 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.
dbeachy1 is offline   Reply With Quote
Old 09-14-2016, 06:59 AM   #32
Linguofreak
Orbinaut
Default

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.
Linguofreak is offline   Reply With Quote
Old 09-14-2016, 02:09 PM   #33
turtle91
Orbinaut
Default

Quote:
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. (
Ascension Island 2016
)

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

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.

Last edited by turtle91; 09-14-2016 at 10:45 AM.
turtle91 is offline   Reply With Quote
Old 09-14-2016, 02:38 PM   #34
jgrillo2002
Conservative Pioneer
 
jgrillo2002's Avatar
Default

Quote:
Originally Posted by Keatah View Post
 Wayback Machine still has the 2010 versions:
https://web.archive.org/web/20160313...m/index-3.html
We could upload them to OH. but we need permission from Doug first, though. Can we, Doug?
jgrillo2002 is offline   Reply With Quote
Old 09-14-2016, 05:08 PM   #35
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

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 is offline   Reply With Quote
Old 09-14-2016, 05:17 PM   #36
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

Quote:
Originally Posted by turtle91 View Post
 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?

Quote:
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?

Quote:
Originally Posted by turtle91 View Post
 .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?
dbeachy1 is offline   Reply With Quote
Old 09-14-2016, 05:42 PM   #37
turtle91
Orbinaut
Default

Quote:
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)

Quote:
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:
Quote:
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.
turtle91 is offline   Reply With Quote
Thanked by:
Old 09-14-2016, 07:25 PM   #38
SpaceCowboyJoe
Orbinaut
Default

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
SpaceCowboyJoe is offline   Reply With Quote
Old 09-14-2016, 07:36 PM   #39
turtle91
Orbinaut
Default

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.
turtle91 is offline   Reply With Quote
Old 09-14-2016, 08:32 PM   #40
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

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

Quote:
Originally Posted by SpaceCowboyJoe View Post
 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.
dbeachy1 is offline   Reply With Quote
Thanked by:
Old 09-14-2016, 08:35 PM   #41
SpaceCowboyJoe
Orbinaut
Default

Thankyou. I'll try that one. Currently the config file is
#WheelSurfaceFrictionCoeff=0.025

It's clearly a commented line but, I guess, it gives me the defaul value which seems pretty low compared to what you suggest.
SpaceCowboyJoe is offline   Reply With Quote
Old 09-14-2016, 09:18 PM   #42
turtle91
Orbinaut
Default

Yes, "WheelSurfaceFrictionCoeff=0.025" is default so I just played around with this setting and ended up with an leading "8" so "0.825".

Btw, I found a strange way to start/land the vessel successfully using such a high friction:
-just set "MaxWheelbrakeForce=0".

So if you want to taxi/start/land, you need to press the brakes, to have less friction.
You still have brakes, but relative low compared to the high 0.825 fricton.
So if you want to stop the vessel, release the brakes.
Somehow this inverts the logic...but somehow it works for me.
turtle91 is offline   Reply With Quote
Thanked by:
Old 09-14-2016, 09:58 PM   #43
SpaceCowboyJoe
Orbinaut
Default

To me it doesn't.
Point is that depending on situation (earth/moon/slope) I still got an accelleration and a rotation.
Whatever combo I can't get easily to a speed low enough to stop the vessel.
At this point I'd just wait for the bug to be fixed either dbeachy1 to make the autobrake to engage at a bigger speed (or even better a cfg parameter)
SpaceCowboyJoe is offline   Reply With Quote
Old 09-14-2016, 10:09 PM   #44
turtle91
Orbinaut
Default

Quote:
... I still got an accelleration and a rotation.
Maybe you are running into ths issue: (?)

http://www.orbiter-forum.com/project.php?issueid=1271

This could happen, if you have used an autopilot before landing (i.e. hover.mfd has still not implemented the known workaround in its current release).
But this would apply to all ships which have RCS-thruster, like i.e. the ShuttleA.
turtle91 is offline   Reply With Quote
Old 09-14-2016, 10:24 PM   #45
SpaceCowboyJoe
Orbinaut
Default



Found a very easy workaround.

- Dont pause the game
- Open the scenario Editor (in 2016 you have it enabled in the function button toolbar on top center screen)
- Leave everithing as default and just add one hour and return back to current time and...

TADAAAAAAAAAAAAA!

your vessel is stopped!
SpaceCowboyJoe is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Addons > Addons


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 04:30 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.