John Dowson

is also almost certainly caused by the same problem But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before..... ...and the installer no longer requests admin privileges anyway...

Thats code from the installer to determine the location of your UserCfg.opt file.Thats whats failing for you during installation, and so thinks you have an MS Store install.

FSUIPC installs nothing in the Admin folder, unless you are running as admin. However, yout installation log does indicate that it is installing in the admin folder: Not sure why thiis is either. Did you install the first time as admin? Once installed, it will use the previous location in the registry the next time you install. Try running the uninstaller manually (from the FSUIPC7 installation folder or the Windows App management panel) and re-install again, to see if it picks up your correct Documents folder. And show me the new InstallFSUIPC7.log file please. Your Documents folder is taken from the registry for a fresh install, using the HKCU Personal key under "SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" Due to these errors, there may be some other empty folders that have been created that you may want to move: Create folder: \fsuipc-lvar-module Create folder: \fsuipc-lvar-module although those may have failed....Thats an issue in the installer which I will correct - it shouldn't try and install the WASM if the Community folder can't be determined.

Then I have no idea why this test is failing: IfFileExists "$APPDATA\Microsoft Flight Simulator\UserCfg.opt" steamUserCfg nsArray::Set LogMessagesArray "Determing Community folder for MS Store install" ... steamUserCfg: nsArray::Set LogMessagesArray "Determing Community folder for Steam install" Looks to be a space between your t and a (e.g 'AppDat a' as opposed to 'AppData', but maybe thats just your image/font/my eyes... Other than that. I have no idea why its not determining the correct location. It works for everyone else...very strange....

vJoy won't do anything by itself unless you have also assigned to the virtual buttons its using....show us you .ini and .log, with the advised logging activated, which should hopefully show what is happening.

The World Update II was just scenery, and the SDK does not know about lvars/hvars, so I'd find it surprising if thhey changed anything. Weird..

Well, not according to the installer. You should not modify the batch file. Remove that and add the folder C:\Users\jackp\AppData\Roaming\Microsoft Flight Simulator : EXE.xml If you already have aan EXE.xml file there starting something else, just extract the "<Launch.Addon>....</Launch.Addon>" section that starts FSUIPC7 and add that.

Anyway, here's the WASM. Just extract into your Community folder and it will be recognised by FSUIPC: fsuipc-lvar-module.zip The other issue you will have though is that FSUIPC will not autostart with MSFS as it cannot find the location of your EXE.xml. Did you not notice this? Is it a problem?

You do not (and should not) install as admin. The problem, for your installation, looks to be that your APPDATA environment variable is not set correctly and the installer cannot find your UserCfg.opt file location. Can you check what this is set to? Should be 'C:\Users\jackp\AppData\Roaming'.

Yes, It can be omitted, sorry. Please generate a short log as advised. It shouldn't be. Turn off other logging, especially IPC Reads/Writes that will make the log huge. Also add offset logging for the offset you are using, 0x66C0, as U32 in hex. Note you can also use the DontLogThese ini parameter (both in [General] and profile sections) to prevent the spurios logging of many events in various aircraft.

Perhaps I should have been more clear. I'm not trying to set the value of the 03C0 offsets directly. If you look closelier at the .ini line I used, I'm not setting that offset directly, I'm simply pressing the associated button (actually... I'm using the control to set that buttons flag... 1003). By my understanding that should change the offset to reflect that the button was pushed except for this: Again in my initial questions I said: I couldn't tell exactly from this post whether or not "when there is at least one assignment to that joystick" means "when there is an actual device in the [JoyNames] section mapped to joystick number matching the offset I'm trying to read... OR if it means "when there is an entry in the [Buttons] section that uses that joystick as the trigger". Since I wasn't sure and I can't force a particular device to be assigned to joystick number 15 (or at least, I don't know how to force that assignment) I tried to add an entry in the [Buttons] section for with joystick 15, button 9 as a trigger with the "no-op" control and it still didn't work. Because of this, I assumed that you must've meant "when there is a [JoyNames] assignment" as opposed to a "[Buttons] entry". Perhaps you could verify that I'm correct about this. Offset area 03C0 is what FSUIPC maintains for button presses. You can/should NOT wtite to it, by any means, either directly. You cannot set a button flag on a joystick tat doesn't exist. Please just forget this offset for your issue. You don't need the mobiflight wasm if using FSUIUPC, but you can use the mobiflight events instead of the fsuipc facilities if you prefer. You image shows that the FSUIPC WASM module was not installed. Looking at yout log file, it shows this: Do you have an MS Store install or a Steam install? Do you know the location of your MSFS UserCfg.opt file?

What has changed on your system since this change? Was anything updated - MobiFlight, G3000 or the 580 overlay?

Your offset conditions are not correct: 14=DA000&200 49,8,66502,1 ;vor flag&setting flag 1 -{1: Press=AP_NAV_SELECT_SET }- You need to add the condition. To check the bit is set, use: 14=DA000&200!0 49,8,66502,1 i.e. check the flag is set: And here: 14=D66C0 49,8,66502,1 ;vor flag&setting flag 1 -{1: Press=AP_NAV_SELECT_SET }- As documented, the format is: You have the '<size><offset>', but not the '<mask><condition>'

Sorry, was confused by this in my previous response (with another support request...). Yes. that offset should be working. I'll check your ini.... Could you also supply a log file please, with only buttons & keys + Events logged.

Sorry, I wasn't going to, but I would also like to comment on this: I think that is far too strong. We provide documentation to hopefully reduce the time spent on support, which takes away from development, bug-fixing, and other activities that are more productive and useful (and also more interesting) than repeating things said many times and also documented. We don't expect a *thorough* reading (who has time for that with all the software/hardware you need to install these days!), but a quick look to know what's available and a review of the user' manual is always a good idea. Then, use then as needed to help you, depending on your knowledge of flight sims and maybe earlier versions of FSUIPC. And if you have an issue or need more specific information, you should consult the Advanced guide or the specific guides for using lua, PMDG aircraft or offset use. If you can't find anything there, then try a quick search of the forums, and maybe look in the FAQ section, or User Contributions if something extra thats not provided. All we ask is that you try to help yourself first, using the provided resources, before asking. The answer may be deep in the documentation somewhere and not easily found - it is far from perfect I'm afraid....! I have no preference whatsoever on the technical understanding level of the people who post for help. Many people who post here have a far better and deeper understanding of aircraft and aircraft subsytems than I do (or probably ever will), and there are far better lua programmers/experts on here as well. I would certainly never judge a persons technical understanding on what they post, as they are often posting to learn anyway, regardless of ability or previous experience, and am not interested in any qualifications, technical or not, of any poster. John

Hi Peter, sorry, but I think you tried the wrong dll - you used 6.1.1a (22nd April), whereas I would like you to try the latest added to that thread, which was 6.1.1f (2nd May). So before I look in detail at your scripts, could you first try that version, and any issues show me your FSUIPC6.log file again please. Just be be sure, here it is again: FSUIPC6.dll No, as they are not running then.... But if you remove them from the [Auto] section, they aren't running! You should really add them to your [Auto.A2AC172] section - or whatever your A2A profile is called, assuming you have one. If not you should create one and use this. They would then only be started when you load the aorcraft that uses them. Try that dll, but I think there could be various threading/timing issues when starting the lua threads (which then start the coms) then you switch straight away, killing everything to restart. Of course, this is not to say that it shouldn't cause issues killing the scripts and restarting. I will look into this further if needed. John

Yes, but that is for reading. If you check the FSUIPC Offset status document (and column L of the spreadsheet), you will see these offsets are read only and cannot be written to (No in last column): 03C0 64 The current state of the buttons on actively scanned joysticks (local ones, 0 to 15). Each of the 16 DWORDS contain the 32-bit state of the joystick 0-15, in order. Button 0 is the least significant bit (bit 0) in each DWORD. Ok-Intl No So if you want to do that, user a free user offset. Note also that those offsets are only populated for a joystick if/when there is at least one assignment to that joystick, If you mean the G1000, it has/was reported as mostly not working using standard events/controls, although some things may be working now via lvars/hvars. For full functionality, you should look at the Working Title mod for the G1000 (see https://msfsaddons.com/2020/12/06/the-working-title-g1000-mod-greatly-improves-the-glass-cockpit-in-flight-simulator/) Yes, you should use that. Not just for the 128 buttons, but also for the lvar/functionality. It is pretty much complete - I just need to update the documentation (and add a minor fix to event.button for buttons > 32) and will release this officially soon, hopefully at the weekend. You can use the mobiflight events if you like. The events may work in the stock G1000, but still probably better when using the WT mod. Note also that all MF events are based upon activating hvars or setting lvars, which you can do now directly in FSUIPC7 with the FSUIPC WASM module installed. You can install both WASMs (MF + FSUIPC WASMs) if you like and try both methods to see which works for you. You should have a WASM entry under the Add-ons menu, where you first need to activate the WASM functionality (you do this once). Did you select to install the WASM during installation? If so and its not there, please show me your InstallFSUIPC7.log file. Also check your MSFS community folder. FSUIPC7 only adds the Add-ons ->WASM entry if it can see the FSUIPC WASM folder fsuipc-lvar-module in your MSFS Community folder. Update: No OBS at the moment in the WT G1000, and so some people prefer the stock one. See this thread: https://forums.flightsimulator.com/t/release-working-title-g1000-v0-3-updated-to-v0-3-5-on-14-apr/288944/626

No, not yet. I'll take a look at the weekend.

Yes, and that kind of makes sense...I just don't know why it isn't working for some....

Interesting. Did you try using H:AS3000_TSC_Horizontal_BottomKnob_Small_DEC to see if that also works? You can try this using the Add-ons->WASM->Execute Calculator Code function (if its not in your hvar file), using: (>H:AS3000_TSC_Horizontal_BottomKnob_Small_DEC) Strange that it doesn't work for @guit33. I'll take a look but probably not until the weekend. Trying to get the garden in shape this week (as it it has been abandoned the last 6-12 months or so!) so am only covering basic support until next week...

Ok, thanks. Would be useful to know what those are and if they can account for the differences...

But what mods are you using, besides the WT G3000?

You can turn on logging for IPC writes - this will log anything written to offsets via external programs.

If its the MobiFlight commands that are not being executed (i.e. you are assigning in MobiFlight, not FSUIPC), I think you should try the MobiFlight support (or Discord channel) first. Sorry, but I don't use MobiFlight (except the WASM) so cannot advise on this.

Yes indeed... Do you also use a mod for the TBM930, of so, which? Not at the moment - seems strange that the _1.. version works for some, and the one without for others. I can only think that it must be different mods or versions. It makes sense having _1... and _2.. versions for 2 PFDs, as also indicated by @hiddencreative, but I don't understand why this is different for different people unless the mods used are different... I haven't installed the WT G3000 yet, I'll take a look sometime. Maybe the difference is using this with or without the GTC 580 (the touch-screen controller)...