lordofwings
-
Posts
108 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by lordofwings
-
-
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?
-
BTW guys, I just want to give props to Paul, not only for this awesome DLL which has been a blessing for me, but for the OUTSTANDING support he provides. It's something that really needs to be brought out in the open. He's always available no matter what the question is and is extremely professional. My hats off to you, sir.
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 :(
-
You entitled this thread "GPS Altitude not working", yet I see no further reference to this. Why is that?
I have no idea what you mean by "Single" (is this a term applicable to whichever .NET language you are using?), but as a programmer you must know that a 4 byte value contains 32-bits (4 x 8 ), which is the standard integer size in a 32-bit process (as of course both FS9 and FSX are). You therefore need to use whatever variable type a 32-bit integer is in the language you've chosen.
Are you converting it properly into FPM? Sounds like you are not!
If you refer to the offset documentation again, you will see that this offset is only a COPY of the proper V/S at 02C8. Unless you are only wanting touchdown speed (which is what this is for) you should be using 02C8. If you bothered to refer to 02C8 you will see it clearly says that the units are in 256ths of a metre/sec. It even tells you how to convert it!!!
Pete
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.
- 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?
-
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)
-
It would be nice if the next release of FSUIPC.NET Client came with both an x86 DLL as well as an Any CPU dll. I develop in Windows 7 Ultimate x64 usually with Any CPU but when I try to compile my flight sim projects I get a warning about the MSIL mismatch :(
For now I had to switch all my flight sim projects to x86 but would be nice to also have an "Any CPU" dll I can link to.
-
I noticed there is an ADF IDENTITY offset of type string of 5 bytes but I only see it for ADF #2, there is no such offset for ADF #1? most FS aircraft have only one ADF and that would be ADF #1, right?
-
You use the Offset BEB ?? The Gear positions are read in 0BEC 4 Gear position (nose): 0=full up, 16383=full down 0BF0 4 Gear position (right): 0=full up, 16383=full down 0BF4 4 Gear position (left): 0=full up, 16383=full down The value for Gear down is 16383.
According to the documentation the offset address is 0xBE8 (Bravo Echo Eight) and not 0x0BEB (Bravo Echo Bravo). Also could you confirm whether writing to the 0x0BEC, 0x0BF0 and 0x0BF4 (each offset is 4 bytes long) actually works, or are they read-only?
Programmatic pushback
in FSUIPC Support Pete Dowson Modules
Posted
good idea, will check that out as everything else seems to work.