John Dowson

Many of the camera controls in MSFS are not working when assigned externally, including the zoom controls. There are also some MF presets for zoom, but these also don't seem to work. Therefore to control zoom, you can either assign in MSFS, or assign in FSUIPC7 to the default key assignments. So, for example, to assign to cockpit zoom-in, assign your button to send the equals key ('='), and for zoom-out, assign to the hyphen/dash key ('-').

You still have not changed the preset assignments on repeat in your [Buttons.PMDG 777] section - change these as well, as I said in my last comment:: 15=RF,4,CPPMDG_B737_FD_Switch_Capt_On,0 -{Preset Control}- 17=RF,31,CPPMDG_B737_FD_Switch_FO_On,0 -{Preset Control}- 21=RE,4,CPPMDG_B737-7_GEAR_DOWN,0 -{Preset Control}-

That log file you attached ends after 94 seconds before you even had the 777 loaded and ready to fly, and so is useless. You also have other presets sent on repeat - please also change these: 15=RF,4,CPPMDG_B737_FD_Switch_Capt_On,0 -{Preset Control}- 17=RF,31,CPPMDG_B737_FD_Switch_FO_On,0 -{Preset Control}- 21=RE,4,CPPMDG_B737-7_GEAR_DOWN,0 -{Preset Control}-

For all auto-start issues, see Sorry to hear that. No idea wht your issue was as I never saw your files. There does seem to be an occasional issue with the WASM when using the 777 which I am investigating.

This issue is usually caused by flaps calibration. If flaps assigned in FSUIPC, make sure it is assigned with 'Direct to FSUIPC calibration'. If not assigned in FSUIPC, check that you are not post calibrating. You can attach your FSUIPC7.log and FSUIPC7.ini files and I can take a look.

II need to see your FSUIPC7.log file as well please. I always need that. I have now experienced a WASM crash switching between the PMDG 737 and 777, so there is definitely an issue there. But your WASM log shows that it ran ok for you, so it must be something else. I am investigating the WASM crash and will get back to you once I have found anything.

Yes, that looks correct. Check the FSUIPC Offset status document for a free offset, e.g. there are 512 bytes free starting at 0xA000 No. Your lua script is only for reading at the moment. If you want to update the lvar when you update the offset, you have to have that as well. So you need to add an event.offset call (on the offset you use) and in the handling function you can set the lvar value. Before you set the value, check it was not the value received and written to the offset, e.g. store the lvar value in a local script variable when received and check its different from the offset value when that changes before you use it to set the lvar value.

First, what version of FSUIPC and what simulator are you using? For information on offsets, please see the FSUIPC Offset status document for your version of FSUIPC. However, there will be no offset holding that lvar value. FSUIPC does not hold any lvar values in offsets by default. If you want to add an lvar to an FSUIPC offset, you can do that but it doesn't happen by default. In FSUIPC7, you can use an [LvarOffsets] section of the FSUIPC ini file - see the Advanced user guide for details. For other versions of FSUIPC you would have to use a lua script. The script should wait for the lvar value to change (event.lvar) and in the handling function, write the value to a free/spare FSUIPC offset. But if using MobiFlight, doesn't that have access to lvars without using FSUIPC? John

I noticed this was missing in the ini file you attached, which I thought was strange... Not sure what could cause this. Anyway, please keep an eye on things and send me the files again if you get a problem, as there may be an issue somewhere as others are having similar problems.

First, get you stop all these errors: These are from preset FNX320_LIGHT_LANDING_BOTH_ON which you have assigned on repeat, so this is getting sent 20 times a second, causing those errors. Please change the assignment line in your [Buttons.Fenix A320] section: 14=RE,17,CPFNX320_LIGHT_LANDING_BOTH_ON,0 -{Preset Control}- Change that R to a P: 14=PE,17,CPFNX320_LIGHT_LANDING_BOTH_ON,0 -{Preset Control}- You are also using the same assignment in your TBM 930 profile - change there, or maybe just remove those assignment to Fenix presets. Other than that, it looks like WASM connection wasn't working, which is why the presets weren't working. Can you make that correction please and test again and show me the new FSUIPC7.log file and the FSUIPC_WASM.log file. The location of the latter is:

