Update XR Beta DLLs for Orbiter 2016 Release Candiates

[Ripley]

I'm sorry I can't help more. I'm on a sailboat in the Tirrenian Sea, lucky me!

Anyway, SVN rev 60 was tagged as RC3.
Now the latest is rev 61. Maybe 60 and 61 are still the same, as far as this test concerns.
I understand your ISP bandwidth issue, but try to update to rev 61.

 

[turtle91]

Now the latest is rev 61. Maybe 60 and 61 are still the same, as far as this test concerns.
I understand your ISP bandwidth issue, but try to update to rev 61.

No, missunderstanding....my fault. I am allready at latest SVN-level. (rev 61)
I have just pointed out the surface-handling-fix which has been implemented in rev 60.

I'm sorry I can't help more. I'm on a sailboat in the Tirrenian Sea, lucky me!

Np, enjoy your trip and...bon voyage captain.

 

[turtle91]

I have another one, might be related.....

I went to Mars...and all went fine.
After landing at Olympus/Pad01, I cannot get the wheels stop using brakes.
It's a bit strange, because the vessel reported a full "wheel stop" and it stays on position, even after going to max time-accel.
Also all MFDS are "quite", so the vessel is def. at a stopped state.

But the wheels are spinning very slowly, so I cannot aply the parking-brake, or connect any external resources.

The only way to stop the wheel-spinning is to use RCS a bit.
As soon as external view shows no more-wheel-movements, I can aply the parking-brake.
But...after a couple of seconds, the parking-brake dissengages, and the wheel are starting to spin again.

Again, while all this happens, the vessel is stable on the ground...no moves..just the wheels.

For esy repro-test, below my scenario:

BEGIN_DESC

END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 52130.2113387405
  Help CurrentState_img
END_ENVIRONMENT

BEGIN_FOCUS
  Ship XR2-01
END_FOCUS

BEGIN_CAMERA
  TARGET XR2-01
  MODE Extern
  POS 2.543811 -46.853121 -6.732254
  TRACKMODE TargetRelative
  FOV 40.00
END_CAMERA

BEGIN_PANEL
END_PANEL

