John Dowson

So you are assigning in MobiFlight and not in FSUIPC? How was mobiflight starting your original lua script? Why don't you assign in FSUIPC rather than in MobiFlight? No, this is just not true. Many people are using lua scripts to control encoders perfectly fine with FSUIPC. But if assigning in MobiFlight I cannot help. If you are using MobiFlight, then why are you using lua? I don't know how (or why) you use FSUIPC's lua capabilities via MobiFlight, but I would recommend either using lua via FSUIPC or asking on the MobiFlight discord how you can assign to set lvars in MobiFlight without using lua - I am sure that is possible (using a presetm for example).

What do you mean by this? There are various different pause states (5 in all) - some controls work in some pause states, some not. The pause state indicator at offset 0x0262 whoulc indicate the current pause states: That will depend on the pause state, But FSUIPC is also a SimConnect application and if the sim time is paused then it cannot be changed, unless you are using the active pause state (possibly). I doubt this will be fixed by Microsoft / Asobo as it is not an issue. John

No - it is a free update. Id you gad previously registered, you do not need to re-register - just use the same key file. If you are installing in a separate location for MSFS2024, just copy across your FSUIPC7.key file from the MSFS2020 installation. For all installation and registration issues, please see the provided documentation, both the README.txt and the Installation and Registration manual. John

No, and there won't be any as MakeRwys is no longer supported: John

Yes, as each time the script is ran, it needs to be compiled first. It needs to be auto-ran, but you need to modify the script and assignments first. As you are using ipcPARAM, you could try: function setPitchBug(param) ipc.writeLvar("MJC_VAR_WRITE_VALUE", param) ipc.writeLvar("MJC_VAR_WRITE_CODE", 46987) end event.param("setPitchBug") Have that auto-ran, and change your assignment to use LuaValue <name-of-plugin> together with the parameter (if not using that already). Alternatively, you could remove the assignments in FSUIPC, and use the lua event.button function to handle the rotary buttons and then send the appropriate commands in the handling function for the button press/release event(s). John

Ah, sorry...misread that!

I would need to see the complete lua script to advise. But for performance issues, make sure the lua is always running, i.e. it uses the event library and is not compiled and started each time on a button/key press. Also, to improve lua performance, you should consider setting the LuaAffinityMask ini parameter to move the lua execution threads off of core 0/1. This goes in the [General] section and is a mask of the cores to use - if you are not sure what value to use, you can use this web page to calculate it for you: https://bitsum.com/tools/cpu-affinity-calculator/. For example, I have 6 physical cores, but really 12 as I have hyper-threading (HT) active. To move lua threads off of core 0/1, and use 2-11, I would set LuaAffinityMask=xFFC For rotary encoders that only have one button in each direction, you can also consider using a lua script that gives both fast and slow virtual buttons in each direction, so that you can assign larger inc/dec values on a fast virtual button. Such a script is provided in the example lua plugins. John

I don't expect you to tell me what to do! I need to see your log files....and also attach your FSUIPC7.ini file.

If its working on one PC but not on another, then I would have thought that this implies there is some difference between the PCs that needs to be looked at, not with the software itself...

I have rebuild this now with VS2022 and it will be updated in the next release. John

Is it working when running as admin or not? You said it was but later 'in fact doesn't work...' - why did you think it was initially working? There are no changes from 7.4.18 that should affect add-ons really, except for the change in offset 0x3308 which is what that latest beta version is addressing. Can you activate logging for IPC Reads and IPC Writes and show me the FSUIPC7.log file from both versions and I will take a look. Try and keep the logs as short as possible, i.e. start your software and when it fails or connects, exit FSUIPC7 and attach the logs here. Also any log files from the G-Step software showing the error may be useful. Ok. John

No - that parameter was added in FSUIPC5 and is not available in earlier versions of FSUIPC. John

Presume you mean 7.4.18... id you show me the logs from both versions I can take a quick look to see if there are any issues. But if you want me to help you, you have to answer my questions: ? If you do not want notification when a new version is available, you can set: OpenOnStart=Never See the Advanced User guide for details. John

Are you using the 7.5.1a version, and did you add Init3308=13 to the [General] section of your FSUIPC7.ini file? But if its the G-Step software that isn't working, you should contact their support. I cannot help with that. John

Then the G-Step software must be running as admin. All client applications must run at the same privilege level as FSUIPC.

There is no point adding that line again if its already there, and that is to dix a specific problem - to fix issues with 3rd-party programs that are expecting a value in that offset even when FSUIPC is not connected to the FS (i.e. basically for software not yet updated for MSFS2024). If you get any issues with a new release, you should always raise a new support topic. John

No, no idea - have you tried support from G-Step? There is a change in 7.5.0 that could affect 3rd party software. If such software is reading the FS version at offset 0x3308, then this offset is no longer populated until FSUIPC has connected to the FS, whereas in previous versions this offset was initialised to 13 (the value for MSFS2020). There is a new version available that has a fix for this, available in this post: John

No, this isn't possible, sorry. I tried this previously and it caused a lot is issues as many 3rd party FSUIPC apps also use that link which I have no control over. I understand that there is an issue with browsers caching the download, which is why its better to download from fsuipc.com (which has no-cache directives) rather than the download links in this forum. I have no idea why this would happen - you should raise a support issue for this. John

This is support for FSUIPC, not FeelThere. For FeelThere support, see https://feelthere.com/contact-us-support/ John

👍😎

Can you try the attached version please to see if this helps. For this version, please add the following to the [General] section of your FSUIPC7.ini file: Init3308=13 You can use the value 14 if using MSFS2024, but if using software not updated for MSFS2024 best to stick to 13 regardless of the version of MSFS being used. The value will be updated/overwritten with the correct version anyway once FSUIPC7 connects to MSFS. This will initialize offset 0x3308 to that value (to whatever value is given) on start-up. This should then mimic the behavior in 7.4.18. John FSUIPC7.exe

Yes it is (or button assignments)....you don't need MobiFlight or anything else for this (you can still use MobiFlight if needed). Why don't you just try it? If you don't know how to use FSUIPC, please consult the manuals provided before asking questions here...

To assign to a preset, just check the Select for Preset checkbox in the assignments panel. Then check Find Preset... and navigate to the preset you want to use and select it. John

You can also try logging to see if any event or input event is logged when you operate the switch in the VC. Best to try this with the logging console open (Log->Open Console) and with logging for Events and Input Events activated. You can also try listing the available lvars (Add-ons->WASM->List Lvars) to see if any of those look applicable and if so try those. John

Presumably this is because offset 0x3308 is now only populated after FSUIPC has established a connection with the sim whereas previously it was populated on start-up (as it only ever used to connect t0 MSFS2020). This is most probably due to the same reason. Does it connect if you start the software after FSUIPC has connected to MSFS (when offset 0x3308 is populated)? Have you checked with the software provider to see if an update will be provided for MSFS2024? Also can you please always exit FSUIPC7 before attaching any log files.