Paul Henty

If you have a registered copy of FSUIPC you can enable 'event' logging and then operate the controls via the mouse or keyboard to see the controls the aircraft is using. However, it may not use standard FSX controls. Complex third-party aircraft like iFly and PMDG tend not to use the built-in FSX controls. Instead they build their own systems simulation separate from FSX. It's not unusual that SimConnect and FSUIPC do not work with these aircraft. iFly have their own SDK which might enable you to do what you want. I would suggest you have a look at that or ask this question to iFly technical support or in one of their forums. Paul

Another thing to check is that the date on your PC is set correctly. Paul

Offset 0x6535 is only 1 byte so you really need to use: VSI = ipc.readUB(0x6535) However I think you have another problem because using readUW (reading 2 bytes) will not produce nothing, it will just give you the wrong value. I don't have any PDMG aircraft so I can't test this here myself. Here are some things you can try: 1. Use the FSUIPC Logging tab to log the 0x6535 offset to the FSX Screen. Use the section on the right "Specific Value Checks". Enter the hex address and set the type to 'U8'. Tick the box to display to the FS Window. If this shows the wrong value then there is something wrong with the link between FSUIPC and the PMDG aircraft. If this is correct then there is something wrong with the LUA script. 2. Try reading one of the standard offsets in your LUA script, for example the pause indicator. (2 bytes) ipc.readUW(0x0264) If this shows 1 when you pause the sim and 0 when not paused then you will know your lua script is running properly. If this doesn't work then the problem is with the lua script, or running the lua script, and not with the PMDG offsets. 3. Make sure you are using the latest version of FSUIPC (4.393n) If you need more help, please let me know the result of tests 1 and 2. Also please describe the problem in more detail. For example are you getting a display window or not? Are you getting any value displayed? If so what is it? Are there any errors in the FSUIPC4.log file? Paul

In FSUIPC the block of PMDG offsets is read-only. To write to the PMDG NGX you must send controls to the flight sim. The control numbers can be seen in the document called "PMDG_NGX_SDK.h" which comes with the PMDG SDK. The relevant section begins with the comment '// Control Events'. To write controls in LUA use: ipc.control(n) or ipc.control(n, param). Controls can also be bound directly to Keys and Joystick buttons in the FSUIPC interface. Paul

They are also wrong in FSX. The data used for the airports is quite old. In January 2011 the runways were renumbered because of a change in the magnetic variation. There is only a one degree difference. Source: http://phys.org/news/2011-01-tampa-airport-runways-renumbered-due.html Paul

Hi Tommy, I don't think you need to write any 'keystrokes' as you don't need to generate these on the WideClient pc. You just need to tell WideClient to run the programs when you send the key messages from the server (SendKeys). So, in the WideClient.ini you need something like this: [User] Run1=C:\Program Files\TRC Development\The Real Cockpit\TRCLink.exe RunKey2=C:\Program Files\SimkitsUSB\USBFSUIPCLink.exe KeySend2=RunKey2 RunKey3=C:\Program Files\Ruscool Electronics Ltd\Radio Displays\Radio Displays.exe KeySend3=RunKey3 RunKey4=C:\Program Files\Ruscool Electronics Ltd\64 Inputs and Encoders\64 Inputs and Encoders KeySend4=RunKey4 RunKey5=C:\Program Files\Ruscool Electronics Ltd\Bell 206 Annunciators\Bell 206 Annunciators.exe KeySend5=RunKey5 Then on the FSX PC you need to go into the FSUIPC dialog and program keys 1-4 to send these key numbers (2-5). If you haven't already done that here's how to setup key 1 to send code 2: 1. Open the FSUIPC Dialog and go to the 'Key Presses' tab. 2. Press the [set] button, then press the key you want to bind (in this case the '1' key) 3. In the dropdown called "control sent when keys pressed" select the option "KEYSEND 1-255 (WideFS)" 4. In the "parameter" field enter the code number you want to send. In this case it's 2. 5. Press the [confirm] key. Pressing key 1 in FSX:SE will now launch the program marked in WideClient.ini as RunKey2. Just repeat for the other keys. Paul

Hi Tommy, The delays are not working because all your "delay ready" commands are spelt wrong. Some don't have the numbers after them, some are missing a y. Here's what is should look like: Run1=C:\Program Files\TRC Development\The Real Cockpit\TRCLink.exe Delay1=60 RunReady2=C:\Program Files\SimkitsUSB\USBFSUIPCLink.exe DelayReady2=30 RunReady3=C:\Program Files\Ruscool Electronics Ltd\Radio Displays\Radio Displays.exe DelayReady3=60 RunReady4=C:\Program Files\Ruscool Electronics Ltd\64 Inputs and Encoders\64 Inputs and Encoders DelayReady4=30 RunReady5=C:\Program Files\Ruscool Electronics Ltd\Bell 206 Annunciators\Bell 206 Annunciators.exe From reading the manual, I think this will do what you want. Paul