BEGIN_SHIPS
XR2-01:XR2Ravenstar
  STATUS Landed Mars
  POS -135.4300661 12.7399988
  HEADING 101.69
  ALT 2.559
  AROT -165.197 -40.298 -112.813
  RCSMODE 0
  PRPLEVEL 0:0.802261 1:0.985214 2:1.000000
  IDS 0:199 100
  NAVFREQ 588 466 84 114
  XPDR 193
  SECONDARY_HUD 0
  LAST_ACTIVE_SECONDARY_HUD 0
  ADCTRL_MODE 0
  TAKEOFF_LANDING_CALLOUTS 0.066927 0.000000 0.000000 0.000000 0.000094
  APU_FUEL_QTY 0.710080
  LOX_QTY 0.206395
  CABIN_O2_LEVEL 0.209000
  CREW_STATE 0
  INTERNAL_SYSTEMS_FAILURE 0
  COGSHIFT_MODES 0 0 0
  MWS_ACTIVE 0
  COOLANT_TEMP 31.200000
  DMG_0 1.000000 Left Wing
  DMG_1 1.000000 Right Wing
  DMG_2 1.000000 Left Aileron
  DMG_3 1.000000 Right Aileron
  DMG_4 1.000000 Landing Gear
  DMG_5 1.000000 Nosecone
  DMG_6 1.000000 Retro Doors
  DMG_7 1.000000 Top Hatch
  DMG_8 1.000000 Radiator
  DMG_9 1.000000 Airbrake
  DMG_10 1.000000 Left Main Engine
  DMG_11 1.000000 Right Main Engine
  DMG_12 1.000000 Left SCRAM Engine
  DMG_13 1.000000 Right SCRAM Engine
  DMG_14 1.000000 Fore Hover Engine
  DMG_15 1.000000 Aft Hover Engine
  DMG_16 1.000000 Left Retro Engine
  DMG_17 1.000000 Right Retro Engine
  DMG_18 1.000000 Forward Lower RCS
  DMG_19 1.000000 Aft Upper RCS
  DMG_20 1.000000 Forward Upper RCS
  DMG_21 1.000000 Aft Lower RCS
  DMG_22 1.000000 Forward Star. RCS
  DMG_23 1.000000 Aft Port RCS
  DMG_24 1.000000 Forward Port RCS
  DMG_25 1.000000 Aft Star. RCS
  DMG_26 1.000000 Outboard Upper Port RCS
  DMG_27 1.000000 Outboard Lower Star. RCS
  DMG_28 1.000000 Outboard Upper Star. RCS
  DMG_29 1.000000 Outboard Lower Port RCS
  DMG_30 1.000000 Aft RCS
  DMG_31 1.000000 Forward RCS
  DMG_32 1.000000 Bay Doors
  IS_CRASHED 0
  MET_STARTING_MJD 51984.966555
  INTERVAL1_ELAPSED_TIME 3.495220
  INTERVAL2_ELAPSED_TIME -1.000000
  MET_RUNNING 1
  INTERVAL1_RUNNING 1
  INTERVAL2_RUNNING 0
  ACTIVE_MDM 3
  TEMP_SCALE 2
  CUSTOM_AUTOPILOT_MODE 0
  AIRSPEED_HOLD_ENGAGED 0
  SCRAM0DIR 0.000000 0.000000 1.000000
  SCRAM1DIR 0.000000 0.000000 1.000000
  HOVER_BALANCE 0.000000
  MAIN0DIR 0.000000 0.000000 1.000000
  MAIN1DIR 0.000000 0.000000 1.000000
  GIMBAL_BUTTON_STATES 0 0 0 0 0 0
  ATTITUDE_HOLD_DATA 0.000000 0.000000 0 0 0.000000
  DESCENT_HOLD_DATA 0.000000 -3.000000 0
  AIRSPEED_HOLD_DATA 0.000000
  OVERRIDE_INTERLOCKS 0 0
  TERTIARY_HUD_ON 0
  CREW_DISPLAY_INDEX 0
  GEAR 1 1.0000
  RCOVER 0 0.0000
  NOSECONE 1 1.0000
  AIRLOCK 1 1.0000
  IAIRLOCK 0 0.0000
  CHAMBER 1 1.0000
  AIRBRAKE 1 1.0000
  RADIATOR 1 1.0000
  LADDER 0 0.0000
  HATCH 0 0.0000
  SCRAM_DOORS 0 0.0000
  HOVER_DOORS 0 0.0000
  APU_STATUS 0
  EXTCOOLING_STATUS 0
  TRIM 0.000000
  LIGHTS 0 0 0
  XR1UMMU_CREW_DATA_VALID 1
  UMMUCREW XI0-Lee_Nash-39-65-78
  UMMUCREW XI1-Kara_Miller-32-65-58
  UMMUCREW XI2-Sharon_Valerii-26-67-54
  UMMUCREW XI3-Cameron_Mitchell-36-65-77
  UMMUCREW XI4-Samantha_Carter-33-66-53
  UMMUCREW XI5-Daniel_Jackson-35-68-75
  UMMUCREW XI6-Teal_c-31-64-104
  UMMUCREW XI7-Vala_Mal_Doran-30-67-53
  UMMUCREW XI8-Elizabeth_Weir-36-68-56
  UMMUCREW XI9-John_Sheppard-34-64-77
  UMMUCREW XI10-Rodney_McKay-35-72-90
  UMMUCREW XI11-Teyla_Emmagan-27-68-57
  UMMUCREW XI12-Ronon_Dex-32-63-97
  UMMUCREW XI13-Carson_Beckett-38-74-95
  PAYLOAD_SCREENS_DATA 0.2 0 1 1
  PAYLOAD_BAY_DOORS 1 1.0000
END
XR2-01_Bay:XRPayloadBay
  STATUS Landed Mars
  POS -135.4301169 12.7400090
  HEADING 101.69
  ALT 3.623
  AROT -66.545 -17.235 148.666
  ATTACHED 0:3,XR2-01
  AFCMODE 7
