Oh dear, I've got my copy of the RC3 today and, yes, it is great. However I have a suggestion to do for better supporting SID/STARs without having to do a lot of programming. My suggestion would be to add a wizard kind of interface with the following information:Dear developpers what do you (and of course) others think of this ?Screen 1--------- Ask if plan contains a SID (Checkbox)- Ask if plan contain as STAR (Checkbox)Screen 2 (If SID present)-------------------------- Display a listbox will all fixes and request the user to select the transition fixScreen 3 (If STAR present)--------------------------- Same selection of transition point for the STAR but the listbox should display fixes in reverse order beginning at the destination airportScreen 4 (If SID present)-------------------------Display a multi column display containing all fixes from the departure airport to up to and including the transition fix. For each fix allow the user to specify and altitude and/or speed restriction. The syntax could be FMC syntax or algebraic (or another one :-))For the altitude (ex. 4000 feet): 4000=Cross fix at 4000ft, 4000A or 4000+=cross fix at or above 4000ft, 4000B or 4000-=cross fix at 4000 or belowFor the speed (ex. 220kts): same meanings for 220, 220+ or 220-Display a combo box allowing to optionally select the fix in the SID from which point on ATC could take altitude control, of course ATC must still observe limitations. By default the transition fix is used.- Check box labeled "Last fix is landing fix" (or similar). This means that the last fix in the SID is not to be take into account directly by RC in case of vectoring. However in case of vectoring to the runway this fix determines the point at which the plane should be aligned and at which altitue it should be to start its descend (i.e. intercept the glide slope on ILS runways) In this case the last fix of the SID is the second last fix in the flight plan.Screen 5 (If STAR present)--------------------------Same as for the SID with this additional feature:- A checkbox to specify "Vector to runway after last fix". This for STARs which do not end at the runway, as it is the case for a lot of the large airports. RC4 ATC will take over after the last fix again. If this option is checked a combo box may be used to select any fix of the SID from which on ATC could start vectoring (by defauilt the last fix).Effects on radar Cotact:------------------------- Removes the problem of STARs starting far from the airport (example: KDFW) - Allows Radar contact to compute the correct point to ask to the pilot to start his descent in order to be able to comply to the STAR altitudes- Acurate critique of SID/STAR procedures- ATC could react on pilots busting procedure limits: "Virtual 747, you are below/above published altitude), please decent/climb to 4000", or something similar- ATC could start on the accurate SID boundary - ATC could state something like "Virtual 747, cleared to runway 27L via published procedure" during the descent, before the STAR transition fixThis is not all---------------Other easy options may be foreseen:- Checkbox on each fix to mark it as standard hold pointImpact on Radar contact-----------------------Being a programmer myself I estimate the impact of realizing these additional features very low as all the necessary complicated things like vectoring, descent computation, etc... are already in RC. The only thing is that this wizard will establish some fix data through out,

Interesting concept. It reminds me of the altitude restrictions that Proflight allowed on departure and on arrival. You have added some new ideas as well, and it would allow for new optional functionality in RC. Optional being the key word since everyone seems to want a different animal when using RC.

suggest you send this to doug, and let him put it on the list of enhancements

already done ;).

The only real problem if this is that a data file would need every single intersection in the world (1,000,000 of them), and know every single one involved in a DP or STAR (about a quarter of those).This is no different than having a data file with every single DP and STAR in the world.

Gaston's plan does put the burden on RC to manage all of the points and the altitudes.Why not let the compatible flight planners handle this instead and just modify the way RC reads flight plans? I know MSFS PLN files don't allow for altitudes, but many of the others do.

Bruce,A lot of planners don't include altitudes.I haven't tried an FSNav plan with altitudes, and to see if it exports them. I also don't know if FSNav STARs and DPs have altitudes. I've never used that part of the proggie.I really don't know what the FS planner includes.Either way, it could be a lot of work manually putting in altitude for each point, even if it's only the DP and STAR.But RC could certainly be made to pay attention to the altitudes.

Hi all,I am very glad to see the comments on my suggestion, and of course especially that Doug accepted the "challenge". Let me reply to some of the answers:to .4:"The only real problem is that a data file..."Scott, you are somewhat right as I did forget that the FS2002 flight plan does contain waypoint names but not necessary the right fix names. RC could use the FS2002 database to extract the correct names by its latitude/longitude. This is how FS Navigator doe it by extracting all data to its own database. Fixes that it does not find there, it names it Fix1, Fix2,...) But RC does not have to know which fix belongs to SID and STARs with my suggestion. Of course realism is limited to one single runway with this.One step further, one could imagine to setup an internet DP/STAR server which would allow RC to use them dynamically and feeded by the community as this is done via FS Navigator. However this will also have a drawback as RC does not show the route you won't be sure that you have the correct plate for the downloaded DP/STAR. The database should then have a software allowing to print the plates. But that is a big step farere then what I propose here. While you see that I already thought so far, my first goal was minimal impact for the moment.However there seem to be a valid SD/STAR database that is used for example in the PSS 747-400 FMC. This one does even know the restrictions on speed and altitude.In general I find it better to leave the SID(DP)/STAR planning to the plkanning softwares as those allow you to visually inspect them.to .5:"Gaston's plan puts the burden on RC..."Again this is because of impact to RC. They decided no longer to import the different formats but only the FS2002 format. I did simply comply to this new design decision of the RC developer team. Of course your suggestion would be better, but on the other side, one of the import formats will be the FS2002 flight plans as RC will not force users to use planners, which still will require RC to edit the path.In conclusion,Thanks to all replies so far (and those to come of course),Gaston.

