John Dowson

There is an FSUIPC-added control you can use: List Local Panel Vars. Assign a spare button or key press to that. Alternatively, there is a lua plugin provided - log lvars.lua, in the Example LUA plugins package in your FSUIPC6 documents folder.

There is nothing preventing the use in the of FSUIPC as you say you cannot even assign this in P3D. If there is no P3D axis that controls this, then you cannot assign to this. You should ask the helicopter developers how to control this twist operation. You could maybe try listing the lvars to see if any of them look applicable. If there is an lvar for this, you would need to assign your axis to write its value to a free/spare FSUIPC offset, then have a lua script that monitors the offset, calibrates the axis value and then use this to set the lvar. Yes, - let me know if you get a response. John

So, the throttle axis works to control the collective. So why can't you assign the slider to the throttle axis? So, assigning your slider to the throttle axis results in PROP_PITCH_SET controls being logged with a parameter of 0? When you say 'mapping the joystick axis to throttle worked', did this result in PROP_PITCH_SET being logged with a parameter? Can you please show me your MILVIZ UH-1.ini file, both with assignments when the collective assignment is mapped to a joystick axis and it works, and another when it is mapped to the slider and it doesn't work. If an assignment to a control works on one axis, it should work on another. Do you see the in/out values change in the assignment panel when mapped to the slider? Do you mean the twist axis in the VC? An axis is just an axis, it shouldn't matter if this is a twist axis, a slider or a joystick/yoke. You do have controllers set to ON in P3D: So please check that your axes are not also assigned in P3D. Bet to disable controllers in P3D if assigning in FSUIPC. I see there are also a lot of aileron, elevator and rudder controls logged, all with a 0 parameter. What is generating these?

And when you restart MSFS, is FSUIPC7 again auto-started? And when this happens, if you restart FSUIPC7 the keys then work? The log shows no key presses were received by FSUIPC7. The next time this happens, can you try disconnecting FSUIPC7 from MSFS and reconnecting, via FSUIPC's MSFS menu. This seems to be an issue that occurs occasionally - FSUIPC7 requests all key presses when it connects, but sometimes no keys are sent, and no error is received. I am not sure why this is, or what I can do about it. And I cannot reproduce this behavior here. In your log, I see you are auto-running lua script PMCO_FNX32X.lua which is exiting if the Fenix A320 isn't loaded. Rather than doing this, you should only start the script in an auto profile section for the Fenix A320.

I have moved your post to the FSUIPC7 sub-forum. No - you can mix and match assignments between FSUIPC and MSFS. Just make sure that if assigned in MSFS, then it is not assigned in FSUIPC7. To do this, best to create a profile with both an empty axis section and an empty calibration section, although you can calibrate some axes in FSUIPC7 when assigned in MSFS if you so wish, but you should always first try without calibration. The API provided by MSFS (and FSX, P3D) only allows / provides controls for up to 4 separate throttles, and a generic throttle control that should apply to all engines. So you can try assigning to the generic throttle control. The aircraft itself may provided additional throttle controls for each engine, either via Input Events or lvars. If so, you can use those of you want to assign to 6 levers, using 2 throttles per lever. Can you control all 12 engines separately in the VC? If so, try using FSUIPC's logging facilities to see what is being used when you move each separate throttle in the VC. Try logging for Axis Controls first, then Input Events. If nothing is logged with either of those, try checking for lvars. I guess it may also/instead map the 12 engines to the 4 existing throttle controls. If so, you can map 4 of the levers to the 4 separate engine controls.

I have taken a look at this and it works just fine here. However, please note that when the lvar value changes, PMDG offset 0x64FB is also updated and vica-versa. So you don't need an event on both the offset and the lvar - an event on the offset should be sufficient. I do not know why it has stopped working for you, or why FSUIPC hangs when you restart the script - I can restart just fine here. So something else must be going on. Can you please show me your FSUIPC7.log file from when you have to kill FSUIPC7. If/when you restart FSUIPC7 after killing it, does it run ok and are all lvars loaded?

But why attach the WASM - I distribute that. i need the FSUIPC_WASM.log file, not the files that are installed by the FSUIPC7 installer. A WASM module should not crash MSFS - the WASM will just crash and MSFS will continue. Please see the Asobo forums for all MSFS CTDs. This will most probably be something specific to your new PC. I cannot help with this.

You are not doing anything wrong - just use what works. I don't know why its logging something different from the VC.

Nearly all CTDs in FSX with FSUIPC4 are due to a corrupt weather file. Please see John

Thanks for the update.

There is already a preset for the alt sync, XCub Ap Alt Push, whose preset code does some thing similar to that proposed for the heading: (A:INDICATED ALTITUDE, feet) (>K:AP_ALT_VAR_SET_ENGLISH)

Can you please activate logging for Buttons & Keys and show me / attach a FSUIPC7.log file from when the keys don't work and I will take a look. John

Sorry but I didn't have time to look into this today. I am now on holiday, back in Tuesday 6th (in 4-5 days), and will take a look then. Sorry for any inconvenience, John

