Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Posts

    1,652
  • Joined

  • Days Won

    74

Everything posted by Paul Henty

  1. You'll need to make FsLatLonQuadrilateral classes for each runway at that airport. The you'll need to test all of them to see if the player in inside each quad (runway). Paul
  2. Sure, I've just sent you a PM with a version to try. If anyone else wants this, PM me. Paul
  3. Hello Henrique, You might want to have a look at my .NET DLL for FSUIPC. It much easier than using the old C# SDK that you are using. See this thread for a description and download for version 2.0. http://forum.simflight.com/topic/40989-fsuipc-client-dll-for-net-version-20/ If you like it and want to use it please send me a PM - I have a Beta version 2.2 that allows easy access to the payload and fuel data. I can send you a copy to try. But please get familiar with using the 2.0 version first. Paul
  4. Further to Pete's suggestions, here are two more things you can try: Try copying the FSUIPC_java.dll into C:\windows\SysWOW64. The C:\windows\system32 folder is only used for 64 bit applications. 32 bit applications (like the Java dll) need to be in the C:\windows\SysWOW64 folder. Windows make this look like C:\windows\system32 to all 32 bit processes. (Yes, the names are counter intuitive). Also, check that your application that links the DLL is being compiled as a 32bit binary. If it's compiled as a 64bit (or dual-format) binary then it will be running in a 64 bit process and will not be able to link the 32bit FSUIPC_java.dll. Paul
  5. Hi Timon, I'm fairly sure that FSUIPC4 uses SimConnect to get the AI Traffic information. (SimConnect is used for most of the data in FSUIPC4). If SimConnect itself has a problem with lots of AI Traffic then FSUIPC may not help much. You could try it an see, or wait until Pete gets back from his holiday for more details about this. Paul
  6. You can get this from FSUIPC (and from SimConnect but I don't know anything about SimConnect). FSUIPC maintains two separate tables of AI Traffic, one for ground and one for airborne. The default range for Airborne traffic in FSUIPC is 40NM. This is a setting in the FSUIPC INI file, but can also be overridden in code. I don't know if it goes out to 200nm though. To use FSUIPC (which will mean your application could also work on FS9) you need to download the FSUIPC SDK from http://www.schiratti.com/dowson.html This contains the documentation and interfaces for various languages. If you want to use a .NET language then also get my FSUIPC Client DLL for .NET from here: http://forum.simflight.com/topic/40989-fsuipc-client-dll-for-net-version-20/ My DLL also provides a much simplified interface to the FSUIPC AI Traffic information as well as extra derived info not provided directly from FSUIPC. Paul
  7. Hi Ahmet, The FSUIPC SDK documentation says that this offset is 2 bytes long. You have declared the offset as an 'int' type, which in C# is a 4-byte integer. What you are getting is offset 0E90 AND 0E92 together in one value. That's why it's impossibly large. You need to declare the offset as a 2-Byte integer which in C# is the 'short' type: private Offset<short> _ambientWindSpeed = new Offset<short>(0x0E90) Please take some time to review the User Guide that comes with my DLL. It has a section called 'Registering your interest in an Offset' which includes a table showing which .NET types to use for all the different offset lengths and types. It's impossible to get meaningful data from FSUIPC if you don't understand offset lengths and their related data types. Paul
  8. I'm pretty certain it's not because of getting the offset size wrong. I can't say why it doesn't show in full screen though - Pete will have to address that. Yes, it doesn't mean place a character '0' at the end, it means the last byte in the character array (string) must have the value 0. In any case, you don't need to worry about such things as my DLL takes care of all the string processing for you. Paul
  9. This won't solve your problem, but you need to take care with your offset sizing. Both 0x3302 and 0x32FA are marked a 2 Bytes in the FSUIPC documentation. You have declared them as 'int' which is 4 bytes. When you write to these offsets you are also writing data (0) into the adjacent offsets. Many times you won't notice, but such mistakes could have very bad effects. See my User Guide supplied with the FSUIPC Client DLL for an explanation and table of what .NET types to use for each type of FSUIPC offset. For 2 bytes integer data you need to declare the offset as 'short' or 'ushort', not 'int'. BTW, The FSUIPC docs seems to suggest that 0x3302 is readonly: Paul
  10. But only the whiskey compass offset is a Double type. Please read the User Guide supplied with my DLL that explains what VB.NET types to use with each size offset. The offset sizes are marked in the "FSUIPC For Programmers.PDF" and "FSUIPC Offset Status.PDF" that comes with the FSUIPC SDK. The same documents also explain how to convert the values from FSUIPC into 'human readable' values, as shown in my post above. Understanding these two concepts is essential. You can't use the FSUIPC interface without this knowledge. Paul
  11. Hi Friedrich, You need to get the true heading (0x0580) and then subtract the magnetic variation at the player's location (0x02A0): The offsets declarations are: Dim magneticVariation As Offset(Of Short) = New Offset(Of Short)(&H2A0) Dim playerHeadingTrue As Offset(Of UInteger) = New Offset(Of UInteger)(&H580) The conversion is: Dim hdgTrue As Double = playerHeadingTrue.Value * 360D /(65536D * 65536D) Dim magVar As Double = magneticVariation.Value * 360D / 65536D Dim hdgMag As Double = hdgTrue - magVar This may give you a heading less than 0 or greater then 360. Use a normalisation function to correct this: hdgMag = Norm360(hdgMag) Function Norm360(ByVal h As Decimal) As Decimal If h > 360 Then Norm360 = h - 360 ElseIf h = 0 Then Norm360 = 360 ElseIf h < 0 Then Norm360 = h + 360 Else Norm360 = h End If End Function This will give you the actual True heading and will probably be the same as the GPS heading. It may not be the same as the heading on the HSI instrument because of gyro drift. If you want to factor that in you need to also add: Dim gyroDrift As Offset(Of Short) = New Offset(Of Short)(&HC3E) And add that into the calculation: Dim drift as Double = gyroDrift.Value * 360D / 65536D Dim hdgTrue As Double = playerHeadingTrue.Value * 360D /(65536D * 65536D) Dim magVar As Double = magneticVariation.Value * 360D / 65536D Dim hdgMag As Double = hdgTrue + drift - magVar hdgMag = Norm360(hdgMag) Paul
  12. Hi to everyone using my DLL. I have a new Beta Version 2.2. I've added new features that make it easier to use some of the more advanced FSUIPC features: 1. Trap keyboard presses and joystick button presses made inside flight sim and respond to them in your application. 2. Add your own menu items under the Modules/Add-Ons menu in flight sim and detect when the user has selected them. 3. Easy access to all payload and fuel data. Lots of calculations are done for you, e.g. Fuel Weights (lbs and Kgs) and Fuel Levels (Gallons and Litres), Aircraft Zero-Fuel weight. There is no documentation for the new features yet but all the Intellisense is there. If you want to try it, send me a PM. Paul
  13. Hi Franklin, If the data is not accessible via FSUIPC offsets then my DLL cannot help. If they have their own SDK then you need to write code to use it. LVars are accessible via LUA script in FSUIPC I think. The best thing to do would be to look at the User Contributions sub-forum to see if anyone has already provided a solution. If not then repost in the main support forum where Pete will see it. He may not monitor this thread very often. Paul
  14. Joe, The currency (fake 64bit) ruse is for handling 64bit Integers. This is because VB6 and earlier does not have 64bit integers. The offset 0x2B00 is marked in the documentation as 64bit Floating point, not integer. You therefore need a Double type variable to hold the data (ie, Dim RetResult As Double). VB6 supports double types but I seem to remember you are using VB4 which might not, but try it and see. Paul
  15. Hi, There's your problem. You call the process() method and then you create the offset to get the touchdown rate. So this new offset is never processed. It will always be 0. You need to move the offset declaration down to where all the others are at the form level. Then it will be be created when the application loads and will be processed when CheckGround() is called. The other bad thing about declaring the offset inside CheckGround() is that you're registering a new copy of this offset request with the DLL every time it's called. This will make your app run slower and slower over time and will eventually exceed the memory limits of the FSUIPC data file causing your app to crash. Paul
  16. Firstly, you are right by declaring the PayloadstationcountFS2004 as <int>. There is no need for conversion, just use the .Value directly. About the "index out of range" - I cannot see anything in the code that will cause that. However, you have not shown the code where you declare and initialise your array FSUIPCData.PayloadweightlbsFS2004[]. Is this set to be large enough? Have you checked the value coming back from PayloadstationcountFS2004 to see if it within the bounds of your array? There is also a larger problem here I can see. Is this method calculaPayload() only ever called once? If so then it's OK. But if you call it more than once during the running of your application then you will have problems. Each time you do this: FSUIPCData.PayloadweightlbsFS2004[i] = new Offset&lt;double&gt;(0x1400 + (0x30 * i)); you are creating new Offsets, but the old ones are still there. So if your plane has 20 payload stations and you call calculaPayload() 10 times, you'll have 200 offsets being read during Process(). You need to put the payload offsets in their own group then use FSUIPCConnection.DeleteGroup() to get rid of them before calculaPayload() ends. You could also reset the PayloadweightlbsFS2004 in this method. I've made all those changes in the code below. This might work. If not, please tell me which line the error occurs on. public static double calculaPayload() { int index = FSUIPCData.PayloadstationcountFS2004.Value; // Declare as Offset&lt;int&gt; // Setup a new array with the correct dimensions FSUIPCData.PayloadweightlbsFS2004 = new Offset&lt;double&gt;[index]; for (int i = 0; i &lt; index; i++) { FSUIPCData.PayloadweightlbsFS2004[i] = new Offset&lt;double&gt;("Payload", 0x1400 + (0x30 * i)); } FSUIPCConnection.Process("Payload"); // Pegar peso total double totalWeight = 0; for (int i = 0; i &lt; index; i++) { totalWeight += FSUIPCData.PayloadweightlbsFS2004[i].Value; } FSUIPCConnection.DeleteGroup("Payload"); return totalWeight; } Paul
  17. Indeed. Thanks Pete. I'll edit my post again. Not doing too well with this one! Paul
  18. 0x30 is the length in hex of each payload station block. It's 48 in decimal, as described in the FSUIPC documentation - There are 4 doubles (4*8 bytes) plus a 16 byte string for the name = 48. The "index out of range" is probably because you're trying to using the count as the highest index. If you have 6 stations then your array will only have indexes 0-5. 0 is the 1st element, 5 is the last (6th) element. Therefore if you ask for MyArray[6] you'll get an "index out of range" error. You've probably done something like this: for (int i = 0; i&lt;= NumberOfStations; i++) What you actually need is this: for (int i = 0; i&lt; NumberOfStations; i++) If that's not the problem then maybe you can post the block of code that's causing the problem. [EDITED: Sorry I thought you were using VB. Changed to C#!] Paul
  19. Hi, Assuming you just want the weights from the payload stations like the original poster and not the distances and names, you just need to create an array of Offset<double>, then calculate and set the offset address for each one. 1. At your form or class level declare the array for all the payload offsets: private Offset&lt;double&gt;[] payloadStations = new Offset&lt;double&gt;[60]; 2. Somewhere at the start of your program, create the actual offsets for each payload station and add them to the array: for (int i = 0; i &lt; 60; i++) { payloadStations[i] = new Offset&lt;double&gt;("Payload", 0x1400 + (0x30 * i)); } Note that these are in a separate offset group called 'Payload' so we can control when this data gets read. 3. When you need to refresh this data call Process on the Payload group: FSUIPCConnection.Process("Payload"); 4. Read the payload information: Examples below show reading a single payload station and adding up the weights of all stations: // Get the weight from the Third (#3) payload station. double weight = payloadStations[2].Value; // Gets total wieght of all payload stations double totalWeight = 0d; for (int i = 0; i &lt; 60; i++) { totalWeight += payloadStations[i].Value; } Note that I've hard-coded the number of stations to 60. You can use offset 13FC to get actual number of payload stations for the current aircraft. Paul
  20. If you are using my FSUIPC Client DLL for .NET then you just declare the offset as follows: private Offset&lt;string&gt; aircraftName = new Offset&lt;string&gt;(0x3D00, 256); There is also an example of reading a string (Aircraft title) in the example application provided. If you are using the obsolete C# SDK then strings are one of many FSUIPC offset types that it doesn't support. My DLL can be found in the downloads sub-forum or follow this link: http://forum.simflight.com/topic/40989-fsuipc-client-dll-for-net-version-20/ Paul
  21. Hi, Your query seems to be specific to a Wilco plane. I've never used Wilco planes so, unfortunately, I can't answer your question, sorry. I recommend you repost in either the main FSUIPC support forum or a Wilco support forum. No one else is likely to see your question here. Paul
  22. Friedrich, The example code you posted originally is using the old VB.NET SDK. It looks like you are using my .NET Client DLL, so that's why it looks strange to you and doesn't work. Please download the latest version of my DLL 2.0 from here: http://forum.simflight.com/topic/40989-fsuipc-client-dll-for-net-version-20/ You'll see it has new facilities to give you the TCAS data from FSUIPC using one method call. All the structure stuff is taken care of by the DLL behind the scenes. You just need to retrieve the info from a strongly-typed collection of AIPlaneInfo classes using a For Each loop. It's all explained in the documentation and shown in the new example application. Paul
  23. The only program I know of like that is FSInterrogate which comes bundles in the FSUIPC SDK download. Maybe that was it? If not then maybe ask again in the main FSUIPC forum. Paul
  24. Hi, In VB.NET hexadecimal literals are specified with the prefix &H. So your line should be: Dim playerFuel As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&amp;HAF4) Note that you can type the value as &H0AF4, but the VB editor will remove the leading 0 resulting in &HAF4. LATER: I've just checked the "FSUIPC for Programmers" PDF and &HAF4 is only 2 Bytes, not 4. The value is also unlikely to hold negative values so you should therefore be declaring the offset as UShort, not Integer. Dim playerFuel As Offset(Of UShort) = New FSUIPC.Offset(Of UShort)(&amp;HAF4) I recommend you spend some time reading at least the 'Getting Started' section of the User Guide PDF that comes with my DLL (in the docs folder). In the part called "Registering your interest in an Offset" there is a table that explains which VB types to use for each offset type. If you don't understand this basic concept there is no way your program will ever get sensible data. Paul
  25. Hi Gert, The Byte type in .NET is unsigned, therefore there will be no -tve values represented in this data type. It goes from 0 to 255. You need to declare these offsets as the Signed Byte type (In VB.NET this is called SByte) which can represent values -128 to 127. Note that all the other integer types in .NET are signed, but unsigned versions are provided (e.g. UShort for an unsigned Short). Let me know if this doesn't fix your problem. Good luck with your project - it's looks good. Paul
×
×
  • 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.