Update Updated XR Vessels for Orbiter 2016 Released

SpaceCowboyJoe

New member
Joined
Sep 8, 2016
Messages
36
Reaction score
0
Points
0
Location
Milano
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.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
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. :blink:
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.
 

SpaceCowboyJoe

New member
Joined
Sep 8, 2016
Messages
36
Reaction score
0
Points
0
Location
Milano
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)
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
... 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.
 

SpaceCowboyJoe

New member
Joined
Sep 8, 2016
Messages
36
Reaction score
0
Points
0
Location
Milano
:):):):):):)

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! :hailprobe:
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Yes, it works this way: :thumbup:
I tried it on really bumpy terrain, 0.92 left moving all the time..skipped 1 hour in SCN-edit=vessel stopped.
Reverted one hour back..still vessel in stopped state.

At least we have a workaround for the moment, many thanks for that. :cheers:

Before the workaround.... doing multiple slingshots, aerobraking, reentry all was easy, compared to a "XR1/2 vessel stop". Just parking the vessel, was the most critcical and complicated part of all my missions I have tried in Orbiter2016 so far. :)
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,213
Reaction score
1,559
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
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)

All the XR's parking brakes do is keep the wheel brakes engaged, so if the wheel brakes can't stop the vessel no matter how long you hold them, neither will the parking brakes. The XR vessels' wheel friction parameters have not changed since the previous releases, and the same thing occurs in the Shuttle-A, so there's nothing I can do to fix it: we'll have to wait for Martin to fix it in the core. I recommend reporting the bug in the Orbiter 2016 thread and posting a scenario using the Shuttle-A that demonstrates the bug.
 

SpaceCowboyJoe

New member
Joined
Sep 8, 2016
Messages
36
Reaction score
0
Points
0
Location
Milano
All the XR's parking brakes do is keep the wheel brakes engaged, so if the wheel brakes can't stop the vessel no matter how long you hold them, neither will the parking brakes. The XR vessels' wheel friction parameters have not changed since the previous releases, and the same thing occurs in the Shuttle-A, so there's nothing I can do to fix it: we'll have to wait for Martin to fix it in the core. I recommend reporting the bug in the Orbiter 2016 thread and posting a scenario using the Shuttle-A that demonstrates the bug.

Thank you a lot in any case. It's clearly not a bug about the XR-2 even if for some reason it's more evident with that ship.
I'll report as you said. In the meanwhile we have the workaround to continue playing!! :thumbup:
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,213
Reaction score
1,559
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
I've been thinking about this, and I suppose I could add in a hack to the parking brake PreStep code to force the ship's relative velocity to zero using some DefSetStateEx sorcery whenever the parking brakes are engaged...but I really don't like that approach since it's a total hack. Maybe if I drink two glasses of bourbon I can talk myself into it... :p
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Yes I agree, that's just a hack for a general issue.
But why not implementing this in conjunction with the "air-brake", which has normaly zero purpose at ground, but could act as an emergency(hack)-brake ?
So the possible"hack" is not allways active...just on demand.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,213
Reaction score
1,559
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Fair points, I'll pour a bourbon tonight and implement this hack for the next patch release. May The Probe forgive me... :probe:
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,213
Reaction score
1,559
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Thanks to some help from fred18 I was able to get the hack working. Can you guys please download these beta DLLs and see if they fix your problem with wheel-stop on uneven surfaces? Beta links are:


