Paul Henty

Yes that's what the DLL does. It first gives focus to the flight sim. Then it sends the key you requested. It will then restore the focus to your own application window. But only if you ask it to (third parameter). When you call FSUIPCConnection.Open() it will thrown an exception if a flight sim or WideClient.exe is not running. You should catch these exceptions to know that FS is not running. When you call other functions that talk to FSUIPC e.g. Process() or SendKeyToFS(), these will also throw exceptions if the connection has been lost. You can examine the FSUIPC Application Templates to see the recommended way to handle the connection management. http://fsuipc.paulhenty.com/#downloads Paul

Thanks Matthias, Yes, FS must have the focus. That's just how Windows works. The DLL handles this for you though and can give the focus back to your form if you need to. Paul

Hi Matthias, There is now a function in the DLL to send key presses to the sim. Sending Tab+1 would be this: FSUIPCConnection.SendKeyToFS(Keys.D1, SendModifierKeys.Tab); This also takes care of setting focus to the sim first. If you want to return focus to your own application, include a reference to this form as the last parameter. For example if the code is part of the form class: FSUIPCConnection.SendKeyToFS(Keys.D1, SendModifierKeys.Tab, this); The modifiers in the .net "Keys" enum are not the same as the modifier codes used by FSUIPC. I had to make my own enum for the DLL (SendModifierKeys). For future questions, please make a new thread in my sub forum. Kind Regards, Paul

The current version of my FSUIPCClient.dll (3.1.5) is mixed mode. meaning you can use it in 64 or 32 bit applications. This version is only available on NuGet. Instructions for installing and upgrading from earlier versions can be found here: http://fsuipc.paulhenty.com Paul

It's just a standard .NET class library dll. If you installed it via NuGet then it has been automatically added as a reference. Check the references for your project and you'll see it. The actual dll file will be copied to your build folder (debug/release) as normal. I think the official SDK has a very old version of the dll (maybe 2.0). A lot of new stuff went into 3.0 including the LVar read/write. I moved to NuGet as it's much easier to publish new versions and keep everyone alerted to new builds. Paul

My .NET library for talking to FSUIPC from .NET languages. That's what this subforum is for. Details about the DLL are here: http://fsuipc.paulhenty.com If you're not using a .NET language then let me know and I'll give you the steps you need for talking directly to FSUIPC. Paul

Yes. If you are using the latest version of my DLL (3.1.5 or above) you can now use: FSUIPCConnection.ReadLVar(Name) and FSUIPCConnection.WriteLVar(Name, NewValue) Paul

Hi Mattias, 0x3380 is only for writing your own messages to the sim. It doesn't read text from the sim. As far as I know, there is no way of intercepting messages generated by the sim with FSUIPC. Paul

Hi Vince, Generally, to achieve what you want, you need to be checking the altitude regularly in a timer. If the altitude is 10000 AND the checkbox is checked then you need to pause. However, the altitude may never be exactly 10000, it might go from 9999 to 10001 so you need to test a range. Something like this (Not real code): TimerEvent: FSUIPCConnection.Process() alt = getCurrentAltitudeInFeet() if alt < 10100 AND alt > 9900 AND pauseAt10000 is checked pauseSim() pauseAt10000.checked = false end if Paul

Hi Machado, FSUIPC4 only supplies 2 decimals. I think that's all that's supported in FSX. If you know the spacing between the frequencies in real life you can infer the third decimal. For example, 118.720 may not be a valid frequency, so you can assume it's actually 118.725. I think that's what these planes are doing. If not, they are handling the third decimal internally. You may be able to access it using the plane's SDK if it has one. I don't know if this is different in FSUIPC5 (P3D). You might want to ask Pete about this when he's back. Paul

Hi Jesús If you log into your SimMarket account you can see all of the products you have purchased. Use the 'Your Account' menu and select 'Purchase History'. Find FSUIPC4 and click on the order. This will show you your key, and the name and email address you used. When you register FSUIPC these must be exactly as they appear in the order. Copy and Paste is recommended. Paul

That's the same log as you attached in your first post. The logging options aren't enabled. I think the best thing to do would be to delete all the .log files in the modules folder, then try again. Start FSX Open the FSUIPC interface Enable the logging options Recreate the problem with the landing gear/hud Close FSX Paul

Hi, That's not the correct log file. Can you try again, or find the one that's just called FSUIPC4.log. If you can't upload it just open it in notepad and copy and paste the text directly into your reply. (You can use the <> icon on the editor menu bar to make it easier to read). Thanks, Paul

Hi Steve, I'm not familiar with CCP at all. Are the original devs are not around any more? They would be the best people to ask. If you can't contact them, you can send me an FSUIPC log with these options enabled (only these): IPC Writes Button and Key Operations Events (non axis-controls) (See the logging tab in the FSUIPC dialog). I'll be able to tell you if CCP is intercepting any buttons or key presses. With the logging enabled, run FSX/CCP and reproduce the error. Then close FSX and show me the contents of the FSUIPC4.log from the modules folder. Please start a new thread in this sub-forum if you do. Paul

