lordofwings

good idea, will check that out as everything else seems to work.

Tried enum, number and various other but the same problem. I used Int32, tried Int64 and got a data type error which was expected.

But in SimConnect one does not use "offsets" there is the "PUSHBACK STATE" SimVar which is writeable (well, so it says but I get a data error) and the "TOGGLE_PUSHBACK" event which is used to "toggle" pushback on/off or receive notification that pushback has started/finished. The 2nd does not allow setting straight/left/right/none, only notification or enable/disable.

I assume that with FSX the FSUIPC actually uses SimConnect, if that is correct could you tell me if the PUSHBACK STATE simvar actually works? or how it is used? I am able to read the correct value according to whether there is pushback or not, etc. But even thought the documentation says it is settable, when I try to set a value (32-bit) I get a DATA_ERROR exception.

Do these r/w offsets actually work in SimConnect? I set up my application to put the Airspeed gauge in fail mode (value = 1) by using the "PARTIAL PANEL AIRSPEED" sim variable but it does not seem to do anything at all. I set it to 1 (FAIL) and the gauge keeps on working, showing the same airspeed (I expected it to wind down to zero). I tried by blanking it (value = 2) but the gauge is not blanked, remains operational. I am using SimConnect with FSX.

THis is the first time I actually make use of this offset in any of my programs. It is offset 0x0c4b / 0x0c5b which is documented as follows: 1 byte, Vor indicator with values 0=inactive, 1=to, 2=from. Now I set up my aircraft as follows: Tuned NAV1 to 110.00 (TBG) Aircraft flying within 5nm of the TBG VOR, signal received Aircraft flying heading 203 towards VOR with about 10 degrees off target. Nevertheless flying TOWARDS (TO) VOR station Now, in this setup the cockpit VOR instrument/CDI is showing that I am flying TO the VOR, that is correct. That means that when querying that FSUIPC offset I should be getting the value 1 (to) but I am continually getting the value 2 (from). It appears that the description for that offset should read 0=inactive, 1=from, 2=to. Most likely a typo error.

Amazing! how did I miss that? After all these years now I feel like a fool LOL. Thanks for pointing it out.

It so happens that I also need to interpret the value of the localizer needle value to provide a display of the CDI. I noticed that the offset related to the localizer needle says it has a value between -127 to +127, a signed value. However the FSUIPC Offsets documentation says that offset is ONE byte, which means in FSUIPC .NET CLient DLL one would need to declare the offset as Offset<byte>. But.... in .NET a byte type is an UNSIGNED value, meaning whatever you put there is going to be interpreted as 0..255 and not -127 to +127.

Please disregard, just figured it out.... The Radial offset gives me the proper radial, to get the "bearing" I simply have to get the reciprocal. The value on the "relative bearing" offset plus the current heading modulo 360 would actually give the radial TO.

In my application I need to know these three things I haven't quite figured out.... Precondition being that the NAV1 radio is tuned to a VOR station and the a/c is within the signal reach of the VOR. 1. How do I obtain the radial of that station the a/c is currently in? 2. How to I calculate the bearing TO the VOR station based on the current position? 3. How do I know the radial FROM the VOR station the a/c is currently in?

I concurr ;-) though I get to work with this DLL from time to time as time permits to develop my app, I must say his support has always been very professional, never getting annoyed for no good reason. All in all, 5 star support. I would even say this should be a forum by itself rather than a thread in a forum.

Does this 2.3 version posted a few days ago newer than the 2.3 Beta that was made available some months ago?

Thank you VERY much Paul, that is superb. Will experiment with that soon, in the meantime I already added the code but am short of time for playing. Just one more question with regards to that.... Say I had a connection and my menu items were declared, registered and refreshed periodically. Then all of a sudden I lost the connection with FSUIPC, takes some time before I reconnect, say more than the 14 seconds and FSUIPC removes my menu items, then, since I don't know for sure (maybe it took less than 14 seconds) if my menu items are gone, say they are and I call KeepMenuItemsAlive() or CheckForInput() now that my menu items are gone, will that throw an exception? what would be the FSUIPCError? I don't see any error code relating to that. Would in that case be a way that I can know whether I have to rebuild the menu? I don't see anything in UserInputServices that would let me check if my menu items have been zapped, otherwise they are gone, my app doesn't know and it will cease operating correctly. Anyway, great feature, thanks!

