LarryJ_KMSO

Thanks for your detailed explanations which !!! YES!!! I do understand. And thanks again for being there and being so helpful. Your SDK has been the excuse for two programming projects so far with a third just starting. Great fun. You're the best, Pete! Keep it up as long as you can. Larry

I haven't found a value buried anywhere in FAA documentation or in MS's BGLS that refer to the Latiitude value I read at 0x05D0. Maybe I just haven't looked in the right place yet. So the lower 4 bytes at 0x05D0 should be read as an unsigned four byte integer and the other high four bytes beginning at 0x05D4 as a signed four byte integer? (By the way your SDK doc says the upper four begin at 0x564, a typo isn't it and in my defense, the SDK just refers to integers, you didn't say signed or unsigned) So expressed as a formula not worrying about integer over flow etc, TowerLat = HiSignedInt * 90/10001750 + LoUnsignedInt * 90/(10001750*65536*65536) Is this correct? I understand what you are saying about the tower location not determing the airport. I am now thinking that the only way to be sure is to have a data base of the extents of all FS2004 airports. Then when you plop down on some runway, your coordinates are known, so you query the database to see what area area you are in and that will programaticaly yield the airport upon which you have landed. Alot of work but it could be done, I think....(':shock:') Larry

Good morning Pete and all, Ref the tower Lat Lon data available at Offset 0x0D50. Here's what I found out. The values read here are close but not exact. For example, KSEA's tower is very close to N47 27.28 where the 8 bytes at 0x0D50 shows N47 26.33. The same value N47 26.33 is read regarless of whether the 8 bytes are read from 0x0D50 as one 64 bit integer or two 32 bit integers then converted according to your directions. I thought perhaps the location N47 26.33 was that specified in the FAA's Airport Facility Directory. But KSEA is shown in there on Lat N 47 26.94. Again close but that's not what I read from 0x0D50. So I conclude there's information there but I don't know how to relate it to any other information. 0x0D50 certainly doesn't help one determine the airport ICAO given a lat and long. Larry

Haven't tried reading the tower location yet. I will do so and let you know in a day or so. Thanks, Larry

The tower location info (Lat Lon, Elev) beginning at offset 0x0D50 doesn't reflect whether this data is available for reading in FS2004. (The usual comment field column for FS2004 opposite the offset normally reading "OK" or "Not OK" is blank). If this info is not available, how would one determine the ICAO airport code when on the ground at an airport? Thanks, Larry Jones

For once, it wasn't something totally stupid in my program that was causing the error! Turns out the translation that produced fsuipc.cs (C#) from fsuipc. vb.net was done with an earlier version of the vb.NET which had a problem. That problem got carried into the translated code and caused me to go cross-eyed for a few weeks! So everyone using this routine (C# version of fsuipc.cs), be mindful that a corrected version of the C# FSUIPC class will be published here soon by the vb.NET author Bob Scott. Thanks to Bob for coming to my rescue. If you need the routine before that, I can supply a prelimiinary copy that I have tested. The fsuipc C# routine that is faulty is the FSUIPC_Get method overloaded to fill an array of bytes. Happy New Year to all Larry Jones Florence, MT

It's in the file fsuipc.cs fom the FSUIPC Developer Kit Library for C#.NET line 78: public const int IPC_BUFFER_SIZE = 65568; Well, I've already found a typo in the fsuipc.cs. (Which I communicated to the author Scott McCrory) Not bad for a programmer at my level! I guess I'll print out the Delphi version and compare the two. Then compare with your C version. Maybe I'll be forced to finally understand memory mapped files! I've been in touch with Bob Scott author of the Visual Basic .NET fsuipc version from which the C# fsuipc.cs was translated by Scott McCrory. (One of the great joys of Managed Code, I understand!) Bob suggesed buffer over run which my tests confirm. Just where and how the overrun occurs or just where the buffer indexes are not being reset, is at this point a mystery. Larry

