Lights not set properly

[capp]

Since 1.00.02 I get points deducted for not setting my landing lights properly, though I am sure I do.

[Dutch Owen]

Ack that's bad. I don't think I made any changes to anything related to lights, though. I'll test that immediately.

Dutch

[Dutch Owen]

I just made a test run KSEA -> KPDX for Acme, no light penalty.

Are you sure you didn't forget the NAV lights? Not setting them on will get you written up too.

The FO should warn about both these.

Dutch

[capp]

Pretty sure all lights were set as they should, did a short flight for testing.
I will test it again tomorrow...

[capp]

After some more flights it seems it were the Runway Turnoff Lights. There is no penalty if you leave them switched on til 10.000ft. Guess this is another PMDG issue.
F/O asks to check landing lights on and off though, so it actually notices the landing lights being on and off.

BTW, it still does that 'seatbelt announcement' thing after takeoff on the second leg. On the very same flight the F/O suddenly announced 'Rotate' on descend.


Another thing I just noticed which you may change some time in the future:
On descend it is not passing the transition altitude, but passing the transition level, because you are set to QNE altitude. Not to speak of the transition layer between TA and TL

Calls for TA and lights seem to be based on the QNH altitude. I did not test that yet, but it would be interesting what happens, if you have a very low QNH and a TA/TL way below 10.000ft, which is quite common in Europe e.g. Would you get a light penalty for not having them on, even thoug you are not even near the 10.000ft mark on QNE altitude? Have to try it some time

[Dutch Owen]

Actually this is a bug, and I have fixed it. The fix will appear in 1.00.04.

The issue was that the program was considering 'taxi lights' (as defined by MSFS) as equivalent to landing lights.

Dutch

[capp]

Still getting this fault on every single flight. Would it be possible to include some debug output why and when exactly a fault is triggered? It takes too much time to fly back and forth just for testing different light settings

[Dutch Owen]

In the case of lights, as of 1.00.04 it is very simple:

1. The aircraft departed the ground with NAV lights off.

2. The indicated altitude is above 10,900 feet with landing lights on.

3. The indicated altitude is below 9,100 feet with landing lights off.

Any of these three will trigger "lights not set properly". If you check off the "landing lights on under 10,000" option 2 and 3 will not trigger.

There's one gotcha: there's no requirement that an airplane designer use the LANDING LIGHTS signal in FS to control the actual landing lights -- I have seen one airplane use it to turn on and off the interior lights!

I use the key combination CTRL-L to toggle the lights on and off rather than a switch in the airplane unless I trust the switch. That way I know[/] I'm turning on or off the actual signal that FSCaptain monitors even if some other lights actually turn on or off on the airplane.

Hope this helps,
Dutch

[capp]

Still getting this fault. Even with CTRL-L (which flips the switches correctly).
Checked the landing lights variable using the interrogator program in the FSUIPC-SDK and that changes correctly. Not sure if you use that or SimConnect though Could not find any simple SimConnect client to debug and have not much time at the moment to code one...

[Dutch Owen]

I use neither FSUIPC nor SimConnect to test this, I use the internal XML variable (A:LANDING LIGHTS,bool).

I've never seen a case where what is reported thru FSUIPC or SimConnect is different though.

Remind me again, is this happening on the PMDG 747? I need to figure out why this is happening consistently to you but I never get the penalty unless I screw up the light settings.

Dutch

[capp]

Fixed it actually after monitoring the FSUIPC log closely.
I accidently misconfigured the Shockwave 3D landing lights the way they turn off automatically on retracting the gear. It does not show up on the outside views because the aircraft seems to turn them on again directly. But that triggered the fault in FSC.