Jump to content
The simFlight Network Forums

John Dowson

Members
  • Posts

    13,226
  • Joined

  • Last visited

  • Days Won

    270

Everything posted by John Dowson

  1. Ah...apologies - in my previous response I was thinking of MSFS / FSUIPC7 (event though you clearly state you were using P3Dv5. Sorry about that. Please ignore what I said about presets and the MF HubHop site - these will also be for MSFS / FSUIPC7 only. For FSUIPC6, it is on page 36, section Additional Simulator Variables (simvars) to FSUIPC Offsets (v6.1.8 and later only). However, I doubt very much that those simvars exist in P3Dv5. You could try listing the available lvars to see if there is one that holds avionics bus state. There is a control provided for this - List Local Panel Vars - assign that to a button or keypress and use it to list the available lvars in the FSUIPC6.log file (or, better, check the Send to console window checkbox to see them logged). If there is one available, then you can add this to a free FSUIPC offset, although you would need a lua script for that (I can help you with this if needed). John
  2. That seems to be in offset 0x3101 - GENERAL ENG MASTER ALTERNATOR:1 Avionics Bus 2 looks to be in offsets 0x2E80 and 0x3103 (AVIONICS MASTER SWITCH). There doesn't seem to be an offset for bus 1. However, looking at the MF presets for the C172 (https://hubhop.mobiflight.com/presets/): C_172_AVIONICS_BUS_1_ON: (A:CIRCUIT SWITCH ON:24, Bool) ! if{ 24 (>K:ELECTRICAL_CIRCUIT_TOGGLE) } (A:CIRCUIT SWITCH ON:24, Bool) 1 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:4, Bool) != if{ 4 1 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) } C_172_AVIONICS_BUS_2_ON: (A:CIRCUIT SWITCH ON:25, Bool) ! if{ 25 (>K:ELECTRICAL_CIRCUIT_TOGGLE) } (A:CIRCUIT SWITCH ON:25, Bool) 2 (>A:BUS LOOKUP INDEX, Number) (A:BUS CONNECTION ON:5, Bool) != if{ 5 2 (>K:2:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE) } This would indicate that the state of the avionics bus switches is held in the simvars A:CIRCUIT SWITCH ON:24 for bus 1 A:CIRCUIT SWITCH ON:25 for bus 2 These are currently not held in any FSUIPC offsets. You can add them yourself using the facilities to add any simvar to a free FSUIPC offset, described on page 34 of the Advanced User guide. Generally, to find an offset that holds the state of a switch, you should first check the Offset status document to see if anything looks relevant, and then try logging that offset using FSUIPC's offset logging facilities. Then see if the value changes when you move the switch - you can keep the logging console open using the Log->Open Console menu option and you will see the logged offset value change, if it is being used. If there are no offsets that look applicable, you should then look at the preset code that controls the switch (on the MF HubHob site referenced above). This should give you a clue as to where the information is held, either in a simvar (A: type variable) or an Lvar (L: type variable). If there is one, then both a-type and l-type variables cam be added to FSUIPC offsets amd them used. John
  3. Ah, ok....thanks for letting me know. Very strange... John
  4. Ok...then it already sets the FS to the foreground. Strange it isn't wotking as the key presses are being sent, and as the key presses work directly in MSFS. Did you notice when this stopped working (e.g. after what update)? Sorry but I haven't had time to look at this today - will hopefully get a chance tomorrow... Cheers, John
  5. Thanks Paul - I have updated the 7.3.17a-beta downloadable zip with this websocket server update. John
  6. Yes, should be - I will take a look later today - need to pop out for a few hours. I will let you know once I have taken a look. Also, please remember that when you attach log files, please attach a full log file and not a continuation log (i.e. don't use the New log feature). Does it work if you manually give MSFS the focus? Also. please check that you are using the latest official release 7.3.16, or the latest beta 7.3.17a (available from the Announcements sub-forum). Thanks, John
  7. Does MSFS have the focus? MSFS needs to have the focus to receive key events. Alternatively, you can set the following parameter in the [General] section of your FSUIPC7.ini file: SetForegroundOnKeySend=Yes Otherwise you can use ipc.keypressplus with an option parameter of 4 to change the focus to MSFS before the keystroke is sent, or 12 to do this and also return the focus to the original active window after the keypress has been sent. John
  8. They are presets - custom controls are yet another mechanism, and only available if provided by an aircraft (e.g. PMDG). You should get familiar with presets and the MF HubHop site which provides a good search interface, and they are (or should be!) very easy to use in FSUIPC7.
  9. It is most probably due ti the name of the file - it must be a substring match to the name of the aircraft as known by FSUIPC. To see what this name is, open your FSUIPC7.log file and look for the logged name, e.g for the C172 it logs the following: 52406 Aircraft="Cessna Skyhawk Asobo" so I would name the hvar file Skyhawk,hvar. Also be aware that it is far easier to write a preset to use a hvar than messing around with hvar files. For example, to create a preset for the vision jet for the H:checklist_scroll_up hvar, create a file called myevents.txt and add the following line: VisionJet_CheckList_Scroll_Up#(>H:checklist_scroll_up) In fact, you don't even need to do this as a preset already exists for this, called SF50 Checklists Scroll Up. You can assign to this directly by checking the Select for preset checkbox in the assignments dialog. Please see https://hubhop.mobiflight.com/presets/ for a list of available presets fir the Vision Jet - there are currently 103 available. John
  10. See https://hubhop.mobiflight.com/presets/ Please read the documentation on the WASM and using presets, in the Advanced User guide. John
  11. Try changing aircraft and then restart... Note that the reload function shouldn't be needed in the next version of the WASM / WAPI, as it will periodically (at 6Hz) scan for new lvars and automatically push them to clients if/when found. I will release this version, as well as an FSUIPC7 7.3.17-beta, later today. The total number of lvars supported will also increase from 3066 to 9198. John
  12. I have provided functionality so that you can add any simvar (or A:type variable) to a free FSUIPC offset - see the Advanced User Guide section Adding Simulator variables (simvars) to FSUIPC offsets on page 34. I added this functionality as I am not planning on adding any more simvars to offsets unless they are general simvars and used by many aircraft (and also have been requested). It should be relatively straightforward for you to add the simvars that you want - TURB ENG FUEL FLOW PPH:5 and TURB ENG FUEL FLOW PPH:6 (or possibly TURB ENG CORRECTED FF:5 and TURB ENG CORRECTED FF:6). If you have difficulties (after reading the documentation and trying for yourself) then post again and I can assist. John
  13. Btw and fyi, the execute_calculator_code function is a Gauge API function, not a simconnect function. The SimConnect ClientData areas are used to communicate from the Client to the WASM (that implements the Gauge functions) and back, and so the underlying mechanism is inherently asynchronous.
  14. The best way to do this would be to handle the throttle assignment in a lua script. You would assign your throttle axis to a free FSUIPC offset, and the lua script (which should auto-run) would monitor this offset (using event,offset), perform any calibration needed and then send the appropriate throttle axis control to the sim (using ipc.control). The script could also monitor for the button/switch (using event.button) and set/clear a flag when the switch is pressed/released, and this flag can be used in the function that calibrates the throttle offset value, so that it can be calibrated differently depending upon whether the flag is set or cleared. John
  15. Please try the trial license before purchasing, available here. I cannot advise on what PFC devices are supported (you need to try them). The MSFS 40th Anniversary edition is just the latest release of MSFS2020, which is supported by FSUIPC7. All versions of this are referred to as MSFS2020 (or just MSFS), to distinguish it from FSX. Also, as your question is related to FSUIPC7 / MSFS, you posted in the wrong forum - there is a specific sub-forum for FSUIPC7/MSFS. I will move your post there. You probably need to use the PFCcom64.dll, and without the serial to USB adaptor. If using the adaptor, you could try the PFChid64.dll, There are different drivers for com and usb devices - not sure if they work when using an adaptor though, you will need to try this. John
  16. That's unuseable for me. As well as what Paul has said, your original question, and title of this topic, is how to get values back from a simconnect execute_calculator_code call - I explained that this was not possible but there is a workaround - you write the result of the calculator code to an lvar and then read the value of the lvar. You still need to execute the calculator code, as you would need to do if you were getting the value back from the execute_calculator_code call... I completely understand this...and you can get a callback/event when an lvar changes. However, as this is YOUR lvar, you also need to provide the mechanism for it to get updated,,, Paul has also provided a possible solution to this for you.
  17. There is no GUI with the PFC hid driver - please see the documentation included with the driver (PFChidDLL User Guide.pdf). I am not sure how axes are handled with the driver - check to se if you can see them in FSUIPC's axes assignment tab, and if so, assign and calibrate there. According to the log you originally posted, a PFC throttle quadrant was acquired so that should be assignable, but no PFC rudder - only CH Pro pedals.
  18. You posted in the User Contributions sub-form - I have moved your post to the main support forum. The usual way to handle this is to use an offset condition on your assignments to check the current state of the switch in the sim (held in an offset) and only send the control if needed. See the Advanced User guide on adding offset conditions. This is not possible as FSUIPC only acts on state changes (buttons, switches, axes), so there is no way to determine the initial state. However, if you use offset conditions, your switches will be syncronized after the first activation, if not already. John
  19. Not sure what you mean by this - just use the latest release of each product. The PFC hid and com drivers are the same for FSUIPC5, FSUIPC6 and FSUIPC7, i.e. you use the same driver for each FSUIPC version,
  20. Those errors are nothing to worry about - your PFC Throttle is detected and should be ok to use - what exactly is your issue? Note that the PFChid64.dll was also updated at the end of January so you should update this. The update was for PFC avionics stacks when using MSFS, so should not really affect you, but always a good idea to use the latest version if needing support. John
  21. Download and install the latest PFCcom64.dll and try again...
  22. Sorry, what does this mean? You can ignore that message. You can add a PFC.mcro file to override the default controls/events that are assigned to PFC devices - see the provided documentation for details. Of course - you are using the same PFChid64.dll...there is no difference in the handling of PFC devices in FSUIPC5 and FSUIPC6. Your PFChid64.log file does show these errors: which is probably your issue. Not sure what can be causing those - I will take a look, but tomorrow now. In the mean-time, please reboot and try again... Does it still work with FSUIPC5? John
  23. You need to execute the calculator code to update the lvar. If the lvar (that holds the result) changes value, then you would receive the update value in exaclty the same way as you would get the value from any lvar (I haven't used the websocket server so cannot comment on that). Not sure what you mean by '...without the need of explicitly retriggering (polling) the calculatorCode... ' though... Anyway, just try it and see how you get on.... Johh
×
×
  • 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.