Just drop these DLLs overtop your existing XR DLLs in $ORBITER_HOME\Modules. The vessels should now be forced to a wheel-stop 'landed' status whenever the parking brakes engage, which now happens when the vessel's surface-relative velocity falls below 0.04 meter-per-second (increased from 0.02 meter-per-second). Other changes include:

  • Saved window coordinates are now saved in the registry for each separate window size. This means that if you run Orbiter in different window resolutions, XR vessels will remember the render window's coordinates for each different resolution and restore the window to the correct coordinates when Orbiter loads. This also fixed a bug where the XR vessel would incorrectly move a D3D9 full-screen window when it should not.
  • Lowered the nosewheel steering assist threshold from 90 m/s to 15 m/s to reduce steering sensitivity on the runway (bug reported by PeterRoss).
  • The parking brakes no longer require the APU to be running in order to remain engaged. This persists across restarts as well.
  • Added a check to the external cooling and parking brake logic on startup to allow four seconds for the ship to settle down after the scenario loads before ship movement disconnects the external cooling line or disengages the parking brakes. (This is to help work around this Orbiter core bug.)
  • Fixed bug with the wrong greeting callout being played when the scenario loads with the ship landed: the correct callout is "Welcome aboard, Commander. All systems nominal," rather than just "All systems nominal," which is played when the ship is in flight or moving. (This was caused by this Orbiter core bug.)
  • Implemented two gruesome hacks to force the ship to remain at wheel-stop when the parking brakes are engaged. (This is to work around this Orbiter core bug.) Thanks to fred18 for providing info on how to get this hack working.

Please let me know how these beta versions work for you. :thumbup:
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Many thanks for that. :thumbup:
I have tried the "hack" to its extreme, and it seems to be working in all cases.
I.e. at my "favourite test island"...Ascension Island, I landed on pad1, and the vessel started to roll...as expected...like any vessel on this pad.
So I used the brakes with default settings, but was only able to slow down to 0.12 m/s.
However, I used then RCS thruster, and even a bit retro-engine to have had a successfull/permanent wheel-stop.

Then I connected external-cooling and switched off the APU and saved the scenario.
After scenario has been loaded, the vessel came-up with still IDLE/landed and external-cooling still engaged.:yes:

So I would say, the wheel-stop issue is solved (....or hack-arounded...).
Many thanks again :cheers:

The only issue I have so far is the ground-handling after landing, when using keyboad.
It's like that the nose-wheel is reacting a bit slow:

I.e. while slowing down from 150 m/s to 120 m/s, I lost controll of the vessel multiple times after landing.
Within the 150-120 speed-range, it looks like this:
-yanking in one direction via keyboard (NUM1 or NUM3)...first "nothing" seems to happen, than "all(too much)" happens.
-Then when reached the "all(too much)"-steering-level, you cannot compensate this anymore, maybe it takes too much time for the nose-wheel, to travel back to "neutral" ?

But, I have tested this at KSC RW33 only...so maybe it's just a KSC-thing in combinatiom with keyboard-steering.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,213
Reaction score
1,559
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Many thanks for that. :thumbup:
I have tried the "hack" to its extreme, and it seems to be working in all cases.
I.e. at my "favourite test island"...Ascension Island, I landed on pad1, and the vessel started to roll...as expected...like any vessel on this pad.
So I used the brakes with default settings, but was only able to slow down to 0.12 m/s.
However, I used then RCS thruster, and even a bit retro-engine to have had a successfull/permanent wheel-stop.

Then I connected external-cooling and switched off the APU and saved the scenario.
After scenario has been loaded, the vessel came-up with still IDLE/landed and external-cooling still engaged.:yes:

So I would say, the wheel-stop issue is solved (....or hack-arounded...).
Many thanks again :cheers:

Good to know, thanks for the testing and feedback!

The only issue I have so far is the ground-handling after landing, when using keyboad.
It's like that the nose-wheel is reacting a bit slow:

I.e. while slowing down from 150 m/s to 120 m/s, I lost controll of the vessel multiple times after landing.
Within the 150-120 speed-range, it looks like this:
-yanking in one direction via keyboard (NUM1 or NUM3)...first "nothing" seems to happen, than "all(too much)" happens.
-Then when reached the "all(too much)"-steering-level, you cannot compensate this anymore, maybe it takes too much time for the nose-wheel, to travel back to "neutral" ?

But, I have tested this at KSC RW33 only...so maybe it's just a KSC-thing in combinatiom with keyboard-steering.