END
XR2PayloadCHM-01-1:XR2PayloadCHM
  STATUS Landed Mars
  POS -135.4300311 12.7399917
  HEADING 101.69
  ALT 3.335
  AROT -113.087 -34.062 169.980
  ATTACHED 0:0,XR2-01
  AFCMODE 7
  NAVFREQ 0 0
END
END_SHIPS


BEGIN_DX9ExtMFD
END

 

[martins]

Three tips that might help debugging the issue:

1. Set a fixed time step under Extra | Debug on the Launchpad. This should nullify framerate-related differences between runs on different computers, and make tests reproducible.
2. Open the object info dialog (Ctrl-I) for the focus vessel and scroll down to the bottom. You'll see an indicator ACTIVE/IDLE. As soon as this switches to Idle after landing. the vessel is considered fully parked as far as Orbiter is concerned. This should happen 5 seconds after all criteria are satisified (ground contact, no thrust forces, linear and angular velocities below a fixed threshold
3. Turn on the force vector display (Ctrl-F9). In addition to the weight/lift/drag forces known from Orbiter2010, this also displays (undocumented) friction forces from all surface contact points. This might or might not provide some insight.

 

[turtle91]

Many thanks martins, this makes the trouble-shooting a bit more structured...no so much guess+tries.

I have tried the suggesting changes/settings, and the outcome seems to be XR-vessel-only-related:

I tried various fixed timestamps, but got allways the same result:

-when the scenario loads-up, it takes about 5 seconds to have the "IDLE(landed)" status in Orbiters point-of view (CTRL+-I)
-but when displaying the vectors, I can see at least one vector which seems to be still active:
Here I have an ultra-fast-changing vel-vector which points from the middle of the ship in the SE(relative to ship-nose) direction and aplies all the time 0.218 - 0.219 Nm.
When I aply the brakes, the value goes down to stable 0.184 Nm.
But reaching "0" for a short time is only possible when using RCS.

So...maybe we some kind of "invisible neverending RCS force", which might lead into the problem ?


...just to add, I tried in DX7 and D3D9 client, all other modules disabled, but got allways the 0.2xx Nm SE. (angular torque force)
I have also emptied all the fuel/RCS recources, but..."the force is still with me"


Edit:

I just found out, that every vessel in orbiter shows an angular torque, even while "IDLE(landed".
So maybe we need just some kind of: "if all vel-vectors are < 1 ....stop the wheels to avoid further logic-issues by still moving wheels...."

 

[fred18]

Just a note that I had huge issues when implementing the beta version of Ms2015 to keep the ship stopped in terrains which were not perfectly even. The status never returned to IDLE even if i tried to force it via code. I've been thinking a lot a that it would be good to have a parking brake option or to be able to force the idle status somehow. I don't know if that helps anybody, just giving my idea.

 

[turtle91]

I am realy wondering where this permanent "angular torque force" is coming from.
I.e. the default DG shows me 1.x Nm all the time, while still perfect stopped (IDLE(landed)).
Even trying different "parameters" in Orbiters settings have not changed this behaviour.
I even tried to switch between SW and HW clock, just to see if it's my HW.
But the force remains.

In Orbiter 2010, if a vessel is stopped, there are no "angular torque force" vectors visible.
So if a vessel relies on 0-velocity-vectors, to perform whatever-logic, the logic will never happen.

This could be even worse if a i.e. launch-tower-vessel starts to move over the time.
I.e. you launch a rocket and after probe/capsule-separation, you might use time-accel-max.
In worst case, you might meet the launch-tower somwhere in deep-space...:uhh:

 

[dbeachy1]

Hi all,

I built and uploaded the first full release candidate versions of the XR vessels for Orbiter 2016, including a tweaked flight manual; please try them out and see if anything is missing or incorrect:

• XR1 1.12
• XR2 1.7
• XR5 1.10

Happy flying! :tiphat:

 

[turtle91]

Thanks for the updated complete package.
The "ladder- vs payload-button" issue is solved.
I have just installed it, used the default XR-config, but the wheels are still spinning at Olympus pad 1, even after reaching "IDLE(ladning)" state.
So still no way to connect external resources.

 

[dbeachy1]

