1 hour ago, Wolkenschreck said:

I see your problem and agree that the vacating time is sometimes not optimal. However, the current method initiates the take off roll. while landing traffic is still decelerating with spoilers and reversers deployed. Arriving traffic should be at least attempting to vacate before any takeoff commences. 
Having the tail passed the hold short line would be the most realistic option to define if a landing aircraft has vacated. But maybe could the earliest sign of deviation from the runway heading be used as an earlier trigger to determine if the arriving traffic is about to vacate? Would not be totally realistic but good enough for the sim.

For the takeoff clearance, I found the following in section 3-9-6 Same Runway Separation:
Preceding traffic needs to be airborne and at least 6,000 ft away. 
https://www.faa.gov/air_traffic/publications/atpubs/atc_html/chap3_section_9.html#FIG_3_9_2

I agree getting off runway tarmac should be the best check for runway vacation for both arriving and departing AI, but sometimes AI making a U turn also trigger the same which would also need addressing.

That criteria is true for smaller airports or in normal density operations yes, but at larger busier airports it is now not uncommon to have next takeoffs being cleared earlier or on lift off, at EGLL for instance. The option may be specifically enable for busy airports.

 

@him225 and @Wolkenschreck, both points are valid. I will include both options and the user can pick. Thanks

Could anyone test KJFK 13L approaches? I find that many landing airplanes dont hit the runway correctly. Maybe only one or two out of ten landings are close to the center line. The other landing approaches are set-off to the right side by approx. 50-100+ feets and then keep floating some time at aprox. 50 ft AGL before TO/GA.

Perhaps this is not a ATCAPI problem only, but rather an airport file (ADE) issue. BTW, Im using DDs KJFK. Perhaps it is better with FSDTs KJFK.

Edited December 11, 20205 yr by Nemo

4 minutes ago, Nemo said:

Could anyone test KJFK 13L approaches? I find that many landing airplanes dont hit the runway correctly. Maybe only one or two out of ten landings are close to the center line. The other landing approaches are set-off to the right side by approx. 50-100+ feets and then keep floating some time at aprox. 50 ft AGL before TO/GA.

Perhaps this is not a ATCAPI problem only, but rather an airport file (ADE) issue. BTW, Im using DDs KJFK. Perhaps it is better to use FSDTs KJFK.

I don't own those 2 airports. But what I can I say is that the addon, does not interfere with the landing itself and the flare. do you experience this with other airports? Thanks

Edited December 11, 20205 yr by fs1

1 hour ago, fs1 said:

I don't own those 2 airports. But what I can I say is that the addon, does not interfere with the landing itself and the flare. do you experience this with other airports? Thanks

I've only tested at EDDF (all good) and EDDM (all good). It's just KJFK, but the 13L approach is a special one per se. Maybe someone else has FSDT KJFK to test there.

Will this add-on one day be able to deal with wind changes, or must we anticipate changes in the winds and edit the XML each time?

Pete

 

Hi @Pete Dowson, currently you need to edit the XML. Next build, there will be a possibility to be simvar driven. Thanks

Edited December 11, 20205 yr by fs1

Well, as long as P3D does not take into account the ADE files with the open/close runways I don’t think it is a good idea to let P3D decide which runways are active or not ..... did I miss something here ? At least we should keep the possibility to force departing/arrival runways as it is the case today. 

2 minutes ago, pmemery said:

Well, as long as P3D does not take into account the ADE files with the open/close runways I don’t think it is a good idea to let P3D decide which runways are active or not ..... did I miss something here ? At least we should keep the possibility to force departing/arrival runways as it is the case today. 

Yes, the possibility of assigning will remain as it is. I will include some conditions that will be available, the user will decide. Thanks for the feedback

Edited December 11, 20205 yr by fs1

2 hours ago, fs1 said:

Next build, there will be a possibility to be simvar driven.

Good. I'll probably check it out then.

1 hour ago, pmemery said:

Well, as long as P3D does not take into account the ADE files with the open/close runways I don’t think it is a good idea to let P3D decide which runways are active or not ..... did I miss something here ? At least we should keep the possibility to force departing/arrival runways as it is the case today. 

I think you missed something, yes. I want there still to be probabilities for each runway, just not with the current restriction that you if you set them for opposing runways you'll get conflicts. At least, that's what i understood from earlier posts, which is why I'm not tried using the program yet. I don't like to have to decide what runways I'm going to be using in advance. I leave that to my ATC program (Pilot2ATC). I just want the AI Traffic to fall in line.

Pete

 

Edited December 11, 20205 yr by Pete Dowson

hi Pete got your point. What I just would like to avoid is P3D to decide to open a runway end that is closed/never used in reality. 

1 hour ago, pmemery said:

hi Pete got your point. What I just would like to avoid is P3D to decide to open a runway end that is closed/never used in reality. 

Yes, agreed. But I thought L-M fixed the problem with runways not being closed both ends still being used both ends? Wasn't that fixed in one of the P3D4 versions?

Pete

 

Yes, LM fixed it with 4.5 HF2: 

 * Fixed issue where airport runway secondary landing attributes would be ignored and processed as primary landing attributes.

BTW for the time being you can delete the airport section in the config.xml. Doing so you will still get the features like rolling takeoff/line up and wait, while the runway assignment is still handled by the sim/ActiveSky/AFCAD.
_________________________________________________________________________________________________________________

And I too agree with pmemery that runway assignments should be selectable by the user. Wind dependency should only be an optional selection. Many airports like EDDF Frankfurt have a preferred configuration (here RW 25s), which they keep open even with a tailwind component up to 5 KT. Wind dependency would prevent such configurations that are contradictory do the default sim behavior. Also, conflicting configurations are useful. KLAX for example operates under certain circumstances with arrivals from the ocean (RW 6s/7s), while departures go to the ocean.(RW 24s/25s). Lukla in Nepal would be a similar case. 

24 minutes ago, Wolkenschreck said:

. Many airports like EDDF Frankfurt have a preferred configuration (here RW 25s), which they keep open even with a tailwind component up to 5 KT. Wind dependency would prevent such configurations that are contradictory do the default sim behavior

Yes, that's reasonable. So maybe the wind facility should have a parameter allowing that to be specified. i.e a tailwind max parameter. I'd still rather it dealt with the wind direction in the same way as I'd expect ATC to deal with it.

The other change in runway preference, which would add to realism at somewhere like EGLL (for one) is a time of day based runway preference. EGLL swaps Left and Right Landing / Takeoff usage midday (I think).

Pete

 

 

21 minutes ago, Pete Dowson said:

The other change in runway preference, which would add to realism at somewhere like EGLL (for one) is a time of day based runway preference. EGLL swaps Left and Right Landing / Takeoff usage midday (I think).

Another example is LAX and its night time operations.

Then IIRC landing are RWY 6s or 7s but takeoff still RWY 25s or 24s.

Daylight 6/7 operations are very rare (strong Santa Ana winds?). Don't know about the tailwind components for switching to the 6/7s.