What do you want in a 3rd party flight planner ?

[Guest FlightPlannerProject]

>Hi,>>Could you give us an update on progress please? I check your>blog but there has been no update since 1 Aug.>>Thanks.I think i will give a detailed progress posting on my blog by next weekend.Right now, i am trying to talk FSX into accepting my application window as a child window even in full screen mode. That would give the user the option to run my program inside FSX (like FS Navigator) as well as outside FSX (like FS Commander).

[Ray Proudfoot 8,961]

Good man. Thanks very much. I'll have a look at your blog next week. Good luck with the work!

[Orlaam 306]

Sounds promising so far. In regards to NavData in the sim, I've found it very odd that so many developers and others who like to tweak haven't explored the idea of updating a lot of the Navdata in the sim. There are reasons I can think of that no one is interested in this part of upgrading the sim, mainly because so many people rely on an FMC, GPS, or other systems that utilize up to date NavData from various sources. However, I still think a lot of those people could benefit from updated NavData within the sim's database, especially when using a product that reads that data for it's flight info.Only a small number of actual approaches have been upgraded to reflect newer procedures in the sim using add-on AFCADs. This got me to wondering why so many people say you can't change, update, or fix the NavData in the sim, when I've done that very thing over the last few days. I'm referring to FS9, but I don't think FSX is that far removed from the code FS9 uses for it's NavData, at least from what I've read. I'm waiting to build a new computer to even install FSX.So, for example, I've removed an ILS, changed CTAFs/Unicoms, and even added waypoints to FS9. Example, yesterday I wanted to fly a route that called for the use of the RIICE1 arrival. Well, when planning the route, I found a lot of the waypoints weren't in the sim. I realize the game doesn't use STARs, but for planning sake, I decided to add them to see how it would take. I made my own BGL file, inserted it into the Namc folder, and my waypoints were in the GPS and map no problem.Simply creating a BGL with this inside:<?xml version="1.0"?>Containing all the waypoints not found in the default BGLs, using the code above, I was able to add them and have the RIICE1 arrival. I really think someone could easily create a program that would provide the means of updating various components of the NavData in these sims without too much trouble. Typing it by hand IS time-consuming.Anyhow, to remark on the snapshot of your Spring 2005 navigational data, yes, it can be changed and updated very easy, just seems no one wants to do it, except for Jim Vile and a couple others who are providing new approaches and fixes for airports.ETA: I attached a couple snapshots of the fact I inserted the waypoints in the sim. One of the data on the map with RIICE and another fix showing, and one pic of the info for an RNAV fix I added, AAAXX.

[Reset XPDR 1,271]

Sounds promising, but can you remove outdated data by this method too? If so, you may have a winner.Gary

[Orlaam 306]

Yes, any of the waypoints, airways, and various other "stuff" can be changed and removed. I suspect scenery designers of various products (mainly ground, airport, and AFCAD) know this can be accomplished, but for some reason they don't want to address the issue. I just wanted to see how far I could go these last few days, and since I've never programmed to a serious degree, nor played with XML, I wanted to see what could really be done. I hear all the time how the data is frozen so to speak, when in fact that's not true. You can extract all the XML out of the BGLs that hold the NavData and edit it any way you like, provided you don't break it, when you recompile it back to BGL, it will read all the new changes. I was playing around with one file that had an Alaska airport data in it, along with the respective approaches. This perticular airport had an ILS in FS9, but according to the real world data, no ILS exists at this place. So, I simply removed the lines of text pertaining to the ILS, recompiled and it was gone! It displayed this way in the GPS and Map, plus no errors such as a CTD. In many ways this is very easy to do, but it is time-consuming and requires some knowledge obviously, as well as a couple different decompiler applications since some have said the BGL extraction software leaves certain data out or corrupts it. I haven't really looked at this area yet, although I'm liking NewBGLAnalyze best so far.For the most part, a lot of the major airways, waypoints, and approaches have stayed the same. In my experience using the sim, about half or little less is missing or wrong now. I'm referring to the U.S. and have no real charts or data to compare outside the U.S. The most changes seem to be with larger and busier airports, such as KPHX, KATL, KLAX, and so on. It's totally within reason that anyone with no knowledge of actual programming can create their own BGLs with fixes and approaches for the sim to read. I can't say how the VORs and NDBs are handled yet, but I can't imagine it's that much different. I just know I've been able to introduce new waypoints, change frequencies, and rename things pertaining to fixes and airports without causing any harm. If I had to guess, new approaches and waypoints (fix/intersections) are the main thing people would like to see changed. The act of renaming airports, changing their ICAO codes and frequencies is so easy, anyone could do it. The best part? That update takes no time at all once you've done one or two.The most difficult at this point for me are the approaches and especially the airways. The approach code isn't that tough, but so much goes into each leg of any one single type of approach (e.g., RNAV, VOR, NDB). It takes some time to get it right since some values have to be very precise to work 100%. The only code I've yet to fully understand are the airways. The way in which the airways and respective intersections are scripted is strange. One waypoint may be mentioned several times just to make up one small segment. Kind of odd, but I've yet to really print one out and study it.I'd say worst of all is the fact the DAFIF data is no longer available and that seems to be the one place where you could get what was needed to enter everything correctly. To make my waypoint file for the RIICE1 STAR, I had to enter the coordinates into a conversion utility to get the proper format so FS9 would read it and place it exactly where it goes. The GPS coordinates are a royal pain to work with.I added my BGL and the XML code that adds the RIICE1 missing waypoints to FS9 so you can see how easy it is.