Also, please add TestOptions=x800 to the [General] section of your FSUIPC7.ini file. This will add extra logging on when/why FSUIPC7 is starting, or not..

Sorry, but your log file again shows that you were trying to use presets before FSUIPC was ready. Did you actually load an aircraft and get ready-to-fly? Looks like you got to the main MSFS menu after 76 seconds, then exited MSFS 5 minutes later, and FSUIPC7 did not detect you having an aircraft loaded and ready-to-fly. Can you please explain what you did. Also, please try another aircraft. Maybe this is an issue with the Fenix.

This is because you are not using substrings for your aircraft names in the [Profile.xxx] section of your FSUIPC7.ini. You need to edit the names there to be a substring of the aircraft name that matches the aircraft regardless of livery. Otherwise, you can switch to using UseAirLocForProfiles instead (see Advanced User guide on this parameter), but if you do this you will have to add each aircraft to your profiles again, and remove the current entries under your [Profile.xxx] sections as these will no longer be relevant.

Ok. Please also set Debug logging in the WAPI (Log ->WAPI -> Debug) and show me your FSUIPC7.log, FSUIPC7.ini and FSUIPC_WASM.log file if/when this happens again, and attach after exiting FSUIPC7. Also worth checking the MSFS debug console (you need devmode activated to see this) to see if any errors (related to FSUIPC) are reported there, especially if there is a message relating to the FSUIPC WASM crashing.

Also change your profile aircraft names to use substrings - if you don't do this, your assignments will not load when you use an aircraft with a different livery. Change to and to and to etc. i.e. You should change the aircraft names added to a profile section to a substring that catches ALL variants. If you leave the name as it is, you will have to add the aircraft again when you use a different version/livery. You should get into the habit of doing this each time you add an aircraft to a profile.

Are you manually starting FSUIPC7 or is it auto-started? The log file you attached shows that FSUIPC7 was manually started. You tried to start using presets 5 seconds after starting FSUIPC7, which gave errors: However, FSUIPC7 only became ready for use after 11.422 seconds: Any assignments will not work until after the 'Starting everything now' line is logged, and presets are not available for use until the '[INFO]: Connected to MSFS' line is logged, and generally you should wait until initial lvars have been received and any lua autos have been loaded, which is after this line: 11422 Lvars/Hvars received - checking aircraft autos.... Your ini file also does not contain the DetectToConnectDelay or DetectToConnectDelayAuto ini parameter - did you remove these? Please add the following to the [General] section of your FSUIPC7.ini file: DetectToConnectDelayAuto=60 DetectToConnectDelay=1 StartUpTuningActive=Yes and change the following (currently set to 45): InitialStallTime=15 Well, it would have be useful to see your FSUIPC7.log file generated when FSUIPC7 was auto-started and you had this behavior - the log you attached was from when you manually started. Make the changes I mentioned above, then run MSFS, let FSUIPC7 get auto-started, and then exit MSFS. This will allow FSUIPC7 to auto-tune those start-up parameters. Then run MSFS again and let FSUIPC7 get auto-started. If you have any issues after this, exit FSUIPC7 and show me your FSUIPC7.log and FSUIPC7.ini files again.

Were you running any other FSUIPC clients (including WideClient) when you generated those logs? Better to not have anything else running (except WideClient, but only if running RC on a client machine). This also includes lua scripts, as it looks like these are also logged. A single log file containing RC reads/writes would be the most useful, and it doesn't have tpo be that big. Once RC is running and working but has the incorrect altitude, exit FSUIPC7 and then attach the file. I don't think you will need to spoof everything that RC is reading, only what is necessary. For example, probably not necessary to spoof cloud info (and this is not available anyway!). If the main issue is with the altitude, then this is what needs to be read correctly. You can also just spoof them with dummy values for now - they don't have to be accurate for the time being. Thats okay though, as those offsets are populated correctly, no? That is interesting....how did you determine what those offsets are holding? The problem with the area at CC00-CFFF is that this is weather at 'the requested location', i.e. I would expect to see writes to offsets C800-C8FF to specify the location before these offsets are read, but I see no writes at all for this area. However, I do see writes to the 'weather at requested location; read area CC00-CFFF: Not sure where those are coming from - are they being spoofed (via lua)?

