John Dowson

Then I do not understand what your issue is or why you think this is related to FSUIPC. Maybe you can explain in more detail. And, when I ask for a log, please show me a full log file, not a continuation log. I ALWAYS need to see a full log file for support purposes. The log file you attached just shows view changes and cowl flaps changes, nothing else. John

Well, yes. If you are only using one lever with different ranges for left/right brake, then you would only be applying either the left or right brake, not both, so you will effectively be turning.... Whats wrong with using a joystick button? If using a single button for braking, you could try this lua script: But this really depends on what you are trying to achieve. If you want differential braking, i.e. to use left/right toe brakes individually, then you will need two axes (or two buttons). If you just want to apply the brakes equally, then you can use your lever and assign to both left and right toe brakes, or a single button using that lua script. Ok, so it is differential braking (only?) that is needed. Then both my previous suggestions still apply. Pedals would, of course, be better! John

I don't think this would help but you could try it, won't do any harm. John

Seems a strange thing to want to do, but I can think of two ways you can do this: 1. Assign your lever to an unused axis (i.e. has no affect on the aircraft) with 'Send to FS as normal axis'. Then, use the right hand side if the axes assignments panel to assign various lever positions to Axis Left/Right Brake set with an appropriate parameter. This would give you up to 5 discrete brake settings for each brake. 2. Assign your lever to 'Send to FSUIPC Offset', and have a lua script to monitor the same offset using the event.offset function. In your lua event handling function, you can then convert the parameter to a left or right brake axis value, and then send the appropriate control (again , either Axis Left Brake Ser or Axis Right Brake Set) to the FS. You probably want such a lua to be auto-started. John

This really shouldn't be necessary, especially if using the JoyLetters facility. This handles changes in Joy Ids, but not GUIDs, but they shouldn't change when changing USB ports. A change if GUIDs will always need some manual editing if the FSUIPC .ini file, but is straightforward when using JoyLetters, more complicated otherwise... John

Then sorry, I don't know - looks like its not possible, I don't know why and don't have time to look at this. John

Are you sure you are using FSUIPC6 to start the engines? You only have assignments to your 777.mcro file, which look like they are for Wipers (on key presses), and engine 1/2 cutoff on/off and AP (on joystick buttons). Are you following the correct procedure to start the PMDG 777? I cannot help with this - I'm sure there are plenty of tutorials on the web... If you think there is an issue with your current FSUIPC assignments, could you please: 1. First update to V6.1.5 - you are using 6.1.4 and only the latest version is supported. I will also soon be releasing 6.1.6, hopefully later today. 2. Activate logging for Buttons & Keys and Events. 3. Produce a short log file showing your issue, then shutdown P3D/FSUIPC. 4. Show me your FSUIPC6.log file, together with your 777.mcro file John

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