Frather,I tested your gauge and the following happened:Sunangle < 10 : Nav lights Off, Sunangle > 10 : Nav lights On.In both positions it was impossible to use the Nav Lights Switch.(i did mention that earlier)I use:%((L:local_sun_angle,number))%!d!.Also noticed your 0.0000 value!It must be the synthax, cause mine showed -41 (other side of the earth?); perhaps distances between the characters are important.The next snip is an unaltered copy of my functioning formula. (P:ZULU TIME,hours) (A:PLANE LONGITUDE, degrees) 15 / + (P:ZULU DAY OF YEAR,number) 3 - 365.25 / 2.0 pi * * sin 7.3 *(P:ZULU DAY OF YEAR,number) 80 - 365.25 / 4.0 pi * * sin -9.8 * + 60 / - (>L:local_sun_time,number) (P:ZULU DAY OF YEAR,number) 80 - 365.25 / 2.0 pi * * sin 23.5 *(L:local_sun_time,number) 24.0 / 2.0 pi * * cos90 (A:PLANE LATITUDE, degrees) abs - *(A:PLANE LATITUDE, degrees) 0 > if{ - } els{ + }(>L:local_sun_angle,number)%((L:local_sun_angle,number))%!d!(A:Light Nav, bool) 1 == (L:local_sun_angle, number) 10 < && if{ (K:TOGGLE_NAV_LIGHTS) ! (>K:TOGGLE_NAV_LIGHTS) }(A:Light Nav, bool) 0 == (L:local_sun_angle, number) 10 > && if{ (K:TOGGLE_NAV_LIGHTS) ! (>K:TOGGLE_NAV_LIGHTS) }"Still digging further..."Jan"Procul Negotiis"

Where is your gauge with invisible element placed? On the VC or on the 2D panel? Wasn't there a problem with "invisible" gauges on the VC reported lately?Arne Bartels

Ok next try. I checked your code in an "invisble" part of a gauge on the 2D panel, and displaying the L: result in the same gauge in a element. I found some things. First the writing to a L: variable must be accompagnied with the unit (>L:anyname,number) not (>L:anyname). Then always a gap of at least one space after a '{' or before and after a '}' (never a space between 'els' and '{' or 'if' and '{', I made that mistake recently). And last, never a carriage return in a (...) statement, your (A:PLANELATITUDE, degrees)wasn't evaluated properly.Result: (P:ZULU TIME,hours) (A:PLANE LONGITUDE,degrees)15 / + (P:ZULU DAY OF YEAR,number) 3 - 365.25 / 2.0 pi * *sin 7.3 * (P:ZULU DAY OF YEAR,number) 80 - 365.25 / 4.0 pi ** sin -9.8 * + 60 / - (>L:local_sun_time,number)(P:ZULU DAY OF YEAR,number) 80 - 365.25 / 2.0 pi * * sin 23.5* (L:local_sun_time,number) 24.0 / 2.0 pi * * cos 90 (A:PLANE LATITUDE, degrees) abs - * (A:PLANE LATITUDE, degrees) 0> if{ - }els{ + } (>L:local_sun_angle,number)Arne Bartels

Arne,Was this answer for frather Bill?I had no problems, functions perfect!Btw. have now a pretty stable fmc.Completed uneventfully EHAM-KLAX with SID, Transatl. Waypoints, STAR and Approach.With automatic speed- and altitude settings and light changes (sunangle!!)Now after take-off only LNAV and VNAV etc...Going to fly a Cessna.Jan"Procul Negotiis"

Yes it was for Bill.Arne Bartels

Yes, it appears to work perfectly. Thanks Arne and others involved in this. The only "problem" was that a direct copy and paste introduced the errors Arne described - those lacking but highly important spaces in the code.The following text element uses the now calculated sunangle and panel light switch to determine a bright or dark cockpit, and dims the radio accordingly:Anyone up for taking aircraft elevation, earths curvature, and aircraft HPB angle into account? Hehe, just kidding :DAgain, thanks a lot. I've been playing around with this without success from time to time. Finally!!! Yes! :)

>Ok next try. I checked your code in an "invisble" part of a>gauge on the 2D panel, and displaying the L: result in the>same gauge in a element. >I found some things. >First the writing to a L: variable must be accompagnied with>the unit > (>L:anyname,number)> not> (>L:anyname).I have the 'gauge' installed to a 2d panel, in fact not 'invisible' at all, since I wanted to see the L: variable displayed while I worked.The function displays the L: variable regardeless of whether the 'units' is used in the formula or not. >Then always a gap of at least one space after a '{' or before>and after a '}' (never a space between 'els' and '{' or 'if'>and '{', I made that mistake recently). There is exactly ONE space between the { x } wherever used...>And last, never a carriage return in a (...) statement, your >(A:PLANE>LATITUDE, degrees)>wasn't evaluated properly.Even using "text mode", the forum software inserts carriage returns and wordwraps long lines. The formula in the actual .xml gauge has no carriage returns, but is one long, long line! :)I'm going to post a screen shot showing the results at present.BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://mtco.com/~rsam/fartslogo.jpg

