Jump to content
The simFlight Network Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by ark1320

  1. I think you are correct. To me NumLock works as a kind of lockable shift toggle, so using the shift key toggles NumLock as you said. Interesting. Al
  2. Hi John, FSUIPC7 ver 7.2.11a does distinguish between left and right Ctrl and Shift keys for key strokes sent in response to a button push. One interesting thing; with NumLock on the num2, num8, num4 and num6 keys show up as Down, Up, Left and Right when combined with one of the Shift keys. But when combined with one of the Control keys, these numpad keys show up as num2, num8, num4 and num6. So, for example, with Numlock on if I enter lshift + num2 in the keys to be sent when button pushed window, what I get is lshift+Down. However, if I enter lctl+num2 I get lctl+num2. Not sure what to make of this, just passing the info on. Thanks for working on distinguishing the left and right shift and control keys! Al
  3. The good news is there is only one Tab key! 😉 Al
  4. BTW John, the same issue applies to the Alt and Right Alt keys. Being able to distinguish between the two Ctrl, Shift and Alt keys makes a ton of additional key combinations available via FSUIPC7. Thanks for looking into this, Al
  5. MSFS distinguishes between the left and right control keys (called Ctrl and Right Ctrl, respectively). However, FSUIPC7 does not distinguish between these two keys as best as I can determine. I discovered this when trying to send a key stroke with a button push. The command I wanted to activate with a button needed the key combination Right Ctrl + Num1, but FSUIPC7 could apparently only send Ctrl + Num1. I don't know how difficult it would be for a future release of FSUIPC7 to distinguish between the two control keys, but if reasonably doable it would be a useful addition to FSUIPC7. Thx, Al EDIT: Seems the same situation as above applies to the left and right Shift keys (Shift and Right Shift) which MSFS distinguishes between, but FSUIPC7 does not.
  6. Hi John, Select for Key Press under the FSUIPC7 Buttons and Switches tab does not seem to be available -- is this because of another SDK limitation? Thx, Al
  7. I rewrote a couple of scripts to use event.flag() which then allowed me to keep the windows open. Thx, Al
  8. Hi John, I have been experimenting with the wnd library. One thing I have noticed is each time a window is opened, there is a flicker and the sim loses focus for an instant as the window opens. Is there a way to leave the window open so each time the same script is run you don't have to reopen the window, thus avoiding the flicker which seems to be associated with opening the window? One thing I tried was using a separate script to open the window (and not close it) and then pass the window handle to the frequently used script using the ipc.set/ipc.get pair, but have not been able to get that to work. I assume that while "w" is used throughout the wnd library documentation as the window handle, any valid Lua variable name can be used for the handle. So different windows can have different handle names. Also, I noticed in your FPS_MonitorW example after closing the window you set the window handle w=0. Why? Thx for any ideas, Al
  9. I'll certainly consider this if Asobo doesn't fix things -- thanks! Al
  10. OK John, I understand now. Sigh. I have lots of Lua scripts and just about all of them make use of the FSUIPC text capability. And I'm sure I am not alone in this. Thanks very much for all your efforts with FSUIPC7! Al
  11. OK John, but I think a message to Asobo from the FSUIPC developer would carry a lot more weight than a message from just a typical MSFS user. Al
  12. John, Do you know if Asobo is aware of how the broken SimConnect_Text API function impacts FSUIPC, and if they plan to fix it? Thx, Al
  13. John, Did you ever have a chance to figure out what the purpose or function is of the default entry SteeringTillerControl = 0 in the FSUIPC JoystickCalibration section? Thx, Al
  14. If a profile specific aircraft section does not have a specified [AXES.xwz] section, does it automatically use the [AXES] specification in the general, non-profile section of the FSUIPC.ini file? Thx, Al
  15. In previous sims I have always disabled controllers and set up all my axes using just "Send Direct to FSUIPC Calibration". In MSFS it seems I need to make use of the Sensitivity and Reactivity settings as well ( using just the FSUIPC axes slope curves do not seem to be sufficient in my case). If I still use "Send Direct to FSUIPC Calibration" for my axes in MSFS, will the MSFS axes Sensitivity and Reactivity settings be applied to the axes data output from FSUIPC? In other words will the axes be "processed" twice? Or would it be better to just use the MSFS axes controls? Thx, Al
  16. I put together a little Macro test file MacroTest.mcro that looks like this: [Macros] 1=L:PITOT_L=SET,0 2=L:PITOT_R=SET,0 3=L:PITOT_L=SET,1 4=L:PITOT_R=SET,1 In the resultant FSUIPC6 Key Assignment dropdown list, the 0 and 1 SET values do not show up, so the dropdown has what looks like duplicate entries. That seems confusing, am I doing something wrong? I had expected the actual SET values associated with each line in the Macro file to show up in the dropdown list to facilitate the key assignment process. For SET, the FSUIPC user manual says: Set copies the parameter in the Macro invocation to the identified Lvar. Alternatively, a value can be given explicitly here, by “Set,n”. It is not clear to me what is meant by "Macro invocation" -- is this referring to the Parameter field associated with the dropdown list? If you do have to enter the desired SET value in the Parameter field, what is the utility of using SET, n in the Macro file? Thanks, Al
  17. Hi, Just saw your question here-- sorry I didn't notice it sooner. You need to put the Lua script in the same location as your FSUIPC.ini file, and then use FSUIPC to assign either a keyboard key or button to activate (call) the script. Al
  18. Well that's interesting. What I'm doing is calling a script that sets a flag after a delay -- the delay (set by the user) could be from about 0.5 to 3 seconds or so, and the script could be recalled before the delay has run its course. So I could implement the delay with ipc.sleep(), or use a delay loop that looks for a change in time using ipc.elapsedtime(). With respect to the blocking system call issue you mentioned, does the delay loop approach have any advantage over using ipc.sleep()? Thanks, Al
  19. I know that if when a Lua script is running you re-invoke (recall) the same script, the previous script is 'killed' and replaced by the 'new' one. My question is, if the script contains an ipc.sleep() function and that ipc.sleep function is active when the script is re-invoked (i.e., the script is sleeping), is the original script, and the ipc.sleep action, still instantly killed? From some simple tests I tried it does seem 'everything' is killed when the script is re-invoked, but just wanted to check here in case someone has experienced something different in this regard. Thanks, Al
  20. Is there a way to restart FSUIPC6 without having to restart P3D? Thanks, Al
  21. Hi John, The download for FSUIPC 7.0.8 seems to install as ver 7.0.7, at least that's what the installer says, and what it says under the 'new' installed FSUIPC7 'Help > About' dropdown, and also what the Win10 Control Panel Programs and Features shows. Perhaps just a file naming issue? So not sure what version has really been installed. Regards, Al
  22. It all works now with you latest version of FSUIPC7. The Offset Status documentation is quite clear. I just had forgotten it was BCD ☹️ -- sorry. Another age problem I guess. Sigh. Thanks for the help. Al
  23. John, The good news is I can now at least get the transponder in the steam gauge C172 to respond using your new FSUIPC7. The bad news is the value displayed in the transponder is wrong. I tried an experiment and get the following results when setting the C172 transponder using, for example. ipc.writeUW(0x0354, 0010) which displays 0002 in the C172. Code Written Code Displayed in the C172 0000 0000 0001 0001 0010 0002 0100 0064 1000 0360 So it seems the values being written are getting scrambled somehow. I don't see anything "common" in these results. However, values read back are apparently being interpreted as a Hex value. If I set the transponder with the mouse in the VC and then read the value with ipc.readUW(0x0354) I get: VC Transponder code Value read back and displayed 0000 0 0001 1 0010 16 0100 256 1000 4096 Al
  • 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.