Jump to content
The simFlight Network Forums

Paul Henty

  • Posts

  • Joined

  • Days Won


Everything posted by Paul Henty

  1. I've found that bug. Please try 0.3.1 - you shouldn't get that particular crash any more. http://fsuipcwebsockets.paulhenty.com/#home Yes it was working then. If there was no connection it would have reported a "NoFlightSim" error. For your connection problem - it sounds like something in the WASM module. The log entries are directly from that module, so not part of my software. To check, please try John's WASMClient.exe which can be found in the "FSUIPC WASM Module 0.5.4" package available at http://fsuipc.com/ If that also fails to connect then you'll need to ask John Dowson about it. It could be that the other WASM module has messed something up. If his client does work then let me know and I'll look into it more on my side. Paul
  2. It looks like John has fixed the problem. Please overwrite your FSUIPC_WAPID.DLL with the one attached. It should work as expected. Paul FSUIPC_WAPID.dll
  3. Yes I can see that here as well. My DLL is just returning the value from the WASM module which seems to be wrong. I've asked John to take a look at this. Paul
  4. Version 0.3.0 is now available on the website. http://fsuipcwebsockets.paulhenty.com/ The zip now contains an extra file FSUIPC_WAPID.DLL which must also be present in the folder you run the server from. The new MSFS Variables feature has its own page in the main form. This shows you the status of the connection to John Dowson's WASM module and allows you to see logging information and list known variables. From the client, access to the MSFS variables (LVars and HVars) is done through the 'vars' command. I've made it work almost identically to the offsets commands for consistency. Once difference is that to write variables, they don't need to be included in any 'declare' first. Any variable can be written at any time. This means the 'vars.write' will not send back a 'read' as it's not tied into a group of variables. In theory calculator code can be run with 'vars.calc' but I've no examples here to try. Full documentation is on the website along with working example code. Paul
  5. I have the MSFS LVar and HVars working in the socket server. Just need to finish the documentation and do a final test. If all goes well I'll release it tomorrow. Paul
  6. First declare yourself a new instance of PMDG_737_NGX_Offsets. Best to do this at the form or module level so you have access to it throughout the code: Private pmdgOffsets As PMDG_737_NGX_Offsets = New PMDG_737_NGX_Offsets() Then when you need the values you call RefreshData() and then access the offsets you want: (You'll need an open connection). pmdgOffsets.RefreshData() ' Get the latest values for the offsets ' Each value is just an offset declared with the correct type. Dim ltsPos As Byte = pmdgOffsets.LTS_PositionSw.Value MessageBox.Show("LTS_Position = " & ltsPos.ToString()) Paul
  7. Hi Allan, I think the only way to set HVars is via the WASM module, so it wouldn't be possible with the SocketServer at the moment. My FSUIPCClient DLL (used by the socket server) now has support for accessing LVars/HVars directly from the WASM module. It seems to be stable now so next week I will expose this via the Socket Server. This will mean you won't need to assign LVars to offsets anymore. You'll have direct access to them with something like "lvar.request". You'll also be able to set HVars and execute calculator code. This will only be for MSFS/FSUIPC7. Paul
  8. You can achieve the same thing by using the same event handler for all the LVars you want to monitor. The eventargs (e) will tell you which LVar has changed... Something like this: this.lVarListen1 = this.VS.LVars["A32NX_ADIRS_KNOB_1"]; this.lVarListen1.OnValueChanged += lVar_OnValueChanged; this.lVarListen2 = this.VS.LVars["A32NX_ADIRS_KNOB_2"]; this.lVarListen2.OnValueChanged += lVar_OnValueChanged; private void lVar_OnValueChanged(object sender, LVarEvent e) { // One of your LVars has changed. // The changed one is e.LVar Log(e.LVar.Name + " has changed to " + e.Lvar.Value.ToString("F4"); } Will that do what you want? Paul
  9. 1 - A new version of the DLL is now on NuGet - 3.2.10 The MSFSVariableServices has had some changes to make it work better. Unfortunately most are breaking changes but they're not that drastic: The VariablesReady property has been removed as that never really worked after it was initially set to true. The OnVariablesReadyChanged event has been replaced with OnVariableListChanged. This fires whenever the WASM module detects new LVars or HVars. You can use this to know when the variables have been detected and are ready to read. 2 - Example Code / Test Project I've added an example project for the MSFSVariableServices to the website: http://fsuipc.paulhenty.com/#downloads C# only at the moment. I'll convert to VB.NET if anyone requests it. 3 - Requirements This new version should be used with version 0.5.3 of the FSUIPC_WAPID.dll or later. Also required is FSUIPC7 V7.2.7 (or later) as this will install the 0.5.3 WASM module into MSFS. Both can be download from http://fsuipc.com/ 4 - Access Violations in CRJ This may or not be fixed with this version. John has increased the number of LVars that can be handled in 0.5.3 which might have have been the problem. Paul
  10. Hi, The equivalent in VB.NET would be: Dim flapStatus As Double = FSUIPCConnection.ReadLVar("L:VC_PED_FLAP_LEVER") Paul
  11. Hi, Yes, another use above has the same issue with a CRJ aircraft. I assume it's Aerosoft. I think it's something to do with the high number of variable this aircraft has. It was too many for the limits baked into WASM module. I can see in the GitHub project that John has expanded the capacity in version 0.5.3. I'm hoping that will fix the issue. The fsuipc.com page still has 0.5.2 so we'll need to wait until John releases the new version to try it. Paul
  12. Ah, okay that's clear. I'd not heard of .evt files before. In that case you can use my DLL to send the control number (also called Event ID): FSUIPCConnection.SendControlToFS(eventID, parameter); Most controls will not take a parameter value, so just pass 0. You'll just need to calculate the ID number as described. So if that's your only .evt file then A320_Neo_MFD_BTN_CSTR_1 will just be control number 32768. A320_Neo_MFD_BTN_WPT_1 = 32769 etc... Paul
  13. I can't really say at the moment because I don't know what these are. I don't know MobiFlight. Are these LVars or HVars that are being triggered somehow? If so you can access them with my FSUIPCClient dll. If these are plain SimConnect events then you'll need to use the SimConnect API rather than FSUIPC. Using the .NET SimConnect wrapper isn't easy however and while there was one for FSX and P3D, I don't know if Asobo have made one for MSFS. If not you'll need to use C++. I have the FBW A320 so I'll have a look at its lvar list and see if I can see that variable. I'll report back later today. Paul
  14. No, but I'm making a simple example project. I expect it will be ready tomorrow. Paul
  15. Your code looks fine. These offsets are new for FSUIPC7 so it looks like a problem specific to FSUIPC7. The historic string offsets like 0x3D00 work fine. Please report this to John Dowson in the MSFS support sub-forum. https://forum.simflight.com/forum/183-fsuipc7-msfs/ It looks to me like the 0 terminator at the end of the strings isn't being written. It also looks like there are double quotes in the string which shouldn't really be there. I guess you could find the end of the string by looking for the second double quote, but that's not really how it's meant to work. There should be a 0 terminator which my DLL will handle for you. Paul
  16. No luck unfortunately. I installed it and run your code a number of times. I saw constant lVar updates and I changed lots of knobs and switches. Then flew around for about 15 minutes. No crashes at all. Paul
  17. I've followed your instructions for the stock CJ4 - changing the panel brightness quickly from 0 to 100. No crashes. Tried 5 restarts of your test app. I also tried the stock a320 using the upper and lower display brightness and also no crashes. Paul
  18. I got MSFS for a month so I can test this properly here. Sadly I can't reproduce the access violation at all. I've tried with my test code and your exact code from three posts up and it runs flawlessly. I did a few 30-minute flights with no problems. I've tried a few different aircraft but I can't see any CRJ so I guess that's in a better version of MSFS or it's third-party. So it could be something with so with the CRJ. Do you also get access violations with the built-in aircraft? Paul
  19. Okay - well I guess John was wrong that you can just pass 0 or any other value. I'll remove this from the next version. I'll look into this over the weekend. Paul
  20. Everything looks okay to me. I suggest using FSUIPC to log the A000 offset. This will take my DLL and your C# application out of the equation. In FSUIPC7 select Log->Offsets and log A000 as S32 (signed 32bit) a the MSFS Title bar: With your Lvar to offset set up in the ini file. you should see the value of A000 appear on the title bar. If it's 0 there then the problem is with your FSUIPC setup. You can go back to John with this logging result and without any C# code. If you can see a good value there then it's something in the C# side of things and we can continue here. Sorry this is frustrating for you, getting passed back and forth from me to John, but hopefully this strategy will make it clear where any problems are and you can go to the right person. Once you can see valid values in the offset with the FSUIPC7 logging then you can bring the C# part back into play. Paul
  21. Ah so the CRJ isn't resetting the LVar itself. That's a pain, so yes you'll need to do this yourself. The delay requirement is likely to be down to a timer somewhere. Maybe the CRJ code checking the LVAR value, maybe FSUIPC checking the offset value. If you change it to 0 and then back to 1 too quickly (between another component's timer tick) then it won't notice the change. That would be my guess. There is also a whole chain of communication from my DLL to FSUIPC to the WASM module to SimConnect to the CRJ code so there are a number of places it could get missed if you change values too quickly. Paul
  22. Yes, normally offset values are read from the sim when you call Process(). They only write if the value has changed. So setting the value to 1 when you have previously set the value to 1 won't trigger the write. Your code would be fine if the LVar took an explicit value for each state (which is usually the case), but since it's toggling with a 1 you'll need to use a write-only offset. These write on every process() even if their value has not changed. Because of this it's advisable to put them in their own group so you can control when they are written. var offset = new Offset<byte>("ToggleHeading", 0xA000, true); // write only Then your code will only need this: offset.Value = (byte)1; FSUIPCConnection.Process("ToggleHeading"); This uses a special offset that instructs FSUIPC to send the LVAR value. It's write only and clears itself internally after each request. So every time you call this method the Lvar gets written regardless of the previous value. Paul
  23. I can't test this myself as I don't own MSFS. Your c# code looks fine. I don't think the problem is there. I notice you're using a profile called crj. Are you sure you've set this up properly in FSUIPC? Are you sure it's being used (active)? You could try it without using profiles - just change the section to be global: [LvarOffsets] 1=L:ASCRJ_FCP_HDG=UB0xA000 If that works then your crj profile isn't set up properly or isn't being activated. If it still doesn't work then John is really the person to help you on this. If you show him your full fsuipc.ini file he might be able to spot the problem. It's working via all the other code methods so the problem will be somewhere in your FSUIPC configuration. Paul
  24. @kingm56 @activex Version 3.2.9 BETA is now on NuGet. (Tick 'Include Prerelease' to see it). This might fix the access violation problems. I've changed the way the incoming strings are handles from the C dll. It was technically wrong before so I'm hoping this will fix the problems. Also there are new overloads for Init() so you don't need to pass a window handle. The DLL will handle this internally. Paul
  25. Understood. It's most likely a problem on my end. I think I've found a mistake with the way I'm marshalling the strings into the managed code so hopefully that will sort it. @activexI'll update the thread in my sub-forum later today when I have a new version for you to test. 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.