John Dowson

The view controls have not been working since MSFS was released - from the README.,txt file: You can also control use using the camera presets (under MobiFlight -> All vendors -> All Aircraft -> Camera). Or you can set the simvars CAMERA STATE, CAMERA SUBSTATE, CAMERA VIEW TYPE AND INDEX:0 & CAMERA VIEW TYPE AND INDEX:1 individually via offsets 0x026D, 0x026E, 0x026F & 0x0270. John

You use the exe I provided to replace the current one in your FSUIPC7 installation folder - iy will use the same installed WASM as the previous release (i.e. no WASM update). Ok, good to know, thanks - probably due to the PMDG 777 thread now running. Could you please show me your FSUIPC7.log file from this version, on the client machine, so that I can check a few things. You should raise a support ticket for this. Also ask if lvar access when running across a network can be added as this should be possible and relatively straightforward, as the .Net dll that SLC uses for this already allows for this. Regards, John

That is everything available from the PMDG 777 SDK. If there are no specific offsets for throttle or auto-throttle, maybe the 777 is using the provided simvars in which case you can use the standard/general offsets for this. Otherwise look at the available lvars, which can be added to spare/free FSUIPC offsets if required (for both read and write - PMDG offsets are read-only). I can see these lvars that may be of use: Throttle1_Pos Throttle2_Pos XMLVAR_LeverThrottleHidden1 XMLVAR_LeverThrottleHidden2 MCPAutothrottleSwitchOnLeft MCPAutothrottleSwitchOnRight MCPAutothrottleSwitchOffLeft MCPAutothrottleSwitchOffRight There are no "Input Events" available for the PMDG 777. There may be some H-vars (HTML variables), but you would need to inspect the throttle behavior to discover these (see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/). But Hvars don't hold values and are only for controlling HTML elements in the UI, so most probably not relevant. If none of this is sufficient for your needs, you can ask PMDG about this. John

I have corrected for this in the attached version, 7.4.17b, if you could try it. Please show mr your FSUIPC7.log file from the client PC after using - and please exit FSUIPC7 before attaching files. John FSUIPC7.exe

I have discussed this with Steve, the SLC developer, and it looks like there are currently restrictions when using SLC on a remote/client PC: SLC will need an update to handle lvars on a remote machine. Ok. Looking at your log file, there are a few issues I need to fix when running FSUIPC7 on a client machine: - I need to update the PMDG 777 thread to be able to use the remote connection - WASM / WAPI facilities are disabled as no WASM installed - the WASM is on the server machine and these facilities should be available (this was previously working, but I think a recent change in initialization order has broken this) I will look into these issues, but I'm afraid that this will not fix your issues with SLC. John

Ok - best to read the section Multiple Joysticks for Multiple Pilots on page 45 of the Advanced User guide.

I think this maybe the issue...Are you also running FSUIPC7 or WideClient on the remote machine as well, or just SLC? If running FSUIPC7, have you configured this for remote access on both the [General] and [WAPI] sections (as explained in the appendix on setting-up FSUIPC7 for remote access)?

Note that another user posted a similar issue a couple of months ago: There was no resolution to the issue though as the OP didn't respond to my last post.

@lamikela1 You posted this in a very old topic and in the main support forum - I have moved your post to the specific sub-forum for FSUIPC7. That is incorrect as you have duplicate index numbers, so only one will be used. All index numbers MUST be unique, so try: John

I have no idea as I don't have SLC and know nothing about this.... What does this mean? There is a known issue with the WASM in that it can crash when using complex aircraft and complex add-on scenery. There is a FAQ entry on this with a fix - see If that is not your issue, please provide a more detailed explanation of what the problem is, and please show me/attach your FSUIPC7.log and FSUIPC7.ini files, attached when FSUIPC7 is NOT running, and also your FSUIPC_WASM.log file (see the Advanced User guide if you do not know where this is located) attached when MSFS is NOT running and after a session where you experienced your issue. John