Thanks @ark1320 - should have checked the MSFS documentation on this. Hopefully @Guido can try your preset using PLANE HEADING DEGREES MAGNETIC simvar. Any further issues, I will take a look next week (back on support on the 6th). John

I tried that preset in the PMDG 737 and it is working as expected here. Have you used any presets before, and if so were they working? Do you have the WASM installed and enabled? Could you please attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. Note that i am on holiday from this evening, back on support on Tuesday 6th. So unfortunately I will not be able to look into this further until later next week. Also ,ale sure that you are using the latest version of FSUIPC7, version 7.4.16. If you install that and accept the defaults, the WASM should be installed and enabled, but if not enabled you can enable from Add-ons->WASM->Enable. Try that and any issues attach those files and I will take a look next week. John

Probably a better solution rather than using the HSI BEARING simvar unless this is correct. If so, you could use the following preset: SYNC_HDG_BUG_TO_HSI_HDG#(A:HSI BEARING, degrees) (>K:HEADING_BUG_SET) Suggest @Guido tries both - add them to your myevents.txt file (create this if not present) and try them both. I will take a look later if I have time, but am rather busy and am on holiday from tomorrow until the 5th (inclusive), so it may be next week. John

Still a lot of reconnection attempts though. Looks like it takes a long time for your MSFS to start-up and get to the main menu... Try increasing the parameter, i.e. DetectToConnectDelayAuto=400 And when you get to the main menu in msfs, take a look at FSUIPC7 and wait until it connects before you do anything. This will then tune that parameter for the correct value for your system. John

Don't worry about it - its not an issue. I have checked further and it is an issue with this preset defined in MobiFlight. It will be ignored. John

The log file you attached shows that FSUIPC7 was not able to acquire a simconnect connection to MSFS. Not sure why this is, but can you please change the DetectToConnectDelayAuto ini parameter (in the [General] section of your FSUIPC7.ini file) to the following and try again: DetectToConnectDelayAuto=120 Please reboot your PC first. You also seem to have a preset that exceeds the maximum defined length: This is in the events.txt file but is NOT an MF event. Did you add this? You should not modify the events.txt file (as any modifications will be lost when you update), but use the myevents.txt file instead. Please see the documentation (Advanced User guide, WASM section). John P.S. Please STOP posting images. They are useless, especially as you keep posting images of things you don't see.,., I ALWAYS prefer to see your files and not screenshots. Only post images when asked for.

A lot of posts, and of images showing that the lvars have been loaded. But you say they are not...please show me/attach your FSUIPC7.log file. The current WASM version included in FSUIPC7 version 7.4.16 is 1.0.5. If you are using FSUIPC client apps built with an earlier version, you will get version incompatibility warnings, but they should work just the same as the API has not changed. John

I don't know this AP - which aircraft is it in? How do you do this (synch the HSI heading bug) on the AP (in the VC)? HEADING_BYG_SET is an event, or FS Control, not a simvar. You can assign to this, but you need to provide the value/parameter. If no control (hvar, lvar, preset, input event) is available and you want to do this, you would need to write a simple lua script to get the bearing and then set it. The script would read the HSI BEARING from offset 0x2FA8 and then send the HEADING_BUG_SET event/control: bearing = ipc.readUW(0x2FA8) ipc.control(66042, bearing); However, offset 0x2FA8 should hold the HSI BEARING simvar, but this is documented as untested with comment 'Doesn’t seem to work. Feedback?'. So, I would first monitor this offset (using FSUIPC's offset monitoring facilities) to verify that it is indeed holding the correct value.

That looks ok. Maybe the preset isn't working. I can test it here a bit later. Which aircraft have you tried with? Have you tried any other of the camera presets?

For view controls, you can try the available FS controls for switching views: NEXT_VIEW PREV_VIEW NEXT_SUB_VIEW PREV_SUB_VIEW However, if you want to assign a key or button to jump straight to a specific view, you gave two options: - try the available presets (see https://hubhop.mobiflight.com/presets/ and search for Camera). These are the generic camera entries available in the MF evemts.txt file: - try the camera offsets: 0x026D - Camera State 0x026E - Camera Substate 0x026F / 0x0270 - Camera View Type and Index Best to log these first to see what values they hold for the views you want to access via a key or button press. You can then either assign to update these offsets to the relevant values, or create a preset to do this. Also please see other support requests on controlling views. Start with this one, which also contains links to several other similar topics: That should be enough to get you started. If you require further assistance, let me know.

By 'no startups', do you also mean FSUIPC7 or just the programs that FSUIPC7 starts? When you say 'manually started;, do you mean FSUIPC7, or the programs that FSUIPC7 starts, or both? Did you should down FSUIPC7 and all other programs before doing this, or just FSUIPC7? Was this when using RunIf instead of Run? I think your problem lies with these additional programs being started, and not with FSUIPC7. It seems that two of your programs are trying to access the same port, or one program that is being ran twice. I suggest you check your ProSim / SIOC configutation. I also asked Pete about this - this is his reply: John

License now available for download in the first post in this topic.