[Guest FlightPlannerProject]

>Sounds promising so far. In regards to NavData in the sim,>I've found it very odd that so many developers and others who>like to tweak haven't explored the idea of updating a lot of>the Navdata in the sim. There are reasons I can think of that>no one is interested in this part of upgrading the sim, mainly>because so many people rely on an FMC, GPS, or other systems>that utilize up to date NavData from various sources. >However, I still think a lot of those people could benefit>from updated NavData within the sim's database, especially>when using a product that reads that data for it's flight>info.>>Only a small number of actual approaches have been upgraded to>reflect newer procedures in the sim using add-on AFCADs. This>got me to wondering why so many people say you can't change,>update, or fix the NavData in the sim, when I've done that>very thing over the last few days. I'm referring to FS9, but>I don't think FSX is that far removed from the code FS9 uses>for it's NavData, at least from what I've read. I'm waiting>to build a new computer to even install FSX.>>So, for example, I've removed an ILS, changed CTAFs/Unicoms,>and even added waypoints to FS9. Example, yesterday I wanted>to fly a route that called for the use of the RIICE1 arrival. >Well, when planning the route, I found a lot of the waypoints>weren't in the sim. I realize the game doesn't use STARs, but>for planning sake, I decided to add them to see how it would>take. I made my own BGL file, inserted it into the Namc>folder, and my waypoints were in the GPS and map no problem.>>Simply creating a BGL with this inside:>><?xml version="1.0"?>>>xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>xsi:noNamespaceSchemaLocation="bglcomp.xsd">>> waypointRegion="K4"> waypointIdent="CHMPZ"> lat="32.565833"> lon="-96.810667"> magvar="355.00">>>>>>Containing all the waypoints not found in the default BGLs,>using the code above, I was able to add them and have the>RIICE1 arrival. I really think someone could easily create a>program that would provide the means of updating various>components of the NavData in these sims without too much>trouble. Typing it by hand IS time-consuming.>>Anyhow, to remark on the snapshot of your Spring 2005>navigational data, yes, it can be changed and updated very>easy, just seems no one wants to do it, except for Jim Vile>and a couple others who are providing new approaches and fixes>for airports.>>ETA: I attached a couple snapshots of the fact I inserted the>waypoints in the sim. One of the data on the map with RIICE>and another fix showing, and one pic of the info for an RNAV>fix I added, AAAXX.I am not sure about FS9, but FSX has transitions (which to me look very much like STARs), Still no SIDs however ..After installing FSX (and its SDK), go to www.fsdeveloper.com, look for ScruffyDuck and his SDE and ADE projects, and while youre there grab a copy of Osman's document describing the internal structure of bgl files. With SDE and ADE you can decompile BGL to XML, then insert/delete/update whatever navdata you want, and then recompile it back to BGL again. Then you can enjoy last months AIRAC cycle with the standard FSX builtin aircrafts, GPS, ATC and AI traffic.However, I would understand if the authors of certain types of addons prefer the present situation, just like I pray three times a day that MS Aces doesnt touch the builtin flight planner for the next few decades or so .. ;-P

[Guest FlightPlannerProject]