I haven't, no. I've never looked into SimConnect at all. Paul

Hi Motus, As far as I know there's nothing in FSUIPC that can create AI aircraft. For AI aircraft that exist it may be possible (but difficult) by sending normal FS controls to the AI Aircraft. See offset 0x2900 for details. The ID of each AI aircraft can be seen using the AITrafficServices built into the DLL. I've never tried using 0x2900 but I think you need to put the AI aircraft into Slew mode and then use the slew controls. I found this thread that talks about doing something similar with SimConnect. I don't know SimConnect but maybe you can understand this? http://www.fsdeveloper.com/forum/threads/program-control-by-ai-plane-on-a-c-through-simconnect-for-fs-x.206308/ Paul

Thanks for the suggestion. Later this year I will be creating a Nuget package for the DLL, documentation, sample code and project templates. I prefer this solution over a repository because I don't see any need to open-source the dll at the moment. Paul

Hi Eamonn, The FSX:SE value in the enum should not be there. When FSX:SE first came out there was some confusion about what product ID FSUIPC should use. For a short time it was reporting as a different product (or maybe even erroneously as ESP). However, Pete decided that FSUIPC should report it as FSX, so that's what my dll will now say. It's just relaying what's in offset 3308. I forgot to remove the enum value. If you want to narrow the version down further then the correct way is to do an additional check of 3124 as you've mentioned. I will be improving the way products and versions are handled by the dll in a future version. Paul

Hi Raimund, The formula I was using for distance and bearing were not the 'great circle' ones you posted and linked to. I'm not sure how you got my DLL to say the distance between LOWG and EGLL is 732NM. I tried with this code and it came back only 3 NM over. FsLatLonPoint LOWG = new FsLatLonPoint(new FsLatitude(46.991067), new FsLongitude(15.439628)); FsLatLonPoint EGLL = new FsLatLonPoint(new FsLatitude(51.4775), new FsLongitude(-0.461388)); double distance = LOWG.DistanceFromInNauticalMiles(EGLL); I only mention this in case you've got something wrong in your code. Anyway, I've replaced the formulas with those from the web page you linked to. New version is attached. Using the same code above it now reports 677NM and 299 degrees, which is consistent with this web page: http://www.ig.utexas.edu/outreach/googleearth/latlong.html Thanks for reporting this and linking to the formulas. Paul FSUIPCClient3.0_BETA.zip FSUIPCClient3.0_BETA.zip

Hi Raimund, I'm pretty sure I'm using different formulas than you posted. It's likely that the current formulas are either fundamentally inaccurate or, as you suggest, there could be a rounding problem. Let me check it out over the next few days and I'll get back to you with a fix or further comments. Regards, Paul

Yes, if you don't like the blocking behaviour on the main UI thread. The DLL was first written about 9 years ago against the .NET 2 framework. Back then multi-threading and async was not as easy as it is now in .NET 4. I'm considering dropping .NET 2 support for the next version. If I do, I can make 'asnyc' versions the IO methods so that it doesn't block the UI thread and you'll be able to use a 'callback' model if you prefer this. But for now, if you're using .NET 2 or above you can use the BackgroundWorker class to call Open() and Process() etc. If you're using .NET 4.0 or above then you can also use the new Task class. The other thing you can do is design your application to minimise the time spent doing things that will potentially block the thread. For example, having a button or menu option that the user can use to connect to FS, rather than having your program automatically looking for a connection until if finds one. Paul

The error is thrown because FSUIPC did not receive the weather from SimConnect within the time limit. The default time limit is only 1 second. This was okay on the airports I tested on, but it seems some stations take much much longer to respond. To increase the waiting time set ws.LocationReadTimeout to the number of milliseconds to wait. I found 20 seconds was a better setting, but you can go higher if you want. Just remember that if the station really is out of range it will keep trying for the whole timeout. FSUIPC.FSUIPCConnection.Process(); WeatherServices ws = FSUIPCConnection.WeatherServices; ws.LocationReadTimeout = 20000; // try 20 seconds. string weather1 = ws.GetMetarAtLocation("LSZH"); FsWeather weather = ws.GetWeatherAtLocation(Convert.ToDouble(airport.Latitude_deg), Convert.ToDouble(airport.Longitude_deg)); foreach (FsWindLayer wl in weather.WindLayers) { double direction = wl.Direction; double speed = wl.SpeedKnots; } Paul

