Orbiter-Forum  

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

Addon Development Developers post news, updates, & discussions here about your projects in development.

Reply
 
Thread Tools
Old 08-21-2016, 03:00 AM   #31
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

Unfortunately I still can't dupe the issue. I did, however, fix the VESSEL::CreateVariableDragElement, oapiTriggerPanelRedrawArea, and VESSEL::GetHorizonAirspeedVector warnings in Orbiter.log on startup.

Note that there are still some warnings about VESSEL::GetHorizonAirspeedVector in orbiter.log on the included XR scenarios, but they are not coming from XR code -- I get the same warnings when loading the default Delta-glider/DG-S ready for takeoff scenario, so it must be some other module that is causing the issue (maybe OrbiterSound?).

Anyway, one thing you can try is to play around with uncommenting the following settings lines and setting different values for these two cheatcodes in your Config\XR2RavenstarPrefs.cfg file to see if changes how much your ship "slides around" at KSC or Brighton Beach:

Code:
#--------------------------------------------------------------------------
# Maximum wheelbrake force in newtons
#--------------------------------------------------------------------------
MaxWheelbrakeForce=1.0e5

#--------------------------------------------------------------------------
# Wheel friction coefficient (and resistance) when rolling on the ground; 
# also affects braking performance.
#--------------------------------------------------------------------------
WheelSurfaceFrictionCoeff=0.025
dbeachy1 is offline   Reply With Quote
Old 08-21-2016, 04:14 AM   #32
turtle91
Orbinaut
Default

That's realy strange, that you can't reproduce the problem.
What terrain/mesh-files you are using ? Maybe your mesh is more flat at BB.

I played with the values you have mentioned, unil a factor more of 30x more than default...just for testing.

Code:
08.21.2016 05:58:57.164 - [XR2-01] >>> CHEATCODE ENABLED: MaxWheelbrakeForce = 3300000.000000
08.21.2016 05:58:57.164 - [XR2-01] >>> CHEATCODE ENABLED: WheelSurfaceFrictionCoeff = 32.025000
But there was no different.

