Paul Henty

Hi Nuno, I've tried your exact code running under the culture code 'en-GB' and 'pt-PT'. Both give me back the same results (which seem sensible) and no exceptions are thrown. Obviously the input string for the Convert.ToDouble needs to have the . or , appropriate to the culture code. So, running under en-GB I entered "53.024" for latitude, and "2.21" as longitude. I got back "283.196744307048" after running ToString() on the double returned from your function. Then I switch to pt-PT and I entered "53,024" for latitude, and "2,21" as longitude. I got back "283,196744307048". As far as I can see it's running okay. Can you give me any more information about the problem, e.g. the exact strings you are supplying to newLon and newLat? Also when you say you are getting incorrect results what is the incorrect value and what are you expecting? Thanks, Paul

Yes it's that FlightSimFirstOfcV2 program. Paul

When you get the error next time, press the details button. This will show a text box. Copy all the contents of that text box and paste it here, That will show us exactly what program is causing this error. Paul

FSUIPC can only get information from Flight Sim. It doesn't know about add-on aircraft (except for PMDG 737ngx). Flight Sim only has two states for the taxi lights, on and off. If planes like the AXE need more than two states they must model that themselves, outside of Flight Sim. Some manufacturers have a way of accessing this extra data with SDKs or LVars (which can be accessed via a LUA plugin for FSUIPC). But each aircraft is different so you would need to investigate each one separately. The landing rate (030C) is just a snapshot of the vertical speed offset (02C8) taken when the ground flag changes. Bounces can sometimes affect this reading. If you don't like the values it gives you can always monitor 02C8 and the on ground flag (0366) in your code and come up with your own logic to capture the VS at touchdown. For example you could average all the VS readings taken during the last 1 second before touchdown. You could further analyse each rate and filter out any anomalies. If you'd like me to check your code for the 030C offset, paste the offset declaration and the conversion formula. Paul

Hi Robert, The screen shot isn't showing. Maybe try again. It might be helpful if you can tell us what other software you start when you fly. Paul

I mean the source code of the program you wrote using my .DLL. If you didn't write a program yourself then you've posted in the wrong forum. You could try posting again in the main FSUIPC support forum and Pete will see it when he gets back from holiday. But you should first find out what program is giving you that error message because it's not FSUIPC. It's an add-on program. In the first instance you should get support from whoever wrote that program. Paul