@BJHawk When you lose connection during flight, does the PMDG VC still respond? I ask because I see there is a report on avsim about the loss of controls in the PMDG 777 during flight: https://www.avsim.com/forums/topic/646210-pmdg-777-does-not-work-anymore-in-flight-cant-do-anythin/ So there could be an issue with the 777. John

@dutchkip Can you try the following ini file please, attached below. I have corrected your ini and removed the duplicate device letters. Some assignments have changed and I have tried to keep the latest assignments. These are the ones I removed: On B737COL: removed as replaced with assignment to SET_THROTTLE1_REVERSE_THRUST_ON 4=RC,0,K82,11 -{Key press: lctl+lshift+R}- 29=RC,0,K113,8 -{Key press: F2}- removed as replaced with assignment to SET_THROTTLE2_REVERSE_THRUST_ON 37=PC,3,K113,8 -{Key press: F2}- On Flight Yoke System: removed as replaced with assignment to Key press: Home 8=PA,6,K32,10 -{Key press: lctl+Space}- Note also that you have two assignments to button 7 on your Flight Yoke System: 9=PA,7,K45,8 -{Key press: Ins}- 10=PA,7,K35,8 -{Key press: End}- so both key presses will be sent when you press this button. This may be ok, if this is what you intended. And you have the same controls assigned to buttons 6 and 7 of your B737COL: 0=PC,7,C66587,68801 -{ROTOR_BRAKE}- 1=PC,6,C66587,68801 -{ROTOR_BRAKE}- and also the same control assigned to buttons 8 and 9: 2=PC,9,C66587,68901 -{ROTOR_BRAKE}- 3=PC,8,C66587,68901 -{ROTOR_BRAKE}- If you get further issues with your assignments now working on start-up, please exit FSUIPC7 and show me your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files again BEFORE doing anything else. Your loss of controls is another / separate issue. When this happens, exit FSUIPC7 and show me the log file. You can also then re-start FSUIPC7 to see if your controllers work after a restart (when you do this, your previous log file will be renamed to FSUIPC7_prev.log) - if not, show me / attach those 3 files again, John FSUIPC7.ini

@dutchkip Also, there are a few issues with your ini file. First, please hcange your profile sections. Change this: to this: This will then catch ALL variants with of the PMFG 737-800 via substring matching. Secondly, your devices keep getting assigned new letters for some reason (looks like your device names and GUIDs have changed), and rather than correcting this you are adding more assignments to the new device letters. I can clean your ini for this, but I need to see your FSUIPC7.JoyScan.csv file. John

Sorry, but the FSUIPC7.log file you attached ends after half a second and shows that FSUIPC7 was still running and not even yet connected to MSFS. I need to se the FSUIPC7.log file from when you experience the issue. Also, please attach your FSUIPC_WASM.log file, from when you experience this issue. Why was this - did MSFS hang? Couldn't you kill it? Is there anything (i.e. an error or warning in the Windows Event viewer related to this? John

The limitation is that FSUIPC7 does not work / cannot be installed on an xbox console. It works on a PC in all versions, including an xbox-pass license. If you want to try FSUIPC7 first, with full functionality, please see John

This is a known issue with the TBM930 and has been reported several times. Please check for existing posts before creating a new one on the same issue. See the following: In summary, the throttle animation was working in earlier versions but seems to be broken since 2022, You can get some movement in the throttle (see first link above), but it doesn't seem possible to have it assigned externally and have the animation correct for all movement. However, I think the throttle IS working, it is just the animation that is broken. So if you want the animation, I think you need to assign in MSFS. John

When it becomes unusual, can you please exit FSUIPC7 and then show me / attach your FSUIPC7.log and FSUIPC7.ini files please. If you get a CTD, please check the windows Event viewer for further information, and show me that and also the FSUIPC7.log file at the time of the CTD.

I need to see your files. The next time the presets stop working, please exit FSUIPC7 and show me / attach your FSUIPC7.log and FSUIPC7.ini files. Also, please make sure that you are using the latest version of FSUIPC7, v7.4.14. There was a bug in the previous versions that could cause the WASM to crash on occasion, which would prevent presets working. The latest version also has the specific offsets for the PMDG 777 activated. John