Question XR2 Mission Elapsed Timer issue

[XonE32]

Hi,

Just a quick question about the M.E.T for the XR2 (Original Orbiter)

I've notice in some scenarios I've created and/or changed by either adding an XR2 or changing the date when one was already in there etc.. The Mission Elapsed Timer stops initiating at wheel's up.

I've noticed that the two .scn lines below don't look like they are below, but if I change these two .scn lines to the values seen below it seems to fix the problem and the M.E.T starts as normal.

Question: is that all I have to do in my .scn's that have a malfunctioning M.E.T? or can I just change one of the lines? just curious. Thanks.

MET_STARTING_MJD -1.000000

MET_RUNNING 0

Cheers

XonE 32

 

[dbeachy1]

Those two lines define the state of the MET timer in the scenario when it loads: if MET_STARTING_MJD is >=0, then it means the timer is already running and so it will not restart at wheels-up. Can you please post the exact steps to reproduce the problem?

 

[XonE32]

Those two lines define the state of the MET timer in the scenario when it loads: if MET_STARTING_MJD is >=0, then it means the timer is already running and so it will not restart at wheels-up. Can you please post the exact steps to reproduce the problem?

Shoot dbeachy I wish I could. I'm sure it has something to do with me being in orbiter and using the scenario editor to either add an XR2 or move it or changing the MJD of a .scn?

I just noticed that during a playback .scn that someone posted the M.E.T. started at wheels up which made me realize that in my own .scn's that didn't happen (The M.E.T. didn't start).

When i compared the two .scn's (mine and the playback one) I noticed that the MET_STARTING_MJD in mine had some weird date in it (weird in that in didn't match the MJD of the .scn) but also weird in that it had a date as opposed to a -1.0000 which was the value in the playback .scn.

And the MET_RUNNING value in mine was set to 1, but set to 0 in the playback .scn.

Once I changed the two values in my .scn to match that of the playback .scn (i.e STARTING MJD to -1.0000 & MET_RUNNING to zero) I ran my .scn and the M.E.T. started fine.

For some reason the .scn's that weren't working had this for those 2 lines

MET_STARTING_MJD 104319.179906

MET_RUNNING 1

How those numbers ended up in the .scn file is unknown, but I'm wondering if it had something to do with changing the .scn MJD?

 

[dbeachy1]

MET_STARTING_MJD records the MJD at the time the MET started -- i.e., when you first went wheels-up. After that, it will run until you land and reset it by holding down the reset button for two seconds. The MET readout shows the delta between the current MJD and the MJD when the MET timer started running.

The second parameter, MET_RUNNING, is simply a boolean flag that indicates whether the MET was running when the scenario was saved.

 

[XonE32]

MET_STARTING_MJD records the MJD at the time the MET started -- i.e., when you first went wheels-up. After that, it will run until you land and reset it by holding down the reset button for two seconds. The MET readout shows the delta between the current MJD and the MJD when the MET timer started running.

The second parameter, MET_RUNNING, is simply a boolean flag that indicates whether the MET was running when the scenario was saved.

Yep that all makes sense. I would imagine it got screwed up when I manually changed the MJD of the whole .scn but didn't make a similar change for the timer and it was running. Either setting it back to 0 in the .scn or adding the new MJD to the readout line. I'll just have to remember to do it if I change the MJD of a whole .scn that includes an XR2 with the M.E.T. running.