John Dowson

Yes, no point in updating at the moment - there should be another PMDG SDK update within the coming days/weeks and I will fix the offsets with this release (with the publication of the SDK). Any updates/additions after that will be added to new offsets and not affect the PMDG offsets already allocated. John

I have now released a beta version of FSUIPC7 with the PMDG 737 offsets enabled and populated. Please see John

I have now released a beta version of FSUIPC7 with the PMDG 737 offsets enabled and populated. Please see John

I have now released a beta version of FSUIPC7 with the PMDG 737 offsets enabled and populated. Please see John

I have now released a beta version of FSUIPC7 with the PMDG 737 offsets enabled and populated. Please see John

Ah, ok...I thought MSFS would stop programs that it has started once exited...but, thinking about this, FSUIPC7 does monitor for MSFS and shuts itself down when not present, so I guess it starts them but not stops them... You would need to use FSUIPC's facilities for starting this program if you also want it exited when you quit MSFS/FSUIPC7. Its quite straightforward to do this - see the section in the Advanced User guide for details. John

You could check if it is using the standard control by activating logging for Events, open the logging console and flip the switch in the UI to see if anything is logged. You could also try listing the lvars to see if any look appropriate, and if so see if the value of that lvar changes when you flip the switch. This should help determine if there is a standard control or lvar that you can use to control the switch. John

Yes, that sounds correct. The value for this parameter really depends upon what aircraft you are flying (as well as which lvars you are using). For example, in the FBW A320 you need to set to somewhere between 45-60 seconds (or more) to load most/all lvars. The more complex the aircraft, the longer it takes for the lvars to be initialised. If you see that the lvars you are using are not available, you can also either reload the WASM (Add-ons->WASM->Reload) or re-connect to MSFS (MSFS->Disconnect, MSDS->Connect). John

What a strange request... FSUIPC7 is a different product and requires you to purchase a new key, available from SimMarket. This should be obvious... As you have purchased FSUIPC6, you will automatically get a discount which is applied when you checkout. What is 'Jackson Stipe' (the title of your post) - is that your name? Nobody is interested in that..please give your posts an appropriate title. And please search the forum for similar posts before posting. John

Not easily if its not using a standard control/event, which standard event logging would show. You need to delve into the aircraft code - I can't help you with this. I suggest you ask about this (and your aircraft) on the MobiFlight discord channels - someone there may be able to help. John

Please show me your FSUIPC7.ini and FSUIPC7.log files, the latter with logging for Buttons & Keys as well as Events activated. John P.S. No point in posting videos without showing your log and ini files, especially when the videos you post require specific access permissions that are not available without a request...

It will be a timing issue - the lvars you are using were not yet available when the WASM module scanned for available lvars. You need to increase the LvarScanDelay WASM ini parameter (i.e. in the FSUIPC_WASM.ini and not in the FSUIP7.ini). See the Advanced User guide for details - I recommend you set this in an FSUIPC_WASM.ini in the WASM permanent storage area, not in the one under your Community folder as this will get overwritten (again, see the Advanced User Guide for details). John

There are better ways of achieving this...if using a 'wheel' (which presumably has just one button in each direction). then you can use a lua to determine a 'fast' button press or a slow one, and use the trim position offset to increase/decrease by different amounts for a fast and a slow press...there are plenty of topics in this forum on how to do this.. C65607 is the control (C) 65607, which is ELEV_TRIM_UP. BUT button logging is certainly working (and you probably also want to activate Event logging). Please show me/attach your FSUIPC7.log and FSUIPC7.ini files. John

That log is normal - those bold lines indicate the lvar names have been received in the client, and they should be available to use once received. Note that when using the WAPI, you should register for a callback using the function registerUpdateCallback(void (*callbackFunction)(void)) and then only start using the WAPI to access lvars/hvars etc once the callback has been called. This sounds like the lvars are not available when the lvar scan is performed. The scan is performed after LvarScanDelay seconds after the aircraft has loaded. This is a WASM ini file parameter that defaults to 5 (seconds). You can increase this by setting this parameter in your FSUIPC_WASM.ini file - see the Advanced User guide for details. If writing your own WAPI client, you could also check for the existence of all the lvars you are using before you start, and if the lvars are not available you can wait and then reload the WASM, which will re-scan for lvars. The best way of doing this would be first to determine the last lvar that is loaded that you are using - this will be the one with the highest id. You can then check that this lvar has been loaded, by retrieving the id of this lvar using getLvarIdFromName(). If the id is -1, the lvar isn't available, and you should wait/sleep for a short period (e.g. 5s) and then call reload() and check again. Repeat until the lvar id retrieved is not -1 and then continue, or until a certain number of retries have passed without the lvar being found and then exit with an appropriate message. John

Looks ok to me, so I'm not sure why its not loading....are you sure that this is the correct path: C:\Program Files (x86)\NaturalPoint\TrackIR5\TrackIR5.exe ? If so, you could try switching FSUIPC7/TrackIR5 around - I have done this for you in the attached Exe.xml file: EXE.xml If that isn't working, you could try re-installing TrackIR5 into a different non-windows protected folder (and then update the Path in the EXE.xml). Alternatively, you can look into using FSUIPC7 to start TrackIT5 using the FSUIPC7ini file [Programs] section - see the Advanced User guide for details. You can also try starting TrackIR5 from the command line using the same command as in the EXE.xml - this may give you an error message telling you why it can't be started... John

If FSUIPC7 is starting automatically, than that entry must be correct and pointing your FSUIPC7.exe in its installed folder. If that is not the case, just re-run the installer - now your EXE.xml is in the correct format you shouldn't have any issues when you reinstall anymore. John

I just corrected the format of the files - I left the paths as they were specified. Then just change the paths in the EXE.xml file so that the <Path> element is pointing to the correct location for the exe....its not that difficult to understand... John

The trial license has been renewed, now valid until 30th July. John

Yes, of course - did you not take a look? You should, and familiarise yourself with the format so that you can correct if something corrupts it. John

The desktop shortcut should be removed and added again when you re-install. I suspect that things are going astray as you are running the installer from the zip file. You should extract the zip and re-install from the extracted installer - no need to re-register. John

You ran the installer directly from within the zip file. You shouldn't do this as it can cause issues - please unzip/extract before you run the installer. However, the log file you attached shows that you are running a licensed version: Where is it saying that it is not registered when you launch? Do you see the Assignments menu? John

Could you attach your InstallFSUIPC7.log and FSUIPC7.log files please, and let me know your SimMarket order number and I will check here. Thanks, John

Replace that file with the attached. John EXE.xml

Another thing to try, as the button press is sent before the ' Starting everything now' line, is to add an offset condition on the ready-to-fly flag in offset 0x3364. This will be non-zero before everything is started, and 0 afterwards. So add B3364=0 before your assignments, i.e. John

Ok, took a look at the video and I think I understand your issue - it is the initial press being triggered on start-up. I am not sure why this is occurring... FSUIPC usually only reacts to changes in state, so it must be receiving an initial state of 'off', then on the next scan it is on, and so triggers the assignment. Not sure how to prevent this... One thing you could possibly do is have a small lua that is auto-run that sends the control again, i.e. ipc.control(66725, 1) This will then send the control twice (i.e. once from the initial button state, once from the lua), and should so then be in sync with your hardware. Not ideal, I know but maybe worth trying. Otherwise we need to determine why the initial button state is triggering a button change event... John