The only way to force a wheel-stop at default-BB-scenario I found so far:
-loaded the scenario...the vessel slightly moves to the right (0.08 - 0.10 m/s)
-started APU...pressed brakes
=able to maintain a stable 0.10 m/s right-move (no more accelerating to > 0.10 m/s
but no wheel stop

-used the RCS-yank commands (numpad 1 and 3) to force a "RCS-brake"
=after some RCS-bursts, the wheels finaly stopped, and I was able to aply the parking-brake

Then I enabled external-cooling, before I quick-saved the scenario

However, after reloading the scenario, the problem is back:
=
-external cooling offline
-vessel moving again to the left...starting with 0.08 m/s

I also tried different Orbiter-difficult settings (like complex-flight-modell etc.), but got allways the same result. (tested in DX7 and DX9 client btw).

I am running out of ideas....
turtle91 is offline   Reply With Quote
Old 08-21-2016, 05:41 AM   #33
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

One thing that may be different is that I am using the high-resolution textures and mesh -- maybe that has a different effect with the Orbiter core?
dbeachy1 is offline   Reply With Quote
Old 08-21-2016, 05:48 AM   #34
turtle91
Orbinaut
Default

This would make sense, I am using the low-res meshes/textures.
Forced by my ISP, who gives me 5 GB per month..before reducing my bandwith to 5k/s
turtle91 is offline   Reply With Quote
Old 08-21-2016, 04:00 PM   #35
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

I just tried it in a clean Orbiter 2016 RC4 install at KSC with OrbiterSound, UMMu, and the XRs, using both the inline and D3D9 clients, both with and without vertical sync, and it works fine for me -- external cooling is restored and the parking brakes remain engaged when the scenario reloads. The ship does not move.

Maybe it has something to do with framerates? What framerate are you getting?
dbeachy1 is offline   Reply With Quote
Old 08-21-2016, 05:59 PM   #36
turtle91
Orbinaut
Default

When using the default "1 - Ready for Takeoff to ISS" scenario, all went fine.
I aplied ext cooling, saved and reloaded the scn.
Ext cooling has been restored an parking brake is still active...no more bounces or moves...at least at KSC.

My FPS is initially at 67 FPS...which should be fine.
turtle91 is offline   Reply With Quote
Old 08-21-2016, 06:19 PM   #37
dbeachy1
O-F Administrator
 
dbeachy1's Avatar


Default

I also retested it with the default XR2 Landed at Brighton Beach scenario and it works for me -- the ship does not move and external cooling is restored when the scenario reloads with the parking brakes on. Unfortunately, I'm out of ideas here...
dbeachy1 is offline   Reply With Quote
Old 08-21-2016, 06:54 PM   #38
turtle91
Orbinaut
Default

I tried again with the "Landed at Brighton Beach" scenario.
Here I have 74 FPS, but the problem persits.

However, this time I have not touched the keyboard and waited until the vessel performed a wheel-stop (took about 20 seconds).
Then I enabled ext. cooling and saved.

After reload, the ext-cooling was disconnecetd caused by a slight right-move.
After about 3-5 seconds the vessel stopped an I was able to re-enable the ext. cooling again.

So I saved again, but everytime after loading the scn, it took a couple of seconds to stop the vessel (by itself...still not touched the keyboard).

Maybe we have still a diffrent terrain/mesh (I used SVN to keep Orbiter up-to-date...caused by my bandwith limit).

But at least it shows, that on a not perfect-flat pad, the XR-vessels have more problems to establish a wheel-stop compared to default vessels. (at least in my case)

I.e. I replaced the XR2 wit a stock DG, and here the DG was stable...not moving/sliding after scn-reloads.

Maybe somebody else could do some testing ? Maybe at different bases/pads ?
turtle91 is offline   Reply With Quote
Old 08-21-2016, 08:08 PM   #39
Ripley
Tutorial translator
 
Ripley's Avatar
Default

As far as I understood, dbeachy1 is testing on RC4 + HiRes texture and turtle91 is testing on latest rev 61 on SVN + LoRes texture.
I'm sure you are aware of how difficult it can be to get a common outcome with such different starting situations (on such a delicate issue, BTW).

Just my 2 cents.

Last edited by Ripley; 08-21-2016 at 08:10 PM.
Ripley is offline   Reply With Quote
Thanked by:
Old 08-21-2016, 08:24 PM   #40
turtle91
Orbinaut
Default

Thanks Ripley,

you might be correct, the main differenece could be the terrain-data.
But from the code-side, both RC4 and rev60+ SVN should behave similar, I believe:

Code:
Revision: 60
Author: martins
Date: Samstag, 6. August 2016 05:02:18
Message:
VESSEL::SetTouchdownPoints: old 3-point interface now sets stiffness and damping parameters according to vessel empty mass (warning: this introduces a race condition: vessel mass must be set before touchdown points)
As far a I know, the latest XR-dlls are taking care about this change.
But again, you might be correct and there are differents in both Orbiter releases/snaps, which could cause some confusions.

I would start the RC4 download right away, if my ISP would not limit me to 5GB per month. So I am currently stuck at SVN-updates.

Maybe you can test this with a "pure" RC4 ?
turtle91 is offline   Reply With Quote
Thanked by:
Old 08-21-2016, 10:29 PM   #41
Ripley
Tutorial translator
 
Ripley's Avatar
Default

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.

Last edited by Ripley; 08-21-2016 at 10:39 PM.
Ripley is offline   Reply With Quote
Old 08-21-2016, 11:29 PM   #42
turtle91
Orbinaut
Default

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

Quote:
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 is offline   Reply With Quote
Thanked by:
Old 08-24-2016, 03:21 PM   #43
turtle91
Orbinaut
Default

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:

Code:
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
turtle91 is offline   Reply With Quote
Old 08-24-2016, 03:40 PM   #44
martins
Orbiter Founder
Default

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.
martins is offline   Reply With Quote
Thanked by:
Old 08-24-2016, 04:02 PM   #45
turtle91
Orbinaut
Default

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...."

Last edited by turtle91; 08-24-2016 at 06:57 PM.
turtle91 is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Development

Tags
2016, beta, xr1, xr2, xr5


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 02:59 PM.

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.