|
Post by andqui on Sept 30, 2014 22:32:27 GMT -5
When asking the user to enter local time while creating flights, does FSCaptain use it's own time zone database or does it pull the local time from FS? I'm asking because I'm using a set of timezone bgl's that update the FS world's time zones and make them more realistic, and sometimes there seems to be a mismatch between the local time in the sim and the local time in FSCaptain. The last flight I did was between EIDW and EGLC, departing at 19:30 local and arriving at 20:50 local. This corresponds to 18:30 GMT and 19:50 GMT. When I entered 19:30 and 20:50 local in the flight creation process, and committed the flight, going into the sim at 19:30 local (18:30 GMT) was outside the entry window and I could not choose the flight in the ACARS. When I changed the local times in FSCaptain to 18:30 and 19:50, and chose 19:30 local in the sim, I was "on time" and could load the flight. It seems FS Captain was using GMT+0, when the real local time in Ireland/Britain now is GMT+1.
Why not just use UTC time instead? It would remove any chance of this sort of error and make things much simpler in general.
|
|
|
Post by Travis on Oct 1, 2014 23:37:21 GMT -5
FSCaptain uses the standard database for time zones. If they've been changed, then we may not be aware. Moving to a different time zone base is tricky in that we would have to account for Captains who don't want to change... it's a widely varied simulated world that we're doing out best to handle. And yes, we do have a few plans in mind... for post 1.5.1 integration.
|
|
|
Post by andqui on Oct 2, 2014 11:58:08 GMT -5
it's a widely varied simulated world that we're doing out best to handle. Yes, which is why UTC makes much more sense, so there's no variation. Anyways, is there a way I could look at the internal database FSCaptain uses, to see if I need to use a different local time in different situations? Is it in a config file somewhere, or in the binary?
|
|
|
Post by peter on Oct 2, 2014 12:44:47 GMT -5
I've been arguing for UTC before as well. Here's another reason why UTC should be implemented: If you fly on Vatsim, all times are given in UTC, so to be in line with ATC your FSX UTC time needs to agree with the actual UTC time. However, if you use FSX local time, your UTC time might be wrong and you get into problems. Just a few days ago I witnessed when a pilot was sending his position report (for transatlantic flights) and got all times wrong because his simulator had the wrong time settings.
How about the following solution: FSCaptain could check local and UTC time in FSX. If one of these times agrees with the departure time of a scheduled flight it is displayed, otherwise not.
Cheers, Peter
|
|
|
Post by Travis on Oct 4, 2014 9:31:04 GMT -5
Yes, which is why UTC makes much more sense, so there's no variation. Anyways, is there a way I could look at the internal database FSCaptain uses, to see if I need to use a different local time in different situations? Is it in a config file somewhere, or in the binary? If you're being bugged by time issues (and we are approaching the end of summer time in the US, so there'll be a one hour shift for a few weeks), the easiest way to avoid them is to not specify an arrival time for a flight. You can have flight 123 scheduled to depart Walla Walla Washington each day of the week, but as long as you don't specify its arrival time you can show up at any time of the day and make that flight. What we're doing is not that complicated - FSCaptain just gets the date & time from the simulator using the standard environmental variables - LOCAL TIME, etc. The simulator uses a BGL file that has time zones for the world -- I always forget which file it is, but we just ask the simulator for the data. And while it would be easy to simply globally rename all variable calls, changing LOCAL to ZULU, I shudder to think what impact that would bring. (Just yesterday as I was working on the Dispatch Release, i changed the label of CREW to STANDARD (ITEM) and I began to get overloads. It turns out another bit of code was looking for that label ("CREW") and not finding it, added a few thousand extra pounds to the manifest.) Currently, some gremlin is eating all of my passengers. I guess so, since they're on the Manifest, but never make it to the Load Map. Once I fix that bug, I'm leaving the Dispatch Release alone until we release. And as I was about to post, I realize one place where we have to get LOCAL TIME -- the ground icing calculator needs to know local time so it can determine if there's a chance of active frost. So that one has to stay LOCAL.
|
|
|
Post by andqui on Oct 4, 2014 15:56:08 GMT -5
Fair enough. The reason the local time issue could be a bit annoying is because of the maybe(?) unusual way I use FSCaptain. I've written my own program that's populated with thousands of real world flights, with the correct local times depending on the season, which I can pull random flight from. So, for example, I'll be assigned flight SAA8514 from FAOR -> FLND, 0945 to 1215 local, on a Monday, with a BAE 146-200. I then open up FSCaptain and create a flight, using those times/parameters, to get my payload. Then I use PFPX to actually do the flight and fuel planning, following which I stick the flight plan, ETE and fuel needed into the FSCaptain Administrator, and then commit. If the local time ends up wrong, I need to close FSCaptain, note and copy the payload it originally gave me, and then restart FSCaptain and make the flight again with the same payload and corrected times. It's not too much of a hassle, and I know what I need to do to fix it when it does occur, but it can be a pain. Anyways, I'd appreciate it if sometime in the future there was some sort of option to be less strict about when you can commit a flight, or maybe checking both local and UTC like the person above suggested, to avoid this.
|
|
|
Post by Travis on Oct 4, 2014 22:11:53 GMT -5
That's an interesting method... not "unusual" since we each fly our own ways. I do know that FSC 1.5.1 has a better VNAV profile which should lead to allowing Captains to build better fuel burn rates. For now, I strongly recommend that you only list departure times and not arrival times.... If you can email me a link to the "updated time zone files" that you are using, I will install them to one of my simulators so we can check what's nice & possible with them versus what's nice & possible with the default files....
|
|