Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Content Count

    1,270
  • Joined

  • Days Won

    39

Paul Henty last won the day on April 27

Paul Henty had the most liked content!

Community Reputation

69 Excellent

About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
    Male
  • Location
    Gloucestershire, UK

Recent Profile Visitors

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

  1. It crashes because that HVar doesn't exist. You can see the list of LVARs and HVARs found by using LogHVars() and LogLVars(). What do they show? Remember that you need to wait a few seconds after Start() before the WASM module is ready. Paul
  2. There seems to be a problem somewhere other than your code/my dll then. The best thing to do would be to ask John about this in the MSFS support forum under a new topic. If you tell him the WASMClient.exe is connecting but not finding any LVARs he may be able to suggest things to check, Paul
  3. Your code looks okay now. Can you please try running John's WASMClient.exe program to check if that is returning any LVars. You can find it in the FSUIPC-WASMv0.4.10.Zip file. Paul
  4. You'll need to add a call to VS.RefreshData() after the sleep, and before you try to read the LVAR. If it still doesn't work try the following: 1. Waiting longer than 2 seconds. 2. Check the list of LVar names at VS.LVars.Names to see all the LVars that have been found. (If you have logging set up you could also use VS.LogLVars()) Paul
  5. Make sure your exe is compiling and running as a 64 bit process. The FSUIPC_WASPID.dll is 64bit so cannot be loaded from a 32-bit process. In your exe project properties, go to the Build tab. Make sure your platform target is either x64 or "any cpu". If it's "any" make sure the box for 'prefer 32bit" is NOT checked. Paul
  6. I can't help much as I don't have MSFS. From what I know: 1. HVars need to be added to a file somewhere so that the WASM module knows about them. 2. You need to wait a few seconds after calling Start() as the WASM module needs time to discover the variables. 3. HVars do not have values. They are only actions that can be 'Set()'. 4. When you change aircraft or change the HVar files you need to call MSFSVariableServices.Reload() to discover the new variables for that aircraft. If you've added these variables to the file and you've waited for the WASM module then @John Do
  7. Yes, but for Beta versions you must check the box "Include Pre-release" in the Nuget manager.. Paul
  8. My .NET Client DLL now has direct access to LVars/HVars in MSFS from managed code via the MSFSVariableServices class. See here: This uses John's WAPI DLL in the background. Paul
  9. If it is then WheelChocksSet must be 6C60. Paul
  10. Thanks. I also noticed the addresses for some of the old offsets seem to have changed now... Everything from FMC_CruiseAlt onwards has moved 1 byte forward FMC_PerfInputComplete has typo: 6C20 FMC_DistanceToTOD onwards have been shifted forward 4 bytes. Is this intended? Paul
  11. Sorry John, one more error: FIRE_APUHandleIsUnlocked isn't an array, it should be FIRE_EngineHandleIsUnlocked to match FIRE_EngineHandleIlluminated. I've double checked against the .h file and all the others seem okay. Paul
  12. Hi John, I think you uploaded the wrong document - this one you attached doesn't have the arrays and still has COMM_ReceiverSwitches at 6C58. Paul
  13. Hi T, This offset doesn't take the engine number like that. As the offsets document says, each bit in the offset represents an engine. So bit 0 is engine 1, bit 1 is engine 2 etc. If the bit is set to 1 the engine is failed. If 0 it's working ok. The easiest way to work with bits using the DLL is to declare the offset as an FsBitArray: private Offset<FsBitArray> engine_failure = new Offset<FsBitArray>(0x0B6B, 1); Note that the 1 (second parameter) is the length of the offset. This is required for some types like FsBitArray. 1 here means 1 byte as can been seen in
  14. Okay - I'll add these new offsets to my DLL. Paul
×
×
  • Create New...

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.