John Dowson

Found an issue when adding lvars to offsets when the lvar id > 1023. I've corrected this and will post an update shortly. There also seems to be an issue when using the SD size specifier for lvar offsets. The lvar has the correct value but the monitoring if the lvar doesn't show the correct value or value change. I am looking into it. John

There doesn't seem to be any logging available. Can you try just leaving it running to see if it eventually loads - with just the FSUIPC7 WASM in your Community folder, nothing else.

Just taken a look and I can now see those lvars. For ASCRJ_VAR_AP_SELHDG, you need to treat it as an 8-byte double, so use and monitor as a FLT64.

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