In the screenshot that follows, the upper display contains the 'formula' a string display of the calculated L: variable and has the 'autoswitch' logic.The second display has only a string function to display the calculated L: variable.As you can plainly see, the calculated value is displayed on the top, but the lower has only ZEROS displayed, showing that the L: variable is truly empty! BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://mtco.com/~rsam/fartslogo.jpghttp://forums.avsim.com/user_files/7170.jpghttp://forums.avsim.com/user_files/7171.jpg

>Anyone up for taking aircraft elevation, earths curvature, and>aircraft HPB angle into account? Hehe, just kidding :D>"Fortunately" there is no need for this, in FS the world very flat, as you stated already. My formula is still not perfect, it has still errors up to +-3

Hi, Fr. Bill.A couple of things may help. If you use NotePad, try to post a pic. with the code in NotePad, Wrap On, or maybe someone else can post the pic. with the proper syntax. I do not have time right now to try the code, but I will do it later, and post, if no one does it before.There is a XMLNotepad that may help, it's called "xpsetup.exe", about 300k, I can EMail it to you if you want, I got it from MS site? long ago. This helps with the Syntax Errors. If I copy the code directly from the AVSIM posts I get a lot of Errors. I hope it helps.You are right about the Sun position, overdone, I wish there was away to Hex edit the code and disable it. Thanks, to all you guys, for all the work you put into this sim. TV

Thanks to everyone's help, Arne, Jan and Karl. It is now working just fine!The daytime "Panel Floods" fx is switching OFF at the transition dusk/night (currently about 8:13pm in Chicago) and switching ON at the dawn/day transition. This is ~ 35 degrees sun angle.Now the VC is nice and bright during the day, regardless of direction being flown, and the night lighting isn't overwhelmed by the really, realy BRIGHT daytime "floods!" :)BTW, I've been using XMLNotepad from MS from day one. Never leave home without it! :)BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://mtco.com/~rsam/fartslogo.jpg

There exist a problem with FS lightning though, which has nothing to do with sun elevation accuracy at all, and that is the fact that *only* the sun creates light. There should be added an ambient light to simulate the lightning emitted from the atmosphere. Especially up here at the northern latitudes, it gets dark way too soon because the sun is rather low. In real life though, the atmosphere continues to cast a rather flat light even after the sun has set below the horizon.If they wanted to go "all the way", they (Microsoft) should mix these two light types based on the cloud cover amount, and the aircrafts position related to these. During overcast, the light is always flat.I hope they address this problem (at least partly) with FS2004:COF.Okay, a little off topic, but...

And additionaly there is an athmospheric refraction that lets the sun appear higher over the horizon that it actually is, plus an apparent change in size.Arne Bartels

After struggling with the major flaws of my formula (negative angles at southern lats, complete rubbish at low lats) I found astronomic formula on the web (http://www.jgiesen.de/SME/details/basics/index.htm), which look much more logic then my original garbage. The trick is to use proper spherical trigonometry to tilt the celestial coordinates to earth coordinates, not my "plain" geometry attempt. Don't ask me why I wasn't able to figure that out in the first place.The new formula is:%( (* zulutime+longitude/15 *)(P:ZULU TIME,hours) (A:PLANE LONGITUDE, degrees) 15 / + (* (7.3*sin((dayofyear-3)/365.25*360) *)(P:ZULU DAY OF YEAR,number) 3 - 365.25 / 2.0 pi * * sin 7.3 * (* -9.8*sin((dayofyear-80)/365.25*720)) *)(P:ZULU DAY OF YEAR,number) 80 - 365.25 / 4.0 pi * * sin -9.8 * + 60 / - (>L:local_sun_time,number) (* declination is the sun height over equator at midday *)(P:ZULU DAY OF YEAR,number) 80 - 365.25 / 2.0 pi * * sin 23.45 * dgrd (>L:declin,number) (* sin(sunelev) = sin(decl)*sin(lat)+cos(decl)*cos(lat)*cos(localsuntime-12h) *)(* sin(decl)*sin(lat) *)(L:declin,number) sin (A:PLANE LATITUDE, radians) sin * (* cos(decl)*cos(lat) *)(L:declin,number) cos (A:PLANE LATITUDE, radians) cos * (* cos(localsuntime-12h) localsuntime-12h aka "hour angle" or "right ascension" of the sun *)(L:local_sun_time,number) 12 - 24.0 / 2.0 pi * * cos * + asin rddg(* apparent athmospheric refraction effect *)0.8 +(>L:local_sun_angle,number)(L:local_sun_time,number) d int )%!02d!:%( 1 % 60 * )%!.1f! %( (L:local_sun_angle,number) )%!.1f!Note that there seems to be an athmospheric effect used by FS, I approximated it with +0.8 degrees, which is of course only true for small elevations. There are some pretty sophisticated formulas available at http://www.srrb.noaa.gov/highlights/sunrise/calcdetails.html, but I haven't checked, if they are used in FS and for sunrise/sunset calculations a constant value might be sufficient.Arne Bartels

Arne,Fine! A Question about the clock:It shows hours, minutes, seconds?If so, the seconds go slow.If 1/10 of a minute it seems ok.Jan"Procul Negotiis"