Bug XR series: APU won't turn on

[Archabacteria]

I hit the switch. It sits there and claims to be powering up for the next decade. Can't take off because someone attached the hydraulics to something that won't turn on.

This has consistently happened in the scenario 'today' (the one that starts with the system date and populated out to mars) with the XR2 that is landed at Wideawake. It also happens if I add any XR-series vessels in the same area. The one on the moon works just fine (the Arrow though has problems in that it considers everyone dead if it has even the slightest bumpy landing- it once landed after hovering an inch off of mars and said everyone died. Probably not related.)

Seems to happen more often if at any time I am out of the vessel's perspective for even a second (ie I change camera or did not start in said vessel) regardless of the fact that it should only do so when the vessel is not the focus.

 

[dbeachy1]

Are you absolutely sure you didn't accidentally hit "R" to bump time acceleration down to 1/10th normal speed? [Check for a 'Wrp' value in the top-right corner of the HUD that reads "0.1"; with time acceleration off, that area should be blank.]

One other thing you could do as a test is to set "APUAutoShutdown=0" in your XR2RavenstarPrefs.cfg file:

#--------------------------------------------------------------------------
# Enable or disable auto-shutdown of the APU when the pilot switches vessel
# focus; this is a safety feature designed to prevent the pilot from
# accidentally leaving the APU on and running out of APU fuel while the
# focus is switched to another vessel.
#
# The default value is 1 (APU auto-shutdown ENABLED)
#
#   0 = APU auto-shutdown disabled
#   1 = APU auto-shutdown enabled (recommended)
#--------------------------------------------------------------------------
APUAutoShutdown=[COLOR="Red"]0[/COLOR]

 

[Archabacteria]

I guess it's possible that I was at that warp setting. I already have unlimited APU fuel, so I guess setting the auto-shutdown to off won't be too bad.

Someone remind me what warp .1 is useful for?

 

[Nemoricus]

It's handy whenever you want to precisely control when something happens. The tail end of TransX burns are a good example.

It's also the lowest time setting you can play at, so if you want to fiddle with things without worrying about time, it's useful.

 

[orbekler]

I agree, should be Time Warp. Try to hit key "T".

 

[Archabacteria]

Hit the key all the way up to 100x. Didn't actually turn on, just said it was powering up.

And why does Orbiter think 15:54 is actually 22:54 whenever it uses my system time? It's bright out here, yet every time I load the scenario America is covered by night.

 

[DaveS]

Hit the key all the way up to 100x. Didn't actually turn on, just said it was powering up.

And why does Orbiter think 15:54 is actually 22:54 whenever it uses my system time? It's bright out here, yet every time I load the scenario America is covered by night.

I think Orbiter automatically corrects the system time to UTC. So 15:54 Eastern Time in winter would correspond to 22:54 UTC and explain the nighttime.

 

[dbeachy1]

As a test, can you try it in a clean installation? It is possible that another add-on is trashing memory, causing odd behavior.

 

[xx_mortekai_xx]

I have had this same issue before. I usually fix it by reloading. It has happened less frequently since I reinstalled orbiter.

 

[dbeachy1]

Update: this bug is fixed in the upcoming XR patch versions; it occurred whenever the simulation time (simt) became negative by the pilot moving the simulation date back via the scenario editor.