John Dowson

As far as I am aware, there is no access to z vars provided by the the SDK. But you say they are A:vars aka simvars....so what is the difference between a Z and and and A var? If they are treated the same via the SDK, then you can just use the facilities provided by FSUIPC to add any available simvar to an offset. Otherwise, if they are more like L:vars, then I would need to check if they were readable by the WASM and provide a mechanism to pass the values back to FSUIPC as I do with lvars. But I can't really say much more until I know more about what z:vars are and how they can be accessed. I don't see anything about these in the MSFS SDK documentation - do you have any references? John

This really should be possible....maybe take a look at these posts for other VRInsight devices John

First, you posted in the User Contributions sub-forum where it explicitly states Not for support requests. You also don't say what aircraft you are using. Many add-on aircraft can use custom controls and/or lvars, rather than the standard controls provided by the FS. If you want help with specific assignments, please attach your FSUIPC ini and log files, the latter generated showing your issue and with relevant logging enabled (e.g. usually axis controls for axes assignment issues and events (non-axis controls) for buttons a & key assignments). I provide extensive documentation. FSUIPC is a product that work with an huge range of controllers and all aircraft, and the configuration of each controller can be different for each aircraft and for each persons' preference. It is just not possible for me to provide specific guides for each controller or aircraft. There are plenty of guides for specific issues in the User Contributions and FAQ section, and I think there are also several user-posted videos on youtube on various issues.

Looks like you need to remove a registry entry...I'm finishing now (got to take the dogs for a walk!) - I'll post you a regedit file tomorrow. John

The data is as explained in the PMDG offset document - please see that to find out how to interpret the data.

The lua example I showed you should do the first part - you need to add the ability to write out the CDU_data array variable to a text file.

Not sure what you mean or what FSUIPC has to do with this....

I think changing the aircraft/livery name is not a good idea as any changes will get overwritten when you update. Just use multiple substrings, so that you catch each livery, e.g If you load an aircraft with a livery that is not matched, just add it to the profile using the FSUIPC UI. Afterwards, you can look at the ini and change the full aircraft name. FSUIPC will only add full aircraft names to profiles, even when using UseAirLocForHvars - I will change this at some point to add the folder name instead... This really isn't that complicated.... John

Why are you posting me ASP3D logs? It means nothing to me - show them to AS. You can post your FSUIPC log file here, not logs from other client programs. And the title of your post is very misleading. It is not working as you do not have it configure correctly, not due to FSUIPC. Is FSUIPC even running?

That picture means nothing to me. I support FSUIPC, not whatever that is. But, as that screenshot shows, do you have FSUIPC installed and running? If not, install it and run it and try again. If your issue is that FSUIPC7 is not auto-starting with MSFS, see Otherwise, tell me what your issue is with FSUIPC7, otherwise I suggest you try the support for the program you are using. John

If it works with LINDA, it should also work without, as that is built upon FSUIPC's lua facilities. See the appendix on VRInsight devices in the Advanced User guide, together with the additional document Lua Plugins for VRInsight Devices.pdf. John

Btw, if you have a keyboard where it is difficult to tell the state of the Num, Caps and Scroll lock, you can use this free utility: https://keyboard-leds.com/ That is what I use. It sits in your tray and shows the state of the locks and allows you to change the state easily, and is pretty customizable. John

Fixing the script how? Is this your issue? I don't see this at all and would need to see your logs to see why this is happening. The script works as expected here, although I find it very difficult to control using keys rather than a yoke or joystick... I think I also now understand why the Num5 key isn't working for you - you do not have NumLock on! I just tried with NumLock off, and the other keys still work but not the 5 key. So, either switch numlock on, or change the centreAllKeycode from 101 (Numpad5 with NumLock On) to 12 (Numpad5 with NumLock Off). Looks like the other numpad keys send the same keycode regardless of the NumLock state. Or, you can just add the following line to the bottom of the script to support when numlock is on or off: event.key(12, 0, 1, "flightControl") -- request on initial press only, NumPad5 with NumLock Off John

Can you try this one first - just start MSFS/FSUIPC, once it has started exit and show me your updated FSUIPC7.ini and FSUIPC7.log files and I'll see if a registry edit is needed. John FSUIPC7.ini

How do you want to read this data, and what do you want to do with it? If you want to read all of the CDU data, you can do this using a multi-dimensional array. Something like: -- Define the size of the array - we will start are indeces at 0 to make offset calculation easier CDU_Colums = 24 - 1 CDU_Rows = 14 - 1 -- Initializing the array CDU_data = {} for i=0,CDU_Colums do CDU_data[i] = {} for j=0,CDU_Rows do CDU_data[i][j] = 0 end end -- Read the data: 0x5400 == 21504 in decimal for i=0,CDU_Colums do for j=0,CDU_Rows do CDU_data[i][j] = ipc.readUB(21504 + i + (j*(CDU_Colums+1))) end end I haven't tried this! John

