pellelil

For a project where I need to connect to various simulators I am working on a .Net connector, and just for completeness I would like to know which sim is detected as "11" public const int SIM_ANY = 0; public const int SIM_FS98 = 1; public const int SIM_FS2K = 2; public const int SIM_CFS2 = 3; public const int SIM_CFS1 = 4; public const int SIM_FLY = 5; public const int SIM_FS2K2 = 6; public const int SIM_FS2K4 = 7; public const int SIM_FSX = 8; public const int SIM_ESP = 9; public const int SIM_P3D = 10; public const int SIM_Unknown = 11; public const int SIM_P3D64 = 12; public const int SIM_FS2020 = 13;

I stand corrected 🙂 and I am not surprised about the nightmare'ish complexity of finding heads and tail in this new (un-/not proper documented) Eco-system. Anyhow I hope you will succeed at some point in time, as I am sure many 3rd party software would like access to this info. Hopefully ASOBO will do more on the documentation-side of things, when they hopefully gets more time after having ironed out the most serious bugs, and have added the most requested features ... so probably not in a short while.

Pete I'm glad to hear you plan to update it. Let me know if/when you need a beta-tester, as I have the software to visualize the data it extracts 😉

The reason that FS-Interrogate (FSI) works, is thanks to the work by John and Pete ensuring the new FSUIPC is working like previous versions. FSI haven't been changed for years - I still have the old-source, but I don't have the development platform for recompile it 🙂

Pete, I probably have myself to blame as I use a non-standard method to convert what I read, so my software read "629.92" as "62992" (as it removes all non-number chars before converting). Anyway I changed the software to expect a floating-point now 🙂 Pelle

Ahhhh I see. Altitude was changed from an integer value to a float, which my software did not detect. Version 484 write it as: <Altitude>630</Altitude> Version 4891 write it as: <Altitude>629.92</Altitude>

Hi Pete/John There seams to be a bug in MkRwy version 4891 regarding airport elevation, that was not there in version 484. For my software (Flightplan Visualiser) I use MkRwy to scan installed scenery to obtain info regarding the airports, and I just had an issue with this software which I though was a bug in my own software, but it turned out to be an apport with an elevation greater than 60000 ft. I then put into some code to test how many airports that hat an elevation that was more than 1000 ft appart from what I think the elevation should be (based on some other airport data I have in my software). It turned out that the elevation was off at most airports: 20:24:21.177|1|INFO|Elevation correction: UTSL, changed from 130899 to 1309 20:24:21.193|1|INFO|Elevation correction: UTSS, changed from 222401 to 2225 20:24:21.193|1|INFO|Elevation correction: UTST, changed from 102699 to 1028 20:24:21.193|1|INFO|Elevation correction: UTTT, changed from 141399 to 1417 20:24:21.193|1|INFO|Elevation correction: UUBP, changed from 63001 to 666 20:24:21.193|1|INFO|Elevation correction: UUDD, changed from 53499 to 594 20:24:21.210|1|INFO|Elevation correction: UUDL, changed from 30499 to 305 20:24:21.210|1|INFO|Elevation correction: UUEE, changed from 62992 to 630 20:24:21.210|1|INFO|Elevation correction: UUEM, changed from 46899 to 469 20:24:21.210|1|INFO|Elevation correction: UUOB, changed from 73501 to 735 The 1st value is the elevation as detected by MkRwy and the 2nd is the from the other data-source I have. Installing MkRwy 4.84 in stead, this problem (with wrong elevation values) disapear. Pelle

Fred I hope you don't mind, but if I can comment your form-dessign I would strongly recommend loosing the red background color in the input/entry-fields, as it makes it very hard to read the text (especially blue text on a red background is a "no no", and the green text on red is not much better).I see the red color is the same as in the logo ("SKYDream"), but it "hurts" the readabillity (if I had to use that program I think I in many cases would cut-and-past test into Notepad) Pelle

Hi Pete Glad to see FS-Interrogate is still working :-) I have just myself recently "returned to FS" (P3Dv2.5) and I am in fact struggeling with getting up to speed with SimConnect to control the camera - more or less trying to accomplish the same as "rfresh". But it's worth the try to see it it is possible with FSUIPC in stead. Pelle

flyboy I'm looking forward to read your PDF in details. In the meantime (for CH-Product users), it seems that ControlManager for vista is entering its Beta face (and it still got a few tricks that can't be implemented via FSUIPC - at least as far as I know).