The process() call in my test form is just to update the player location (this.playerLatitude and this.playerLongitude). I just wanted to check that it was okay calling Process() and accessing offsets on a different thread. Most of the internal trigonometry involving lon/lat uses values that are offset by 180 (lon) or 90 (lat) degrees so that there are no negative values to deal with. So for example the longitude runs from 0 to 360 degrees instead of -180 to +180. It's many years since I wrote this but I'm guessing it kept the maths formulas more simple. Glad to hear you've sorted your problem. Paul

I've replicated what you are doing (as far as I can tell) and I can't see any problems. Below is the short test form I set up that creates a quad using FSLatLonPoints and then tests the player's position. There are two buttons, one runs on the main thread and the other on a background worker thread. Both come back instantly. I think there is something else in your code that is causing the issues; the DLL itself seems quite happy with being called from other threads. using FSUIPC; using System.Threading; // Form is called 'frmBackgroundThread' // Two button on the form called 'btnMainThread' and 'btnBackgroundThread' // Test will return 'true' when on runway at EGJJ private Offset<long> playerLatitude = new Offset<long>(0x0560); private Offset<long> playerLongitude = new Offset<long>(0x0568); public frmBackgroundThread() { InitializeComponent(); } private void frmBackgroundThread_Load(object sender, EventArgs e) { FSUIPCConnection.Open(); } private void frmBackgroundThread_FormClosing(object sender, FormClosingEventArgs e) { FSUIPCConnection.Close(); } private void btnMainThread_Click(object sender, EventArgs e) { bool testResult = createAndTestQuad(); MessageBox.Show("result on main thread was: " + testResult.ToString()); } private void btnBackgroundThread_Click(object sender, EventArgs e) { BackgroundWorker bw = new BackgroundWorker(); bw.DoWork += bw_DoWork; bw.RunWorkerCompleted += bw_RunWorkerCompleted; bw.RunWorkerAsync(); } void bw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) { MessageBox.Show("result from background thread was: " + e.Result.ToString()); } private void bw_DoWork(object sender, DoWorkEventArgs e) { e.Result = createAndTestQuad(); } private bool createAndTestQuad() { FsLatLonPoint NE = new FsLatLonPoint(new FsLatitude(49, 20d), new FsLongitude(-2, -10d)); FsLatLonPoint NW = new FsLatLonPoint(new FsLatitude(49, 20d), new FsLongitude(-2, -20d)); FsLatLonPoint SE = new FsLatLonPoint(new FsLatitude(49, 10d), new FsLongitude(-2, -10d)); FsLatLonPoint SW = new FsLatLonPoint(new FsLatitude(49, 10d), new FsLongitude(-2, -20d)); FsLatLonQuadrilateral quad = new FsLatLonQuadrilateral(NE, NW, SE, SW); FSUIPCConnection.Process(); FsLatitude testLat = new FsLatitude(this.playerLatitude.Value); FsLongitude testLon = new FsLongitude(this.playerLongitude.Value); FsLatLonPoint testPoint = new FsLatLonPoint(testLat, testLon); return quad.ContainsPoint(testPoint); } If you need any more help with this let me know, Regards, Paul

HI, The FSLonLatPoints are only local-memory structs and all the calculations are done by locally by the DLL. Nothing is created in FSX/FSUIPC. It certainly shouldn't take 25 seconds to new up 4 instances of these. I'll try it here on a background thread and see if I can see the problem. It does sound like some kind of cross-threading blocking. I'll get back to you with my findings and hopefully a fix. Paul

I assume these cycle through the points already defined in a mission; so you would need to know all the points when you create the mission. You can send these controls via offset 0x3110. Declare this offset as an <int>, then set the value to the number of the control. Paul

I don't know sorry. I can only give support for the use of my DLL. I don't know anything about missions. You should ask on a forum dedicated to creating missions. Paul

Yes, you can create them as part of a mission using a mission editor, or writing the XML file yourself. My DLL is nothing but a way of using FSUIPC from .NET. There are no facilities in FSUIPC to create mission POIs. Paul

Sorry, I don't know how to create the green arrows. It's not something that FSUIPC deals with. Paul

Hi, I've tried it here and the accuracy of PS.FuelLevelUSGallons is correct to many decimal places. It could be that version 2.4 (which you are probably using) has a bug in it. I've attached version 3 (beta) if you want to try that. I see you've worked out how to add fuel. You've probably also worked out you need to call PS.WriteChanges() after you've made all your adjustments to send the data to FSUIPC. I only mention it because it's not in the code you posted. Paul FSUIPCClient3.0_BETA.zip

Okay I get it now. :-) New version attached with the non generics GetValue. Paul FSUIPCClient3.0_BETA.zip

Okay - from your previous post you have this: string val2 = (string)offset.Get(typeof(string)); Is this what you want? object Offset.GetValue(Type returnAsType); Paul