Is there an update in the documentation? I have noticed a couple of new classes like FsFuelTank & FsPayloadStation or something like that but they are neither static classes, nor have a constructor so they can't be used :(

My mistake, I was originally going to post about the GPS altitude but this more important issue came by. However, I am mentioning what I observed by monitoring the V/S at the given offset as documented in your latest PDF. No need to get so hostile Pete, Jesus, take it easy man. I cross referenced to the FSUIPC.NET Client document which indicated that for a 4 byte FSUIPC value, it could either be a single precision value or an integer.

I am using FSUIPCClient.dll (.NET) to connect to FSX. I wrote a simple program to experiment with the connect/disconnect behaviour so I started by simply monitoring GPS latitude, GPS longitude and GPS altitude and a few others. According to the documentation offset 0x030C (aircraft vertical speed) the value is updated while airborne. However, it does not specify whether these 4 bytes represent a Single or Integer value. With Single I was getting very bad results, apparently it works better with integer. However, I noticed that the offset's Value property returns something that doesn't match what you see on the V/S gauge or its tooltip. For example, in this flight (C172) during climb the gauge showed exactly on the +400 fpm line but the value obtained with the offset read +485 fpm. Also, the offset doesn;t say the units (FPM or MPM). In observing the values I noticed the difference changes considerably, sometimes it is off by 200 units or more.

I have a question about FSUIPC DotNet Client., well a few questions.... If the FSUIPCConnection object loses the connection with FSX, can I reuse the object and reconnect or must I dispose it and use a new one? If FSUIPCClient loses contact with FSX, after I reconnect (see question above) do I have to reconnect ALL the offsets again, or does it remember which ones it is tracking? Can I have multiple FSUIPCClient instances on the same application? or is it meant to be a singleton pattern? if there are multiple, do they share the registered offsets? or each have their own? I normally write a wrapper around it but it would be nice if the FSUIPCConnection instance also exposed events such as these: SimulatorDisconnected() - the current connection was closed in response to Close(). SimulatorConnected() - An Open() was completed or perhaps re-open(). An argument could indicate what is the FS version to which it is connected (as it may have changed...) SimulatorFaulted() - The FSUIPCConnection instance has faulted and can possibly not recover.

Thanks greatly appreciated. BTW I found this nice (and free) dependency utility: http://www.codeproject.com/Articles/246858/Depends4Net-Part-1

Just checked, I have v2.3Beta which I downloaded from this thread but in VS.2012 the FSUIPCClient.dll from 2.3 shows runtime v2.0.50727

I am using your DLL in a project of mine that uses WCF, all my assemblies in the project are .NET 4.5 with runtime 4.0 and target platform x86. So on my part I checked that all my references are for 4.0 including System.dll The problem is when I run the WCF service under the service host I get an error indicating that one of the assemblies could not be loaded, a BadImageException. In the Microsoft forums they told me to check the version of System.DLL referenced by the assemblies. So as I said, all my projects reference the 4.0.0.0 runtime version of System.dll. The only one I can't verify is your FSUIPCDotNetClient DLL. Could you tell me for which .NET platform it was compiled AND which System.dll version it is referencing?

Is there any way to know the Maximum Landing Weight (MLW) of the aircraft using FSUIPC? I seem to recall an XML gauge in FS 2004 (freeware addon) that gave you a red indication when your current weight (0x30C0) exceeded the MLW. I am unable to see any MLW in the FSUIPC offsets document I have (v4.70)

Is there any way to know the Maximum Landing Weight (MLW) of the aircraft using FSUIPC? I seem to recall an XML gauge in FS 2004 (freeware addon) that gave you a red indication when your current weight (0x30C0) exceeded the MLW. I am unable to see any MLW in the FSUIPC offsets document I have (v4.70)