John Dowson

I suspect that the crash before the luas were loaded may be to do with the WASM/WAPI but cannot confirm. Could you please add/change the following ini parameter to your FSUIPC7.ini file, under the [WAPI] section: LogLevel=Debug and send me your log file(s) if/when you get a crash. This is something I have experienced occasionally but cannot reproduce very often to track down. Anyway, the logs should tell me if this is the issue or not. For the crash after the luas were started, I have no idea...Has your lua changed again? Can you show it to me please. I think you need to activate lua debug logging again if its crashing in the lua. How often are you getting these crashes? John

Could you try the version attached below please. I have removed registry scanning, and reverted to checking the the standard locations for the UserCfg.opt file as is done in the installer. Just download and replace your current FSUIPC7.exe. Any issues, please show me you updated FSUIPC7.log file. Thanks, John Attachment removed as out-of-date.

Have you tried just pasting the character into the string, e,g, wnd.text(wHandle, "Its " .. todaysTemp .. "° today.") Don't see why that won't work, it is just an an ascII character after all. Or am I missing something? John

FSUIPC7 thinks you are running a Steam install rather than an MS Store install for some reason, and so cannot find your UserCfg.opt file to determine the location of your MSFS Add-ons folder, due to missing or invalid MSFS registry entries. The strange thing is, the installer correctly determined the correct install type and found the UserCfg.opt file ok. Not sure why this is at the moment - I will check and get back to you later. John

Try this with both rev checked and unchecked, two different sessions please, if you can, and show me both files from both sessions. Or with the ',*-1' added/not-added if you prefer, as either should reverse the axis range being sent to the FS. Thanks, John

I have also just noticed that you posted in the Announcements sub-forum, where it explicitly states Not for support requests. I have moved your post to the correct forum. Please take care to post in the correct forum, i.e. this one for all products except FSUIPC7/MSFS2020, which has its own sub-forum. John

Sorry, I meant your FSUIPC4.ini file. The latter, i.e. you add to the end of the indexed axis assignment that you want to revert. As I advised, please see the section Additional parameters to scale input axis values in the Advanced User guide. Please activate logging for axes controls, and produce a short log file where you move your effected axes through their entire range. Then show me/attach your FSUIPC4.ini and FSUIPC4.log files and I will take a look. John

Note also, that once a WAPI instance is created, the setSimConfigConnection() method should be called to set the connection number to be used, if not using the default (local) one, before the start() method is called. I presume this is handled correctly via Paul's dll when setting the VS.SimConfigConnection. However, I haven't yet tried configuring a WAPI client (or any other SimConnect client) to run via a networked SimConnect connection to MSFS. I will look into this further when I can, maybe next week... John

But you shouldn't nee to do anything if you have AutoAssignLetters set to Yes - any new device will automatically be assigned a device letter. However, if not using that option, you do need to manually assign a letter to a newly connected device. To do this, you change the number to a letter in the [JoyNames] section for both the GUID and name entries of the new device. When FSUIPC is restarted, it then adds back in the joyid entries for the letter mapping to function correctly. John

this is correct or is there a configuration ini file. Adding to what Paul has already said, I think the default (local) connection is -1 (SIMCONNECT_OPEN_CONFIGINDEX_LOCAL). If you use another value, you need to have that SimConnect connection value defined in your client's SimConnect.cfg file. Ok, then I would expect it to be possible to run such a client on a client PC with a correctly defined SimConnect network configuration, and without the need for WideClient on the client PC. John

Forgot about the WAPI being used, which does of course use SimConnect, so yes, that would need a networked SimConect connection. However, doesn't his client/your library, also require the FSUIPC SDK, and so also FSUIPC to be running (or, on a slave PC, WideClient)? Or can he use a version of your client libraries for WAPI access that doesn't use the FSUIPC SDK? If so, it should be possible to configure a networked SimConnect connection for that client and run without FSUIPC/WideClient. John

Also, of you are developing an FSUIPC client (and NOT a SimConnect client), then a networked SimConnect config isn't going to help, as you are using the FSUIPC SDK and not SimConnect directly. To run FSUIPC clients on a slave PC, you currently need a license for WideFS and use WideClient on the slave PC. John

Try this post: https://forums.flightsimulator.com/t/simconnect-on-2nd-pc-network-setup/365647/7 Also, check the SimConnect config documentation. Google can also help if you have issues, e.g. https://www.fsdeveloper.com/forum/threads/setup-remote-client-for-simconnect.5187/ http://www.prepar3d.com/forum/viewtopic.php?t=127714 Note that the SimConnect functionality should be the same for MSFS as FSX/P3D in this area. Its not something I've looked at yet in detail. It is something I'll be looking into when I allow FSUIPC7 to be ran on an MSFS client/slave machine. Not sure when I'll be doing this at the moment though. John

As this is a question on MakeRunways, I have moved it to the main support forum where @Pete Dowson can take a look. John

