Jump to content
The simFlight Network Forums

Paul Henty

  • Content Count

  • Joined

  • Last visited

  • Days Won


Paul Henty last won the day on November 14

Paul Henty had the most liked content!

Community Reputation

49 Excellent


About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
  • Location
    Gloucestershire, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Paul Henty

    Reading LVars over WideFS

    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
  2. Paul Henty

    Reading LVARs through WideFS

    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
  3. 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
  4. Paul Henty

    Reading LVARs through WideFS

    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
  5. Paul Henty

    Reading LVARs through WideFS

    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
  6. Paul Henty

    Reading LVARs through WideFS

    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
  7. Paul Henty

    Reading LVARs through WideFS

    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
  8. 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
  9. 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
  10. 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
  11. Paul Henty

    Coordinates returned as 000

    Hi Aidas, The problem is that the text boxes are using these form variable that you've defined: private FsLatitude latitude; private FsLongitude longitude; this.lat.Text = this.latitude.ToString(false, "d", 6); this.lon.Text = this.longitude.ToString(false, "d", 6); But these variables are only ever set in the constructor (i.e. when the form loads): public frmMain() { this.latitude = this.playerLat.Value; this.longitude = this.playerLon.Value; So they will always be 0 degrees. You either need to update these variables after every process, or just use the offset directly. I can't see much point in using another variable... this.lat.Text = this.playerLon.Value.ToString(false, "d", 6); this.lon.Text = this.playerLat.Value.ToString(false, "d", 6); Paul
  12. Hi Lennart , 6576 is an offset, not a control. The PMDG offsets are read-only. The controls are listed in the PMDG SDK. My post below explains how to use the SDK to set up buttons and key presses in FSUIPC. It will give you some background about the SDK, show you where to find the it, and explains how to work out the control numbers and parameter values. The key/joystick button binding requires a registered FSUIPC. However, if you want to use these controls from C++ you have 2 choices: 1. Use FSUIPC offset 0x3110 to send the control (with the parameter) to the sim. See the Offsets Status PDF for details on how to use this offset. 2. Use the PMDG SDK directly to communicate with the aircraft. It's written for C++. I'm not a C programmer so I've no idea how, but presumably it will either be obvious to you as a C++ coder, or PMDG will have some documentation/tutorials. Paul
  13. Paul Henty

    Elevation data by fsuipcclient ?

    No, this is not possible with FSUIPC or my DLL. The easiest solution would be to add the airport elevations to your database. Pete makes a program called MakeRunways. Available in this thread in the downloads sub-forum: https://forum.simflight.com/topic/66136-useful-additional-programs/ This extracts airport and runway information from the users' BGL files. This includes airport elevations. My DLL (version 3) has an airports database which reads the output files from MakeRunways and gives you easy access to airport and runway data from .NET. See the section called "Airports Database" in the example code application. This doesn't seem to be available in MakeRunways, so it's not in the DLL's Airports Database. You'll have to source those yourself. Paul
  14. Paul Henty

    FSUIPC To Excel?

    I'm not sure what you're asking with regard to the spare offsets. Reading and writing lvars with FSUIPC is done using two specific offsets. One offset is where you write the name of the lvar you want. The other offset is where you read the result (value). No spare offsets are needed. I can't tell you the actual offset numbers until next week, but they are clearly listed in the offset status list. Search for the word Lvar or L:var. Have you looked? Paul
  15. Paul Henty

    FSUIPC To Excel?

    Maybe. FSUIPC has a facility to read and write LVars. You need to be able to write a string (The name of the Lvar) to an offset. Can the Excel code do that? If you search for Lvar or L:var in the FSUIPC offsets list you'll find the offsets you need and how to use them. I'm away at the moment, back on Sunday. If you can't get it to work I'll be able to help more next week. I don't have access to the documentation right now. Paul

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.