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, 10:42 PM   #46
turtle91
Orbinaut
Default

Yes, it works this way:
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.

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


Default

Quote:
Originally Posted by SpaceCowboyJoe View Post
 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.
dbeachy1 is offline   Reply With Quote
Thanked by:
Old 09-15-2016, 08:20 AM   #48
SpaceCowboyJoe
Orbinaut
Default

Quote:
Originally Posted by dbeachy1 View Post
 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!!
SpaceCowboyJoe is offline   Reply With Quote
Thanked by:
Old 09-15-2016, 06:27 PM   #49
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

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...
dbeachy1 is offline   Reply With Quote
Thanked by:
Old 09-15-2016, 06:56 PM   #50
turtle91
Orbinaut
Default

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.
turtle91 is offline   Reply With Quote
Old 09-15-2016, 07:01 PM   #51
Interceptor
Orbinaut
 
Interceptor's Avatar
Default

Plus once the issue gets fixed in the next orbiter patch,you could remove it.
Interceptor is offline   Reply With Quote
Old 09-15-2016, 07:30 PM   #52
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

Fair points, I'll pour a bourbon tonight and implement this hack for the next patch release. May The Probe forgive me...
dbeachy1 is offline   Reply With Quote
Old 09-17-2016, 02:05 AM   #53
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

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.
dbeachy1 is offline   Reply With Quote
Old 09-17-2016, 10:17 AM   #54
turtle91
Orbinaut
Default

Many thanks for that.
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.

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

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.
turtle91 is offline   Reply With Quote
Old 09-17-2016, 04:34 PM   #55
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

Quote:
Originally Posted by turtle91 View Post
 Many thanks for that.
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.

So I would say, the wheel-stop issue is solved (....or hack-arounded...).
Many thanks again
Good to know, thanks for the testing and feedback!

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

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. 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 again. Might be related that I have increased the brake-force a bit in the config. More agressive brakes=more left/right turns.

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.
turtle91 is offline   Reply With Quote
Old 09-18-2016, 12:24 PM   #57
PeterRoss
Warranty man
 
PeterRoss's Avatar
Default

Quote:
Originally Posted by turtle91 View Post
 So....yes...agreed...convinced....I need a joystick.
Yes, joystick helps

This new patch/hack makes taxiing possible, and the vessel is controllable during takeoff run on ground. Everything's cool
PeterRoss is offline   Reply With Quote
Thanked by:
Old 09-19-2016, 06:30 AM   #58
SpaceCowboyJoe
Orbinaut
Default

Quote:
Originally Posted by dbeachy1 View Post
 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.

Thank you so much. Looking forward to install the patch!!!!
SpaceCowboyJoe is offline   Reply With Quote
Old 09-19-2016, 08:24 AM   #59
jroly
Donator
 
jroly's Avatar
Default

Quote:
Originally Posted by dbeachy1 View Post
 Fair points, I'll pour a bourbon tonight and implement this hack for the next patch release. May The Probe forgive me...
jroly is offline   Reply With Quote
Old 10-25-2016, 02:13 AM   #60
Fury
Orbinaut
Default

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 ?
Fury 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 07:50 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.