@Andreas und die anderen,
hab gerade was interessantes entdeckt, was mit so noch nie auffiel:
Ich habe eine fs9.exe, die mit "vorheriger flug.flt", fs9.cfg und aktueller Systemzeit startet. Sonnenaufgang etc. alles 100%-ig richtig
Daneben habe ich mir im Sommer (!) eine fs9_vfr.exe erstellt (exakte Kopie der fs9.exe, nur anderer Name), die mit dem Flug "vfr.flt", fs_vfr.cfg und ebenfalls eintragungsgemäß mit aktueller Systemzeit startet. Die cfg unterscheidet sich nur hinsichtlich AI und div. Terraineinstellungen, die FLT enthält eine Cessna und einen kleinen Platz.
So, und nun kommt's: Habe ich mit fs9.exe begonnen (Systemzeit November) und wähle dann im Menü unter "Flug auswählen" den "vfr" aus, startet er mit der seinerzeitigen Systemzeit (Juli) und daher 2h Differenz. DIESE DIFFERENZ BELIBT AUCH, WENN ICH FÜR DIESEN FLUG JETZT DIE AKTUELLE ZEIT (NOVEMBER) SETZE!
Und weiter: Starte ich die fs9_vfr.exe direkt vom Desktop, so komme ich zur aktuellen Systemzeit ABER MIT DER 2h DIFFERENZ!! und dann habe ich in München heute auch um 7:10 dunkle Nacht, während es beim Start mit der fs9.exe und "vorheriger flug" richtig (1h) ist.
Ich hoffe, ich habe mich nicht zu kompliziert ausgedrückt ;-), wichtig ist, daß obwohl für den FS-Start in allen Fällen "aktuelle Systemzeit" vorgegeben ist, die Zeitdifferenz zu UTC unterschiedlich ist, je nach Erstellzeitpuntk der flt-Datei, d.h., wenn ich den vfr.flt (im Winter) nicht neu abspeichere, sondern einfach nur schliesse, kommt es in der Winterzeit zu dem 2h-Fehler
Zusammengefasst heißt das doch: Startet man immer wieder mit seinem persönlichen xyz.flt Standardflug, der nicht "vorheriger flug" heisst und der im Sommer erstellt wurde, und hat diesen im Winter nie erneut abgespeichert, hat man den "Dunkelheitsfehler" jetzt morgens im Winter. Da man "Systemzeit beim Start verwenden" eingestellt hat, startet der FS zum heutigen Datum, aber mit falschem Sonnenstand!
Testet's mal aus.
a3g
Wolfgang
|