I have just installed it, used the default XR-config, but the wheels are still spinning at Olympus pad 1, even after reaching "IDLE(ladning)" state.
So still no way to connect external resources.

I reproduced what you are seeing at Olympus with the default DeltaGlider using both the inline DX7 and D3D9 clients, so unfortunately this appears to be an Orbiter core bug. Here is the scenario that reproduces the problem -- the DG, like the XR2 at the same pad, has a constant 0.07 meters-per-second velocity per the Surface MFD and wheel brakes cannot stop it:

BEGIN_DESC
Mirrors XR2 default scenario Parked at Olympus Base. Notice that the ship moves at 0.07 meters-per-second per the Surface MFD and the wheel brakes can't stop it. 
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 51983.3851829664
END_ENVIRONMENT

BEGIN_FOCUS
  Ship GL-01
END_FOCUS

BEGIN_CAMERA
  TARGET GL-01
  MODE Cockpit
  FOV 40.00
END_CAMERA

BEGIN_HUD
  TYPE Surface
END_HUD

BEGIN_MFD Left
  TYPE Surface
  SPDMODE 1
END_MFD

BEGIN_MFD Right
  TYPE Map
  REF Mars
  BTARGET Olympus
  TRACK ON
END_MFD

BEGIN_PANEL
END_PANEL


BEGIN_SHIPS
GL-01:DeltaGlider
  STATUS Landed Mars
  BASE Olympus:1
  POS -135.4299985 12.7399989
  HEADING 318.01
  RCSMODE 0
  PRPLEVEL 0:0.977 1:1.000
  NAVFREQ 94 524 84 114
  XPDR 0
  GEAR 1 1.0000
  NOSECONE 0 0.05
  LADDER 0 0.1
  AIRLOCK 0 0.1
  IAIRLOCK 0 0.1
  RADIATOR 0 0.0313
  PSNGR 2 3 4
END
END_SHIPS

BEGIN_ExtMFD
END

Can you please see if the default DG in the above scenario also shows the same constant 0.07 meters-per-second velocity for you? If it does, then I suggest you post the issue in the Orbiter 2016 - RC.4 thread (or I could do it).

 

[turtle91]

Yes, I ws able to reproduce the problem, by using your scn.

I can see (in CTRL-I), that the DG shows IDLE/landed, but the velocity shows 0.07 m/s in the same vessel-data-window.