your last paragraph is slightly wrong. we accept fs200x .pln files, and previous rc version export files (.apl). we did that for backward compatibility. there is a ton of .apl files out in the virtual airline space, so we kept the ability to read that format.we have never read the planners native format flight plan files.

I am sorry for that missunderstanding. I knew that I had to export for RC in FS Navigator, but did believe you would import the others directly in V2 especially since each planner had a specific tab. Now there are "only" two buttons but then the features are the same as before. I don't know if APL files contain more information than FS2002 files, but since it is used for all planners, most probably it will not include speed and altitude restrictions anyway.Nevertheless the fact remains that FS2002 will be THE suported format anyway and this format has the less features and as such will require the editing to be done by RC as suggessted by me. Puhh, did a mistake and still was right :-)))Additionally I did check during lunch time that RC does already display the waypoints correctly when in flight. Now I don't know if this is an AdvDisp or an RC feature. If it is RC this means that RC already has knowledge on all the fixes via FS2002 I presume.Could you enlighten us on this ?Greatings,Gaston

when you say the waypoints are correctly displayed, do you mean that you see MEM, RMG, VUZ, etc for checkpoints (vor's), as opposed to <1>, <2>, <3> which are displayed if you suck in a .apl file?that was the driving force behind using the fs200x .pln files instead of .apl files. .pln files contain the checkpoint names, .apl files do not.if the checkpoint is in the .pln file, i have everything i need to know. i lookup the long/lat of the checkpoint. that's what you will find in the navs.txt file. r.txt contain all the runway information. fixes.txt contains all the intersections. a.txt contains all the airport information.

>when you say the waypoints are correctly displayed, do you >mean that you see MEM, RMG, VUZ, etc for checkpoints >(vor's), as opposed to <1>, <2>, <3> which are displayed if >you suck in a .apl file? Yes thats, what I mean. But my mistake was that since I am in the office and do not have FS2002 here, I did download a pln file from AVSIM and checked its contents. It seems that I had no luck as all waypoints did not contain names but where labeled WPT01,WPT02,... Viewing this I believed that FS2002 was not storing the fix names in the plans. This reverses now in that sense that apl files have the less features in this regard.This will make my suggestion to work fine with .pln files which shoud be the standard to be used anyway if I understand well (.apl only for compatibility). Supporting it in .apl files would require to extract the fixes from the FS2002 database.Gaston

Why not make it a bit more simple, and just have a user editable file, where anyone can add sid/stars to. Sort of like the runway file. You'd give the name of the departure/arrival, the waypoints, and altitudes.Also, you could say, that at a certain point in the star you would start recieving vectors to a certain runway in use, or if the star calls for vectors to the runway at the end. I dont have specific examples at the moment, but I have seen plates that say, expect vectors to xx runway at this intersection (or something similar).If the waypoints are already known, thru grabbing them from FS or some other means, it shouldn't be much of a problem. The only problem I would see is if theres 2 fixes that have the same name, rc wouldn't exatly know which one to use, tho you could just use the one closest to the other points (most of the same name fixes I've seen are 1000's of miles apart).Once the file gets populated enough, RC could then use the database as a sort of flow for a particular airport. so that even if you dont file a particular arrival, or depature, rc could come back and give you vectors based on the procedure and your departure/arrival direction used for that airport. Just some thoughts on the subject. I have no idea if these would be practical from a developer standpoint. The biggest point I want to make, is that the developers/testers don't have to come up with all the information. I would be willing to put in the info needed before a flight, and have it added to the master database on someones website, so others wouldn't have to put the same info in every time they go into the same area.

Hi Nristow,>Why not make it a bit more simple, and just have a user >editable file, where anyone can add sid/stars to. Sort of >like the runway file. You'd give the name of the >departure/arrival, the waypoints, and altitudes. This would be no problem for me and allow for more flexibility, however the developers have to evaluate what is easier for them AND for their customers to use. Anyway an editor should be provided to make editing the SID/STARs easier especially as longitude and latitude of the fixes will be required to be stored in this file too to identify them for sure.If the developers would prefer this approach, I might find the time to write such a SID/STAR editor. For sure this approach will be the most flexible one as it will in a future allow RC to select DP/STARS according to the direction of the wind and so the rwy it will use.What do you think, dear developers ? The editor could be made to allow all (or nearly all) features of DP/STARs while RC development could select over time which ones it will really implement.>Also, you could say, that at a certain point in the star you >would start recieving vectors to a certain runway in use, or >if the star calls for vectors to the runway at the end. >I dont have specific examples at the moment, but I have seen >plates that say, expect vectors to xx runway at this >intersection (or something similar). Yes, KDFW is such an example where you have one fix for vectors to the north and another for south. I thought about that too, but in my idea thjis was a next step which could build on the first step where I limit the vectoring point to a specific runway.>If the waypoints are already known, thru grabbing them from >FS or some other means, it shouldn't be much of a problem. >The only problem I would see is if theres 2 fixes that have >the same name, rc wouldn't exatly know which one to use, tho >you could just use the one closest to the other points (most >of the same name fixes I've seen are 1000's of miles apart). Longitude/Latitude should be stored anyway as this will uniquely identify the fix.>Just some thoughts on the subject. I have no idea if these >would be practical from a developer standpoint. They would not be to difficult to implement from my point of view but in a second step. >The biggest point I want to make, is that the >developers/testers don't have to come up with all the >information. I would be willing to put in the info needed >before a flight, and have it added to the master database on >someones website, so others wouldn't have to put the same >info in every time they go into the same area. Thats the goal.Gaston

v4i guess i know a couple of guys that want to beta test, too :-)