mfor

Well I found everything to look quite a bit grey-washed in XP11 due to the "realistic" haze. IMHO it's overdone for close ranges and some weather situations. You could try Reshade to get some more saturated colors in XP11 or use XP10 (like me)

Well they'e called wing (inspection) lights because they light up the wing (e.g. to allow checking for ice in the dark) and that's a fairly good location for them Seems like they are a little bit more to the front in this aircraft, but it might be a different model. Edit: If you were looking for the landing lights - those are operated by the four switches on the bottom left of the overhead panel. The left two extend and turn on the outboard ones and the right two control the lights located at the wing roots.

Most likely - I did a quick test on the online lua site (https://www.lua.org/cgi-bin/demo) and with 100 samples I would see numbers from 7.5 to 12.5 hours within a few clicks. OTOH I don't know how good the lua rand function really is.

Nice testing - looks like it's working as intended. Probably a good idea to make the test variable local as well (or get rid of it) just in case - forgot that in my suggestion... LUA is weird

Those were the days Getting the same failures over and over again would be a sign of using the same random seed for each run (which would produce the same number sequence every time).

That's why they're called pseudo-random numbers However calling the function twice (as the script does now) doesn't improve the "randomness". As long as the function roughly follows the expected distribution it doesn't really matter in this case though, as we're not building a crypto application where true randomness is essential, but just a "random failure" feature where inspiring the feeling of randomness in a human observer is sufficient. Edit: IIRC rand() in php is/was notoriously bad, which is why mt_rand() was introduced and made an alias for rand in php 7.1. Also Windows actually offers CryptGenRandom if you need a fairly good random generator, which would be overkill in this case though.

@Tom Stian Thank you for providing this script and a question/suggestion if I may: Have you considered using an MTBF number instead of an arbitrary FailFactor, that get's checked twice (against 1..2000 and 1..100) giving it some odd squared characteristic up to a value of 100? local mtbf_hours = 2.5 local test = math.random (1 , mtbf_hours*360) if test == 1 then ... I think this should give you the failure chance for a MBTF of mtbf_hours if called every 10 seconds, which would make it easier to estimate what amount of failures to expect.

You can switch the transponder to feed off of Bus #2 using the 1-2 switch at the bottom. Other than that I don't think you can do much about it in that case. Also I'm not sure what exactly fails with the "AC Electronic 1" entry. Tried consulting this schematic from http://www.b737.org.uk/ but there are some issues I couldn't explain. This failure seems to affect the "No1 EL. 115v" box in the lower left, as GWPS and the Captain's altimeter failed with that "AC Eletronic 1" failure. Auto-throttle however seemed functional and instead the box on the FO's side went dark, the yaw damper tripped and the No1 Mach warning test failed. This would indicate a problem in "No1 Elec DC" but from the schematics I can't really tell why those two should be related and whether this a is problem with the failure modeling, the schematic or my understanding of those things

Make sure that the altitude fields in the legs page are set. I flew from SLLP to SPJC via ELAKO6 ELAKO UA304 JUL UM415 REMUS DCT CEDRO CEDRO5 and the hight setting for ELAKO was blank and VNAV wouldn't engage. After setting the altitude for ELAKO it worked just fine.