Many MSFS aircraft continually emit some events, and these events are different for each aircraft. You can stop such events being logged by using the DontLogThese ini parameter. Ok. The 4th registry entry isn't causing any issues so you can ignore this. This is something that the MSFS steam edition seems to create on start-up. If you exit FSUIPC7 and restart it once MSFS is running, you should not see this device. What that ini parameter does is to ignore this device when detected, so it shouldn't cause issues. I also need to see your FSUIPC7.ini as this has also been modified...you now seem to be using a profile called 'Fenix A320 - Scoot (2018) 8K' which wasn't present in the ini files you previously attached... Did the 'safety no smoking' presets work: ? Do other presets work after you have determined that the seat-belt preset doesn't? If not, you may be experiencing a WASM crash. Please see the following FAQ entry on how to determine if the WASM has crashed and if so how to prevent this: If that is not the issue, then I will need to investigate further, but I can't see how this can have anything to do with the use of the IgnoreDevice ini parameter The seat belt presets you are using just change the value of the lvar L:S_OH_SIGNS between 1 (on) and 0 (off). When you execute the preset, does the lvar value change (you can list the values using Add-ons->WASM0>List Lvars)? If so, then the preset is working as expected. If not, can you manually change the value of this preset using the Add-ons->WASM0>Set Lvar menu item and does that have the desired effect? For any future logs, please activate logging for Buttons & Switches, Events, Extras and WAPI->Debug level logging. No logging for Input Events necessary. You can also ignore those other events by adding the following to your Fenix [Profile.xxx] section (where xxx is the profile name): DontLogThese=66068,65957,66519 Probably also a good idea to set Debug level logging in the WASM (via the FSUIPC_WASM.ini file) - see the Advanced User guide on how to do this / where that file is located. John

No need to see the log file as you have determined that the WASM crashed - just try with the updated parameters.

They are in the Offset Mapping for PMDG 777 document which should be in your FSUIPC7 documents folder, and is attached below. John Offset Mapping for PMDG 777.pdf

You need the IgnoreDevice ini parameter, so please leave that, If some of your buttons are not working, please generate a log file (with logging for Buttons & Keys as well as Events activated) and show me/attach that, together with your FSUIPC7.ini and FSUIPC7.JoyScan.csv files and a brief description of what button didn't work. Also, please exit FSUIPC7 before attaching files. How many 'RIGHT VPC MongoosT-50CM3' devices do you actually have - 3 or 4? Only 3 are detected in HID scanning but there are 4 registry entries - one may need to be removed.,

For all issues with FSUIPC7, please use the specific sub-forum for FSUIPC7 - you posted in the main support forum. I have moved your post. You do NOT need to run as admin. Click on what exe? The installer or FSUIPC7? Also, clicking just selects - you normally need to double-click to run... There is certainly nothing wrong with the zip file and its contents are correct. Try downloading again. And check any anti-virus software you have running as that maybe interfering. If so, disable (or add an exception) while installing.

The events.txt file (not eventing.txt) is installed in your FSUIPC7 installation folder. If you cannot see it, you probably have windows explorer set to hide the extensions of known file types. If only presets for the A320 (which one?) are there, then you are either looking at the wrong file or you are using a different file to the one installed by the FSUIPC7 installer. I don't understand why you are having such difficulties, Have you read the section 'MobiFlight Presets and the events.txt file' in the Advanced user guide? If not, start there.... John

