Jump to content
The simFlight Network Forums
Sign in to follow this  
Jasper Bussemaker

[RESOLVED] AI/Multiplayer traffic - FSUIPC

Recommended Posts

Hello Peter,

I am developing an application which links FS to Google Earth (http://www.utr-online.com/GPS60.htm). But I now want to add the function to display AI/Multiplayer traffic.

Screenie:

GoogleEarthRealtime-1.png

The problem is, I don't have a clue how the data transferring works, because how I want the data, is actually in a kind of array with all the information related to all the active AI/Multiplayer traffics.

While testing some offsets, they returned """ (empty string).

How do I use the FSUIPC offsets related to AI/Multiplayer traffic?

Greeting, Jasper

Share this post


Link to post
Share on other sites

I am developing an application which links FS to Google Earth (http://www.utr-online.com/GPS60.htm). But I now want to add the function to display AI/Multiplayer traffic.

Display it on the Google Earth display, you mean? That'd be clever? In 3D, or do you just mean mark their positions?

The problem is, I don't have a clue how the data transferring works, because how I want the data, is actually in a kind of array with all the information related to all the active AI/Multiplayer traffics.

While testing some offsets, they returned """ (empty string).

What are you reading? Have you downloaded the FSUIPC SDK and checked the documentation?

You won't get any multiplayer data unless some program is providing it directly to FSUIPC. FSUIPC only gets AI Traffic data direct from FS -- try using the supplied TrafficLook program to see.

How do I use the FSUIPC offsets related to AI/Multiplayer traffic?

As documented. Have you any more specific question? I really cannot teach programming from scratch, you have to tell me what you don't understand, after you have referred to the documentation supplied.

Regards

Pete

Share this post


Link to post
Share on other sites
Display it on the Google Earth display, you mean? That'd be clever? In 3D, or do you just mean mark their positions?

Yeah 8) , The version now online are already working PERFECT with use of your FSUIPC :).

It can log your flight and display it afterwards in Google Earth, or immediately display your flight in Google Earth (while flying).

So I want to add a new function (well, actually two):

1. When running in realtime mode, display the AI/Multiplayer traffics (In my case multiplayer, as I fly mostly online @ IVAO). This will be in 3D...

2. A TCAS on the main screen!! :)

I will try to understand and read the documentation (and try TrafficLook), thank you.

Greeting, Jasper

Share this post


Link to post
Share on other sites

1. When running in realtime mode, display the AI/Multiplayer traffics (In my case multiplayer, as I fly mostly online @ IVAO). This will be in 3D...

Nice. For multiplayer on FS9 or before you have to be sure the on-line link program injects the data into FSUIPC's TCAS tables. I think Squawkbox 3 does. Not sure about the IVAO programs. There was a program called AIBridge which did it for previous programs (that's by Jose Oliveira). For FSX I think the on-line flying programs create AI traffic instead of using the MP interface -- if they do they should be already sorted.

I will try to understand and read the documentation (and try TrafficLook), thank you.

Well TrafficLook will allow to corroborate what you are reading with what it sees. Of course you can also use FSInterrogate to show the TCAS tables areas in FSUIPC offsets.

I can answer specific questions if you stumble over anything.

Regards

Pete

Share this post


Link to post
Share on other sites

If you look at this application (one of the two most known FS-Google Earth links), it is able to put the AI or Multiplayer traffics into Google Earth, in 3D. That's the only thing I need to do.

So the data I need is: Tail nr (or log in name on the networks), Position (Lat/Lon), altitude, heading and gs.

I just put the AI trfc @ EHAM on 100% and started TrafficLook.exe and saw it took such a long time to load, I suppose I will have to make the update time of the GPS (at least for the traffic data) longer than 1 second :P

So if I am right, the online client (SB or IvAp) must inject the online traffics into the TCAS table, otherwise FSUIPC doesn't know they exist?

And this means I have to read the TCAS to know where the online traffics are?

So if I want to read data from the TCAS table, I first have to supply a number of the slot I want to read to an offset?

It all doesn't seem that clear to me...:(

Greeting, Jasper

Share this post


Link to post
Share on other sites
If you look at this application (one of the two most known FS-Google Earth links), it is able to put the AI or Multiplayer traffics into Google Earth, in 3D. That's the only thing I need to do.

Yes, as you already said I think.

So the data I need is: Tail nr (or log in name on the networks), Position (Lat/Lon), altitude, heading and gs.

