Amount of AI planes in FSUIPC

[Garfield_X]

Hi

At the moment FSUIPC can handle 96 AI planes on the ground and in the air.

What will happen when an airport has more AI planes?

Will it always shows the active ones?

When the ground list is full and a plane is landing and switch from air to ground, will it be visible in the ground list?

Peter

[Pete Dowson]

At the moment FSUIPC can handle 96 AI planes on the ground and in the air. What will happen when an airport has more AI planes?

Will it always shows the active ones?

No. At present the criteria is purely distance from the user aircraft. The 96 nearest the user aircraft are retained. For most purposes I think this is best -- even if the aircraft is merely parked "sleeping" and not assigned its flight plan yet.

It may be an improvement to also take into account the status of the ground aircraft, but I'm not sure. It's nice to show the occupied gates in programs like Trafficboard, even for sleeping aircraft. If I were to include the first 96 active aircraft, and only sleeping aircraft when slots are still available, some of the programs out there would lose some of their interest and usefulness.

However, I'm open to other arguments on this if you have any.

When the ground list is full and a plane is landing and switch from air to ground, will it be visible in the ground list?

Yes, if it is one of the 96 nearest to the user aircraft.

Regards,

Pete

[msagner]

Is it conceivable to make this an option, so an application can specify which planes are to be included?

If this option defaults to the current mode, this would be compatible with existing software.

[Pete Dowson]

Is it conceivable to make this an option, so an application can specify which planes are to be included?

Not easily. None of the TCAS table options are currently application-settable. And exactly what algorithm would you suggest be implemented? Obviously "active" aircraft ignoring distance can't be the option -- this would include aircraft in nearby airports too. So some balance,is needed. But what?

What exactly is the application that needs this change? I'd like to understand the reasons.

Regards,

Pete

[Garfield_X]

Hi

So i understand that (and i'm only talking about the AC's on the ground) one can miss an aircraft on an airport if there are more than 96 AI planes on that airport.

Will such a plane show up if it comes active?