Pete, My read data method DOES perform a call to "process" for each block of data. I've snipped the code below. My three successive calls are Read_FSUIPC_Data(ref buffer, offset, 0x4000); where buffer is an array of bytes large enough to hold 16K and the offset is 0xD000; (like Read_FSUIPC_DATA(ref buf, 0xD000,0x4000) The fourth call for 16K like that above throws an error to the listBox from the Get method. (including a hex output of the first four bytes of the output array which are always zero) . The Get method is Scott McCrory's C# translation of Bob Scott's FSUIPC VB.net . Works just fine for three calls of 16k then fails on the fourth call for 16K. If I increase the buffer size to 128k, I can make 128k/16K -1 calls before the error is returned. (With the default IPC buffer size of 64K, I can make 64k/16k -1 passes). That's why I am assuming this is related to the buffer size. If I call for 4k of data, I can make 64k/4k -1 calls successfully before on call number 16 an error is returned from the Get method. Again, if the fourth call for 16k is preceded by FSUIPC open and Init, the data is correctly read and I can make two more calls for 16K of data. Obviously, TrafficLook runs all day without error. I must be doing something wrong. Thanks, Larry private int Read_FSUIPC_Data(ref byte [] buf, int offset, int bytesToRead) { bool result = false; int result1 = 0, token = 0; result = f.FSUIPC_Read(offset, bytesToRead, ref token,ref result1); if(result == false) { listBox1.Items.Add(String.Format("Error in FSUIPC_Read call, Error = {0} ", result1)); return -1; // error in Read } else listBox1.Items.Add(String.Format("FSUIPC_Read went OK... Pass = {0} ",pass)); result = f.FSUIPC_Process(ref result1); if(result == false) { listBox1.Items.Add(String.Format( "Error in FSUIPC_Process call, Error = {0} ", result1)); return -2; // error in Process } else listBox1.Items.Add(String.Format("FSUIPC_Process went OK... Pass = {0} ",pass)); result = f.FSUIPC_Get(ref token, bytesToRead, ref buf); if(result == false) { listBox1.Items.Add(String.Format("Error in FSUIPC_Get callPass = {0} ",pass++)); listBox1.Items.Add(String.Format("bytes returned = 0x{0:X} 0x{1:X} 0x{2:X} 0x{3:X}",buf[0],buf[1],buf[2], buf[3])); return -3; // error in Get } else { listBox1.Items.Add(String.Format("FSUIPC_Get went OK... Pass = {0} ",pass++)); return 1; // success } } /[code]

Hello Pete, I have encountered a problem reading large blocks of data using FSUIPC and WideFS. The block I want to read is the AI block which is about 12k. I've created a demo program which illustrates the problem. You can read three blocks of 16K without error. Read the fourth and method "Get"returns an error. However if you read three blocks of 16K followed by FSUIPC open and Init, you can keep reading 3 x 16K bytes without error, apparently indefinitely. I'd send the program but apparently there isn't any way to attach a zip file? So 16K * 4 is 64K and the IPC buffer is 64K. This suggests that the internal buffer is not circular and that the fourth dump of 16k to it causes the buffer to fill/overflow and is flagged as an error. Apparently, FSUIPC Open and Init resets the buffer indexes (or creates a new buffer). Is there a way around this? 1) Keep a byte count and perform an FSUIPC open and Init when the count would exceed 64K? 2) I've tried increasing the buffer size to 128K but this just postpones the inevitable error, not a clean solution? 3) Is there some function call I can make to reset the buffer indexes so that I don't have to incur the memory mapping overhead with a call to FSUIPC open/init ? If you want the demo program, let me know how to send it. Thank you Larry Jones Florence, MT

Good morning Pete, Thanks for the information. I look forward to the new SDK! I included the slots with a zero reference id just to see what FS2004 was doing with them. A zero slot means apparently that this zero slotted aircraft has moved out of the immediate area (or has moved from the "ground" list to the "airborn" list)and that slot is available for incoming aircraft. I noticed that the slots are re-used. Slots an id == 0 will not be shown eventually. Yes , a simulated terminal ground radar display showing the all AI aircraft with a breadcrum trails would be fun. Perhaps that would extend my knowledge of C# .NET programing and perhaps produce a useful freeware utility at the same time. Larry

Hello Pete, The winters are long in western Montana so to pass the time and fend off the mental cob webs of old age, I decided to recreate your TrafficLook program using M$ C#.NET. I've attached my progress so far. I can read from the FSUIPC and sort the columns but I don't know where to find the data for some of the columns. So I am wondering where you found the data for the "Rwy", "From", and "To" columns? Is it read from the Adventure Language interface? The other columns ( such as "Dist", "Brg", and "Alt Diff") I could probably calculate if necessary. My FSUIPC SDK doesn't include a reference for these items. You'll need the .NET runtime (CLR) to run my program. http://www.microsoft.com/downloads/detalaylang=en. I've only tested it with WideFS so far. Thank you for any help and thanks for WideFS and FSUIPC! Larry Jones near Missoula, Montana USA AI_Traffic_List.zip

Everyone here seems to be having one trouble or another. Not me. I paid the fee for both WideFS and FSUIPC on line, received the reg codes via email, installed the new DLL versions in Modules, used the old .ini files, and everything is working! Even GPSout runs MicroSoft Streets and Trips via com1: on second (older) computer. I think I'm ready for FS2004. Good work and thanks Pete! Larry