>Scott, >>This is still in development. If all it takes is a >simple checkbox: "Stick exactly to waypoints and altitudes ><40 miles", then that's what will be done. Then you will >have to make sure your waypoints in Approach space are >accurate and flyable. You will also not be able to change >runways unless you request vectors. Well many STARs start much farer away from the facility than 40 miles! So RC should know what the transition is.>>One final note.....the expectation that you will have to >>cross 40NM from your final fix at 10000ft every single >>flight gets really monotonous after a while. I think this >>would be a welcome change in the next version.>>If you don't have pilot autoreply checked, then you can >respond "Unable". This does not relieve the monotonly, but additionally reduces realism.>How it's really done is for Center or APC to say >something like: "Descend and maintan 18,000, turn heading >120 for POWDR TWO Arrival, BASEE transition. Cross POWDR at >or below one two thousand, 270 knots. Traffic is two zero >miles in tail, 10 knots faster. Keep your speed up on >descent." Obviously you can see the problem with that in >RC. It goes back to the above with RC only making you >follow the plan. However, I would be happy to have a >crossing restriction AT a waypoint myself, instead of the >stock 40 miles from the airport. It does get a tad dull, >but then again, since I always know where it's going to be, >I always have it in the plan. I am sorry, but I don't understand what you want to say exectely here. But in the implementation of the proposed suggestion we should get rid of any fix distance from the airport anyway. The 40M rule has no reason to remain (at least if the "STAR" feature is used).Cheers,Gaston

Well,Since all this is ahead of us for a long time (RCv4) I would like to go a different way. I would like to virtually withdraw my initial proposal and work out a new one.If you agree, leet me a month or so, so that I can acchieve the following:- Gather all usefull real features from SID/STAR plates around the world- Select thos which are usefull for overall simming (not only for RC)- Describe a kind of editor for SID STARs- Categorize the features into there dificulty to implement with the current features of RCv3 in mind- Establish a SID/STAR (or better an departure/arrival) model for RCv4This all in PDF. This will be a nearly ready for use document for the developers.

KRENA is the transfer control point from Chicago Center. No one is flying the STAR, they are all on radar vectors. It has nothing to do with 14R/14L, as aircraft crossing KRENA can and will be vectored to any runway. Just like RC, approach control vectoring starts at about 40 miles. During peak periods ORD lands three arrival runways and traffic crosing KRENA could go to any of them.Runway 18/36 is closed and is used mostly as a taxiway or as a parking lot for overflow parking when the gates are full.Larry

---

http://www.jdtllc.com/images/RCbeta.jpg

The term "SID" (Standard Instrument Departure) is no longer used. They are called DP's or Departure Procedures.Larry

---

http://www.jdtllc.com/images/RCbeta.jpg

Larry,Your poor relatives across the pond still call them SID's :-(I cannot comprehend why such a change in nomenclature was not worldwide...Stamatis

Hello Scott, I agree with necessitating the user's input for any STAR. I suggested this to the forum as soon as I installed V3 a few weeks ago. I hope this issue, which I personally wish for, is part of V4. Implementation of a user menu for this purpose would eliminate the huge programming issue that would arise for the company if all STARS, included in the package, were considered to be a requirement. With V3 we do have the option of filing Arrival NOTAMS and it is an acceptable work-around as I enjoy the STAR flying even though they are not always completed in the RW due to on-the-spot ATC directives.Regards

Larry, Stamatis,Or why this change of nomenclature has been done at all ? This is why in many of my posts here you find me saying SID(DP). Sometime I forget it.Cheers,Gaston

Mu humble apoligies Sir! My focus sometimes gets a little narrow. But then wait, I thought my suggestion was accepted across the boundaries of the ICAO world... :-lolLarry

---

http://www.jdtllc.com/images/RCbeta.jpg

i guess DIP was already taken :-lol

I wanted to add some input and additional support to this outstanding post from about two weeks ago.I recently flew the SAM and LAM DP's from EGKK. These procedures contain crossing restrictions of 5000 and 6000 feet at designated points. Soon after departure, in a LNAV/VNAV scenario, I can't seem to avoid getting chewed out for not climbing as instructed to FL 120. In the U.S, there are several STARS which provide for profile descents. For example, the DYLIN Arrival for KEWR consists of profile altitudes. Recently, (real-world stuff) some altitude changes were agreed to in order to better facilitate a more efficient VNAV path descent. The phraseology issued by ZDC ARTCC is "Descend via the DYLIN Arrival". with the altitude profile being:KERNO - AOA FL270DQO - AOA FL200 (following the upcoming change)SOMTO - Between 11000-12000DYLIN - 8000. It would be great to be able fly these in RC3 with vertical 'freedom' in the same way lateral freedom is offered by use of Departure Procedures. In short, just curious if there has been anymore discussion on this subject since this original post.