Thanks for that. Unfortunately I can't see anything obvious that's causing the lost connection. It may have to wait for Pete to get back so get his advice. In the mean time you could try running another FSUIPC program along side your problem application, e.g. TraficLook (http://forum.simflight.com/topic/66136-useful-additional-programs/), FSInterrogator (available in the FSUIPC SDK zip), or my sample application from my DLL download zip. If FSUIPC really is rejecting requests somehow then other FSUIPC programs will also report a lost connection (how they do this will depend on the program). If the other program(s) continue with no problem after your crashes then it's a problem specific to your program. If all the programs stop working then it's a general FSUIPC problem. If it's just your code that has the problem, I can look at it it you want. Just paste the relevant parts here, or PM me if you prefer. I'd need to see the offset declarations, the open() and process(). Paul

Hi Robert, Looks like the first log is probably your most recent (Version 4.92) but the log is incomplete. I would suggest the following: 1. Update to the latest version of FSUIPC (4.936) http://forum.simflight.com/topic/66139-updated-modules/ 2. Run FSX and your problem application. 3. After you get the FSUIPC_ERR_SENDMSG exception, close FSX (this is important) and then paste the log here. Regards, Paul

Hi Robert, This message is caused when FSUIPC doesn't respond to any messages. If you look at the log file in the modules folder (FSUIPC.log or FSUIPC4.log) it might show you why it's failing. Post it here if you want me to have a look. Paul

Hi Ruediger, It's good that you got it working. I'm not convinced that the problem was running Process() from a different form. Unless you're explicitly running the other form on a separate thread, both forms will be running on the same thread. This means that the process() method cannot be executed at the same time by both forms because only one form can run code at a time. The isBusy flag won't be of any use to single-threaded application. Anyway if it's working now, that's the main thing. Paul

Hi Ruediger, There is only one place the DLL throws this error. It's during the process() when it detects that the data exchange file is greater than approx. 32K. If you're only requesting a few offsets and the amount of data is way under the 32K limit, the most likely cause is a that you program is creating the same offsets over and over. Have you changed where/how you are declaring your offsets? Make sure each offset only gets declared once in the lifetime of your application. Usually this is done by declaring them as variables in the form/class level. If you create them in code then make sure that code only runs once, or if it needs to run more than once, make sure you clean up the offsets by either: a. Calling .Disconnect() on the offset before it goes out of scope. b. Adding them to a group and then calling FSUIPCConnection.DeleteGroup() before they go out of scope. If you still can't see the problem in your code I'll be happy to take a look if you want to paste the offset declarations here, or PM them to me if you prefer. Otherwise I could add some diagnostics to the DLL so you can better see what's happening with the memory file. Paul

Hi, The second error message (Connection already open) is because you're not calling FSUIPCConnection.Close() in the Catch block. Close() will clean up the failed connection and allow you to retry. The first error means that FSUIPC or WideClient.exe was found, but the DLL couldn't send a message to it. I'm not sure what might cause this. You could try running other FSUIPC applications to see if they work (e.g. FSInterrogate2std.exe which comes with the FSUIPC SDK). I suspect they won't work either. If they do work then let me know. If they don't work then you have a problem with your FSUIPC. In which case check the following: 1. Make sure that your program (or Visual Studio) is running at the same privilege level as FS2004. That is they are both running 'As Administrator' or both NOT running as admin. 2. If you have a registered version of FSUIPC make sure the date on your PC is set correctly. Let me know how it goes. Paul

I'm not sure why you chose 3340. This is an offset for reading joystick buttons. All controls just use 3011 and 3114. You have to convert any values (parameters) you are writing for the control to a 4-byte integer. So of you want to write boolean, you just write 1 or 0: private Offset<int> controlParameter = new Offset<int>(0x3114, true); private Offset<int> sendControl = new Offset<int>(0x3110, true); sendControl.Value = EVT_VNAV; controlParameter.Value = 1; // Set to 1 or 'true'. For 'false' set to 0. FSUIPCConnection.Process(); Paul

Hi Nuno, Looking at the documentation for 0x0894 is says the length is 2 bytes. This means you should declare the offset as an unsigned short: private Offset<ushort> eng1Ignition = new Offset<ushort>("AcarsData", 0x0894); The UserGuide.pdf (found in the Docs folder of the Zip file you downloaded) has a section that explains what .NET types to use with various offset sizes. See page 7, The documentation for FSUIPC is written for C programmers. In C, unlike C# there isn't really a dedicated boolean type. Any integer > 0 is considered 'true', 0 is 'false'. So Pete is just saying that the offset value will be 0 if the engine is not running and > 0 if it is. bool engine1Running = eng1Ignition.Value > 0; For the aircraft info, 0x3148 is only the aircraft type as defined in the Aircraft.cfg file. The name of the airline is in 0x3148. Offsets 0x3130 and 0x313C might also be useful. Paul

Hi, You need to set the controlParameter value to the position you want. I don't have the 737NGX so I can't test this, but it should work: private void btnlight_Click(object sender, EventArgs e) { sendControl.Value = LWiper; controlParameter.Value = 2; // Set the position value here This sets to 2 = 'LOW'. FSUIPCConnection.Process(); } Paul

The offsets for the 737NGX are all read only. To write values you need to send control values to FSUIPC using offset 0x3110 and 0x3114. To send a control you write the control number to 0x3110. If the control has a parameter value you write this to 0x3114. Not all controls have a parameter value. Below is an example of sending the 'Refresh Scenery' control which forces flight sim to reload the scenery. First create the offsets. (Note the order is important. You must create 3114 before 3110). private Offset<int> controlParameter = new Offset<int>(0x3114, true); private Offset<int> sendControl = new Offset<int>(0x3110, true); Here I define a variable that holds the number 65562, which is the 'refresh scenery' control number. private readonly int REFRESH_SCENERY = 65562; In the main code, this will send the command to Flight Sim. Note that refresh scenery doesn't take a parameter value, so it's not included here. sendControl.Value = REFRESH_SCENERY; FSUIPCConnection.Process(); To find the correct control numbers to send for the 737NGX you need to look in the 'PMDG_NGX_SDK.h' file. The controls may also be called 'events'. They are the same thing. This file is found in the 737NGX SDK from PMDG. It is not included in the FSUIPC SDK. As a 737NGX customer should be able to download their SDK from the PMDG website. Paul

Hi Chatchai, 0x2F80 is correct for the default aircraft that come with FSX. Some add-on aircraft do not use the normal systems provided by FSX. PMDG 737NGX is one such aircraft. Many of the system for this plane are handled outside of FSX, therefore it is usual that reading the normal offsets will not give you the correct results. FSUIPC can interface with the 737NGX. There is a separate set of offsets for reading, and controls for writing. This is explained in a document called "Offset Mapping for PMDG 737NGX.pdf". You can find this in the "\Modules\FSUIPC Documents" folder under your main FSX install folder. Paul

You could give your users a button or menu options for 'Rebuild Scenery Data" or something. Then run Makerwys.exe from inside your application. This is what commercial programs like Radar Contact do. I assume you are using .net since you are posting here, so you can use the System.Diagnostics.Process class to start the Makerwys.exe and wait for it to finish. You'll need the path to the Flight Sim install folder which you can either ask the user for, or get from the registry: HKEY_CURRENT_USER\Software\Microsoft\Microsoft Games\Flight Simulator\<version no> It's more complicated if your users use your application over wideFS. Then you'll need to get them to run your ACARS on the flight sim PC first to do the scenery data rebuild, or resort to getting them to manually run the Makerwys.exe. Paul

Hi Chakko, I have two things you can try that could improve this a bit... 1. If the local data files do not exist then the lua library should create them for you when you write them the first time. You shouldn't need to create them manually. 2. You should be able to eliminate the whole copying process by directly accessing the server files from the client LUA. \ is a special character and needs to be doubled to mean one \. so something like this could work: file = io.open("\\\\SERVER\\Microsoft Flight Simulator X\\Modules\\com1freq.txt","r") Paul

Hi Arun, Using the NWI from a .net language is not simple at all. Especially if you're using the arcane C# SDK that you are using and you don't have a good understanding of C or C++. Even if you managed to get the raw data from the NWI area you've still got a ton of work to do decoding the raw bytes into usable C# variables. To give you an idea, the NWI module in my .net dll is just over 600 lines of c# code. I would like to suggest that you instead try my FSUIPC Client DLL for .NET. I have an unreleased beta version which allows you to access the NWI in a very friendly '.net' way (i.e. using a .net weather object). I'd be happy to let you test it. To find out more please visit my subforum where you can download the DLL and the documentation. http://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ If you want to test the weather stuff then send me a PM and I'll send you the beta version and some sample code. But please get familiar with the basics of reading/writing the more common offsets first. Regards, Paul

In FSUIPC4 (for FSX/P3D) the visibility tab is hidden because the options do not work in FSX. If I remember rightly this is because of bugs in SimConnect. However, it is possible to show this tab and get the broken options anyway by adding an entry in the .ini file. A more detailed discussion of this topic with instructions for enabling the tab can be found in the "FSUIPC4 User Guide.pdf" in the "modules\fsuipc documents" folder under your main FSX installation folder. Look for the section called 'Visibility (optional)'. Paul

SimConnect is installed with FSX and P3D. If your SimConnect installation is somehow corrupt then I believe its very difficult to sort it out. I certainly wouldn't know where to start. However, a bad SimConnect install is very unlikely compared to the other two issues I mentioned which are easily fixed and are known to give the error you posted. You don't say whether you've investigated the version of, or updated, FSXSave and the .NET 2 framework version but those two are place to start. FSXSave is the easiest to check and update. Paul

I don't think this is anything to do with FSUIPC. Either your version of FSXSave is too old (you need V1.05 or you have not got service pack 2 for the .NET 2 Framework installed. To get the latter, either go through windows updates or try the installer here: http://www.microsoft.com/en-gb/download/details.aspx?id=1639 If you have the correct versions then it maybe a problem with SimConnect itself since that's also near the top of the error stack. Paul

This probably won't solve your problem but it needs correcting anyway: You need to set the data before you call Process(), not after. You should set the values of all variables you want to change and then the last thing is to call Process() to actually write that data. Like this: senderfs.Value = &H11000 + 380 '(THIRD_PARTY_EVENT_ID_MIN=0x000011000,senderfs is "offset 3110") ' Set other values here FSUIPCConnection.Process() Paul

HI, You just need to leave the sim in 'slew mode' then. Comment or remove these lines: // Turn off the slew mode slewMode.Value = 0; FSUIPCConnection.Process(); Paul