All that is available for AI traffic (though not necessarily tail number -- it's a user option. Mostly for commercial flights it would be airline and flight number. Whether on-line MP traffic injectors provide all that or not I don't know.

I just put the AI trfc @ EHAM on 100% and started TrafficLook.exe and saw it took such a long time to load

What took a long time to load? The traffic, TrafficLook, or the data in the display? It appears as it is available -- the traffic build up in FS is not instantaneous in any case. I'm not at all understanding what you mean. Nothing takes very long on any system I've ever used it on.

I suppose I will have to make the update time of the GPS (at least for the traffic data) longer than 1 second :P

Really? Why on Earth longer than one second? Most TCAS displays using FSUIPC work very well much faster than that. What is the problem?

So if I am right, the online client (SB or IvAp) must inject the online traffics into the TCAS table, otherwise FSUIPC doesn't know they exist?

Yes, of course, as I've said (several times already?). FS can only read AI traffic details from FS.

And this means I have to read the TCAS to know where the online traffics are?

Eryou read the tables in FSUIPC, if you want to use FSUIPC. I am really bewildered by your questions. You ask about reading traffic data from FSUIPC, I point you in the right direction, then you ask me if you have to read it to get the information you want? Sorry, this is nonsense questioning. Please, can you try to be more specific?

So if I want to read data from the TCAS table, I first have to supply a number of the slot I want to read to an offset?

No. Why do you think that? Where would you supply a "slot number"? What are you reading which even suggests such a thing?

All the traffic data is laid out in 4 tables in FSUIPC's offsets -- 2 for ground traffic, 2 for airborne traffic. There are only so many slots. When a slot is freed (because the aircraft leaves the area or transfers from air to ground or vice versa, that slot may be reused. You can tell which slots are used by the non-zero ID.

The two tables for ground (and also those for airborne) have the same slot allocations -- it should be one table but as more data was added the space ran out, so one table is just an extension of the other.

It all doesn't seem that clear to me...:(

Why? There's lots of information provided in the Programmer's Guide, including the structures to use to define the data format for each slot. All you need is an equivalent set of arrays of structures in your program to read the offset data into, maybe all in just the 4 reads, then deal with the contents as you like. This is effectively what TrafficLook does.

Pete

Share this post


Link to post
Share on other sites
All the traffic data is laid out in 4 tables in FSUIPC's offsets -- 2 for ground traffic, 2 for airborne traffic. There are only so many slots. When a slot is freed (because the aircraft leaves the area or transfers from air to ground or vice versa, that slot may be reused. You can tell which slots are used by the non-zero ID.

The two tables for ground (and also those for airborne) have the same slot allocations -- it should be one table but as more data was added the space ran out, so one table is just an extension of the other.

All you need is an equivalent set of arrays of structures in your program to read the offset data into, maybe all in just the 4 reads, then deal with the contents as you like. This is effectively what TrafficLook does.

lol, this was about the data I needed :)

