Jump to content
The simFlight Network Forums

NovemberUniform

Members
 View Profile  See their activity

  • Posts

    40

  • Joined

  • Last visited

 Content Type 

Posts posted by NovemberUniform

  1. Comments in FSUIPC7.ini?

    in FSUIPC7 MSFS

    Posted

    Hi John,

    this may sound a little pedantic, but with my example from above, the lua ist still not autostarting with the latest FSUIPC7. 

    [Auto]
1=Lua PMCO_FNX32X ;does not start, space seems to prevent it...
2=Lua PMCO_PMDG73X; does start

     

  4. Comments in FSUIPC7.ini?

    in FSUIPC7 MSFS

    Posted

    Hi,

    from older posts I thought it would be possible to add comments to the ends of lines in the FSUIPC7.ini using the semicolon.

    I had to learn that the following code snippet only autostarts the second lua script without comment but not the first one. Is this to be expected? Can comments in that section be supported in the future? It's certainly not a big thing but I had some support requests for my shared lua script because of that. Thanks! 

    [Auto] ;just a test
1=Lua PMCO_FNX32X ;does not start
2=Lua PMCO_PMDG73X

     

  6. native support for long and double press

    in FSUIPC7 MSFS

    Posted

    Hi John,

    I know you can do this already with Lua, and actually I'm doing it succesfully for some time now, but it would be even better to have it natively included in the GUI for button and key assignments. I'm close to the point of running into max number of Lua scripts, lol. 🤪

    I guess this would be quiet a substancial undertaking, but there is no harm in asking, right?

  8. Missing LVAR after 3066 Lvars loaded (since SU11)

    in FSUIPC7 MSFS

    Posted

    On 11/21/2022 at 12:52 AM, Moderate Chop said:

    As you say, MSFS should only provide LVARs for the currently loaded aircraft.  And those of us who use FSUIPC can certainly raise this issue with Asobo.  My concern is that this is so far down their priority list that it will not be addressed in the near future, if at all.

    That's my concern, as well. I don't have high hopes they come to this in the foreseeable future, with all the stuff they are working on. Are they even aware of this? They have a voting system, as far as I know. Is there already a thread I could upvote?

    Not knowing any of the internals, I ask myself, what consequences it would have to increase the number of accessible LVARs in FSUIPC / WASM module to a limit, that can hardly be reached in the future, like factor 10 of what we have now (please don't shoot me for writing this 🙈). Is this even possible? Would it impact performance?

    It's good to have a work around with restarting the sim for the time being. Thanks for the info. I just came across this issue when the A310 arrived and I flew something else than just the Fenix A320. 

  10. German umlaut Ä -> no key action

    in FSUIPC7 MSFS

    Posted

    9 hours ago, John Dowson said:

    Could you run FSUIPC7 without MSFS running. activating logging for Buttons & Keys, press the Ö, Ü & Ä keys (in that order), then close FSUIPC7 and show me what was logged - either paste the lines logged for each key or attach your FSUIPC7.log file.

    I needed to assign the keys without an active profile first (because I usually use profiles). Makes sense, I guess.

    my ini: (order is Ö, Ü, Ä) 

    [Keys]
2=N192,8,1061,0     -{'@key: Press=engine 1 autostart }-
4=N186,8,1062,0     -{;:key: Press=engine 2 autostart }-
6=N222,8,1063,0     -{#~key: Press=engine 3 autostart }-

    Here is the log. Seems all keys were registered. 

          375 LogOptions=40000000 00000001
    17500 *** Entered Keys option page ***
    66985 *** Exiting Keys option page ***
   136797 KEYDOWN: VK=192, Waiting=0, Repeat=N, lParam=2555905 (0x270001), Shifts=0
   136797 FSUIPC Control Action: Ctrl=1061, Param=0
   136797 .. This key is programmed in FSUIPC7 'Keys' options
   136891 KEYUP: VK=192, Waiting=0, Shifts=0, lparam=3223781377 (0xC0270001)
   136891 .. KeyUp received from FS but not programmed
   137969 KEYDOWN: VK=186, Waiting=0, Repeat=N, lParam=1703937 (0x1A0001), Shifts=0
   137969 FSUIPC Control Action: Ctrl=1062, Param=0
   137969 .. This key is programmed in FSUIPC7 'Keys' options
   138063 KEYUP: VK=186, Waiting=0, Shifts=0, lparam=3222929409 (0xC01A0001)
   138063 .. KeyUp received from FS but not programmed
   139110 KEYDOWN: VK=222, Waiting=0, Repeat=N, lParam=2621441 (0x280001), Shifts=0
   139110 FSUIPC Control Action: Ctrl=1063, Param=0
   139110 .. This key is programmed in FSUIPC7 'Keys' options
   139188 KEYUP: VK=222, Waiting=0, Shifts=0, lparam=3223846913 (0xC0280001)
   139188 .. KeyUp received from FS but not programmed
   154391 === Hot key unregistered
   154391 === Stop called ...
   154407 === Closing external processes we started ...

     

  12. German umlaut Ä -> no key action

    in FSUIPC7 MSFS

    Posted

    46 minutes ago, John Dowson said:

    Keyboard input in FSUIPC7 is (usually) received from MSFS via SimConnect. The only keys supported by SimConnect are shown

    Thanks for letting me know. If there is nothing you can do about it, I will work around this by using different key. Strange though, that Ö and Ü are indeed working.

  13. German umlaut Ä -> no key action

    in FSUIPC7 MSFS

    Posted

    Hi John,

    beeing german I use a german QWERTZ keyboard which has umlauts Ä, Ö, Ü (see https://en.wikipedia.org/wiki/German_keyboard_layout).

    I want to use these keys (among many others) to assign FSUIPC controls - lua scripts in this case. Ö and Ü work just fine, but Ä will not trigger the assigned action. You can assign something to Ä in the FSUIPC key assignments window, it is shown there as #~key, but the action is not triggered in the sim. There is also no log entry if I enable key logging. Ö and Ü actions are listed in the log. I also crosschecked the lua script, using it with Ö or Ü is working fine.

    It seems, the umlaut Ä is not working. I know it was working in earlier versions of FSUIPC like FSUIPC5. I'm even pretty sure it was working with FSUIPC7, some versions before this last. I've just updated to the latest version of FSUIPC7 today and it's not working.

    I know a keyboard has many keys and it's not high priority, but maybe there is an easy fix for this.

    Thanks in advance!

  16. Method to read FSUIPC install location?

    in FSUIPC7 MSFS

    Posted

    On 11/3/2022 at 11:20 AM, John Dowson said:

    You can read the installation location from the registry, from InstallDir under HKLM Software\Microsoft\Windows\CurrentVersion\Uninstall\FSUIPC7

    But note that lua files don't necessarily go in the installation folder. If the LuaPath ini parameter is set (under [LuaFiles]), that will be used instead, so you would also need to read that. LuaPath can contain a relative or full path specification.

    John

    Hi John,

    I need to get back to you on this. On my Windows 11 installation the path is this: "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\FSUIPC7". Is this to be expected? Do you know what are the different path versions from Win7 until Win11 (both 32 and 64bit versions)? Thanks!

  20. FSUIPC WASM not always loading

    in FSUIPC7 MSFS

    Posted

    I have a similar question.

    I made a lua plugin that I also shared with a limited number of users from the community. It needs the WAPI to run, because there is interaction with LVARs of the add-on aircraft it was made for. On my computer, everything is running fine. In the log file, I can see the WAPI loading and connecting on startup.

    There are users, where the loading of WAPI is apparently not happening (not in the log), altough they tell me it is installed and presumably running, if they go to the FSUIPC "Add-ons" tab -> "WASM".

    What can prevent the WAPI from loading? If it is listed as running in the "Add-ons" tab -> "WASM", why it doesn't show in the log? Is there more to it?

    Thanks for helping.

  21. WND: Data entry with keyboard problematic

    in FSUIPC7 MSFS

    Posted

    11 hours ago, John Dowson said:

    Please try the attached version.

    I did, and with another addition, this is working fine now. With mouse clicks between or during data entry, MSFS could regain focus. So I put the line  

    ipc.control(1156) -- set focus

    in a event.timer(20, "callback_fcn") callback function, to keep the focus on FSUIPC during data entry. This works very good now!

    11 hours ago, John Dowson said:

    This will then prevent any FSUIPC assignments being triggered while your plugin is active.

    Yes, 100%. Also, no problems with long key presses anymore.

    I'm happy, and I can now concentrate on other parts of my plugin.

    👏

  24. WND: Data entry with keyboard problematic

    in FSUIPC7 MSFS

    Posted

    1 hour ago, NovemberUniform said:

    In the meantime, I will have a look at your proposed alternative for ipc.ask(). Maybe it works better for what I need.

    Well, this is essentially the same thing that I did. It won't bring me any further, I guess.

    I then tried to create events for mouse actions to more or less dial in my values with the mousewheel, instead of typing them with the keyboard, but the events didn't get triggered. Is this a known issue? 

    event.mousewheeltrap("fMouseWheelScroll") -- event for mouse-wheel movement
event.mouselefttrap("fMouseLeftClick") -- event for mouse-click left

  25. WND: Data entry with keyboard problematic

    in FSUIPC7 MSFS

    Posted

    I sent you the files. I think the biggest problem lies in the MSFS keys not being trapped. Whatever the problem is with longer key presses, I can live with that. Just don't press the keys longer than usual.

    In the meantime, I will have a look at your proposed alternative for ipc.ask(). Maybe it works better for what I need.

×
×
  • 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.