> ... >The only code I've yet to fully understand are the airways. >The way in which the airways and respective intersections are>scripted is strange. One waypoint may be mentioned several>times just to make up one small segment. Kind of odd, but>I've yet to really print one out and study it.> ...First some boooooring statistical data from my not even alpha flight planners scenery scanner:In FSX, there are 24490 airports. 5423 airports have 20659 approaches. 3952 airports have 51767 transistions.Radio NavAids: 3549 Markers, 8347 NDBs, 7675 VOR/ILS/LOC/GS/DME.There are 21245 airspaces and 1103 borders/coastlines.There are 102863 waypoints, which are split into three distinct and disjunct groups / subsets. 65490 are terminal waypoints that belong to some airport and their approaches and transistions.28982 are intersections belonging to some airway(s)/route(s).8391 waypoints dont belong to any airport or route.There are no "terminal intersections" that belong to an airport AND an airway.Now to the format how airways are stored in the BGL files. If a waypoint belongs to an airway, it has one or more routeinfo records. Each routeinfo record gives the airways name and type (Victor/Jet/Both) and two (possibly empty) links called prev and next. Each prev/next link gives the next/prev waypoint ID and the minimum altitude for that airway segment. Waypoint IDs (the 5 letter code) are not unique, but if you add the 2 letter region code, they are.If waypoint ALPHA has a next link to waypoint BRAVO, waypoint BRAVO always has a prev link to waypoint ALPHA as well. There are 61550 such link pairs.However 504 of those pairs differ in the route type (e.g. ALPHAs next link to BRAVO says its a victor airway, while BRAVOs prev link to ALPHA says its a jet airway). Thats either an error or i suffer from some serious misunderstanding of the route system. 617 pairs disagree about the minimum altitude. On the other hand, 99% of the data is consistent. However, I am still unsure how to handle those 1% contradictions.So the airways are nowhere stored as a list of their waypoints, but instead they are stored as segments scattered over their waypoints.Which means, poor me had to built that data structure by myself ..Temporarily ignoring the route type (V/J/:(, i found 7135 different route names. Then i check all the waypoints that belong to the same route name. Sometimes the set of waypoints with the same route name falls apart into two or more disjunct subsets (which means the WPs in subset A have no links to the WPs in subset B and vice versa). Then i split the route into two (or more) routes. Looking at the map, these splitted routes look like different routes with the same name, e.g. one route called XYZ in US and another route called XYZ in Europe (in other words, route names are not unique). After splitting, i get 8725 unique routes.Next I want every route to have exactly one begin WP (with an empty prev link) and exactly one end WP (with an empty next link). Most of the time i am lucky, but there are 13 WP pairs that look weird. After checking the maps, i think they are errors, e.g. suddenly a route with 100 nm segments does a 3000 nm jump and back. After supressing those evil 13, all routes have exactly one begin and end.However, there are still weird things. Less then 100 routes have waypoints that have more than 1 next or prev link. I am still unsure, what exactly that means (but it reminds me of string theory ..). So i have frozen my route fixing code until my drawiung code is done, so that i can look at those weird cases on the map, hoping for light bulbs popping up over my head .. ;-PCould i export the data to xml/txt/whatever and post it ? Technically i could, but i fear nasty letters from the lawyers of MS or Jeppesen, because in theory someone who hasnt bought FSX would get access to that data. Its a different thing if John Doe, who has bought FSX uses my application to extract that data to his own local disc for personal use only.

[Orlaam 306]

I've looked at those file in FS9, but unless you're wanting to use the flight planner in FS9/FSX, you really don't need to insert any new code for airways because they don't do anything, and are invisible. If I copy a real world route from FlightAware, which is what I do, I just use the flight planner in FS9 to connect the waypoints myself using my own charts for the U.S., so I have no use for airways in the sim. I like having the waypoint though since those I need to be able to drag the line for the route and connect. As for the NavData in the sim itself I just prefer having the waypoints and approaches be accurate and up to date. Obviously, VORs, NDBs, and airports matter too, but the airports require a lot of AFCAD work to fix if they have a lot of changes, otherwise it's easy. I need to look for the VORs and NDBs in FS9 though to see what I can do there. I know of one VOR close to my state that has a new code and one NDB that no longer exists near KSDL. I wonder if that NDB is gone in FSX? It's been gone since 2005.Anyhow, I look forward to the work you're doing for a FPer, and appreciate the fact you're taking input beforehand.

[Ray Proudfoot 8,961]

Hi,I see your blog hasn't been updated since August 1st. How are things going?

[McCrash 3]

I could be wrong but I don't believe that Jeppesen and MS own the data. It came from DAFIF supposedly and was alway free.I have been in that data and I think about 20% of it is wrong.

[jkeye 152]

Theability to choose flight time,scenic routes and difficulty of approach/landing from the start screen!Export to leveld D 767 .rte formatTa Jay

[Guest FlightPlannerProject]

>Hi,>>I see your blog hasn't been updated since August 1st. How are>things going?I've been busy with infrastructure stuff:- Serialization - done- Running as a module inside FSX - done- CLR Hosting - almost doneSerialization:The MS .NET framework has a serialization engine that transforms memory objects to binary or xml data and back. I need it to write and read my own data files after extracting them from the FSX scenery. Unfortunately the MS serialization engine was too slow, e.g. reading 100.000 waypoints took 15 minutes and consumed almost 1 GB of memory. I tried several options to tune it, but it still was slow. To be fair, the MS serialization engine has to support several quite different usage scenarios. After analyzing whats going on, i decided to write a replacment for its core class (BinaryFormatter), that is tuned especially for my requirements. That took a while .. but now it works fine. Now the 100.000 waypoints take 15 seconds to read or write, the files are three times smaller and memory usage is ten times less.Running as a module inside FSX:I want my FlightPlanner being able to run as a standalone application (like FSCommander) as well as a module inside FSX (like FSNavigator). When FSX runs in window mode, it is easy. When FSX runs in full screen (Alt-Enter) mode, its not ..But i found out what magic spells and rain dances are neccessary to make FSX believe that my window is one of his child windows .. ;-PBecause of some limitations of Windows itself, my application has to run as a module inside the FSX process space and has to share the same thread for window drawing and user interface stuff. That stuff works fine now, I can draw with GDI+ and/or DirectX in my window(s) even inside FSX.CLR Hosting:My application is mostly written in C# (with some C++ where needed), so it needs the CLR (Common Language Runtime, aka .NET runtime). FSX however is a native application written in C++. To be able to run .NET stuff inside FSX, a CLR host is needed (MS Internet Explorer and MS SQL Server use the same technique to run .NET stuff inside). So i had to write my own CLR host for FSX. Since I could use that stuff for my non FS projects too, I decided to implement a CLR host for general usage, that can run as a FSX module, too.First I tried the V1.x Hosting API, which was easy. A bit too easy, cause it has some limitations. So I switched to the V2.0 Hosting API, which is pretty complex - you have to implement a bunch of different manager modules to handle the various parts of a host.This stuff works now, too. Theres still some fine tuning left to do, but I think that won't take long.So whats next ?The graphics module. Since the number of things to draw is huge, I need a tree hierarchy. E.g. when looking close, I draw an airport in full detail, but when looking at a bigger part of the map, I just draw a circle with a line or just a dot. So I need a bunch of classes - one for each type of map item - that knows how to draw itself on the map. These map items are linked into a hierarchy, so that I draw minor stuff only when needed. I want to avoid tar and feathers for stealing too much FPS .. ;-PRight now I am working on that graphics stuff, making good progress.I guess its a bit boring that I still dont have any screenshots, but programming is a bottom-up thing like building a house - first you need a solid foundation ..Martin

[doc1956 0]

>I guess its a bit boring that I still dont have any>screenshots, but programming is a bottom-up thing like>building a house - first you need a solid foundation ..Martin,Thank you for the update on your Flight Planner project. I had a feeling that you were busy programming (where blog updates may not occur with regularity) and from an end-user point of view that is fantastic news. There are a great many people very eager to see your work come to life!Thanks again mate.Paul

[Ray Proudfoot 8,961]

Hi Martin,Thanks very much for posting such a detailed reply. I'm amazed at how much work is involved.Don't worry about the lack of screenshots. The real work lies underneath. I'm reminded of the analogy of a swan gliding across a lake. On the surface all appears serene but underneath the engine room is going like crazy! :-)Keep up the good work!

[Guest rap777]

Hi Martin!I am really getting excited reading about your project and I am looking forward to see it in all its glory!I would have another feature request. Even though not strictly part of the flight planning process it would be great to be able to assign a Start Gate so you do not have to commence your flight on the Active RWY.Maybe not as important but still nifty would be the ability to assign a finish gate/parking spot.As always, I hope that makes sense to you and thanks again for all your hard work!!!!!!Kind regards and God blessAlfred