Melchior FRANZ wrote: > * Melchior FRANZ -- Monday 12 June 2006 13:53: > >> Of course, this is a bad example, as those extensions make the format >> basically useless for any other purpose than for the AI subsystem. No >> other subsystem in fgfs can load them, which is why I would rather get >> rid of this sooner than later [...] >> > > Again, this would much less apply to an apt.dat extension. But for the > AI/Traffic system it's an artificial barrier for future improvements, > and a violation of the FlightGear Way[TM]. It's beyond me how this > could be accepted into cvs. > > The XML format in FlightGear has been chosen such that tag attributes > are only used to describe the node properties (data-type, read-only, > etc.). They are deliberately *not* used for *information*, because this > couldn't be cleanly mapped to the property system. > > I was about to add a feature to the UFO editor that would have allowed > to load AI files, to visualize the waypoints, to edit them, to assign > vehicles etc. One would have been able to create paths by clicking on > the tarmac, defining curve radii, etc. Finally, one could have saved the > result into a ready-to-use AI file again. But all this doesn't work, > because of this braindead decision. > > Melchior, I've tossed around various ideas with different people, and made a decision that seemed to be right at the time. I'm open to any constructive suggestion.
Note that most people working on flightgear are doing this in their spare time and for personal reasons. Keep in mind that everybody writing code is inclined to do things in the best way possible in the best interest of the project. At times this involves the need to make decisions on the basis of limited information and even more limited feedback. Therefore, calling the decisions related to the AI traffic xml files braindead is just plain offensive, and has nothing to do with criticism. As other people have observed, criticizing other people's work is not you're strongest point, so please let me offer you some advice. If you follow the guidelines below, chances are you're still getting your message across, but without running the risk of accidentally or purposefully pissing somebody off. In the long run, I'll guarantee that that will not only be more beneficial to the project, but that it will also help in keeping this fine bunch of people motivated to work on the project: 1) Stick to the facts, leave out you're emotional appraisal of the problem. 2) Give explicit and objective reasons why something is wrong 3) If possible, propose an alternative solution. Cheers, Durk _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
