On 22 Dec 2009, at 14:51, Curtis Olson wrote: > With the old route manager, the first way point is where I want to go for my > first destination, because I just put it in there with that specific goal in > mind. The 2nd waypoint is also where I want my second destination to be, > again, because I just put it there. Same for all the other way points. > Another nice feature we used to have in the original route manager was the > ability to insert and delete waypoints from the middle of the route, allow us > to update and change the route in mid-flight if we changed or mind (or > something like weather changed it for us.) > > What I liked about the old route manager is I could decide I want to fly to A > then B then C then D, I added those waypoints and off I go. > > I feel like I have to fight the new system to get it to do something like > that, and then every time I open up the dialog box, I'm never sure if it's > going to change the route on me or add the original airport back in again > (even if it might already be there.) I haven't tried using the route manager > in a few weeks now, so perhaps some of these things were bugs that are now > resolved. > > I think there was a simplicity and a determinism in the original system (as > unrealistic as that was) and I struggle with the new system trying to > understand how to get it to work and not make unexpected changes or additions > to the route.
I'm surprised by this - partly because it doesn't fit with my intentions, or what I experience using the code daily here, but also because if the system is behaving as badly as you suggest, why haven't you (or other people) made more of an issue of it, here? There were some initial issues right after the commit at the start of October, and I thought I'd resolved those to people's satisfaction, and that the code was working fine for people who use it. To find out now, that that's not the case, is unfortunate. To be clear, the current code: - adds the departure / destination runways if specified, otherwise the corresponding airports, if specified, ONLY when you click 'activate'. That is the *only* time it modifies the waypoint list, and I'm happy to limit that behaviour further if it's really causing problems for people. (I am considering splitting the flight-planning functionality into a separate, new dialog, which uses the same waypoints, but enforces my stricter requirements as regards flight-plans) - Allows inserting / deleting waypoints exactly as with the old code - I use this feature all the time - Allows waypoints to be entered A/B/C/D as you suggest, hit activate, and you should be done. The only additional step is hitting 'activate', and the code is supposed to be completely deterministic. (I guess you can see from that list why I'm so surprised!) Fundamentally, the new code's public API is almost unchanged - there's some (big) structural changes, and new features, but I am quite dismayed that it would be described as complex or non-deterministic - especially when that's at odds with what I see. Of course my expectations are different to other people's, since I wrote the code. As ever, I'd be happiest if people would file bug-report type emails, that gave a precise series of steps, expected results, and actual results. (Obviously the 'activate-adds-departure-and-destination-waypoints' thing is causing some issues, but I find it hard to ascribe all the problems you mention to that one thing ... especially since it's been discussed before, and is documented in the wiki pages for the route manager) > The alphajet has it's own autopilot configuration. I wouldn't characterize > it as "generic" since it is specific for this aircraft. Perhaps some of the > gains could be tweaked, but it behaves pretty well for me. That's not what I'm seeing in CVS data - thought it would explain why I became so confused in trying to test the Alphajet autopilot yesterday. If there's a non generic autopilot config for the Alphajet, where is it? I've just looked through the Aircraft/Alphajet dir, and don't see an autopilot .XML file. Regards, James ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