Hi Michael, Unfortunately that FSUIPC facility only works with user-added menus, not the built-in ones. FSUIPC can tell you if the user is using the menus or a resulting dialog (see 0x3365) but not which one. If you just want to detect the reload then try offset 0x3F02 (ushort). This is a counter that increments each time a flight is loaded or reloaded. The reset might just re-load the same flight and increment this counter. Another idea is that your application could offset a reset-flight option that just sends the appropriate control to P3D (try SITUATION RESET 65591). But at least you know when it happened. It might also be worth asking Pete (in the main forum) if he has any ideas. Paul

I understood this to mean that you can use the same process call to read the value: and doing that seems to work fine locally. I get the idea for the loop, but that would be too slow for monitoring many LVARs in real time. I'll make a note in the DLL documentation that the LVAR feature doesn't work over WideFS. Thanks, Paul

I've just seen that Pete's away until Friday. I've posted my question in the main forum, so we'll have to wait until he gets back to see if anything can be done. Paul

Hi Pete, One of my DLL users has a problem with reading LVARs over WideFS. It's fine locally. I've tested this myself and I get the same problem here. For best performance my DLL writes the LVAR request and reads the result in one process, as described in the documentation. 1. Write user address to 0D6C 2. Write LVAR name to 0D70 3. Read result from user address However over WideFS this really isn't working as expected. The value returned is from the previous LVAR request (if a long enough gap is left between reads)... Read LVAR1 Sleep Read LVAR2 Sleep Read LVAR3 etc.. This gets the previous LVAR value. If there is no gap... Read LVAR1 Read LVAR2 Read LVAR3 They all get the same value. I'm guessing this is because the process() on WideClient is not synchronous with the network updates so it's not waiting around for the correct result to come back. It's just supplying the cached value it already has in the user offset. The only solution I can see is to get the result a short time after requesting the data (i.e. in two process() calls). This is not great because it'll be much slower and I can't be sure of how long to wait. If I find a delay that works on my network, it may not work on another developer's, or end user's network. Do you think there is anything that can be done in your code to help with this? Or do you have any other suggestions for a solution? Thanks, Paul

Understood. Thanks. I think I know what the problem is. I'll need to speak to Pete about it and get back to you. Paul

Okay, that rules out threading problems. So it's something to do with WideFS. Can you clarify a few things... How are you operating the lights? Directly in the sim? Writing to offsets/controls? When you say all the lights turn OFF, do you mean in the sim, or just that your program is reading them as OFF but they are really still ON. Paul

The async call looks okay from what you've posted. That's probably the best way to proceed with these kind of issues. If you just make a single-thread program that read/writes the lights LVARS and see if there's any difference when you run over WideFS. That will at least tell you if the problem is with LVARS over WideFS or if it's more to do with the way you're calling the DLL (probably some kind of threading problem). Paul

Hi Nuno, I've had a look at my code. I can't see anything that would be an obvious problem on WideClient rather than a direct connection to the sim. There is nothing that is sensitive to timing in the DLL code. One thing to note is that DLL uses 'user offsets' 0x66F8 to 0x66FF inclusive to transfer the LVAR value. When you test with WideClient, do you have any other FSUIPC programs running that might use this offset that are not running when you test locally? @Pete Dowson The documentation for the LVAR read/write says that everything can be done in one process. That's how I've done it to get the best performance. Is there anything about the WideFS connection that could mess this up? Values cached locally in WideClient for example? Paul

WideFS (WideServer & WideClient) is not for splitting visuals across different PCs. It extends the FSUIPC interface over a network. This is so programs that use FSUIPC can run on networked machines. Yes, this is by design. WideClient pretends to be FSX or P3D. This is so FSUIPC programs are tricked into thinking there is a copy of FSX/P3D running on the machine. You can't run both. It sounds like you are getting confused with another product called WideVieW. That program is for running external views on networked PCs and links copies of FSX/P3D together. Paul

That lua script will only run through once and then terminate. You need to be constantly checking the LVAR in a loop. Or, better still use event.LVAR to execute your function when the value of the flaps changes. Something like this (I'm not a LUA expert). function setFlaps(varname, flappos) if flappos == nil then -- if there is no LVAR like this do nothing because the pilot is not flying an FSLabs Airbus else if flappos == 0 then -- if there is an LVAR like this and if it is 0 then do nothing because FSUIPC already returns 0 else -- if there is an LVAR with this name and if its value is not 0 then lets begin if flappos >= 100 and flappos < 200 then ipc.writeUD(0x0BDC, 4096) end if flappos >= 200 and flappos < 300 then ipc.writeUD(0x0BDC, 8192) end if flappos >= 300 and flappos < 400 then ipc.writeUD(0x0BDC, 12288) end if flappos >= 400 then ipc.writeUD(0x0BDC, 16384) end end end end event.Lvar("L:VC_PED_FLAP_LEVER",500,"setFlaps") Alternatively, you could use the LVAR facility in my Client DLL and build it into the application. double flapStatus = FSUIPCConnection.ReadLVar("L:VC_PED_FLAP_LEVER"); Paul

Hi Noah, You haven't made a mistake. Some add-ons (mainly the complex, study-level aircraft) use their own code for things like autopilot. They don't use the normal autopilot built into FSX/P3D. This means that the normal offsets won't have the correct data. You need to get the data a different way for each add-on. I'm not sure about Aerosoft but for PMDG can use the offsets specified in: \Modules\FSUIPC Documents\Offset Mapping for PMDG xxxx.pdf Paul