I'm afraid this all depends upon how the aircraft model is implemented. If the implementation accepts an axis control for flaps, then you can use it, otherwise you would have to use the controls available (usually the inc/dec controls). Some MSFS aircraft allow axis controls for flaps but map them on to the discrete positions anyway, while in others the flaps axis controls are confused. You really need to check and try what is available for the aircraft in question. Also, check for any mods if using an MSFS stock aircraft. For example, I see there is a STOL improvement mod for the Savage (https://es.flightsim.to/file/3723/savage-carbon-stol-realism-mod) which has some flaps improvements, namely: But doesn't seem to implement a full linear flaps axis, but then again, maybe that is not available in the real aircraft, I don't know... Sorry I can't be of more help. John

No, the number entries are needed. The numbers assigned to yout devices are read from the registry, and then mapped to the letters based upon the GUID (and name). Both entries are needed in that section as this shows the mapping between the letters and the IDs. Ince you are using joyletters, the letters are used in the assignment sections. You don't really need to 'put the letter assignments in the aircraft profile' - this is all done automarically. Once you are using JoyLetters, you will see the assigned letter in the assignments panels rather than the JoyId. Thats it really, nothing complicated. If you are manually editing the ini then you should also use the joyletters, but if you use the joyids they will be converted back to letters using the current mapping the next time the ini is re-written. I wouldn't worry about this. You can use the letters in most situations, but sometimes the joyIds are needed and so the mapping section is useful. John

Hvars can currently only be assigned using either lua or macros. The easiest way would be to use a macro file - see the Macros to activate Hvars section of the Advanced User guide, P 35. Basically you need to create a macro file (e.g. A32NX.mcro) on your FSUIPC7 installation folder with the following contents: and you can then assign to that macro entry in the assignment controls drop-downs. John

Well, its been around for a while, but has been updated to work with MSFS2020. Note that all previous versions of FSUIPC (for FSX and P3D) were .dll files, and so always started with the FS. It only became an option to start manually with MSFS, as FSUIPC7 is now a separate application, a .exe. As such, it makes more sense defining how you would like to use it when you install. It doesn't make much sense (to me, at least) to have this as an option in FSUIPC7 itself, as it is something that once set you would very rarely want to change. In fact, you will most ptobably be updating FSUIPC7 via the installer more often thn you would want to change this option (as I release updates every 4-5 weeks). I could add this as an option within FSUIPC7 itself, but I think there is far more useful functionality to be added (e.g. some indication of an update being available) at the moment, and I doubt I would ever have time to get around to implementing such a feature. John

How are your axes assigned? If 'Direct to FSUIPC Calibration', you can reverse the axes in the calibration dialog. If you are not calibrating in FSUIPC, you can scale the input axes values - to reverse them, simply add ",*-1" to the end of the axes assignment line in your FSUIPC5.ini file. See the section Additional parameters to scale input axis values in the Advanced User guide. John

Links work just fine here. What are the properties of the link? This is what one of mine looks like (created with the link shell extension): VoiceAttack also starts ok via the [Programs] section for me. However, creating a link to the VoiceAttack.exe doesn't seem to work for some reason. It runs ok according to the FSUIPC7.log file but no window is displayed and no process running when I check in Task Manager. Maybe you can show me your FSUIPC7.log file - there should be errors reporting why the run failed. If the run error indicates a permissions issue, try installing VoiceAttack outside of your Program Files folder, which has some windows restrictions which can cause issues. John

If you install the auto-start component, FSUIPC will be automatically started with MSFS. That is what the auto-start component does! If you don't want FSUIPC to auto-start with MSFS, re-install and de-select/uncheck the auto-start component. You will then need to start FSUIPC7 manually when you want to use it. John

Ok, so VPilot itself is not an FSUIPC client, but when using the later version of FSUIPC, which you need to use FSC 10, this somehow prevents VPilot from working correctly. How strange.... Presume you are doing the in the VPilot UI, with the 'Mode C' button, no? If so, I can't see how FSUIPC can be interfering with this, especially as it doesn't even use FSUIPC. I think you need VPilot support to determine why the Mode C button isn't working when 4.976 is installed. Regards, John

Sorry, but I have no idea what FSC 10 is and cannot support that - does that not have its own support forum? I am still slightly confused though... You said: So is everything working as expected with 4.974? You also said: Is that a vpilot issue? How have you configured FSUIPC to activate Mode C on Vpilot? If you can let me know (and show me your FSUIPC4.ini file), we can try adding some logging to see what the difference is between 4.974 and 4.976. Maybe you could start by activating logging for Buttons & Keys as well as Events, and produce a short log file with each version where you try activating C mode on Vpilot (via FSUIPC). I can then compare the log files. Thanks, John

Ok. I don't think comments are allowed in an auto line, but I am surprised that would crash FSUIPC.... Try just: [Auto] 1=Lua PMCO John

I don't think the file is needed/copied there any more in 5.2 - I do not have one there... No need to do this. Can you show me/attach your FSUIPC6.log and FSUIPC6.ini files and I will take a look. John