John Dowson

This is used (by FSUIPC) to map the joystick IDs to the device letters, or JoyLetters, as they are referred to in FSUIPC. No. P means 'Press', as in a button press. The format is described in the Advanced User guide. 'F' will be the JoyLetter, 3 the button number, etc... Please see the documentation. FSUIPC re-writes the numeric assignment when it scans your devices and registry to determine the id of each device, then maps this to the letter used on the GUID and name. John

No, WideFS7 is the version of WideFS that is compatible with MSFS2020, not WideFS6. John

Please see the provided README.txt, under Problems running FSUIPC7: If that does not solve your issue, please show me your FSUIPC7.log file. John

Please show me your FSUIPC7.log file, located in your FSUIPC7 installation folder. John

Sort of...but its a substring match, so will match any aircraft containing the string "Cessna Grand Caravan" - can be at the start of the string but diesn't have to. As I said, please see the User manual! John

It is not included, it is a separate (licensed) product. You only need a license if you plan to run WideClient on a 2nd/slave PC, to support FSUIPC applications there. John

Log looks ok to me, but I don't know much about LINDA- you need LINDA support. John

A nil is returned if the lvar wasn't loaded, so increasing the LvarScanDelay parameter should hopefully prevent this. I would leave them in for now if changing that. It shouldn't reload if you use the Escape key, only when an aircraft is initially loaded, or when a reload command is issued. John

The log you attached stops after 3min 27 seconds by user request: If you want me to investigate, please show me a full log. Then you probably need Linda support, but a full log file would help. I can't think of any changes from 6.1.5 to 6.1.6 that would affect Linda, but maybe @Scotfleiger could check. Regards, John

Your log shows the crash was just after receiving the hvars for the second time - the crash event was milliseconds after the last log message. This is the crash that I have occasionally experienced (and mentioned), but rarely, and have so far failed to reproduce to track. I am planning to investigate this one next week - taking the weekend off, bar minimal support, for a change! Hopefully get time to actually do some recreational flying as well... If you get a crash, and it isn't directly after a 'EVENT_HVARS_RECEIVED' message (keep WAPI debug logging enabled), then possibly send me the logs. Otherwise not necessary, but maybe keep a record of the crashes and circumstances. You crash log this time shows lvar/hvar data being received both at 512 seconds after start, and again at 517 seconds, which is interesting... Did you perform a WASM reload to do this? I think the crash is somehow related to a WASM reload - may have missed some locks somewhere with data being read as its being overwritten, or a timing issue related to previous data, which is what I am planning to look into next week. Note that, if reloading the WASM to catch lvars that aren't initially picked-up (a common problem, especially for more complex aircraft), then it is better to increase the WASM ini parameter LvarScanDelay. This is set to 5 (seconds) by default, but for complex aircraft I would recommend a setting of around 45, or to test by listing the lvars as the plane is loaded until you see you have them all (or nearly all...some seem to be created a lot later, but thats another story...), Check the WASM section in the FSUIPC Advanced User guide for details. John

Yes! All primary axis can go through FSUIPC 's calibration facilities. And, of course, you can/should also assign and calibrate the rudder. John

Hi Leo, just to let you know that I have released FSUIPC7 v7.2.12 with the above changes (and others). However, I have made a small change in one of the areas. In the 2nd version I gave you to test, I added some extra code to kill luas earlier, with the SimStop message is received. However, I am not 100% sure on this change as spurious SimStop messages can be received during certain situations. Most of the time this doesn't matter (e.g. during start-up) but could possibly kill the luas when not needed (possibly on a flight reset). I have therefore made this 'earlier killing of luas' optional on an (currently undocumented) ini parameter, which is off by default. I suggest you keep this off initially, but if you get further issues with luas crashing (and maybe hanging FSUIPC) then you can re-enable this functionality by setting the following in the [General] section of your FSUIPC7.ini file: KillLuasOnSimStop=Yes John

That is the first log file, but still shows nothing... Please read my previous comment: You have very few assignments in FSUIPC, and all via Mouse Macros. You are not doing much at all with FSUIPC, and I do not understand why you think FSUIPC is related to your issue. This is why I require further information on what your issue actually is. Your problem: I only have one engine working after configuring the PMDG 777 for P3D V4 sounds like you are not starting the aircraft correctly, which I cannot help with. Note that PMDG aircraft also have their own SDK, with custom controls and its own FSUIPC offset area. John P.S. This may help:

But did you click the Register button? I think not.... John

Here's the 4.975a build for you to try, if the issue persists with the previous build: FSUIPC4.DLL Thanks, John

@Jay75 Could you please try this earlier build of 4.976 to see if you get your issue with this build. Save/rename your current (working) dll first so that you can revert if needed. If you still get your issue with that, I'll post a 4.975a build for you to try. I don't understand how or why FSUIPC can be interfering with VPilot as its not being used, but it would be useful to know at which version this issue started. Thanks, John FSUIPC4.dll

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.