Paul Henty

Everything is in the FsWeather structure. The intellisense will tell you everything you need to know after you press the '.' key. To get you started, here is a sample of stepping though each wind layer and getting the speed and direction: FsWeather weather = ws.GetWeatherAtLocation("EGLL"); foreach (FsWindLayer wl in weather.WindLayers) { // get information from the wind layer e.g. Double direction = wl.Direction; Double speed = wl.SpeedKnots; } Paul

Yes, see offsets 3380 and 32FA. Make sure offset 3380 is declared before 32FA. FSUIPC get this from SimConnect which uses a special format for FSX. If you want a more standard one you have two choices: 1. Create a new one by parsing the one above and pulling out the information you want. 2. Get back a full weather structure with: FsWeather weather = ws.GetWeatherAtLocation("EGLL"); You'll then need to construct your METAR string by reading all the information in the weather structure. Paul

Hi, By far the easiest way is to use Version 3 of my DLL. I haven't released it because I haven't written the documentation yet, and I've had a few users testing it. I've attached the latest to this post. It seems to be pretty stable now. Just overwrite your current DLL and XML files with the ones included in the zip. There are different version depending on what version of the .NET framework you are targeting (2 or 4). To get the METAR for an ICAO use the following code: // 1. Get a reference to the weather services to save typing... // NOTE: Connection must already be open. WeatherServices ws = FSUIPCConnection.WeatherServices; // 2. Get METAR string at London, Heathrow string METAR = ws.GetMetarAtLocation("EGLL"); You don't need to call Process() when using the weather facilities, you get the results immediately. The DLL has full Intellisense documentation, but if you need any more help let me know... Paul FSUIPCClient3.0_BETA.zip

Not with Visual Studio. You can download a tool called ILMerge that will merge the .exe and the dlls into a single .exe after they are compiled by VS. It's a command line utility but it's quite simple to use. You can get it here: http://www.microsoft.com/en-us/download/details.aspx?id=17630 Here is an example of the command to merge my example project .exe with the FSUIPCClient.dll. This is run from the folder with the two files in, e.g. the bin/release folder, so 'cd' there first. "C:\program files (x86)\microsoft\ilmerge\ilmerge.exe" FSUIPCCLientExample_CSharp.exe FSUIPCClient.dll /out:ExampleMerged.exe /target:winexe /targetplatform:v4 /log:mergelog.log /ndebug After the ilmerge.exe command, list the name of the main .exe followed by all the dlls you want to merge (I just have one in this example). Set the /out: parameter to the name you want your single .exe to be. Then add the other options, but make sure you set the target platform correctly, i.e. if you're targeting version 2 of the .NET runtime then you would need /targetplatform:v2. In my example I was targeting version 4.0. Paul

In the zip file that you downloaded there is a docs folder. In there is a file called userguide.pdf. On page 7 there is a table explaining how to choose the variable type from the information given in Pete's document "FSUIPC4 Offset Status.pdf". Paul

Hi Ido, Declare the offset like this: private Offset<string> nearestICAO = new Offset<string>(0x0658, 4); Then in your code, after the process(), read the value like this: FSUIPCConnection.Process(); MessageBox.Show("Nearest airport is " + this.nearestICAO.Value); Paul

Yes, the simplest way is to use each byte (each offset number in the block) to store a 1 or 0 value and read these from .net. You could make it more memory efficient by using individual bits, so each byte will hold the state of 8 lights. This is a little more complicated as you'll need to deal with the lua to set and reset each bit individually i.e. ipc.clearbitsUB(offset, mask) and ipc.setbitsUB(offset, mask). If you use my DLL you can declare the offset using the BitArray type to make this easier on the .net side. Paul

You have all of that area of memory to use (64 bytes). The offset addresses you use within this block will be determined by what kind of data you are writing there, specifically the length in bytes of each value. If you wanted to write 64 values and each was 1 byte long then you would have all offsets (hex numbers) available. However, let's say you're writing an integer value that is 2 bytes long (e.g. 'short' in most .net languages). The first value would be written to 0x66C0, but it would take up 2 bytes so 0x66C1 would be taken by the second byte. The next available offset would be 0x66C2. (If you wrote anything to 0x66C1 you'd overwrite part of the first value). What you have to do is map out your own offsets within the block based on the length (in bytes) of each value you are writing. Paul

Download 2.4 from the sticky at the top of this sub-forum. Paul

It's almost impossible to see what's wrong without seeing your code. Specifically we need to see where you are reading the offset (or the Offset<> declaration if you are using my DLL). According to the documentation 0x30C0 is 8 bytes and is in double floating point format. You must make sure you read 8 bytes and that it's being converted to a 'double' type in c#. If you are using my DLL you just declare the offset type as double. From the results you've posted it seems like you are only reading 4 bytes and treating the returned value as an integer. Paul

Hi Paul, None of the .csv files contain info about the airport beyond the ICAO code. The Runways.txt file contain lots of information about the airports (including runway and comms info) but it's not in a very friendly format for parsing by code. It's possible, but I think it's more intended for humans to read. Your only other option (and the one I used) is runways.xml which has some good information about the airport (lon/lat, name, city etc). It also has runway info. You'll need to write some code to read the XML file and then push this data into your SQL database. Depending on what programming language you are using there could be some built-in or free libraries to parse XML files into an easily navigable class structure. Failing that you'll need to write your own text parser based on the rules of XML. Dealing with the XML will be much easier than trying to work out the format of a third-party's binary file, especially if you have access to ready-made libraries that handle XML reading. Paul

0x311A COM1 standby frequency 0x311C COM2 standby frequency 0x311E NAV1 standby frequency 0x3120 NAV2 standby frequency They are in the offsets status document. Paul

Hi Joe, The code you posted is just reading offset B800, but it's more complicated than that. There is a weather reading process you need to go through first to tell FSUIPC what station or lon/lat you want the METAR for. This is all described in the "NewWeather ReadMe.txt" document supplied with the FSUIPC SDK. Specifically the section called "CC00-CFFF (Area 3): Weather reading area". This should be read in conjunction with "NewWeather.h" which is a C header file that contains the data structures. I'm not sure how you're going to deal with writing C data structures in VB6 though. You may need to build byte arrays instead but I don't know VB6 that well. Paul

Hi JayCee, I think the simplest explanation for this is that the FSHostClient program isn't transmitting the local com frequency to the server. It's probably not something they thought of doing. If that's the case then there's no way FSUIPC (and therefore my DLL) could pick it up. I suggest getting confirmation from Russell about this first. Paul

Just a small suggestion; you might want to look at using the "event.Lvar" function rather than the infinite while loop. I believe it's far better from a performance point to view. Paul

You are right, there is no offset or any feature in FSUIPC to transfer data to or from lua. There are spare offsets you can use in FSUIPC, I think called user offsets or free offsets in the docs. Sorry for being vague but I am away at the moment with no access to the docs. You can have your lua program copy the LVAR data into these offsets and read them from your program in the normal way. If your program is being released to the public then it is advisable to ask Pete for some allocated offsets for this purpose instead of using the free block. Another way would be writing the data to a local file in lua and then reading it from your program. Or you can open a local tcpip socket connection using the libraries in lua and .net and have the two program's communicating over that connection. I think those are your options. Paul

Hi, I think the problem is being caused because you are creating multiple offset instances for the same address. For example if you want to access 4 bits from the same offset you end up with four entries in your FsVarList collection, each having the same offset address but different bit numbers. For each one of these you create a new Offset but they all have the same address. The problem is that when writing to FSUIPC, all bits of the offset are written at the same time. So say you want to write 1 in bits 0 and 1: Your first instruction to FSUIPC would be to write the value 1 to offset x. Then you use the second copy of the offset to write the value 2. This second copy does not know about the first one so it cannot send the correct value of 3. When you call process after each set, all the offsets that were not written get updated from FSUIPC. So after you write 1 that second copy of the offset gets updated to 1. Then you set bit 2 on this offset so the new value is 3 which is correct. To fix this you should only have one Offset instantiated for each address. Then you will be able to call process() after you set everything which is more efficient. I suggest keeping a dictionary of offsets keyed on the address. Before creating a new offset check the dictionary to see if there is already one there for that address and use that if there is. If not create one and store it in the dictionary for other FsVar objects to use. You want each FsVar object that uses the same address to be using the same instance of the FSUIPC Offset. If you need any more help with this let me know. Paul

You make a mistake when copying the code. For setting the bit on you need to OR the bit value not AND it: FS_lights.Value = FS_lights.Value Or (2 ^ 3) ' Expected: only taxi light (3) should change (light ON) Paul

Hi Dan, FSUIPC has no facilities to write to a bit directly. The BitArray is used by the dll to make things easier. Normally you'd need to treat 0D0C offset as a short and perform bitwise operations to set the correct bit. e.g. to set bit x you would need to do this: (This is 0 based, so the value of x for the least significant bit is 0 (as specified in the FSUIPC docs)) FS_lights.Value = FS_lights.Value Or (2 ^ x) To reset the bit you do this: FS_lights.Value = FS_lights.Value And (Not 2 ^ x) To get a bit value you do this: Dim bitValue As Boolean bitValue = (FS_lights.Value And (2 ^ x)) > 0 This might help you because I presume you have some way of handling the different sizes of integer at the moment (1,2 and 4 bytes). So you can use the same method to declare the offsets (byte, short, integer), you just can't use the nice bitarray syntax, you must use the above maths. Alternatively you could just ask the user to give you the length of the offset along with the offset address when they want to use a bit array. Let me know if need any more help with this. Paul

I can't suggest anything else. The only reasons I know that the key would be invalid are: 1. The system date is wrong. 2. You're not using the current installer (4.936) 3. Your Name is not entered exactly as it is on your simMarket key page. Use copy and paste. 4. Your Email address is not entered exactly 5. The Key is not entered exactly 6. You've bought a key for WideFS6 (not 7) by mistake. Pete gets back on Tuesday if no one else has any ideas. Paul

Also, make sure the date on your PC is set correctly. Keys have a start date and won't work if your PC's date is set in the past.

Hi Gerrit, From what you wrote in post #9 above, you seem to be following the correct procedure. The steps are written in the document called "installing and registering FSUIPC4.pdf". This is found in the Zip file containing the FSUIPC installer. The procedure is the same for registering FSUIPC, except you just choose the WideFS radio button. You say that the key disappears from the screen when you press ok. Normally, a message appears under the key input area. It will either say "Thank you. Registered okay", or tell you that the key is invalid. With invalid keys it blanks out the key input fields. With a successful registration the key stays. Are you getting a message underneath the key saying the key is invalid? The only way I could get the key to disappear without a message appearing underneath was pressing the [clear] button. Paul

This tutorial video might help you get going... https://www.youtube.com/watch?v=TkOg-r_MKwM Paul

If you've got FSUIPC registered then you will have a file in the Modules folder (under your main FSX folder) called FSUIPC4.key. If you open it with Notepad you can see if your key for WideFS was entered. If not, you can add the WideFS line and key manually and save the file. Then start FSX again. This might get you working if the installer is having a problem accessing that file. Here is my key file so you can see what it should look like (But obviously I've hidden my Keys). [User] Name=Paul Henty Address=paul.henty@u***********e.net FSUIPC=************ WideFS=************ Paul

I've only heard of two applications (both payware): "It's Your Plane" and "FS2Crew". I've never used them, so I can't say if they are good or not. Paul