OnCourse Software

Andayle wrote: *

Mon May 01, 2017 5:29 pm

Hi vololiberista

I see in your screenshot that you have the actual STAR waypoints as part of the flight plan, this makes sense as you can then assign altitudes, but what happens if the wind changes during flight and you get assigned a different runway than originally planned? Some airports use a completely different set of STARS for different runways.

Generally speaking a STAR is is the lead in to an airport from the direction of of your flight. For example if I am flying from an origin South East of the destination I am therefore likely to fly towards the destination from the South East. So there will likely be STAR that tacks on to the end of my fpl that will be SE of the airport. Let's assume a rwy 27/09. So the STAR, assuming terrain is not significant, may be to the SE of rwy 27. Every time I fly that same fpl route I will always arrive using the same STAR regardless of the wind or weather conditions. So when I arrive at the end of the STAR ATC have the option to vector me to whatever rwy is in use either 09 or 27 or I can use a published procedure and announce my arrival so to speak to the Tower. You should only be given a STAR that starts at the last wypt of your fpl. Yes there are occasions when perhaps a STAR divides as it were so that you may have a different route to a parallel rwy. This is usually taken care of by entering both routes into the FMC. From PF3's point of view that would in effect be a second fpl. The best way round that is to have a fpl for PF3 and another for your navigation system. And in the screenshot example that is indeed the case.
The PF3 fpl stops at RTT. But the inertial navigation continues RTT AB INN LOJV8 LOWI
Here is the second part of the fpl LIPZ to LOWI in operation. You will see that PF3 will step me down in the hold then clear me to the localiser for rwy26 even though the landing rwy is 08 and then I side step the localiser and do the circle to land procedure. This is a difficult test for PF3 and it performs very well. Btw this is the correct approach method used by airlines for the localiser to rwy 26 and circle to land. You will notice that the speeds are much lower than what one sees elsewhere on YT. Because in reality one uses the same speeds as normal but for longer. If you can't do 133-135kts at the final turn you can't land!

Andayle wrote: *

Mon May 01, 2017 5:29 pm

Hi vololiberista

I see in your screenshot that you have the actual STAR waypoints as part of the flight plan, this makes sense as you can then assign altitudes, but what happens if the wind changes during flight and you get assigned a different runway than originally planned? Some airports use a completely different set of STARS for different runways.

You don't include the STAR waypoints that are runway specific in your flightplan that is loaded into PF3.
In Vololiberistas example this is not a problem because after RTT approach procedures to both RWY 08 and 26 are possible.

RALF9636 wrote: *

Mon May 01, 2017 2:46 pm

Nevertheless for the reasons given by Vololiberista I don't think it would be worth the effort to implement that into PF3. Remember that knowing the terrain would not be enough. The whole vectoring calculations would have to be redone because PF3 would have to find reasonable vectors around the terrain. Just imagine vectoring into LOWI. How would a universal algorithm ever be capable to do that reasonably? Seems too complex to me.
And eventually that is what charts and standard procedures are there for - not ATC.

Well, personally I would disagree. If it can be done it should not be ruled out as a future enhancement for PF3. If PF3 is to be marketed as a superior product to MS's default ATC it should be able to. The default ATC will get you into Innsbruck perfectly. It has a built-in custom approach - probably not accurate but it works.

It is very easy for the hardened PF3 user to say "we don't need that" or even "we don't want that" but you really shouldn't forget that we all once came to PF3 looking for an improved experience. Migrating from the default system where you are used to being guided in and having to adapt to software that directs you into the nearest mountain is hardly reassuring on that front.

I know it would involve considerable work to implement, but if it can be done I think it should be done . . . and provided with an "on/off" switch for those who really don't want it. Not necessarily in the near future but certainly not ruled out permanently.

John

johnhinson wrote: *

Mon May 01, 2017 9:56 pm

It is very easy for the hardened PF3 user to say "we don't need that" or even "we don't want that" but you really shouldn't forget that we all once came to PF3 looking for an improved experience.

I must admit that during the early days of PF3 beta I really missed the Easy/hand-holding ATC option that PFE/PF2000 had, so I can understand very well that people are intimidated by PF3. But I quickly learned to rely on the aircraft's navigation systems (and not just use it to confirm that ATC is pointing me in the correct direction), especially since PF3 was very picky about the user reaching the waypoints in these early days.
I'm glad that navigating using (mostly) VOR/DME, (sometimes) ADF, or (when I get lazy) GPS is now really useful, instead of just being an additional/optional action.

So I'm not sure what would be the best for the users of PF3, and where Dave's development time should be invested. Letting do PF3 more than a real ATC would do is probably lower on my list (even if helpful for people) than adding/improving things that increase the realism. On the other hand, if PF3 is more helpful for more people, it gets more users. And even if those users have a different usage profile than me, this is a good thing.

ThomasAH wrote: *

Tue May 02, 2017 7:45 am

So I'm not sure what would be the best for the users of PF3, and where Dave's development time should be invested. Letting do PF3 more than a real ATC would do is probably lower on my list (even if helpful for people) than adding/improving things that increase the realism. On the other hand, if PF3 is more helpful for more people, it gets more users. And even if those users have a different usage profile than me, this is a good thing.