Sorry for the vague questions :(

But can you tell me then, what offsets I must read to get the data of the airborne traffic (because only airborne traffic is shown on a TCAS) and what type of variable they return? I suppose a string (ASCII)?

Thank you

Share this post


Link to post
Share on other sites

But can you tell me then, what offsets I must read to get the data of the airborne traffic (because only airborne traffic is shown on a TCAS) and what type of variable they return?

Er, do you have the FSUIPC SDK? If not download it. Inside you will find a "Programmers Guide" document. There's sections near the front describing the structures I mentioned. Structure definitions include variable types, of course. The offsets are listed -- there's a large table of all the offsets and you'll find the ones you want in there.

I really thought you would have looked first. It makes sense now that your earlier questions were so, basic and confused. You should really use the tools provided, including the SDK. Get it from www.schiratti.com/dowson.

I suppose a string (ASCII)?

Of course not. Why encode stuff like Lat/Lon/Alt/Hdr etc in string format? There's not enough space as it is! That would be very inefficient!

Pete

Share this post


Link to post
Share on other sites
Of course not. Why encode stuff like Lat/Lon/Alt/Hdr etc in string format? There's not enough space as it is! That would be very inefficient!

:lol:, but I mean things like the tailnr...

Well, actually, I do have the FSUIPC SDK, and I used the VB example and the fsInterrogate.exe application for the most programming work. But that were things like heading, gndspeed and so on (so only reading).

I have no experience whatsoever with writing data to FSUIPC. And in your guide for the TCAS (the front section of the Programmers Guide as you said), you also not tell what length and what type the written and read variable must be. Because I different bit lengths (8, 16, 32 bit) return different outputs...

Or do I need to use fsInterrogate for that?

Let's mention something positive now :D : I really like your response time on the forum!:D:D :wink:

BTW: I almost finished programming on the structure needed for the application to work, the only thing I need is the actual data itself!

Greeting, Jasper

Share this post


Link to post
Share on other sites

:lol:, but I mean things like the tailnr...

As you will see from the data definitions 9the structures in the documentation, yes, the one field which needs to be an ASCII string is an ASCII string, but its only the one.

I have no experience whatsoever with writing data to FSUIPC.

Well, writing is the same as reading except you supply the data and use a different command. But there's certainly no writing involved whatsoever in READING traffic data! Where do you get that idea?

And in your guide for the TCAS (the front section of the Programmers Guide as you said), you also not tell what length and what type the written and read variable must be. Because I different bit lengths (8, 16, 32 bit) return different outputs...

Sorry, what is this about? Please be more specific. The structures are most certain of a specific length, each variable in them is defined by the language they are shown in. And the size of each slot is defined. What are you reading? You seem to be reading something completely different! I've never had so much trouble with such simple things! Have you done much programming before?

BTW: I almost finished programming on the structure needed for the application to work, the only thing I need is the actual data itself!

Which is fully defined in the documentation if you'd only read about it! :-(

Please, if you are going to misread documentation, at least be specific so I can see what you are reading. It evidently isn't the parts in which I describe this facility.

Regards

Pete

Share this post


Link to post
Share on other sites
Well, writing is the same as reading except you supply the data and use a different command. But there's certainly no writing involved whatsoever in READING traffic data! Where do you get that idea?

:shock:

I thought I needed the 'Read full AI identity string' part...

But I apparently need the F2004/2 AIR traffic data (sorry!)...

And yes, I did pretty much programming before, if you look at http://www.utr-online.com, there are several applications, which are in my opinion very sophisticated.... Like the WCG, which generates clearances and the UTR which reads a timetable file and display it...

Well, I have to admit the FSUIPC module must be more sophisticated...

I think the problem is that, I don't really understand your programming architecture and the way you explain it in your documentation, so that's a pity...

Furthermore, I am not stupid, I am 15 years old and just about to go to the 4th grade of the VWO (I even did the TTO (see wikipedia article) for 2 years, but the school was no fun and the english part of the school didn't make the school much more challenging for me) :wink: , maybe the problem is that sometimes I just ask help a bit too fast (cause I am lazy :))... I am going to experiment more today...

Greetings, Jasper

Share this post


Link to post
Share on other sites

I got it I think :o

I set fsInterrogate to 'inverstigate' the variables and suddently if gives all these different things (lat,lon,hdg,alt) but then 96 versions (slots) of it!!!!!!

Thats not fair, because you do not mention anywhere in your documentation which offsets I must read to get the next airplane!!!!!

This is not funny: http://msdn.microsoft.com/en-us/library/aa263420(VS.60).aspx

Because there is no data type which stores 32 bytes! :(

But I got it now, the only thing is, there is no data returned while requesting it from FSUIPC, but thats about the data types (and their storage size; 8,16,32 byte)... So I need to fix that...

Greetings, Jasper

Share this post


Link to post
Share on other sites

I set fsInterrogate to 'inverstigate' the variables and suddently if gives all these different things (lat,lon,hdg,alt) but then 96 versions (slots) of it!!!!!!

Thats not fair, because you do not mention anywhere in your documentation which offsets I must read to get the next airplane!

Sorry, what exactly IS "the next airplane? The table contains details of up to 96 aircraft. Each slot can contain details of an aircraft, or it can be free. As aircraft come and go slots get freed then re-used. You can tell when slots are used or not and when they change from the ID. There is no such thing as a "next airplane". What sort of idea is that?

And what do you mean by "not fair" in this context?

Because there is no data type which stores 32 bytes! :(

Of course there is. Where are you learning your programming? Structures can be of any length. Just define the structure as documented for you. That's most of the programming already done!

And why are you referring to 32 bytes? Neither of the tables have 32-byte slots. One is 40 bytes per slot, and the other is 20 bytes per slot, as clearly documented.

Assuming you only want the data in the main Airborne table, the 40-byte per slot one, all you'd need to do is declare your array:

TCAS_DATA tcasAirBorne[96];

then read into it (i.e. to

 (BYTE *) &tcasAirBorne[0]

) 96 x 40 (i.e. 3840) bytes from offset 0xF080.

When that completes you have all the data in your own array of 96 entries and you can scan reading the id's, for example:

for (i= 0; i < 96; i++)
{    if (tcasAirBorne[i].id != 0)
// deal with airborne aircraft
}

I shouldn't really have to teach programming here.

Regards

Pete

Share this post


Link to post
Share on other sites
I shouldn't really have to teach programming here.

Well, I program in VB, and I learned it myself, with a bit of help from my father...

I just look a look at declaring Types (is this what you mean?) and I will try this in my application.

Private Type TCAS_DATA
    id As DWORD
    lat As Single
    lon As Single
    alt As Single
    hdg As Integer
    gs As Integer
    vs As Integer
    idATC As String * 15
    bState As Byte
    com1 As Integer
End Type

Goog type declaring.

I used the Integer instead of the WORD (Because VS has no WORD), because in the MSDN library it states that it is a 16-but variable...

And why are you referring to 32 bytes? Neither of the tables have 32-byte slots. One is 40 bytes per slot, and the other is 20 bytes per slot, as clearly documented.

If you look at FSInterrogate, it states the Var. Type, which is sometimes 8, 16 or 32 bits. So I guess we are confusing bits and bytes now... :(

Greeting jasper

Share this post


Link to post
Share on other sites

Well, I program in VB, and I learned it myself, with a bit of help from my father...

I just look a look at declaring Types (is this what you mean?) and I will try this in my application.

Doesn't look like it helps there with structures, does it?

I just Googled for "structures in VB" and found these two which may help.

http://msdn.microsoft.com/en-us/library/78kf2xd4(VS.80).aspx

http://weblogs.asp.net/pleloup/archive/20138.aspx

The first most certainly seems to indicate that VB supports structures and arrays of structures. I don't know VB at all. Don't you have any reference material you can read?

And what offset should I use to read the data from FSUIPC into my own declared type (the one in your programmers guide with a length of 40 bytes)? :?:

Erplease re-read my last message, in which I declared the data area for reading, the offset and the size. You seem to be skipping things! Please read what I write otherwise we will get nowhere.

If you look at FSInterrogate, it states the Var. Type, which is sometimes 8, 16 or 32 bits. So I guess we are confusing bits and bytes now... :(

We? I am not confusing them, and you must not either. Your program will never work if you don't take care to use the correct types and not mix them up. Bits are not bytes!

Pete

Share this post


Link to post
Share on other sites

Yeah sorry, but I was editing my last post continuously, sorry for that... So some things of your last post, are not content of MY as post :)

Private Type TCAS_DATA
    id As DWORD
    lat As Single
    lon As Single
    alt As Single
    hdg As Integer
    gs As Integer
    vs As Integer
    idATC As String * 15
    bState As Byte
    com1 As Integer
End Type

I used the Integer instead of the WORD (Because VS has no WORD), because in the MSDN library it states that it is a 16-bit variable...

I made this, does it seem OK?

Share this post


Link to post
Share on other sites

Private Type TCAS_DATA
    id As DWORD
    lat As Single
    lon As Single
    alt As Single
    hdg As Integer
    gs As Integer
    vs As Integer
    idATC As String * 15
    bState As Byte
    com1 As Integer
End Type

I used the Integer instead of the WORD (Because VS has no WORD), because in the MSDN library it states that it is a 16-bit variable...

I made this, does it seem OK?

Well, i don't know VB, but aren't their Strings fundamentally different in storage to standard ASCIIZ? For example, don't they start with a length byte instead of ending with zero? And I seem to recall that by default it uses either Unicode or wide character format, not ASCII. You may need to declare that field as an array of 15 BYTES instead, to be safe, then convert it to a VB string afterwards.

After that, provided Integer is definitely 16-bit ("WORD" is a Windows type defined as "unsigned short"), and provided VB doesn't pack any extra bytes between any of the fields, it should be okay.

I suspect VB doesn't support "unsigned" types -- if not, take care with the heading as you'll get that in the range -32768 to +32767 (representing -180 to +179.9999), so you'll need to correct for that to get the proper unsigned range, 0-359.9999.

If you can declare an array of 96 of those structures, and read the complete 96 x 40 bytes in, you have all the data to hand. read it at, say, 1 second intervals (normal TCAS scan rate) and you should be fine.

Regards

Pete

Share this post


Link to post
Share on other sites

Private Type TCAS_DATA
    id As DWORD  'This one (DWORD), as I saw, is declared within the FSUIPC.bas (module).., so it not even standard in VB......
    lat As Single
    lon As Single
    alt As Single
    hdg As Integer
    gs As Integer
    vs As Integer
    idATC As String * 15
    bState As Byte
    com1 As Integer
End Type

Dim AI() As String, AI2() As TCAS_DATA                       'Define AI as a string array and AI2 as a TCAS_DATA array

ReDim AI2(0 To 96)           'Define the length of the AI2 array (96)
    If FSUIPC_Read(&HF080, 3840, VarPtr(AI2), dwResult) Then     'Read data from offset F080 with length 3840 (96x40) into array AI2... (but doesn't work)
        If FSUIPC_Process(dwResult) Then                                'If the processing returned no error
            ReDim AI(0 To 96, 0 To 6)                            'Define the length (2D) of the AI array, this is the array in which the usable data (for my application) will be stored.
            a = 0
            For i = 0 To 96                         'Cycle all the 96 entries of AI2.
                If AI2(i).id <> 0 Then
                    AI(a, 0) = AI2(i).id                 'Assign the needed values to the AI array
                    AI(a, 1) = AI2(i).lat
                    AI(a, 2) = AI2(i).lon
                    AI(a, 3) = AI2(i).alt
                    AI(a, 4) = AI2(i).hdg
                    AI(a, 5) = AI2(i).gs
                    AI(a, 6) = AI2(i).idATC
                    a = a + 1
                End If
            Next
        End If
    End If

This doesn't work.... :( :cry:

This is what goes wrong:

When running this code, VB returnes a 'Type mismatch' and selects the AI2 in between the VarPtr

VarPtr appears to be a function (standard in VB) to convert the supplied variable into a Long type (because this is needed by the FSUIPC_Read function). The variable needed to be supplied for the VarPtr function, can be anything, so in my opinion it is weird to have a type mismatch....

Share this post


Link to post
Share on other sites

'This one (DWORD), as I saw, is declared within the FSUIPC.bas (module).., so it not even standard in VB......

Most of the capitalised types are Windows API types, declared for C/C++ users in Windows.h or one of its subsidiary files. DWORD is simply an unsigned 32-bit integer, much as WORD is an unsigned 16-bit one and BYTE is an unsigned char, or 8-bit quantity.

I use standard Windows types (as opposed to C/C++ types) a lot, because much of programming for Windows, and FS, uses API calls which declare them for their parameters, and it saves having to use casts all the time.

If FSUIPC_Read(&HF080, 3840, VarPtr(AI2), dwResult)

I seem to remember from other VB users that "&HF080" is actually changed by VB's compiler into &HFFFFF080, which is no good. Even giving it as &H0000F080 seems to be no good. I think you have to use a postpended & to tell the stupid compiler not to mess about, thus: &HF080&. But please check this. I'm only vaguely remembering it.

Really you need to talk to someone who knows a bit about VB. This isn't FSUIPC programming.

           For i = 0 To 96                         'Cycle all the 96 entries of AI2.
                If AI2(i).id <> 0 Then
                    AI(a, 0) = AI2(i).id                 'Assign the needed values to the AI array

Not sure why you have to copy data from one place to another. And I don't understand the syntax of these assignments at all. Why can't you simply use the data as it is, in the Array? Why so ccomplicated?

This is what goes wrong:

When running this code, VB returnes a 'Type mismatch' and selects the AI2 in between the VarPtr

VarPtr appears to be a function (standard in VB) to convert the supplied variable into a Long type (because this is needed by the FSUIPC_Read function). The variable needed to be supplied for the VarPtr function, can be anything, so in my opinion it is weird to have a type mismatch....

Well, sorry, I can't help with that at all.

All your troubles are now with understanding VB, more than FSUIPC. You need to read up some more, maybe, or hope for some VB guru to come along. Maybe you should now formulate all your VB questions and post in a new thread with "VB Help Please" some place in the title. We do get some helpful VB experts popping in here now and then, but they won't be enticed by the current thread's title.

Regards

Pete

Share this post


Link to post
Share on other sites

Can't you give me the code of your own reading of the TCAS table (in C). Just the reading, and then I will try to translate it.

Because I have read somewhere that C is a bit like Actionscript (flash), and I have got a bit of experience in that...

Thank you

Share this post


Link to post
Share on other sites
Can't you give me the code of your own reading of the TCAS table (in C). Just the reading, and then I will try to translate it.

Because I have read somewhere that C is a bit like Actionscript (flash), and I have got a bit of experience in that...

Well, I more or less gave you it. With

TCAS_DATA tcasAirBorne[96];

declared, the Read call would simply be:

FSUIPC_Read(0xF080, 3840, (BYTE *) &tcasAirBorne[0], &dwResult);

or even just

FSUIPC_Read(0xF080, 3840, (BYTE *) tcasAirBorne, &dwResult);

because C/C++ uses the address of an array when its name is used, though I like to explicitly show I'm taking the address (&...) of the first element of the array ([0]) because i think it is less ambiguous when reading it.

The (BYTE *) casting probably isn't needed either -- the prototype for the call specifies this parameter as a "void *" (pointer to a void), meaning what it points to doesn't have to be typed. However, again, I don't like the possible uncertainty, and when the call gets to where it is going it is being cast into a BYTE pointer in any case, so it can be copied across into the shared memory block.

Pete

Share this post


Link to post
Share on other sites

As I read this all, I definitely realize that VB is not programmed to make applications which use complex bit and byte transferring :P

So it must be about this:

Dim AI() As TCAS_DATA, CurOffset as Long
ReDim AI(0 To 96)
For i = 0 To 96
    CurOffset = Val("&HF080&") + Val(Hex(i * 40))
    If FSUIPC_Read(CurOffset, 40, VarPtr(AI(i)), dwResult) Then
        If FSUIPC_Process(dwResult) Then

        End If
    End If
Next

Share this post


Link to post
Share on other sites
For i = 0 To 96
    CurOffset = Val("&HF080&") + Val(Hex(i * 40))
    If FSUIPC_Read(CurOffset, 40, VarPtr(AI(i)), dwResult) Then
        If FSUIPC_Process(dwResult) Then

        End If
    End If
Next

Good grief! Can't you read the whole set in one statement? Why not replace all that with

    If FSUIPC_Read(&HF080&, 3840, VarPtr(AI(0)), dwResult) Then
        If FSUIPC_Process(dwResult) Then

I really cannot see how the compiler knows what the 3840 means, compared to the 40, and it is the FSUIPC interface code which is filling the bytes in, so why not read all 3840 in one statement?

And why use strings for numbers anyway? What's wrong with

CurrOffset = &HF080& + (i * 40)

Something's getting very very muddled here. I've never known any programming language in which you have to give literal numbers in strings when you are operating on them arithmetically!

Pete

Share this post


Link to post
Share on other sites
What's wrong with

CurrOffset = &HF080& + (i * 40)

Well, I actually didn't try it out, but I thought the i * 40 was added to it as decimals, but not really sure.

But let's suppose I did load all the 3840 bytes, I just do like:

AicraftName(0) = AI(0).idATC
AircraftLon(0) = AI(0).lon
'ect. ect.

NOTE: The arrays AircraftName and AircraftLon are just examples, I am not going to use them, they are just to show you, in case you wonder...

And if I would replace it all by one statement, all the data is put into the AI(0) only, so the rest of the 96 is empty...

And what about sending the sourcecode of trafficlook.exe to me :)

See my website for my email address

Jasper

Share this post


Link to post
Share on other sites

Well, I actually didn't try it out, but I thought the i * 40 was added to it as decimals, but not really sure.

Here's some of your confusion. Just because the FSUIPC offsets are documented and known in hexadecimal doesn't mean that they can only be addressed in hexadecimal. That's merely a convention. It's a number. You can express numbers in a lot of different ways. The offset &HF080 is the same as decimal 61568 or binary 1111000010000000 or octal 170200. Inside the computer they are all the same! You simply use the most convenient format in your program, the compiler converts it all to internal representation.

This is all basic fundamental computer science, something which should be in the first chapter in any programming book, even one on VB.

But let's suppose I did load all the 3840 bytes, I just do like:

AicraftName(0) = AI(0).idATC
AircraftLon(0) = AI(0).lon
'ect. ect.

NOTE: The arrays AircraftName and AircraftLon are just examples, I am not going to use them, they are just to show you, in case you wonder...

Why on Earth are you copying from one place to another? Why not simply USE the data where it is? I don't understand your obsession with making copies of everything. It is so wasteful, and anyway completely irrlevant to anything to do with the FSUIPC interface. Once you have the complete array of 96 slots in your program, do with it as you wish. That part is entirely your concern, that's YOUR program. I don't mind helping ith the FSUIPC interface, but everything else is yours. I thought you said you'd written programs already?

Regards

Pete

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.