Hi Greg, Well to start with the good news, I ran your file using my current development version, and the aircraft departed right on time. In my local version, the aircraft started taxiing at 02:32 UTC. Note that this is two minutes behind the scheduled departure time, which is due to added startup related ATC messages, which I'm currently working on. The basic timing functions haven't really changed between FlightGear 0.9.10 and current CVS, so I presume that your file should also work using FlightGear 0.9.10.
I did need to make one change: Change the aircraft model patch from Aircraft/AI/737-Qantas.xml to AI/Aircraft/737-Quantas.xml, which is the new file path convention for v1.0.0 and beyond. But other than that, your example ran pretty much out of the box. I ran FLightGear from the commandline, using: fgfs --airport=YMML --aircraft=ufo --start-date-gmt=2008:05:03:02:15 --log-level=debug You can verify the internal time used by FlightGear by opening the property browser [File -> Browse internal properties ] and by going to the /sim/time node. There you find the gmt-string property, which gives a human readable version. If you don't see the aircraft move, try speeding up the internal clock by pressing the 't' key. You can slow down again by pressing SHIFT-'t'. If the aircraft doesn't move at 02:30 UTC, will it do so 24 hours later? You may want to play with these time warp functions a bit, to get a better idea what's going on. Please let me know if it works or not. Some more comments below: > > Sure have; that was the first place I looked. I followed the > instructions there to create my AI traffic and ground network files, and > to download and install the AI aircraft models. Okay, just wanted to make sure. > > I'm surprised (and a bit concerned) that the format of the XML file > should have any effect on the behaviour of FlightGear. XML should be > reasonably free-format. If there are constraints on the layout of > elements (that is, on the white space characters between elements, > including tabs, spaces, and CR/LFs) then the data files will be much > harder to get right. Well, it really shouldn't matter, but the fact that tabs caused weird behavior makes me a little cautious. Therefore, I couldn't rule out the possibility of a subtle bug here. However, it looks like you're in the green, regardless of the format of the file. (Incidentally, I received a suggestion for a fix for the tabs problem, so your question has actually contributed towards uncovering and fixing a bug. Thanks for that). > Which introduces another question: What if the flight spans a day > boundary? Can I specify a departure time of 2300hrs, and an arrival time > of 0100hrs? This is very important in Australia, because we have some > very long flight times. For example, Melbourne to Los Angeles is 16 > hours; to Singapore is 11 hours; Perth is five hours. (Time zones make > this even more complex: the 16-hour Melbourne-to-Los Angeles flight > arrives two hours before it leaves Melbourne /on the same day/! UTC > eliminates this issue, but it still messes with your head.) This shouldn't be a problem. FlightGear knows that when one time precedes an earlier one in the sequence, that it is really meant to be the next day. Incidentally, in real life I once was at risk of missing a flight from Honolulu to Sydney, just because of that: I was leaving Sept 30, around 1AM, and arriving in Sydney on October 1st. In reality, my flight left in the evening of the 29th of September, but since it was just after midnight, it was technically already the 30th. Very tricky. I found out a few weeks earlier, while playing with FlightGear.... > > A particular aircraft will often fly a complete circuit. For example, > one Qantas 747 flies Melbourne - Phuket - Bangkok - Sydney - Melbourne > every 24 hours. I would like to model it in FlightGear. Should be okay. As long as all the flights are completed within the 24 hour period, you should be okay. If not, you could try using a weekly schedule, but that is a lot more complex. Incidentally, if you have something going, I'd be happy to "officially" include them in our data directory. > I re-checked the KSFO parking.xml file, and realised that the gates are > counted as nodes. The taxiway segments connect the gates with other > nodes. I had missed that in my first attempt. I have modified my > simple ground network file so that it now has one gate, one node, and > two taxiway segments. The node is at the start point for the runway > (that is, it's the point at which the UFO appears when you fly from > YMML). The two segments connect the gate with the node in each > direction. The AI aircraft still doesn't fly, though... One thing to note Re: FlightGear 0.9.10 is that it contains a small hard coded push back sequence. This has been implemented in a more appropriate way in FlightGear 1.0.0. This shouldn't have an impact on the departure time, but it might cause you to observe some aircraft movements that are not in your groundnetwork. > > I have increased FlightGear's log level to "bulk" but the logs contain > only one reference to the Traffic Manager, and don't contain any > diagnostics for it. This actually made me think that we probably should have some more meaningful messages. I just changed my local copy to output the following messages, when log-level is set to debug: Traffic Manager: Processing registration QAN01 with callsign Qantas0001 Traffic Manager: Flight is pending. Traffic manager: QAN01 is scheduled for a flight from YMML to YSSY. Current distance to user: 0.958282 Traffic manager: Creating AIModel Cheers, Durk ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Flightgear-users mailing list Flightgear-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-users
