RC5 suggestion: Dedicated Navdata Cycles

[G-YMML1 582]

Hi,Have you guys ever though about creating your own Navdata the way other commercial developers do? That would make life (and ATC realism) much easier. The user would have a certain flexibility with requesting DIRECT-TO vectors in flight or using predetermined fixed and NAVaids.What do you think about it?

[jd 57]

Hi,Have you guys ever though about creating your own Navdata the way other commercial developers do? That would make life (and ATC realism) much easier. The user would have a certain flexibility with requesting DIRECT-TO vectors in flight or using predetermined fixed and NAVaids.What do you think about it?

since i won't be letting you request direct to a checkpoint that isn't in your .pln, i don't really need the database.everything i need is in the .pln files, and the flight planners usually get their data from navdatajd

[jordanal 70]

since i won't be letting you request direct to a checkpoint that isn't in your .pln, i don't really need the database.everything i need is in the .pln files, and the flight planners usually get their data from navdatajd

Not true, typical (most flexable) flightplans are exported without SID-STAR waypoints, but do include the transitions to the beiginning and end of the actual plan. I then also force a VOR to within 5nm of the destination to pickup weather-holds, but delete the 5nm VOR in the FMC after I'm enroute. When a plan is loaded in the FMC, the most current SID or STAR (updated from Navigraph) can then be used to get to the transition and not be pinged by RC for not following a specific plan (transition still within 40nm of airport). This also makes the plans reusable from one flight to the next, but flexable with numerous runways which also helps for changing winds between FS startup and takeoff.You need to use the updated SID-STAR cycle data after flight is loaded and determine which rwy is in use and issue the appropriate SID (& star near descent) based on the AI and weather, and get us to the transition filed in the flightplan. Also, pull-in the expected arrival weather if we're using a third-party weather app, much like Fightsim Flight Keeper and FSBuild can already do, by parsing the weather_bin.txt file that ActiveSky generates, for example. If they can read it, so can you.Then read the weather at a given distance from the arrival and issue a STAR. That would really help on those 10 or 12 hour long-hauls, whereby weather can change significantly between the time the FP is submitted and the beginning of the approach, switching to an appropriate STAR, starting with the filed transition. Importing the expected arrival weather would then also allow you to generate weather-related holds much more realistically.

[jd 57]

Not true, typical (most flexable) flightplans are exported without SID-STAR waypoints, but do include the transitions to the beiginning and end of the actual plan. I then also force a VOR to within 5nm of the destination to pickup weather-holds, but delete the 5nm VOR in the FMC after I'm enroute. When a plan is loaded in the FMC, the most current SID or STAR (updated from Navigraph) can then be used to get to the transition and not be pinged by RC for not following a specific plan (transition still within 40nm of airport). This also makes the plans reusable from one flight to the next, but flexable with numerous runways which also helps for changing winds between FS startup and takeoff.You need to use the updated SID-STAR cycle data after flight is loaded and determine which rwy is in use and issue the appropriate SID (& star near descent) based on the AI and weather, and get us to the transition filed in the flightplan. Also, pull-in the expected arrival weather if we're using a third-party weather app, much like Fightsim Flight Keeper and FSBuild can already do, by parsing the weather_bin.txt file that ActiveSky generates, for example. If they can read it, so can you.Then read the weather at a given distance from the arrival and issue a STAR. That would really help on those 10 or 12 hour long-hauls, whereby weather can change significantly between the time the FP is submitted and the beginning of the approach, switching to an appropriate STAR, starting with the filed transition. Importing the expected arrival weather would then also allow you to generate weather-related holds much more realistically.

this is all true. but i'm not having the capability in v5, to change your flight plan, 2 hours into it. if you want the flexibility to fly any star you want, i'll have that. but i won't need data then. sort of the same as flex dp on the front end, imagine a flex star on the back end. essentially the last checkpoint in the plan is the common point of multiple stars. once you reach it, you will have the flexibility to fly any star from that point, to the airport. rc won't be nagging you or watchdogging what you are doing.if you want the nagging or watchdogging, you will need to file the star the way you intend to fly it.jd