I ask this because people use AITA (the program i've written and which is being updated soon AITA2004.pvdveen.net) mainly for checking their flightplans/AFCAD . (departure and arrival time etc)

But at an busy airport (with more than 96 AC's at the ground) they can miss some flights in this case.

It would be nice that FSUIPC list more than 96 AC's or always list the active AC's and when an AC becomes active but not in the list will show up in the list, replacing a sleeping AC. In such a case AITA can log this plane because it looks only at active planes.

Because in this case (ground) logging find place on a specific airport the distance to the user AC is always less then 2 or 3 nm. (At the airports i've checked i've never seen planes which ar further away than 1 nm)

(I already thought that the ground list lists only AC's near the user plane.)

Peter

[Pete Dowson]

So i understand that (and i'm only talking about the AC's on the ground) one can miss an aircraft on an airport if there are more than 96 AI planes on that airport.

Will such a plane show up if it comes active?

Yes, if it is one of the 96 nearest to the user aircraft. No otherwise.

This is the same criteria as used in the air, except there is also a (documented) low distance limit on ground aircraft.

But at an busy airport (with more than 96 AC's at the ground) they can miss some flights in this case.

Where is the user aircraft when this program of yours is being used? On the ground at the airport, or in the air near it? Because that makes much more of a difference. The range is 3 nm only if the user aircraft is on the ground. This covers the size of most airports, but does it cover all? If the user aircraft is in the air the range is 6 nm. This is clearly documented.

It would be nice that FSUIPC list more than 96 AC's or always list the active AC's and when an AC becomes active but not in the list will show up in the list, replacing a sleeping AC. In such a case AITA can log this plane because it looks only at active planes.

That's all very well, but for other applications is it just as important to see what aircraft are parked in which gates and so on, especially as these are approached by a taxiing user aircraft.

The most I think I could or should do is treat "sleeping" aircraft as further away than active ones -- so effectively the furthest among them would be replaced by further active ones (within the 3 or 6 nm) once the table becomes full. How would that be? I think, in general, that would pretty much meet both criteria.

Originally of course the idea was only to provide TCAS information -- i.e. data for TCAS gauges, so only airborne craft. The ground traffic addition was a little "nicety" added for fun. It seems nowadays that the tail is wagging the dog! :wink:

Regards

Pete

[rana]

The most I think I could or should do is treat "sleeping" aircraft as further away than active ones -- so effectively the furthest among them would be replaced by further active ones (within the 3 or 6 nm) once the table becomes full. How would that be? I think, in general, that would pretty much meet both criteria.

Hi Pete,

when/if you implement this change, I hope it would be triggerable from the code itself, rather than the ini file. As you said, different program uses these datas differently - for my freeware movingmap, I am more interested in aircraft near the user (both ground and air)... and it would be a bit vexing for the user to not see an ground aircraft next to him/her on the map (as it is sleeping) because it was replaced by an active aircraft 6nm away.

[Pete Dowson]

when/if you implement this change, I hope it would be triggerable from the code itself, rather than the ini file. As you said, different program uses these datas differently - for my freeware movingmap, I am more interested in aircraft near the user (both ground and air)... and it would be a bit vexing for the user to not see an ground aircraft next to him/her on the map (as it is sleeping) because it was replaced by an active aircraft 6nm away.

I appreciate that. I'll try to please everyone if I can. It isn't easy. I for one have never seen the ground table fill up completely, even though I use Ultimate Traffic, one of the heaviest traffic additions. The airborne table often fills though.

Regards,

Pete

[Pete Dowson]

How about something like this?

TCAS Table option settings

The 8 bytes at offsets E068 and F068 independently contain the current option settings for Ground (E068) and Airborne (F068) aircraft. They are used as follows:

Byte 0 Range in nm (0 = unlimited). For ground, this is the range when the user aircraft is airborne. Defaults are 40nm (airborne), 6nm (Ground)

Byte 1 Range in nm (0 = unlimited) for Ground aircraft only, when the User aircraft is also on the ground. Default is 3 nm.

Byte 2 The TCASid option setting, thus:

. 0 = Tail number

. 1 = Airline + Flight number

. 2 = Type

. 3 = Title

. 4 = Type + last 3 digits or tail number

. 5 = Model

Byte 3 = 0 normally, giving preference to nearer aircraft when the table is full

!=0 to give preference to active aircraft. This is only applicable to ground traffic, and an aircraft is considered inactive if it is in states 80 or 81 (initialising or sleeping).

Bytes 4–7 Reserved.

Normally most of these options will be as set by the user via the FSUIPC options dialogue or INI file. Applications can change them by writing to these bytes, independently for ground and airborne traffic. However, FSUIPC will automatically re-instate the user’s settings in approximately 20 seconds after the last write to any one of these bytes (airborne or ground). If an application wants to continue with changed settings it must re-write that changed setting at regular intervals. I would suggest using an interval of no more than 5 seconds in order to allow for delays when Networking is being used or FS is under other loads.

This is only a proposal at present. If it suits folks I'll see about implementing it in an interim test version sometime next week.

Regards,

Pete

[Garfield_X]

Where is the user aircraft when this program of yours is being used? On the ground at the airport, or in the air near it? Because that makes much more of a difference. The range is 3 nm only if the user aircraft is on the ground. This covers the size of most airports, but does it cover all? If the user aircraft is in the air the range is 6 nm. This is clearly documented.

The user aircraft is on the ground at the airport, and in my list i normally see only a distance from 0 to 1 nm on most airports.

For most airports 96 is enough, but on some busy airports like KLAX or EHAM i've sometimes 110 parked AC's (counted with MS traffic toolbox).

It is not possible to list more than 96 AC's?

As i understand from your proposal FSUIPC will always list active aircrafts and when a sleeping aircraft which is not in the list becomes active it will show up (and replacing a sleeping one). The same should apply to AC's which after landing goes from airborne to ground.

In that case i'm happy with your proposal of byte 3. Setting it to 1 will give my program the opportunity to log the active planes within the 3 nm range of the user aircraft. I do a read every 2 seconds, and could easily do a write to continue this display.

Peter

[Pete Dowson]

It is not possible to list more than 96 AC's?

Not without a complete change in design and interface, which I'm not really willling to contemplate at this stage. Sorry. The main requirement always was for TCAS, which is met admirably.

There is a traffic SDK, and a new DLL could be written using MS's own interface (which arrived far too late for me to use) to supply whatever you needed. If you are a C or C++ programmer it may be well worth investigating.

As i understand from your proposal FSUIPC will always list active aircrafts and when a sleeping aircraft which is not in the list becomes active it will show up (and replacing a sleeping one). The same should apply to AC's which after landing goes from airborne to ground.

This is true only if that option is set (and repeatedly set) by an application. It will remain as it is now by default.

In that case i'm happy with your proposal of byte 3. Setting it to 1 will give my program the opportunity to log the active planes within the 3 nm range of the user aircraft. I do a read every 2 seconds, and could easily do a write to continue this display.

Okay.

I'll be looking at doing all this in the next week and will post a test version here in due course.

Regards,

Pete

[Garfield_X]

It is not possible to list more than 96 AC's?

Not without a complete change in design and interface, which I'm not really willling to contemplate at this stage. Sorry. The main requirement always was for TCAS, which is met admirably.

I just saw this. There are not enough adress spaces. That's not an option because a lot of other programs uses FSUIPC.

There is a traffic SDK, and a new DLL could be written using MS's own interface (which arrived far too late for me to use) to supply whatever you needed. If you are a C or C++ programmer it may be well worth investigating.

Do you mean the traffic toolbox SDk or the Panels and Gauges SDK?

I've read those, but found not much regarding AI planes (except the small data provided by the trafficinfo.dll) Or do you mean another SDK.

I'm a VB/VB.net programmer and do not know if a DLL written in VB.net can expose itself to FS. Maybe it is possible for me to write a small DLL that exposes the AI data. (if i could find the information where FS stores it)

I'll be looking at doing all this in the next week and will post a test version here in due course.

Thanks a lot for your cooperation. I appreciate it very much.

Peter

[Pete Dowson]

Do you mean the traffic toolbox SDk or the Panels and Gauges SDK?

I've read those, but found not much regarding AI planes (except the small data provided by the trafficinfo.dll) Or do you mean another SDK.

I thought the "TrafficInfo" DLL provided most all the information needed for TCAS type operations. Doesn't it? Apologies if not, I only glanced briefly at it when it first came out -- I was deep into other FSUIPC matters then.

I'm a VB/VB.net programmer and do not know if a DLL written in VB.net can expose itself to FS.

I think that is most unlikely, or at best extremely difficult. You'd probably be able to do it by having a bare bones C DLL, made following the Panels SDK but as a DLL, which did nothing but call your separate non-FS loading VB-made DLL. If the latter was placed in the FS Modules folder you'd need to call it something else, like .BIN or .PRG or something, but it's a trivial matter to call procedures in a DLL by any name.

Maybe it is possible for me to write a small DLL that exposes the AI data. (if i could find the information where FS stores it)

It isn't really a matter of finding where it is stored so much as finding the internal C++ class pointers and deriving the virtual functions and their parameters and return formats so you can call them and use the returns. Things are several layers down, and it gets horribly complicated. Then, after all that, you have to work out a way of doing it all without impinging upon FS performance -- the latter is where I spend as much time designing in FSUIPC as I do finding the stuff in the first place.

Regards,

Pete