Is it possible to determine the sunrise and sunset time at a specific location, for example an airport?I'm aware of this thread: http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchI'm having trouble getting my head around adopting it to actually display the sunrise and sunset time.

OK I've been sitting here for the best part of 24 hours trying to get this to work, but it's frustrating the #### out of me! Thing is, it must be possible because FS9's sunrises and sunsets happen pretty much exactly at the time you get on any web-based sunrise/sunset calculator, for any part of the world.Therefore my equations must be at fault, but I've tried just about everything I could find. Does anyone know of an idiot's guide to calculating this stuff? I've gone through many equations found on the net and I'm still clearly missing something. I've translated various equations into an XML gauge and even the number of daylight hours comes out wrong for various parts of the world. Doing the calculations with a pen and paper produces the same result as the gauge, the wrong one.

If anyone cares to take a look, the problem seems to be with the last part of the calculation. Declination, Equation of Time and Hour Angle all check out according to other sources of sunrise/sunset times. It's just the very last equation that doesn't give a desired result.Equations for calculating sunrise/sunset:http://www.srrb.noaa.gov/highlights/sunrise/solareqns.PDFOnline calculator for reference:http://www.srrb.noaa.gov/highlights/sunrise/sunrise.htmlDeclination Table:http://www.wsanford.com/~wsanford/exo/sundials/DEC_Sun.html %(pi 2 * 365 / (P:ZULU DAY OF YEAR, Number) 1 - (P:ZULU TIME, Hours) 12 - 24 / + * (>L:sun_Y, Number))%(0.006918 0.399912 (L:sun_Y, Number) cos * - 0.070257 (L:sun_Y, Number) sin * + 0.006758 (L:sun_Y, Number) 2 * cos * - 0.000907 (L:sun_Y, Number) 2 * sin * + 0.002697 (L:sun_Y, Number) 3 * cos * - 0.00148 (L:sun_Y, Number) 3 * sin * + (>L:sun_DEC, Number))%(229.18 0.000075 0.001868 (L:sun_Y, Number) cos * + 0.032077 (L:sun_Y, Number) sin * - 0.014615 (L:sun_Y, Number) 2 * cos * - 0.040849 (L:sun_Y, Number) 2 * sin * - * (>L:sun_EQTIME, Number))%(-0.83 dgrd sin (A:PLANE LATITUDE, Radians) sin (L:sun_DEC, Number) sin * (A:PLANE LATITUDE, Radians) cos (L:sun_DEC, Number) cos * / - acos (>L:sun_HA, Number))%(720 4 (A:PLANE LONGITUDE, Degrees) (L:sun_HA, Number) rddg - * + (L:sun_EQTIME, Number) - (>L:sun_RISE, Minutes))%(720 4 (A:PLANE LONGITUDE, Degrees) (L:sun_HA, Number) rddg + * + (L:sun_EQTIME, Number) - (>L:sun_SET, Minutes))%Solar Declination (Radians): %((L:sun_DEC, Number))%!f!%n%Solar Declination (Degrees): %((L:sun_DEC, Number) rddg )%!f!%n%Equation of Time (Minutes): %((L:sun_EQTIME, Number))%!f!%n%Hour Angle (Radians): %((L:sun_HA, Number))%!f!%n%Hour Angle (Degrees): %((L:sun_HA, Number) rddg )%!f!%n%Sunrise (Minutes UTC): %((L:sun_RISE, Minutes) 60 % flr)%!02d!%n%Sunrise (Hours UTC): %((L:sun_RISE, Hours) 24 % flr)%!02d!%n%Sunset (Minutes UTC): %((L:sun_SET, Minutes) 60 % flr)%!02d!%n%Sunset (Hours UTC): %((L:sun_SET, Hours) 24 % flr)%!02d!

Not to be a smart #### or anything like that, Mr. Bartels ( the author ) got me hooked on the XML stuff like this from day one.. THNX :-). There is 1! thing that throws me...........There are alot mathematical formulae being done with a suffix of ,number... IIRC- ,number as a variable unit is that of a whole number. Just a throw-out, try replacing all references of ",number" with ",enum" just for the BS of it. ( 1 = 1.00000000 no matter what day it is )Keppler is a rightous cool dude, may your orbit never decay! Roman

enum trims the float64 number variable to be an integer......which probably won't be a good idea when using trig functions! ;)

>enum trims the float64 number variable to be an integer...>"Enum", "number" and "bool" mean a same FLOAT64 identifier. There is no internal conversion between them.To convert any of these units into an integer, you must use "(LVar) int"Tom