You should read the description of this preset: For encoder. Requires also setting output timer handler "PMDG B777 Baro Timer Handler" preset And the PMDG B777 Mins Timer Handler preset states: Used along with EFIS L Mins Inc and Dec and EFIS R Baro Inc and Dec events. Note however that this is an Output preset, and so cannot be used in FSUIPC. It is not clear to me why this was implemented this way or how you use these presets together (and I don't have the 777 to test/look into this). You could ask about this on the MF Discord server (MSFS2020 channel), but probably better to look into other methods of control as FSUIPC does not support Output presets - these are for use in MobiFlight and there are other ways to access lvar values in FSUIPC. There is the preset PMDG B777 EFIS L Baro Knob which has the description: This is the Baro knob INCR/DECR. There is additional code required for the "slew" capability. Takes inputs from -50 to +50. This makes me think that the additional timer code in the inc/dec presets are for this "slew" capability. There are two other things you can try: 1. Use the 737 presets. These use the rotor brake controls (i.e. custom controls via the Rotor Brake control). These should also be valid for the 777, as I believe the PMDG SDK header file for the 777 is the same as that for the 737, 2. Define your own preset (using the myevents.txt file) as follows: My_PMDG_B777_EFIS_L_Baro_Knob#$Param (>L:CABaroKnob, number) Then assign to this giving a negative parameter (e.g. -10) for decrement, and a positive parameter (e.g.10) for the increment. The lvar takes values from -50 to +50, so you can adjust the parameter to suit your needs.

Yes - corrected. I have also delayed the request of keys from MSFS to prevent this issue (or to at least make it less likely to occur) in the next release. I have attached a beta with this update below if you would like to try it. With this version, you should be able to keep the delay at 85, although there should also be no issue increasing this slightly. John FSUIPC7.exe

As I said, I only update the list of presets (events.txt file) with each release of FSUIPC7. If there are newer presets you want to use, you can download the latest file yourself and use that,

I am not sure what you mean by ' to the same VPC dial as for B737'. Could you please show me / attach your FSUIPC7.ini file so that I can see your assignments. Note there are presets defined for the PMDG B777 EFIS L Baro Inc and Dec - PMDG B777 EFIS L Baro Inc & PMDG B777 EFIS L Baro Dec. Have you tried those? If they are not working as expected, you can ask about these on the MobiFlight discord server, in the msfs2020 channel.

I have this aircraft now. EVT_LEVER_SPOILER_1 is an Input Event - there are several input events for the spoilers: EVT_LEVER_SPOILER_1<;FLOAT64>=0.000000 EVT_LEVER_SPOILER_2<;FLOAT64>=0.000000 EVT_LEVER_SPOILER_INC<;FLOAT64>=0.000000 EVT_LEVER_SPOILER_DEC<;FLOAT64>=0.000000 EVT_LEVER_SPOILER_ON<;FLOAT64>=0.000000 EVT_LEVER_SPOILER_OFF<;FLOAT64>=0.000000 It is relatively straight-forward to assign buttons/switches (or axis ranges) to Input Events, by checking the Select for Input Event checkbox and then selecting the Input Event, but assigning to an axis is more complicated. Direct assignment if an input event to an axis is not currently provided, as you would need to calibrate the axis value range to the Input Event range, To do this, you have to assign the axis to a spare/free FSUIPC offset (Send to FSUIPC Offset), and then monitor the offset for value changes in a lua script, and then calibrate the axis value to an input event value and then send the input event with this value. However, as there is also an lvar to control this, it is easier to use the lvar via a preset, as you have done. Just FYI. John

No, as you calibrate the control for the axis and not the actual axis itself. If you calibrate the control for its assignment on one axis, it will also apply if the control is assigned to another axis. Note that it is generally not a good idea to assign the main flight controls to multiple axis. The problem with doing this is that any movement on the joystick will send the control, and so the joystick not currently being used can still send values which can cause the assigned axis to jump around. You would normally only assigned multiple flight controls if using a pilot/co-pilot set-up, and when doing this you should assign using “direct to FSUIPC calibration” and FSUIPC will actually arbitrate between them, the maximum value (away from zero) being the one which “wins”. And the joysticks for pilot/co-pilot should be the same and use the same calibration. You can maybe look into calibrating each axis first in windows (game controllers), although I am not sure if this will help. FSUIPC will see the windows-calibrated values before applying its own calibration.

Sorry, but I do not understand the question. I download and add the events.txt file (from MobiFlight - the file that contains the presets) either on the day of release of FSUIPC7 or sometimes the previous day. So the preset file included in FSUIPC7 version 7.4.16 will be from the 24th or 25th July. The date individual presets are added is only available in the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/), where you can also download the latest events.txt file if there are new presets you want to use not included in the one installed by the FSUIPC7 installer. John

That is a message from your acars program, not FSUIPC. Is FSUIPC7 running? You need to verify that first. If programs that use FSUIPC cannot connect, it is usually because they are running at a different privilege level. Everything must be ran at the same privilege level to connect. John

You did, and I cut and pasted your key here and it validated just fine. I would like to know now if the key validates ok for you now. And if so, why did it not validate when you cut and pasted previoulsy. It is trivial and I am not arguing - I would just like to understand why so many people seem to have issues with registration, I get several support requests every week on failed registration issues, but whenever I check/validate them here they are all fine. I send the key to the OP (i.e. you in this case) and then i get told its all fine now but I never get to the bottom of the issue as to why the customer/client could not validate correctly themselves in the first place. If I could find out what the issue is for such users, I could update the documentation (or even the registration process) so that I do not get so many support requests in something that should be so straight-forward. So any feedback on what the issue was is important so that I can improve things going forward.