John Dowson

I was starting on a runway with engine running, and I still couldn't see those lvars. Did you try issuing a Reload command to rescan for lvars (from add-ons->WASM menu)? The scanning of lvars is done shortly after the aircraft is loaded, but the full set of lvars may not yey be available, especially in more complex aircraft. There is a WASM parameter that you can adjust (via the FSUIPC_WASM.ini) called LvarScanDelay, which adds a delay before the scanning of the lvars is performed. I suggest that you increase this. You can also manually issue a Reload to check if more lvars are available. FSUIPC only scans in aircraft load. As I said, issue a Reload to see if you get more. Could you please show me your full log file, together with your .ini. Also, please also list the lvars again if/when the monitor log shows 0. I'll take another look at the CRJ700 later to see if I can get that lvar...

The SimConnect_Text API function is broken completely in the latest SDK update, which is what FSUIPC relies on for the message display facilities. Currently the only way to display messages is using the lua wnd library.

@Maniek45Please do not hijack an unrelated topic. There are similar topics to your issue - either post in one of those or create a new topic. Note, however, that the menu items are grayed out until the initial list of lvars is received from the WASM module, which occurs when you have loaded an aircraft and are ready-to-fly. The installation log looks fine, so I have no idea why the WASM module isn't loading and is preventing MSFS from starting correctly. Maybe there is some sort of logging in MSFS (possibly in the dev mode). I'll take a look and get back to you.

Please re-install again, this time with the WASM selected for install, and try again. If it doesn't work, show me your new install log, and manually move the WASM folder out of your Community folder of it doesn't work (rather than uninstall/reinstall). Also, show me your FSUIPC_WASM.log file, if there is one - it will be under your AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module folder. I am not sure why it is running with the WASM installed, very strange. This was reported before, but a re-installation solved the issue last time. John

So its not getting as far as loading FSUIPC7 no? If its stuck in the loading screen, its usually due to something in your MSFS Community folder. Did you install the FSUIPC7 WASM module? Maybe try without that - no need to reinstall, just move the fsuipc-lvar-module folder outside of the Community folder. Do you have anything else in there? If moving the WASM module out of the Community folder solves your issue, please show me your InstallFSUIPC7.log file.

That doesn't work for me. However, if I assign to send the control Toggle Fuel Valve Eng1 when leaving the bottom range of the Prop Pitch1 axis, using the right-hand side of the axis assignments panel, then this unfeathers the prop. You can also send the same control when entering the range, which should then feather the prop when you pull the prop pitch fully back. I'm using the range assignments option as the throttle/Prop axis levers I am using do not have a button that triggers on the detent. If you have such a button, then you can try assigning that control to the detent button.

Yes, that has been available from the initial release. However, if developing using FSUIPC offsets, you may find the FSInterrogate2 utility useful - its available in the Utils folder of your FSUIPC7 installation. John P.S. not sure your post is related to this thread!

Found this on the avsim forums (from July 29): To get out of feather from cold & dark, you now need to move the Manual Override lever (between the trim and throttle) forward. The prop should now unfeather. Could that be the issue?

Can you try the following hvars - try them using the Add-ons->WASM->Execute Calculator code functionality first, and if they work you can add them by creating a hvar file (or adding to an existing one) for that aircraft: (>H:TransponderOFF) (>H:TransponderSTBY) (>H:TransponderTST) (>H:TransponderON) (>H:TransponderIDT) (>H:TransponderVFR) (>H:TransponderCLR (>H:TransponderALT)) John

Ok, so this is only an issue when starting cold and dark, and it works once you have moved it to the left slot position using the mouse? Does it then work normally once that is done? I didn't try from cold and dark. Will take a look later.

To do this, you need to detect when the drone camera is being used and add an offset condition to your assignments. I don't think that there is anything available that can determine the camera that is in use, but you could detect when switching between drone/cockpit cameras either by - assigning the ins key (the default MSFS key assignment that switches from drone to cockpit view and back) in FSUIPC7 to update a user offset flag, so the flag shows 1 when using the drone camera and 0 otherwise. If you do that, you can then add an offset condition to your assignments so that they are only sent when not in drone cam mode - you could have a lua script to intercept the VIEW_MODE control/event, and again update/toggle a free user offset when such an event is received

For all aircraft or for a specific a/c? Please let me know which a/c you have tried and I will take a look. The TRANSPONDER STATE simvar is documented as working in the MSFS documentation.

Check your MSFS assignments for the buttons that you are having issues with. If assigning in FSUIPC, we recommend initially starting with an empty profile for your controllers (except mouse and keyboard) in MSFS.

When the assignments window is open, no controls are sent to the sim. Therefore it looks like you have the buttons also assigned in MSFS. After an MSFS update, you need to check your MSFS assignments as it can re-install the default profiles for your controllers. So please check your MSFS assignments.

Then something must be configured to send those controls. Are you using the Honeycomb configuration software? If so, try disabling that. Otherwise you could try activating logging for Buttons & Keys as well as Events (non-axis controls) in FSUIPC4, to see what is logged when you activate those buttons. You can attached your FSUIPC4.log and FSUIPC4.ini files and I can take a look to see/confirm that they aren't coming from FSUIPC4.