There is no custom nosewheel steering assist at all above 15 m/s, so what you are seeing is handled entirely by the Orbiter core. If you look at the rudder deflection in external view while steering you can see how slow it is to recenter when using the keyboard (this is by design, I'm sure, because otherwise yaw control would be "jerky" while in flight). If you use a joystick with a twist axis for X, then you can have instant steering & yaw deflection changes. Barring that, one thing you can do is tap just one wheelbrake or the other to induce the ship to turn left or right on the ground.
 

turtle91

Active member
Joined
Nov 1, 2010
Messages
319
Reaction score
7
Points
33
Maybe it would be a nice Orbiter-feature, if yanking-controll-speed could be coupled to forward/backward DV. So yaw would be become more smooth with increasing velocity. :hmm: Until a hardcoded cut-off-value of course, to avoid zero reaction...

I tried it allready with a combination of very short yanks and very short toe-braking, but I lost (vessel)controll :blackeye: again. Might be related that I have increased the brake-force a bit in the config. More agressive brakes=more left/right turns. :facepalm:

But good to know that joystick-input works ok....I will give a try (the first time ever, that I will use a joystick in Orbiter...)
But the XRs are deserving a better input-device than a simple keyboard.
So....yes...agreed...convinced....I need a joystick. :yes:
 

SpaceCowboyJoe

New member
Joined
Sep 8, 2016
Messages
36
Reaction score
0
Points
0
Location
Milano
Thanks to some help from fred18 I was able to get the hack working. Can you guys please download these beta DLLs and see if they fix your problem with wheel-stop on uneven surfaces? Beta links are:


Just drop these DLLs overtop your existing XR DLLs in $ORBITER_HOME\Modules. The vessels should now be forced to a wheel-stop 'landed' status whenever the parking brakes engage, which now happens when the vessel's surface-relative velocity falls below 0.04 meter-per-second (increased from 0.02 meter-per-second). Other changes include:

  • Saved window coordinates are now saved in the registry for each separate window size. This means that if you run Orbiter in different window resolutions, XR vessels will remember the render window's coordinates for each different resolution and restore the window to the correct coordinates when Orbiter loads. This also fixed a bug where the XR vessel would incorrectly move a D3D9 full-screen window when it should not.
  • Lowered the nosewheel steering assist threshold from 90 m/s to 15 m/s to reduce steering sensitivity on the runway (bug reported by PeterRoss).
  • The parking brakes no longer require the APU to be running in order to remain engaged. This persists across restarts as well.
  • Added a check to the external cooling and parking brake logic on startup to allow four seconds for the ship to settle down after the scenario loads before ship movement disconnects the external cooling line or disengages the parking brakes. (This is to help work around this Orbiter core bug.)
  • Fixed bug with the wrong greeting callout being played when the scenario loads with the ship landed: the correct callout is "Welcome aboard, Commander. All systems nominal," rather than just "All systems nominal," which is played when the ship is in flight or moving. (This was caused by this Orbiter core bug.)
  • Implemented two gruesome hacks to force the ship to remain at wheel-stop when the parking brakes are engaged. (This is to work around this Orbiter core bug.) Thanks to fred18 for providing info on how to get this hack working.

Please let me know how these beta versions work for you. :thumbup:


Thank you so much. Looking forward to install the patch!!!! :thumbup::thumbup:
 

jroly

Donator
Donator
Joined
Jan 26, 2014
Messages
404
Reaction score
1
Points
18
Fair points, I'll pour a bourbon tonight and implement this hack for the next patch release. May The Probe forgive me... :probe:

th-battles-xindiincident1.jpg
 

Fury

New member
Joined
Sep 5, 2016
Messages
5
Reaction score
0
Points
0
Is DanSteph's UMMU 3 absolutely necessary for this fleet ?
I mean, is there a plan to remedy the situation of not being able to EVA while landed on Earth in Orbiter 2016 with the XR fleet ?
 
Top