FSX error overlay airport

[GHD]

Hi Paul,

I was commenting on my modification to Roby's file. The hold-short nodes are well within range of the runway:



Using this file, on taxi-in, the AI stop at a H-S but do not decalare "Clear of the runway" and eventually disappear.

Using my simplified version, they stop at the H-S, decalare "Clear" then taxi to parking.

 

[BASys]

Hi Folks

George -
Cheers.

EDIT -
Amended my query, as initially I'd misinterpreted your post.

In case I've misunderstood -
Are all 3 screenies are your modified versions ?



Would I be correct in thinking that -

Hold-shorts are now measured relative to the runway's visual ?

Rather than as I'd thought previously,
measured relative to the true runway, (black line) ?



For your top screenie version -

Did all AI fail, or any park successfully ?

If numbering parking locations, left to right,
I'd only have expected that -
- Potentially might work for spots 13-16, (the 5 south-easterly parking spots).
- Potentially might work for spots 1-3, and 9-11, (landing direction dependently).
- Likely fail for 4-7, possibly 8, as their hold-short overlaps both the runway's black-line and parking spots,



My apologies for any confusion,
my AI experience is primarily FS2002 derived.



Many thanks
ATB
Paul

 

[robystar]

Well, it is turning into a habit of having to say once again "you beat me to it".
In the meantime, forgetting for a moment why my AFCAD does not work and yours does, it is definitely strange that the AI does not stop at its (George's) parking spot. I have mine deleted from FSX so it should no longer be interfering with other AFCADS.
On second thoughts, the other strange thing is that it should not matter whether George's AFCAD is in a slightly different location than mine is, as, opening George's ADE, it should show the AI right in the middle of that parking spot anyhow.
I think (but just guessing) that the problem either boils down to
- a quirk in the default OAKB;
- a (as yet unidentified) quirk in the 1AKB;
- a peculiarity of the AI heli but I do not think so, or
- some addon that influences the area.
My AI flightplans for the AI Apache are VFR and the runway pattern altitude is 500m alt and left. IFR makes FSX go berserk! Traffic file compiled with AIFPv2, by the way.

PS I have overlays on carriers where hold shorts, runways and all kinds of stuff overlap and never ever gave this kind of trouble.

 

[GHD]

I'd have only expected that
potentially his 5 south-easterly parking spots might work,
and all those whose hold-shorts overlap, both runway and parking spots,
to all fail.

Don't forget that the "rings" are only a device in ADE to see whether the H-S is within the correct distance from the runway.

Further, on taxi-in, the H-S can be miles from the runway, it is important only that an AI passes through an H-S before parking so that the AI engine will know that the parking spot is occupied.

The distance of an H-S from the runway is used only on taxi-out to allow the transition from taxi-out to take-off 1 then take-off 2. If it is greater than the maximum disstance, the AI aircraft will stall at the H-S.

 

[BASys]

Hi Folks

George -
My apologies for any confusion,
my AI experience is primarily FS2002 derived.

Don't forget that the "rings" are only a device in ADE
to see whether the H-S is within the correct distance from the runway

Yep, understood.

Is there any dependency
on either aircraft length, or wingspan,
versus the hold-short radius actually used by FS ?

Further, on taxi-in,
the H-S can be miles from the runway,

Is that only when you use a secondary hold-short,
after having first passed through the true hold-short, (within runway distance) ?



ISTR, and probably wrongly, (or it was FS2002 specific) -

I'd thought hold-shorts
were also used by AI on runway exit,
as the location from where AI called ground.

ISTR previously when developing the ODG/EGPD traffic,
having had a failure on runway exit,
due to a missing hold-short.



Many thanks
ATB
Paul

 

[robystar]

Hi,

It is 10 PM and I need a clear head (to make tails out of it) and to continue working on this .
I am going to call it a day.
Thanks for your help, I have a lot to think about and check out.

Night,

Roby

 

[robystar]

Solved

Hi,

Another thing that struck me as odd when comparing George's 1AKB and mine was that when going to list---> coms, in mine there were no OAKB frequencies shown (not even in grey) whereas there were in George's.
As nothing seemed to remedy the situation and the AI kept stopping at the hold short and when changing from Multicom to Tower frequences, FS was back with a fatal error again, I deleted my 1AKB, quickly made a new 1AKB airport and now everything works fine.
I think what happened was that, being inclined to be lazy, when making the earlier overlay, I used OAKB, changed the ARP, changed the name and ICAO, deleted everything of OAKB, and added the new airport layout. I must have deleted something then that was necessary for the overlay.

 

[robystar]

solved but maybe some ADE bug

Hi,

Further to the above, I found that I probably did not make a mistake after all.
It is just that when you have FSX running and an airport opened in ADE (in my case OAKB), saved that last one and then go to new airport and start making it (in my case 1AKB) filling in the properties of the new airport, ADE will tell you: the airport has not been saved. Do you want to save it. And then you click yes and continue with the new airport.
However, something is deleted from the new airport then, because afterwards the COM list does not include OAKB any longer and FSX crashes once more when AI try to land on that new airport.
I had to delete all instances of that new airport, start ADE a new without loading any airport and select new airport straight away. Only that way, it seems, can you make a new one that works.
I had to rebuild my 1AKB twice and ran into the same problem when trying to add 2AKB.
As the aforegoing includes some assumptions based on my own experience, it would be nice if somebody could come up with some "corroborating evidence" or with another explanation for this phenomenon.

PS Perhaps John (when tired of sitting at the beach of Pozo Negro - I am only guessing and envisioning him being there of course - and enjoying the beauty and tranquility of this incredible place), might enlighten me?

 

[GHD]

I don't think the comms are the problem. My version does not have OAKB in the comms list.

BTW. I created 1AKB from OAKB by deleting everything in ADE, added the new runway, parking and taxiways. I then compiled it.

BUT, I then edited the xml to delete everything not associated with my new version, including all of the exclusion rectangles, taxiway designators and anything else I could see. I then reloaded from the xml.

 

[robystar]

overlay disabling AI

Hi,

Well, after having tried several times to add a second overlay (2AKB), it turns out that the second one disables the first one.
I now have a working AP plus 1 overlay, but as soon as I make a second overlay it disables the working of the first overlay (Sorry if this seems incomprehensible but I try my best to make myself understood).
I do not know whether this phenomenon is due to the proximity of the ARP's or something else but I doubt it because I have other airports with two overlays even closer together and they work fine.
Another thing that is different between 1AKB and the other airport overlays (OAT1) is that although the traffic explorer indicates Nick Black's AI AH64 has gone to sleep after parking, the cockpit doors are still open, the guns and front instruments are still moving and the pilots are still inside, whereas this is not the case in my other overlay airports where upon parking the cockpit doors open and close again, pilots disappear and all movement stops.
So who knows or has at least an idea of what the matter can be?

 

[jvile]

Is there any dependency
on either aircraft length, or wingspan,
versus the hold-short radius actually used by FS ?

Paul

There are some differences in how hold shorts work in FS9 and FSX. In FSX for departing aircraft the center of the HS distance to the side of the runway texture is a varible value.

1. On a 90 degree taxiway entrance to runway the max distance is 300 ft.
2. On a 45 degree taxiway entrance to runway the max distance is over 600 ft.

To illustrate, the first picture is a stock FS9 EGCC runway 24L. The HS had to be within about 235 ft of the runway texture.



In FSX the distance was recalculated so the entrance HS could be further away allowing departing planes to stay out of the way of the arrivals. The stock FSX EGCC runway 24L entrance HS is over 600 ft.



These entrance HS are important in both FS9 and FSX but we can move the FSX HS further away (based on entrance angle) then what we could do in FS9.

Is that only when you use a secondary hold-short,
after having first passed through the true hold-short, (within runway distance) ?

The exit taxiway HS all along the runway can be any distance from the runway side texture as George points out as long as it is before any taxiway intersection. Intersection meaning there are now more then 2 paths to a parking spot. If you wait and place the HS node pass the intersection then each path must have a HS.

I'd thought hold-shorts
were also used by AI on runway exit,
as the location from where AI called ground.

HS are used for AI/User at both entrance to runway and exit from runway. Your quote above is correct with one important note.

When a User/AI Plane leaves the runway then ATC sees the main gear contact points roll off the side texture of the runway. This is when ATC Tower tells the plane to contact ground and unlocks the runway for the next departure or arrival. The AI plane will come to a stop pass the hold short node and then contact ground for taxi instructions regardless of how far the exit HS is from the runway (minus any intersections).

In FS9 the model radius was used to instruct where the airplane stopped (nose wheel) before the entrance HS for the departing plane. The model radius was also used to tell the arrival plane to stop (nose wheel) pass the exit HS node and then contact ground.

I have not studied FSX to see if it is still the model radius or the wingspan value per the HS node. We do know that half the wingspan is used for the parking spot size.

 

[BASys]

Cheers Jim.

Much appreciated.

ATB
Paul

 

[robystar]

Cause

Hi,

This thing got on my nerves so I continued experimenting.
It looks like the runway of the main airport has an invisible zone on both sides of it (not the runway taxi line) in which the ground frequency is the one of the main airport.
In the case of the default OAKB, the runway width was 50 m.
I noticed that when slewing the aircraft towards the overlay 1AKB, the aircraft changed ground frequency when 100m distant from the OAKB runway edge. Changing the runway width to 30 m and it is still 100 m.
So apparently this runway has a 100 m zone on both sides that can cause a fatal error or a malfunctioning of the AI when a Hold Short node of an overlay airport is placed within it.
Which runway (the one of the overlay or the original one) takes precedence and when, is still a mystery to me as neither the width nor the length nor the type (concrete, dirt) seems to matter.
I include an ADE layout of the 1AKB with some extra info.
Some time ago I made two overlays for another airport that work well and seem to have different zones. How come that one works, escapes me.
I also enclose a picture for it as well.

 

[robystar]

Hi,

Further to the aforementioned, it has now finally become clear to me that, in order for AI to work properly on overlay airports, the HS of each one should be within the range of the ground frequency of that AP.
If there is a HS within that range belonging to another AP, then apparently the problem comes up.
The only way I have come up with to find out how to determine the range of the ground frequency of each AP is to slew the aircraft back and forth and watch ATC tell me to tune to one or the other frequency.
Any suggestions regarding another way to determine this range or why this range is as it is, would be appreciated.
The above explains why George's overlay worked and mine did not.

Roby

 

[GHD]

I'm not sure that is true Roby.

I have 12 overlays working, all of them have the same comms frequency. It is not very pretty on landing where there is much ghosting, but they all eventually return to their correct parking spots.

Taxi-out:







Taxi-in:







All announced "Clear of the runway":

 

[robystar]

Hi,

And thanks for bothering, George.
However, the main difference between your dozen overlays and my three is that yours all have the same frequency.
That may indeed be another solution.
With different frequencies though, the only way to avoid a crash is to have the hold shorts within the range of the AP frequency they belong to.
Unless, of course, you find otherwise .

 

[robystar]

Hi,

No luck so far with same frequencies for overlay airports.
Overlays used to work before without any problem but now that I have compiled them again with the new version of ADE they do not work any longer which makes it look as if ADE has altered something and I cannot figure out what that 'something' could be.
After meticulously placing the HS's in such a way that they lie within the perimeter of the different AP frequencies of the runways, I have no more crashes, they land correctly and taxi to their assigned parking spot, but ... take off is now a problem, due to what I haven't the faintest.
Fact is that once they have parked and me waiting for them to taxi for take off again, they do taxi to their runway, Hold short, are cleared for take off, take off and stay in their take off 2 state and never get cleared off the runway nor do they climb to more than a couple of feet above the ground.
If I restart FSX and set time just prior to take off, they do take off normally.
Does anyone have an explanation for that?
Have been searching for the keyword "takeoff2" but there seems to be no topic or thread dealing with it. Have also been searching for everything JV wrote but no indication there either.
Fyi, wing span is supposed to be the criterium for parking spots etc. in FSX as far as I know. All my paths, runway taxilines and parking spots are set to meet the minimum width.

 

[jvile]

What width runway are you using for the planes that stay at takeoff 2 state?


See my post at the following link for takeoff state problems.

http://www.fsdeveloper.com/forum/showthread.php?t=8731&highlight=state

 

[robystar]

Hi,

Runway 0.3 m wide 214 m long.
Runway taxi line and paths 9 m wide.
Parkings 9 m.
Aircraft: MAIW AH64D Apache (claimed to be optimized for landing on 500ft runways).
Odd thing:
- setting FSX time 15 min. prior to landing, they land, they take off again after a 20 min. interval as per the flightplan and stay in takeoff 2 stage.
- setting FSX time 10 -15 min. prior to take off and they take off normally.
Changing length and/or width of runway/ rwy taxi line does not influence outcome.
Include my two overlays (1AKN and 3AKN)

 

[robystar]

Oh,

And another strange thing:
Setting FSX time a bit after starting time and all aircraft take off one after the other and normally.
But then, when setting FSX time back to before arrival of the planes (heli's), I get a :
Runtime error!
Program: C:\Program...
R6025
- pure virtual function call