This is the point. It is a swings and roundabouts issue. Being able to vector you around terrain when you are out of sight, below the the terrain, behind the terrain is frankly as "unreal" as it gets. It's not done in the real world because it can't be done! So to implement this feature is catering for those who are really not interested in the real world and just want to tank around the sky and expect ATC to obey their every whim without care and attention. They are not all that interested in real world practices and some will cut you down in a trice on avsim if you point out their mistakes! They don't want to have a taste of the responsibility that real worlds pilots have to have.

There are a number of flight planning programmes out there too. That people have spent good money on and swear by. What do all those programmes say? "Not to be used for real world flight planning". Why because what they produce is largely innacurate. The algorithms they use are very basic. They don't choose SIDs and STARs very well and are more often wrong than right. I have often said the real world flight planning is a black art and it is. Of course computer programmes are used in the production of many flight plans. But they are an aid only. The dispatcher has to adjust and correct and sometimes override the results often ending up doing the whole thing manually before a fpl can be good enough to be accepted by ATC. This is because of the many factors that have to be taken into account. And a sole pilot? He/she has to do the whole show by him/herself and get it right too.

PF3 allows the user to make a wide range of choices. Enabling the user to create a very accurate fpl if they so wish. So in this respect it is in many ways closer to real world practice than the other offerings. A spin off of this is that the user may learn something of how real world fpls are created and how ATC responds.
What is wrong with an ATC programme that aims to be as accurate and as close as possible to real world practice? Nothing! Also there is nothing wrong with the user having to do a little extra stuff for and by themselves and in the process learn. And thereby appreciate more what happens in real life and enjoy their new skill.

At the end of the day it is solely up to the developer to decide in what direction he wants his programme to go. Dave is one of the most experienced in this field and whatever he produces is of optimal quality.

For those that are interested in how real fpls are made search for CAP694. It's too big to attach to this forum unfortunately.

vololiberista wrote: *

Tue May 02, 2017 9:37 am

This is the point. It is a swings and roundabouts issue. Being able to vector you around terrain when you are out of sight, below the the terrain, behind the terrain is frankly as "unreal" as it gets.

. . . as is being instructed to fly into the side of a mountain. Real-world controllers would soon be re-classified as ex-controllers if they did that.

John

johnhinson wrote: *

Tue May 02, 2017 4:45 pm

vololiberista wrote: *

Tue May 02, 2017 9:37 am

This is the point. It is a swings and roundabouts issue. Being able to vector you around terrain when you are out of sight, below the the terrain, behind the terrain is frankly as "unreal" as it gets.

. . . as is being instructed to fly into the side of a mountain. Real-world controllers would soon be re-classified as ex-controllers if they did that.

John

You should always activate the STAR option when you fly into an airport in mountaneous terrain. You won't be vectored into a mountain and the controllers keep their jobs.

RALF9636 wrote: *

Tue May 02, 2017 4:55 pm

You should always activate the STAR option when you fly into an airport in mountaneous terrain. You won't be vectored into a mountain and the controllers keep their jobs.

Hmm, what about a list (or algorithm?) to mark certain airports as always requiring a STAR, so PF3 can throw a warning when loading the flight plan and not having the STAR feature enabled?

ThomasAH wrote: *

Tue May 02, 2017 5:28 pm

RALF9636 wrote: *

Tue May 02, 2017 4:55 pm

You should always activate the STAR option when you fly into an airport in mountaneous terrain. You won't be vectored into a mountain and the controllers keep their jobs.

Hmm, what about a list (or algorithm?) to mark certain airports as always requiring a STAR, so PF3 can throw a warning when loading the flight plan and not having the STAR feature enabled?

With Randomizer 3 it will be possible to have a preset for each airport which includes a lot of PF3 settings. These settings can be randomized (thus the name) but also be fixed (by setting the probability to 0 or 100). For example it will be possible to automatically always have the STAR option activated for a specific airport (you can set any probability you like for the STAR option to be activated - so choose 100 % for an airport in mountaineous terrain).

You can already do something with Randomizer 2

viewforum.php?f=10

But if you are not into it yet, don't look closer at Randomizer 2 now. Randomizer 3 will be released very shortly. It offers a lot more options and is much more user-friendly. I think it will be a great enhancement for PF3.

johnhinson wrote: *

Tue May 02, 2017 4:45 pm

vololiberista wrote: *

Tue May 02, 2017 9:37 am

This is the point. It is a swings and roundabouts issue. Being able to vector you around terrain when you are out of sight, below the the terrain, behind the terrain is frankly as "unreal" as it gets.

. . . as is being instructed to fly into the side of a mountain. Real-world controllers would soon be re-classified as ex-controllers if they did that.

John

Exactly the point. So real world controllers don't. They let you the pilot have that privilege! I think this vectoring around terrain issue is more of a game cheat really. To not descend below MSA until the FAF is the real practice and PF3 already has that option.