No - the only FSUIPC version compatible with FSX/FSX-SE is FSUIPC4. To determine what control is used for a specific button (FPS panel or otherwise), you can activate logging for Events (non-axis controls), open the logging console and press the button in the virtual cockpit. See if any event is logged, and if so, you can assign to that. If no event is logged, you could try using a mouse macro. However, not all aircraft support mouse macros - from the User guide: This indicates that mouse macros will not be available. If there are no standard controls/events and mouse macros are not available for the aircraft, you could look into using lvars. If you let me know which default aircraft you are using, I could take a look to see what is available for the GPS of that aircraft, John

Btw, if you did this in the FSUIPC_WASM.ini file located under your Community folder, this will get overwritten the next time you update FSUIPC7. Make sure that you have copied this file to your WASM persistent storage area so that this is preserved - see the Advanced User guide for details. John

The folder where the aircraft.cfg files for the FBW A320 are located are called: _FlyByWire_A320_NEO-LIVERY-XMAS FlyByWire_A320_NEO FlyByWire_A320_NEO-LIVERY ,,,(you may have more) So if you have a hvar file called A320.hvar, then A320 is a substring match to those folder names, and so that hvar file will be loaded any time those aircraft are loaded. John

What does this mean? Did you calibrate in MSFS or FSUIPC? Calibration doesn't 'go missing'... Profiles are loaded automatically when you load an aircraft that is assigned to a profile, and when a profile is used for an aircraft the profile checkbox in the axis panel will always be checked and disabled, and if you have profile-specific calibration that will also be checked and disabled. You can only change profile-specific checkbox for button assignments. It is not possible to manually load a profile - you can only assign an aircraft to a profile and these are loaded automatically. And you always need to show me your FSUIPC7.log and FSUIPC7.ini files if you are having issues with assignments or calibration. Please attach them. They are independent. If you assign in MSFS, you use the sensitivity windows in MSFS and such axes will not be calibrated in FSUIPC. It was previously possible to also calibrate in FSUIPC when assigned in MSFS, but this is broken since SU10 - I have raised a bug report on this with Asobo and am awaiting further information in this issue. If you want to calibrate in FSUIPC, then you have to assign with 'Direct to FSUIPC Calibration', and you cannot use the sensitivity oprions in MSFS when doing this. John

I do not need to see screen-shots, just your ini and log files are enough. And you assignment screenshot also differs from what your ini shows, and so is confusing: 2=GR,B,-16254,-11573,66066,0,66067,0 -{ DIRECT: SpoilersEntering=SPOILERS_ARM_ON, Leaving=SPOILERS_ARM_OFF }- i.e. from is not -15734 but -16254. The log file shows no spoiler axis movement at all. This is because you used the aircraft "Airbus A320 Neo Asobo" which is not using your A320 profile, and so has no axes assignments. Either add that aircraft to your profile or go back to using the "TAP-TNR". You also have a missing device to which you have assignments: This has been re-recognised as device G, to which you also have assignments. This is being caused by your throttle quadrant being recognised twice, once with a new and once without: The registry entries for that 2nd entry without the name should be removed. You could try disconnecting, removng any drivers you installed, rebootung and then reconnect to see if that solves the issue. Otherwise I can provide you with a script to remove this from the registry completely and then you can re-connect and try again. This is why you keep having to re-assign to that device, as it is continually recongised as a new device. Anyway, I have attempted to correct a few things in the attached ini if you would like to ty with this, and show me a log file with the spoiler movement. Otherwise, we can correct for your throttle quadrant first. John FSUIPC7.ini

Yes - I will update the offset document to make this clear. John

That is just the section where the auto-save file names are saved when using P3Dv4 when you have auto-save feature activated. As you have this feature disabled, it will be empty - apart from the Next parameter which is always present.

Yes - that's the crash event for MSFS.

That goes in the FSUIPC7.ini. But you don't need to add this any more, and the WASM is now enabled by default. It will only not be enabled if you have it explicitly disabled in your FSUIPC7.ini file, i.e. and if that is the case you can enable it by using the Add-ons->WASM->Enable menu entry. But really you shouldn't need to do anything. John

I don't know NeoFly but I have just downloaded it and will take a look at some point, most probably over the weekend. Are you using 3.13? That version is quite old now (11 months). I see there is an early-access version of NeoFly4 - maybe try updating to that. There are only minor changes from 7.3.9 -> 7.3.10 and from 7.3.10->7.3.11. What version were you previously using? 7.3.9 was the initial version I released for SU10 compatibility. John