Jump to content
The simFlight Network Forums

[RESOLVED] AI/Multiplayer traffic - FSUIPC


Recommended Posts

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?

No but I mean if I wanted to put a name of an aircraft into a label, I must copy the name in the array to a labels caption right? They just were examples...

I started a tread about this problem on vbforums.com, so I guess my next post on this forum will be the solutions :)

Greetings, Jasper

Link to comment
Share on other sites

if I wanted to put a name of an aircraft into a label, I must copy the name in the array to a labels caption right?

Well, not in C, you can use the ASCII string directly in the Windows API calls. But in VB you most probably need to make a string from the BYTE array. As I explained before, I don't think VB uses ASCII strings like C/C++ (and Windows and FS) do.

Can't you just compile the code you thought of in C into an activeX control and give it to me :) ?

Sorry, I know nothing about ActiveX controls, I have no idea what you mean by the "code I have thought of", and I have too much to do as it is. Why don't you do it yourself? I thought you were (becoming?) a programmer.

I really am not in the business of writing code for people. I have helped you as much as I can, especially considering I don't know VB. I don't know why you cannot understand much of what I've told you -- it seems you need to seek help from VB programmers as I suggested several messages ago. Maybe your foray into other forums will reap rewards.

Regards

Pete

Link to comment
Share on other sites

Ok, I now have grabbed the TCAS table by doing this: :D

When I looked @ FSInterrogate in Interrogate mode, I saw that every slot, has got its own offsets.

I read them all (or actually only the ones I needed like Lat, Lon, Alt, Hdg, Spd, Callsign) by increasing the offset I am reading every time I start a new cycle of 96. Like this:

CurOffset = &HF080& + i * 40

(yes, this works)

What made me solve this (except a mysterious crash, see below):

I looked in the MSDN library at the different types and wrote down what types they were (like U8, U16, U32, FLT32 and FLT64) and declared the variables I used to get the data as the appropriate type. :)

There is still one (little) problem:

Now I have read everything, but when exiting the procedure VB FREEZES AND CRASHED.... :shock: :? :x :twisted: :evil: :cry:

I don't know where it is about, I even added the Call FSUIPC_Close call in the end of the sub!!! :?

So this is very weird.... But as it has (likely) nothing to do with FSUIPC, I will continue to solve this myself... :wink:

Thanks for your help in any way!

Greetings, Jasper

Link to comment
Share on other sites

When I looked @ FSInterrogate in Interrogate mode, I saw that every slot, has got its own offsets.

Yes, of course. It is like memory -- every bytes, every word, everything has an address, and the offset value is simply the difference between the start address (base) and the data address. This is why it is called offset -- the amount the data address is offset from the start or base.

I read them all (or actually only the ones I needed like Lat, Lon, Alt, Hdg, Spd, Callsign) by increasing the offset I am reading every time I start a new cycle of 96. Like this:

CurOffset = &HF080& + i * 40

(yes, this works)

Why not simply read the whole lot in one go, as I keep advising? It's one big array of 96 slots, taking 3840 bytes. I really think you are missing the entire point!

Now I have read everything, but when exiting the procedure VB FREEZES AND CRASHED.... :shock: :? :x :twisted: :evil: :cry:

I don't know where it is about, I even added the Call FSUIPC_Close call in the end of the sub!!! :?

Do NOT, repeat NOT, Open and Close the connection each time. Just Open at the start of your program and Close at the end. The interface depends on things called "memory-mapped files" and you'll be making a complete mess of memory and probably crashing through running out of real memory or handles if you keep opening and closing in a loop.

Regards

Pete

Link to comment
Share on other sites

Sorry, but I just TRIED if closing the connection might have helped solve the error, it didn't so I removed it again.

Yes, of course. It is like memory -- every bytes, every word, everything has an address, and the offset value is simply the difference between the start address (base) and the data address. This is why it is called offset -- the amount the data address is offset from the start or base.

If you said this earlier, it could have solved a lot of problems... :?

Because this helps understanding is a lot better.

Now if I read all the bytes, I must have a way to 'decompress' the data, as I can't do anything with just 3840 bytes....

BTW: The same mysterious crash happens when using this code:

If FSUIPC_Read(&HF080&, 3840, VarPtr(Data), dwResult) Then
    If FSUIPC_Process(dwResult) Then
    End If
End If

Jasper

Link to comment
Share on other sites

Now if I read all the bytes, I must have a way to 'decompress' the data, as I can't do anything with just 3840 bytes....

Groan! :-(

Just read them directly into your 96 slot array, defined as you had it. The 3840 bytes should match exactly the layout in YOUR program's memory and then you can access everything via slot number (index) and the name you gave it in your structure (data type).

Please go back many messages and read them, read where all this was discussed and explained, and ignored it seems. :-(

Sorry. I cannot take this any more. Please do as I suggested and ask for VB help in a fresh thread. I shall ignore it and let VB folks answer.

One last point:

BTW: The same mysterious crash happens when using this code:

Why is any crash "mysterious" when you have a development system which surely includes a debugger? Until your program works you should be compiling it in "debug" mode and either tracing things through, or at least allowing the debugger to give you all the information, and point to the EXACT place and cause of any crash.

On this

FSUIPC_Read(&HF080&, 3840, VarPtr(Data), dwResult)

is this "Data" declared area big enough for 3840 bytes? Else it will certainly cause problems, probably crash. If data is declared as an array 0f 96 structures each 40 bytes long, it should work fine.

Pete

Link to comment
Share on other sites

The 'mysterious crash' is really mysterious:

Off course I run my applications first in debug mode! But when the crash occurs, a message pops up (from Windows) which says that VB doesn't work anymore, so it is not VB error (in the code) but really an application crash!

And BTW, it occurs with the way I use it, a second way (read every slot, but then in 40 bytes length) and even your way of grabbing the table!

Perhaps it is something in the FSUIPC module which I had to add to my project.......

I am going to say goodbye to you now if you can't take it anymore....

Greetings, Jasper

Link to comment
Share on other sites

Hi pete,

I now fully got the table :D

The crash was caused by reading the callsign.

VB includes a function to convert an ascii integer to the actual string, I used that.

I am now working hard on V2, which will be released before sunday I think.

Sorry for the frustrating moments :(

And thank you for your help! :)

Greetings, Jasper

Link to comment
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
×
×
  • Create New...

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.