Been proven wrong then, my mistake. Since day one I "assumed" and used ,number meant 1,2,3,4,5 etc..not 1.2,3.5,2.4569,9.548746 etc... Oh well :-( But this "time of day" thingy should be fixed pronto by MS though.Edit -- has anybody tried in "C+" to somehow get some DirectX data to tell you when the bmp_L.bmp goes active?RomanFS9, AMD 1800+, ECS K7S5a, 1 gig, 100 & 60 Gig 7200rpm HD, ASUS/NVidia 64mb AGP on 21", NVidia FX5500 vivo 256mb on 18", Savage4 32mb on 15"

I think the actual sunrise and sunset times you see in the sim are pretty much spot on with the real life values, give or take a couple of minutes which is fine. If you go anywhere in the FS world and observe a sunrise, it corresponds to the web-based sunrise calculators. Therefore this *should* work! That final equation that aparently gives you the actual zulu time of the sunrise/set must be the culprit.

This is the formula I actually use to automatically handle my panel lights:(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)When Local Sun angle is lower than 12, I "turn on" the lights (as long as switchs are ON).Should be easy to figure out which is the number that fits wtih sunrise/sunsetTom

Thanks Tom, hadn't thought of doing it that way. I'm not much of a mathematical genius but I'll see if I can somehow work it backwards to see what the zulu time would be for sun angle = 0.

Problem solved!Here's the thing:FS reports longitude as a positive value to the East, negative to the West. For the equation to work, you need negative for East, positive for West. Figured this out with a piece of paper , a tennis ball and a blow up globe!So the correct code: (note that this works out sunrise/sunset for a waypoint in the flightplan, @c:FlightPlanWaypoint)%(pi 2 * 365 / (P:ZULU DAY OF YEAR, Number) 1 - (P:ZULU TIME, Hours) 12 - 24 / + * (>L:sun_Y, Number))%(0.006918 0.399912 (L:sun_Y, Number) cos * - 0.070257 (L:sun_Y, Number) sin * + 0.006758 (L:sun_Y, Number) 2 * cos * - 0.000907 (L:sun_Y, Number) 2 * sin * + 0.002697 (L:sun_Y, Number) 3 * cos * - 0.00148 (L:sun_Y, Number) 3 * sin * + (>L:sun_DEC, Number))%(229.18 0.000075 0.001868 (L:sun_Y, Number) cos * + 0.032077 (L:sun_Y, Number) sin * - 0.014615 (L:sun_Y, Number) 2 * cos * - 0.040849 (L:sun_Y, Number) 2 * sin * - * (>L:sun_EQTIME, Number))%(-0.83 dgrd sin (@c:FlightPlanWaypointLatitude, Radians) sin (L:sun_DEC, Number) sin * (@c:FlightPlanWaypointLatitude, Radians) cos (L:sun_DEC, Number) cos * / - acos (>L:sun_HA, Number))%(720 4 (@c:FlightPlanWaypointLongitude, Degrees) -1 * (L:sun_HA, Number) rddg - * + (L:sun_EQTIME, Number) - (>L:sun_RISE, Minutes))%(720 4 (@c:FlightPlanWaypointLongitude, Degrees) -1 * (L:sun_HA, Number) rddg + * + (L:sun_EQTIME, Number) - (>L:sun_SET, Minutes))%((L:sun_RISE, Minutes) 0 < if{ (L:sun_RISE, Minutes) 1440 + (>L:sun_RISE, Minutes) })%((L:sun_SET, Minutes) 0 < if{ (L:sun_SET, Minutes) 1440 + (>L:sun_SET, Minutes) })%Sunrise / Sunset: %{clr2}%((L:sun_RISE, Hours) 24 % flr)%!02d!%:%((L:sun_RISE, Minutes) 60 % flr)%!02d!%Z / %((L:sun_SET, Hours) 24 % flr)%!02d!%:%((L:sun_SET, Minutes) 60 % flr)%!02d!%Z

>>enum trims the float64 number variable to be an integer...>>>>"Enum", "number" and "bool" mean a same FLOAT64 identifier.>There is no internal conversion between them.>To convert any of these units into an integer, you must use >"(LVar) int"Explain then why the SDK makes these distinctions:number, numbers - ~ (these are synonyms) Enum - A positive or negative integer corresponding to the member of the enum Bool, Boolean - The only reliable numeric equivalent is that 0 is returned for False. Non-zero values, especially both 1 and -1, are used to indicate True. BTW, the last note explains why this (A:var,bool) doesn't always work reliably, nor does (A:var,bool) 1 ==I've found that (A:var,bool) ! works 100% of the time... ;)

>Explain then why the SDK makes these distinctions:>>number, numbers - ~ (these are synonyms)> >Enum - A positive or negative integer corresponding to the>member of the enum >>Bool, Boolean - The only reliable numeric equivalent is that 0>is returned for False. Non-zero values, especially both 1 and>-1, are used to indicate True. >>BTW, the last note explains why this (A:var,bool) doesn't>always work reliably, nor does (A:var,bool) 1 ==>>I've found that (A:var,bool) ! works 100% of the time... ;)>>Bill, I honestly don't know the reason of those SDK distinctions, but they are wrongly explained. In fact, I don't trust the SDK too much because it has some other errors as well, so I prefer to do my own tests, as usual :-). I guess "bool" unit is used for better understanding of the variable's return value (could make a deeper explanation on how the whole stuff works but would be rather boring...)Tom

-SNIP->Enum - A positive or negative integer corresponding to the>member of the enum -SNIP-The above statement is SO indicative of what I abhor when it comes to the FS SDK's....referencing the term that isbeing defined with the term...If someone was trying to determine what "enum" meant, the abovestatement certainly wouldn't help them at all... Paul

All of you are right... and wrong regarding what a variable type represents and what values it may/may not contain.number - this is a numeric value that supports fractional values.enum - this is a numeric value that is normally (please READ THAT WORD) used to represent a value of a enumerated list member.bool = this is a numeric value that is defined as 0==false, !0==true. That's it.Now... read my definitions again... note they are ALL numeric values. Every one. If you are doing floating point math, the use of enum is nonsensical. It misrepresents the type of data being used. If you think you're 'saving' something by doing so... you're most likely wrong since I don't think XML actually delineates between number,enum,bool mathmatically.