43 minutes ago, IanHarrison said:

Ray

"I’ll be delighted to see an end to those multiple BGLs where you have to select the correct one for the current weather. Then that stays in place until the next time when if the winds are significantly different requires you to swap them again. "

I have never seen that in my 25+ years of simming.

Can you give an (now defunct) example.

I see I've been beaten to it but LEMD is a classic example as @ZKOKQ mentions. There is a utility program provided with the package that lets you choose which runways will be active based on current winds.

Edited September 28, 20196 yr by Ray Proudfoot

 

 

1 hour ago, Ray Proudfoot said:

I see I've been beaten to it but LEMD is a classic example as @ZKOKQ mentions. There is a utility program provided with the package that lets you choose which runways will be active based on current winds.

Thanks.

As I don't have any of the ones mentioned, that would explain it.

14 hours ago, gsand said:

Hi Simbol,

I do a lot of ADE's and am keenly interested in this one. Looked at LM's site but can't find any documentation for this. So, couple of questions:

- Does this end the adding of phantom runways around the compass to get crosswind runways to work?

- If an airport has 2 long runways at say 09R (10,200ft) and 09L (6000ft) and a 3000ft 05/23 set a little south so that it does cross 09R/27L but just at the 27L end and 05 is enabled will P3D recognize the difference in length and not try to land commercial on the short runway but do land GA on 05? (Yes, this is how my home field KMLB is. 05/23 is the preferred GA runway at MLB for south side and 09L/27R for the north).

https://aeronav.faa.gov/d-tpp/1910/00252ad.pdf#nameddest=(MLB)

Thanks,

Gerald

The fix corrects a long standing problem regarding the secondaryLanding attribute of the <Runway> XML element. This attribute was not being acknowledged at run-time. Instead, the primaryLanding attribute was being acknowledged for both primary and secondary ends of the runway.

This means that secondaryLanding had no effect and primaryLanding would open or close both ends of the runway for landing depending on it's value.

Similar behavior used to happen with take off.

You will not find documentation because HF2 just corrected the problem, things should work now as intended originally in acordance with the SDK.

I suggest you configure your airport as the runway operations are intended and do some tests.

Regards, 

Simbol

17 hours ago, edemeijer said:

I did some testing with this today and I found for the UI aircraft all correct runways are listed. For LEMD I tried take-off 36L and 36R and landing 32L and 32L and vice versa (landing 18L and 18 R, take-off 14L and 14 R), but the first 10 minutes still some occasional landings on the wrong side (might be due to ActiveSky) and some how also some landings on 36R??? But not much, so I see an improvement but in the first minutes still some strange behaviour...

Are crosswind runways still needed?

Wait when P3D starts your aircraft after the loading screen a couple minutes to let weather update. Go up to the time and date menu and change the time and now the AI should be loading in and flying to the correct runways.

40 minutes ago, simbol said:

I suggest you configure your airport as the runway operations are intended and do some tests.

Regards, 

Simbol

Thanks, I will today. Appreciate the info.

MPTO is another airport that will benefit from the runway assignment fix.

Unless I’m misunderstanding the depth of this fix, I don’t think it will remove the need for multiple AFCADs at more complex airport with non-parallel runways in simultaneous use changing based on wind, ie EHAM?

On 9/27/2019 at 2:05 AM, Nickbe said:

We are currently testing a new build EZCA v3 which should solve the problem with the autostart (simconnect issue) still appears for some users, and immediately do work with the new version ActiveSky and the latest hotfix for P3D4.5 compatibility. In addition, we are working on compatibility EZCA version 2 with Activesky and the hotfix for P3D. The release is planned in the coming days.

Thanks! I'm looking forward to a v2 update.

2 hours ago, regis9 said:

Unless I’m misunderstanding the depth of this fix, I don’t think it will remove the need for multiple AFCADs at more complex airport with non-parallel runways in simultaneous use changing based on wind, ie EHAM?

I've never noticed a problem at EHAM? I thought I only had the one AFD BGL.

The one that's always bugged me is EHAM, where the South and North runways conflict. This change certainly fixes that with one AFD BGL now.

Pete

 

I'm running current wx at EGCC so landings are from the east onto 23R. They're fine and nothing is using 23L. But all departures are from 23R. Not one in 12 or so has taxied to 23L. How do you encourage P3D to use both runways?

On an unrelated note the Emirates A380 was inbound but was too high. Ai Controller was running and directed it towards POL (a hold for northerly arrivals). I decided to shutdown Ai Controller and thought the Emirates would then turn south and vector for a 23R landing. But it continued to head north so I shut down P3D. I won't be using Ai Controller any more.

When inbounds are too high and have to go-around they are not performing a standard procedure with a 90 degree turn and another for downwind followed by another for base and then a final turn for approach and landing. They're up to 30 miles away before turning back towards the airport. That could do with being sorted out.

Edited September 28, 20196 yr by Ray Proudfoot

Just managed to grab this screenshot as I was in avatar mode watching takeoffs. I've posted on LM forum but I wonder if anyone else is seeing this. Shouldn't basic P3D Ai handling prevent this sort of thing? EGCC watching 23R.

That taxiway does not have a connection with the runway, Ray. That's because AI planes would be holding short and piling up in the apron areas @ Manchester as they waited for planes on final approach to land and vacate runway 23R. The ATC environment is simply not clever enough at the moment to handle stuff like this. What we need is a more robust ATC that can determine the time required for a plane that is on final approach to land, and get some of the waiting planes to cross the runway at appropriate times. At the monent, AI planes stop and wait as soon as the plane on final approach has been cleared to land.

Someone mentioned that the FSX ATC engine was not designed for high density AI environments, and the situation described above is one of the consequences.

Edited September 28, 20196 yr by Christopher Low

14 minutes ago, Ray Proudfoot said:

Just managed to grab this screenshot as I was in avatar mode watching takeoffs.

Wow. Planespotting in P3D! Is everything moving to the virtual world!

Thanks, Ray. That gave me a good laugh.

LOL

Randy

4 minutes ago, Christopher Low said:

That taxiway does not have a connection with the runway, Ray. That's because AI planes would be holding short and piling up in the apron areas @ Manchester as they waited for planes on final approach to land and vacate runway 23R. The ATC environment is simply not clever enough at the moment to handle stuff like this. What we need is a more robust ATC that can determine the time required for a plane that is on final approach to land, and get some of the waiting planes to cross the runway at appropriate times. At the monent, AI planes stop and wait as soon as the plane on final approach has been cleared to land.

Someone mentioned that the FSX ATC engine was not designed for high density AI environments, and the situation described above is one of the consequences.

Thanks Christopher. I suspect it may have happened because that Tui turned left after landing onto the first taxiway for 23L. It then continued and turned first right back towards 23R crossing as the other aircraft was departing. As there is no holding point it just continued onto the runway ignoring the departing aircraft.

But why would it turn left when logically it should turn right towards its gate? Looking at the AFD I can't see any reason why it would turn left.

I have never seen an AI plane turn left after landing on 23R, so that is a bit of a mystery. To be honest, when I saw your screenshot, the only conclusion I came to was that the TUI plane must have landed on 23L!

Edited September 28, 20196 yr by Christopher Low

On a side note.....my cousin was at Manchester a couple of weeks ago, and he told me that two planes landed on 23L, even though 23R was fully operational