With the SDK you also got a program called FS-Interrogate (I won't tell you who made it ). Load up the FSUIPC.FSI file with this program and use the interrogate feature to lean which data you can access and try writing values back to MSFS and see what happens. While you do this you can use the scratch pad to write your notes as what you can do, in regard to what you try to accomplish.

Download the FSUIPC SDK and have a look on the VB port (sorry but I don't do VB myself). However wether or not you will in fact be able to control the autopilot via FSUIPC is determined if your particular plane is using the default autopilot or if it has its own implementation (e.g. like PMDG's B744)

If you haven't done, go download the SDK for FSUIPC from http://www.schiratti.com/dowson.html Bundled in this SDK you'll find the program FS-Interrogate (by me ) than can help you learn what data you can access, and in the SDK you will also find code examples for various development-platforms. Pelle

What would the "Hmmmm ???" mean ? Pelle

I doubt that PMDG comes with a registred FSUIPC - however I am pretty sure it will install FSUIPC if its not allready on the PC (however un-registred) and since PMDG has come to an agreement with Peter its able to work with an un-registred version of FSUIPC. The un-registred version of FSUIPC will only work with software that "provides a valid key" (e.g. PMDG or other software with accredited keys). If no such key is found you can only use it with the registred version of FSUIPC (and that would generate an error like the one you are seeing). Pelle

As far as I have been able to verify it, VB is missing in the "Unsigned department" (I haven't been able to find "16 bit unsigned" nor "32 bit unsigned", and last but not least i can't find a 64 bit Signed neither). So the 2 type you mention Pete are both signed. I have found the all types for C# and it has support for all the various types both signed and unsigned.

That is the very reason I ask what these types are called in those languages mentioned: VB, VB.Net, C# nd Java. If someboby once and for all would tell me the names of these variabletypes in VB and VB.Net then when YOU use the new version of FS-Interrogate you simply instruct it to use VB types and then you won't you hopefully will not be confused. Howeer as I am not a VB nor VB-Net developer I do n o know the names of the types for VB/VB.Net - hence this is the reason I ask if somebody will tell me. Pelle

In the comming version of FS-Interrogate users will be able to pick how variable types should appear based on their preferences (e.g. a Delphi developer like myself prefer seing the Delphi-types, a C/C++ developer preferes the C-types an so on). In order to complete the list I would like some help as what the types are called in the Development/platforms-languages that are written in subject (hence Delphi and C/C++ is defined). I need the name for the following types: 8 bit Unsigned (Byte in Delphi, unsigned char in C/C++) 16 bit Unsigned (Word in Delphi, unsigned short in C/C++) 32 bit Unsigned (LongWord in Delphi, unsigned int in C/C++) 8 bit Signed (ShortInt in Delphi, signed char in C/C++) 16 bit Signed (SmallInt in Delphi, short in C/C++) 32 bit Signed (Integer in Delphi, int in C/C++) 64 bit Signed (Int64 in Delphi, long long / _int64 in C/C++) 32 bit Floating-Point (Single in Delphi, float in C/C++) 64 bit Floating-Point (Double in Delphi, double in C/C++) Strings (String in Delphi, ASCIIZ in C/C++) Thanks, Pelle F. S. Liljendal

I am currently updating the Delphi Part of the SDK and in the process i have turned it into OOP and in the process I have aimed to make it Thread-Safe (I realize that Delphi is not your development tool however you could use the same method). I have actually made 2 Classes and its only the one that actually communicates with FSUIPC/WideFS (hence this is the only one manipulating the MMF). The child-class has its own buffer and then you call its "Read"/"Write" method all it does is to "prepare" the data within its own buffer that should eventually go into the MMF. When you call the child-class's "Process" method it uses a "Critical Section" to ensure only one is using the "Master-Class" (the one that communicate via the MMF), and the local buffer of the Clild-Class is transfered to the the MMF and the Process of the Master is exectuted and the "Critical Section" is left. This way I can have several Child-Classes in the same program and I can prepare data to be read/written using their local buffers. Only when I try to "Process" data i have to ensure the actuall MMF/FSUIPC communication is protected (Thread-Safe). Don't know if this would help !?

I can't say since I don't know FS Flight Tracker (I was actually today just looking at FS Flight Keeper and acording to its info it has no trouble running on another PC through WideFS). Most FS Add-Ons that uses FSUIPC will work fine through WideFS. The only thing that can "prevent this" is if these addons needs access to other info/files from MSFS and then sometimes all you need is to map a drive through your network. Your best bet is to contact the author of FS Flight Keeper and ask him, since he will know for sure.

Actually WideFS will have to be installed on both PCs (the Server DLL on the PC running MSFS, and the Client part of WideFS on the other PC) - however you only have to license one WideFS since the license is for the Server-part.

I'm using Delphi myself however the way to do the math is basically the same. As stated by Peter you should use a 8 byte integer (_In64) into which you simply read 8 byte from address 0x560 (for Latitude). According to the Description you must multiply this value with 90 then divide it by 100011750 (this result should be calculated using a 32 or 64 bit floating value - In Delphi I would use "Single" or "Double"). According to the dokumentation this value is Southern hemisphere if the value is negative or Northern hemisthere if its positive. This value is simply the degreees as a decimal value. If you instead want it as Degrees, Minutes, Seconds then you'll have to do something like (at least in Delphi): Procedure DecodeLatitude(Latitude: Double; var Deg: SmallInt; var Min: Word; var Sec: Word; var MSec: Word); Overload; begin if (Latitude < -90.0) then Latitude := -90.0; if (Latitude > 90.0) then Latitude := 90.0; Deg := Trunc(Latitude); Latitude := Frac(Latitude) * 60; Min := Trunc(Latitude); Latitude := Frac(Latitude) * 60; Sec := Trunc(Latitude); MSec := Trunc(Frac(Latitude) * 1000); end;

Wrong in Delphi as well (as long as we are talking at least Delphi 7 with Update 1). Previous versions of Delphi had an Int64 variable however it didn't funktion in all cases (ClientDataSets couldn't handle Int64). Paschu you can't simply look at each byte seperatly. Please state which development tool you are using as it will help describe the way to do it.

Well I am not the best bet to solve your problem since I use Delphi and knows next to nothing about VB/VB.net my my guess is that the code you mention simply convert a char to a byte value. In delphi there is a function called "Ord" (ordinal-value), but I'm not sure if VB/VB.Net has anything similar, but can't the char value not simply be "casted" into a byte value ?