If my memory of the flightgear development history serves me correctly, we
originally used system time, without any option to change that.
This had obvious disadvantages, because it didn't allow any flexibility,
although I believe we already had the ("T"/"t") keyboard combinations to
advance / reverse time while the simulator was running. To add more
flexibility, Curt added a --time-offset option, which would enable us to add
or subtract a fixed number of seconds from the system time.
More flexibility was added later by me, after including a modified version of
the posix timezone library. This came with three new options, to one of which
curt is referring below (from the help function):
--time-match-real Synchronize time with real-world time
--time-match-local Synchronize time with local real-world time
--start-date-sys=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
system time
--start-date-gmt=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Greenwich Mean Time
--start-date-lat=yyyy:mm:dd:hh:mm:ss
Specify a starting date/time with respect to
Local Aircraft Time
--time-match-real, basically gives our initial behavior: Simulator time is
read from the system clock, and is used as is. When your virtual flight is in
the same timezone as where your computer is located, this may be desirable,
because the clocks are synchronized. However, when you fly in a different
part of the world, it may not be the case, because there is a number hours
difference, between the position of your computer and the position of your
virtual flight.
The option --time-match-local takes care of this by computing the timezone
difference between your real world time zone and the position of your virtual
flight, and local clocks are synchronized.
The next three options are meant to specify the exact startup time/date. The
three functions differ in that the take either your computer systems local
time, greenwich mean time, or the local time of your virtual flight as the
reference point.
Each of these five options were designed to be used exclusively, however, the
value set by these functions could be modified using the --time-offset
function. The latter would add a specified amount of time to the value
already set by the other functions.
The other functions (--timeofday and --season) were added later, and I
couldn't find out who the author of these functions is.
Hope this clarifies the history a bit,
Cheers,
Durk
On Sunday 02 July 2006 04:22, Curtis L. Olson wrote:
> I forget who setup the original --time-match-local options (and friends)
> and I never really understood how they went together. I think if you do
> test out a change here, make sure that the
> --timeofday=dawn,noon,morning,night,etc. option still works correctly.
>
> Regards,
>
> Curt.
>
> Durk Talsma wrote:
> > Hi all,
> >
> > I'm investigating a time-offset initialization problem, related to a
> > broken --time-match-local command line option. This option should set the
> > local simulator time to the same time as where I am in real life. For
> > example, I am located in a CET timezone, where it is 13:15, and want to
> > fly in the pacific time zone, and also have the time there to be 13:15
> > locally. The --time-match-local option takes care of this by adding a 9
> > hour time offset to the value of "warp".
> >
> >
> > In src/Main/fg_init.cxx, line 1413 in the function fgInitTimeOffset()
> > there is a line that reads:
> >
> > int orig_warp = globals->get_warp();
> > ...
> > [some warp computations]
> > ...
> > which is later followed by:
> >
> > globals->set_warp( orig_warp + warp );
> >
> >
> >
> > The problem is that this function is called twice. The first time
> > through, warp is set correctly, but the second time through it is messed
> > up, because warp is calculated correctly the first time through, but then
> > the same warp is _added_ to the already existing warp value. The end
> > result is that not 9 hours, but 18 hours are added to warp.
> >
> > Considering that this function is called Init, I believe that the
> > statement on line 1413 is wrong. An init function should not carry over
> > existing values or the very variable it is supposed to initialize.
> > Therefore, I'm inclined to remove that part. However, I just want to
> > double check whether there is a compelling reason to keep this in the
> > code. Is there another function that can already set warp before time is
> > initialized?
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