I've just taken a look and assigning to Axis Throttle1 Set (Or just Axis Throttle Set, or simply Throttle) moves the throttle in the FS, so I'm not sure what you are doing. Could you activate logging for Axis Controls, load the TBM 930 and move your throttle axis through its full range, then shutdown MSFS/FSUIPC7 and show me your FSUIPC7.log and FSUIPC7.ini files. You can also try assigning to Throttle1 Set, or Throttle Set.

No - its a signed number not unsigned, so 0xC001 is -16383. I wouldn't worry about it.

Not anymore. Commercial licenses used to be necessary, but ended up being a bit of a mess to administrate, so we do not do this anymore. So you are free to include whatever products we offer (as long as that doesn't include a license, of course!). We appreciate of being notified of such use, and maybe a free license for your software, and, if your profits allow, also a contribution via purchasing a license or two, if you consider that appropriate - but up to you. John Later: sorry, in your case, i.e .for hardware, just go ahead. No charge or license necessary. Just make sure you include any relevant documentation. I do not want to be the first port of call for issues with your customers!

Try FLT32. S32 is for a signed 32-bit integer. Please see P13 of Advanced User manual. John P.S. For future reference, please also check 'Normal log file' in the offsets monitoring log panel, so I can see what it is logging in the FSUIPC7.log files that you show me. Better and easier than a screenshot.

Ok, sounds like a good plan. But, trim control via 2 buttons (up/down) is quite a common issue. I am sure there are various solutions posted somewhere in this forum, maybe in User Contributions or from similar support requests in the main forum. I should probably add trim control assignments to the FAQ...I'll make a note to add something on this... John

I don't think so - which post are you referring to? Setting up trim depends on the type of button/switch/rotary/wheel you are using. I have posted various times on this for different set-ups - 1 or 2 button wheel or rotaries usually... Your ini has: Your log shows that you only clicked buttons 4 and 5: So at no point did you activate the buttons for which you have the larger delta (256) assigned, buttons 6 and 7. So, I think you copied something that maybe doesn't apply. Note that I also use a lua script that converts my 2-button trim wheel (up/down) to 4 virtual buttons (slow up, slow down, fat up, fast down). The easiest way to control the trim via buttons is how you previously had it, assigning to the trim offset with a suitable inc/dec and on repeat. If you want the trim delta to change depending upon the button repeat (or how long you are holding the button), you would have to do this using lua. For example, you could adapt the 'generic triple use lua for buttons' script (available in the User Contributions section) to have a slow inc/dec on a single button press, a larger (repeated) one on a long button press. Alternatively, some folks like to use compound conditions, so that the delta is small (128) when you click the buttons on their own, but increases if you click when you have another button (or key) pressed, then this triggers the same control but with a larger delta (i.e. 256). You can do it this way using compound assignments, explained in the Advanced User guide.

I'm not sure why it adds that again, as you don't have any assignments anywhere to a device A. You can try deleting it again, although it may/probably re-appear. Its nothing to worry about. These are due to some invalid registry entries for both your Razer Tartarus and Orbweaver. If everything is working. I wouldn't worry about it too much. If you want to try and resolve, you would need to disconnect the devices, remove all the registry entries for those devices and then re-connect and re-install. However, if you did this, your ini may need correcting again (if the GUIDS change), but hopefully not.... John

Your log shows the lvars having the same values as the sim shows, except for ASCRJ_VAR_AP_SELHDG: 113766 [INFO]: ID=1553 ASCRJ_VAR_AP_SELMACH = 0.550000 113766 [INFO]: ID=1554 ASCRJ_VAR_AP_SELIAS = 40.000000 113766 [INFO]: ID=1555 ASCRJ_VAR_AP_SELALT = 10000.000000 113766 [INFO]: ID=1556 ASCRJ_VAR_AP_SELVS = 0.000000 113766 [INFO]: ID=1557 ASCRJ_VAR_AP_SELHDG = 0.000000 113766 [INFO]: ID=1558 ASCRJ_VAR_AP_SPDTREND = 0.000000 That looks to have the correct value in the log you showed. I don't understand how the sim can be showing a different value for ASCRJ_VAR_AP_SELHDG (assuming the screenshot was taken at the same time you listed the lvars)- FSUIPC treats all lvars the same, it just receives the name and value from the WASM, so if the value is 0 that is what the FS is sending. I also don't know why I don't see those lvars in the CRJ700 - I'll take another look next week.

Please show me your FSUIPC7.ini and FSUIPC7.log file, showing me your issue, i.e. with the LvarOffset section populating offsets for the lvars you say are always 0, together with your monitoring. Also, please issue a Add-ons->WASM->Log Lvars command, so I can see what lvars are available. I've just taken a look at the AS CRJ 550ER and I get 1752 lvars, and in the AS CRJ700ER I also get 1752 lvars, but I cannot see the lvars L:ASCRJ_VAR_AP_SELHDG or ASCRJ_VAR_AP_SELIAS in either aircraft. Are you sure they exist? If they don't exist, your FSUIPC7.log should show an error when trying to access them. John

I don't know where you got that impression from. It is quite clear on SimMarket, in the download forums here and on www.fsuipc.com which product is for which FS. You can also download and try-before-you-buy. There is a strict no refunds policy (SimMarket) as we do not do on-line license validation, so once a license has been issued it cannot be revoked. It is not possible to transfer a license. However, if you let me know your order number, I will verify your purchase and generate you a complimentary license for FSUIPC7. This may take a few days. In the mean-time, you can use the trial license, available here: John