There is also an angular torque force doing its job at 4.408 and 4.407 Nm...all the time.
I have also seen this forces active when used the default-Atlantis-scenario.
Here the vessel is at the launchpad and I can see angular vectors at the suttle an all its attachments (SRB's, ET...).

In Orbiber 2010, this vectors are not there as long as not moving the vessles (what I expect).

As mentioned before, my Orbiter2016-Install might be not the same like most people are using (I am still on SVN+using outdated textures/meshes).
So maybe you or somebody else with a pure RC4-install could report this to Martin ?
If not...yes I can do it, but if someboy with a more standard-install could do this, it might has more "weight".

 

[turtle91]

Btw...a really unimportant graphics-glitch, in the XR2. (picture attached)

 

[dbeachy1]

Btw...a really unimportant graphics-glitch, in the XR2. (picture attached)

Good catch on the bug, it's in the 1280-wide panel. I can't believe that hasn't been reported before, because it's been there from day one. :lol: I'll fix that for the next build.

Regarding the constant-velocity bug on Mars, I'll post it in the RC4 thread.

 

[turtle91]

Yes, the glitch was from the very beginning on, I just forgot to report this earlier.
Btw...I have seen the same 0.07 m/s TAS on the moon (regardless which vessel).
So atmosphere seems to be unrelated.

Regarding the constant-velocity bug on Mars, I'll post it in the RC4 thread.

Perfect, and many thanks for that :tiphat:

 

[dbeachy1]

I just uploaded a new XR2 version with a fix for the 1280 main panel bug that turtle91 reported. It's the same download link. :thumbup:

 

[turtle91]

I have still issues to perform a full wheel-stop on a bumpy base compared to stock Deltaglider.

A good bumpy base to test: [ame="http://orbithangar.com/searchid.php?ID=6991"]Ascension Island 2016[/ame]
Here at Pad1, after landing, I have no chance to perform a wheel-stop.
While the default DG has not such probems.

The only way to have a wheel-stop at this pad1, is to use the following settings in XR2-config:

MaxWheelbrakeForce=2.0e5 (default DG-setting)
WheelSurfaceFrictionCoeff=0.825(ouch...like having no wheels+and anchor attached)

According to the API, a Friction-value of about 0.1 should be used in wheeled vessels.
If the vessel has no wheels, 0.5 should be used as a starting reference.
...And I need 0.8 for the XR2 ?

If I use this settings, take-off at KSC (using strong/easy) engines is a challenge.
I needed also to change the: AFCtrlPerformanceModifier to about 2.80! to brute-force a lift/push-off.
It took about the entire runway to take-off with such a high friction, and landing was a disaster because of the high friction ( like...landing with "brakes" engaged).

So a "dirty" quick soultion could be to have a "friction100-button" to make sure that the vessels stays on position after landing.(maybe miss-using the air-brake-button..?)

 

[PeterRoss]

I have still issues to perform a full wheel-stop on a bumpy base compared to stock Deltaglider.

A good bumpy base to test: Ascension Island 2016
Here at Pad1, after landing, I have no chance to perform a wheel-stop.
While the default DG has not such probems.

The only way to have a wheel-stop at this pad1, is to use the following settings in XR2-config:

MaxWheelbrakeForce=2.0e5 (default DG-setting)
WheelSurfaceFrictionCoeff=0.825(ouch...like having no wheels+and anchor attached)

According to the API, a Friction-value of about 0.1 should be used in wheeled vessels.
If the vessel has no wheels, 0.5 should be used as a starting reference.
...And I need 0.8 for the XR2 ?

If I use this settings, take-off at KSC (using strong/easy) engines is a challenge.
I needed also to change the: AFCtrlPerformanceModifier to about 2.80! to brute-force a lift/push-off.
It took about the entire runway to take-off with such a high friction, and landing was a disaster because of the high friction ( like...landing with "brakes" engaged).

So a "dirty" quick soultion could be to have a "friction100-button" to make sure that the vessels stays on position after landing.(maybe miss-using the air-brake-button..?)

So, you have troubles with XR2 behaviour while landed too? Could you please check if you have the problem I've described here:
http://www.orbiter-forum.com/showthread.php?p=541220&postcount=11

 

[turtle91]

Yes, I tried to taxi the XR2 a bit at Ascension Island(with default settings).
Beside that a wheel-stop was not possible, I yanked left and right all the time.
I guess, that the nose-wheel lost ground-contact, so steering left/right is only possible on a 101 percent flat taxiway. So I tried a combination of toe-braking and left/right steering...but at the end...I cheated with hovering back to planned position.

So the ground-handling in general could be a bit improved IMO.

 

[T1234]

XR5 Underpowered

Taking off with the XR5 with almost full cargo will not exceed 2km alt and 300m/s, so it needs more thrust,is this a bug? I have wind effects disabled.

 

[dbeachy1]

Taking off with the XR5 with almost full cargo will not exceed 2km alt and 300m/s, so it needs more thrust,is this a bug? I have wind effects disabled.

No, what limits your velocity at 2 km is air density combined with lower main engine efficiency in dense atmosphere -- you need to baby the ship up to a higher altitude where the air is thinner and you can engage the SCRAM engines. Try to keep your SCRAM TSFC in the green on the gauge to get as much thrust as you can out of the SCRAM engines for the SCRAM fuel you have.

To double-check, I just flew a test flight here with a fully loaded XR5 (432 tons of cargo) from KSC using the payload editor to fill the bay in the default "Ready for Takeoff to ISS" scenario, and reached a 257k x 257k orbit with 0.4% SCRAM fuel remaining, 94.3 RCS fuel remaining, and 12.5% main fuel remaining (and I was pretty rusty on a full-cargo ascent :lol. So while it does take some "babying the ship into orbit" when you're hauling 432 tons of cargo, you can do it. After all, challenge is what makes it fun!