this is a version 4 enhancement. not something we could just slam into v3the concern i have is that instead of relying on a planner, now i need something else to keep track of all the sid/dp and stars. they would have to be maintained.what percentage of sid/dp and stars do you think have altitude restrictions? 10%? 90%? 50%?out of 5000 rc users, what percentage of users would avail themselves of an additional nav tool to provide these altitude restricted sid/dp and stars? 10%? 90%? 50%?just thinking out loud......

"the concern i have is that instead of relying on a planner, now i need something else to keep track of all the sid/dp and stars. they would have to be maintained"I see your point. Probably the easier way would be for the user to input special altitudes (Proflight 2000 had this) rather than rely on an enormous database."what percentage of sid/dp and stars do you think have altitude restrictions? 10%? 90%? 50%?"Probably at least 75% - or billions !out of 5000 rc users, what percentage of users would avail themselves of an additional nav tool to provide these altitude restricted sid/dp and stars? 10%? 90%? 50%?Good point, no idea.

"what percentage of sid/dp and stars do you think have altitude restrictions? 10%? 90%? 50%?"If you are only referring to altitude crossing restrictions, as opposoed to "Expect to cross at...", which are not restrictions although some RC users seem to mix them up, I would say roughly 25% of all DP/SID's and STAR's. It could be a lot less, but not more.Stamatis

Dear all,First af all, I want of course thank Les Parson for his support of the idea.Let me just clarify some of the topics named in these latest posts to this threat. The idea of my initial post was to make SID(DP)/STAR available in an easy way (developer point of view) and slma it, as jd calls it :-), into RCv3. This idea did not require any database since it was foreseen that the SID and/or STAR was simply part of the planned route. Since then it came up that new features will not make it into RCv3 I did extend the concept to more realism which would then, and only then, require a database which I am currently designing (I hope will continue to find the time for it).Before speaking about th erestrictions, I want first make sure that I know that the restrictions as stated by Les Parson do apply to the named STAR (well the AOA 13000 at STEFE was missing wich is in DYLIN2)Regarding the restrictions and "Excpect to...", I want to throw in that if a plate mentions an expect to, it is correct that this is not a restriction by itself, but it clearly prepares you that usually this will be the altitude or speed you will be instructed to pass the given fix. In the sim-world this could be simulated by a random factor but would usually be simulated as "equal" to a restriction for simplicity.A mistake that is often done by reading the plates is that altitudes that are written without any additional words are interpreted as assigned altitude restrictions (like: cross at...). But no, altitude numbers do only specify minimum altitudes!A word about the percentage of "restricted" SID/STARs. This figure is useless since it does not honor the small percentage of airports that is used by most of the users. The percentage of users who will use the SID(DP)/STARs is like telling the bottle being half full or half empty, meaning that it depends how it is presented:"Dear user, are you using SID/STARs on your flights, you know these procedures which require you to fly one and the same approach each time with given altitude, speeds,...etc" Answer: The hell, NO :-)or"Dear user, we hae included the SID/STAR procedures in our brand new RCV4, not only that this allows realistic approaches, it also makes sure that you remain cleared of sourounding terrain around the airport,...etc" Answer: Oh, great. :-)It is anyway my believe that any feature of the SID/STARs should be user selectable like the realism settings in FS2002 itself. But I will come back on this when my document is ready.Gaston

I see merit to this idea. Granted, most departures and arrivals into congested airspace are controlled through explicit vectors, it is still not unusual for ATC to hand over control to the pilot at some point along the way and ask them to join the departure/arrival transition.This is not unusual..."Citation 55B, turn left heading 330 and direct FOO direct BAR, climb and maintain 16 thousand; join the departure..."or"Citation 55B, continue inbound on the FUBAR5, cross FOO at flight level 180, maintain 280 knots" (at which point ATC would provide vectors into the Class :(.There is an implied communication in both examples that the pilot knows where to go at some point. It would be nice if RC could incorporate this capability (although it shouldn't require it). Every airport is going to handle this situation differently - but at least the flexibility would be there. Certainly, it would add a twist of fun to have RC evaluate your ability to follow a published procedure (regardless of whether or not the entire procedure is used/never-used in a real world scenario).Perhaps someone could coerce Richard Stefan into creating a DP/STAR AIRAC database that RC could drawn upon so that flight planners wouldn't have to manage this complexity. You could simply file a 'requested' DP or STAR with RC directly and the RC engine could decide how to handle it based on traffic volume around the airport (or some such thing).J