John Dowson

Sorry. but I do not understand your question, and have no idea what SLC is. If you are having a problem installing the FSUIPC WASM module, then please show me your InstallFSUIPC7.log file, and also please show me your FSUIPC7.log file. Note also that if you just want to install the WASM for use with another product, you can download and install the WASM without installing FSUIPC7. The stand-alone WASM module is available here: FSUIPC WASM Module 1.0.4 John

As it states in the FSUIPC Lua Plug-ins document, lua filenames have a limit of 16 characters: Also, FSUIPC scans for valid lua files when oy is started and adds any found to a [LuaFiles] section of your FSUIPC6.ini file. There is no such section in your ini file and so no lua files have been detected. John

I can look into making these offsets writeable, but not sure when I will have time to look into this at the moment. For the time being, why not just use the provided FS controls: I can look into triggering those controls when the offset is written but it will be a week or two before I get time to look at this - I will update this thread once I have taken a look. John

As I said, everything needs to be ran at the same privilege level to connect, and always better to run as non admin - only run as admin if you have to, and of do run EVERYTHING as admin. Why don't you try the support forum for FSRealWX? P.S. I am on holiday now, back next Wednesday the 26th.

Don't think so - and I did ask the OP to check this in my first comment: Strange thing is it was all previously working, so not sure what, if anything, has changed...

The log looks fine - FSUIPC is registered but not WideFS (not required unless you are using WideClient in a separate PC): Is FSUIPC actually running when you see this message? If so, FSRealWX may be tied to a specific version of FSUIPC, but I would find this strange as it also supports FSX and P3Dv2-5 so must certainly work with other versions of FSUIPC.. You could maybe try asking about this on the FSRealWX forums. In the key file - FSUIPC.key (or maybe FSUIPC3.key). I really don't think a windows update could cause this. The way 3rd party programs communicate with FSUIPC is the same way in in all versions of FSUIPC and they are still working... No idea what those are... Those are the FSUIPC files - the application (FSUIPC.DLL), your settings, the log file, the installation log and your key file (registration details). John

You can download FSUIPC7 from fsuipc.com or the download section of this forum: Your key details will be in your SimMarket account (if you have lost your purchase email, where they are also given) - and you can also download FSUIPC7 from your SimMarket purchase/order history, and also the SimMarket App. If you cannot find your key details, let me know your order number and I will send them to you. John

It is better to use ServerName, but with the actual server name and NOT the IP address. You can use ServerIPAddr if you like (with the actual IP address of course, and not the server name!), but you should only use this if you are using fixed ip-addresses for your server, otherwise the IP address can change on router or PC reboot.

But that is wrong! As I said previously, 192.168.22.50 is the ServerIPAddr, not the ServerName. Try changing that to the actual name (better), or switch to using ServerIPAddr if using the IP address and not the actual name. John

I do provide manuals for a reason! Did you also correct the ServerName / ServerIPAddr parameter as well, as mentioned? I am downloading windows 24H2 now anyway... John

The documentation did say that 0.0 would be written if the lvar doesn't exist. This is incorrect, and I have updated this now (for the next release). John

Did you try any of the above? I have tested there now and get the same - a drop of roughly 3fps, so I really can't understand why you are seeing such a drastic drop in FPS when using this aircraft. I also tried switching to use VSYNC (at 50% monitor refresh rate) and I get a steady 30 FPS with or without FSUIPC running. John

Is this the z9b version? If not, please download and install that from There is a note on that version that says: so maybe that is the registration issue... John

No idea what could cause this - maybe check any windows logs. Also check that you are running both applications at the same level - if you are running one with admin privileges and the other without, then they will not connect. I have never used or see FS9 or FSUIPC3 - both way before my time I'm afraid, so I don't think I can help you much. You probably don't need a license anyway if just using to connect a 3rd party app (but I am not sure about this). If you attach your FSUIPC3.log file I can take a look but I am not sure there is anything I can do... John

Presumably the PCs running 24H2 and 21H2 are different PCs, and so will have a different configuration. Did you do what I asked, i.e. check your network configuration, firewalls, workgroup name, etc? Did you read the provided documentation and go through the trouble-shooting steps outlined there? If not, can you please do that first and confirm that you have read and checked the steps outlined in the documentation. This is not correct - the colon should be an equals sign, and that is an IP address and not a server name, and so should be (if that is the correct IP address): ServerIPAddr=192.168.22.50 However, usually better to use the ServerName ini parameter instead unless you are using fixed IP addresses. As I said, I am not running 24H2 yet and will check once it has reached here, but I doubt that this is an issue with this release.

License sent via PM. John

Nothing has changed for this in in FSUIPC... Those offsets use the simvar RECIP ENG FUEL FLOW (indexed by engine) which are documented under Reciprical (Piston) Engine Vars as The following SimVars are only valid for piston engines. For non-piston engines, maybe try offsets 0x2060 and 0x2160 which hold the indexed simvar TURB ENG FUEL FLOW PPH. Otherwise, you need to ask about this on the FBW forums. John

Sorry for the delay. I have checked this here now and can see the problems you are having. I have found the best way to assign the flaps and wing sweep to different axes is as follows: 1. For the flaps, define four ranges for the axis for the 3 distinct positions (the axis itself is unused) - you need the same two ranges for the central position as you are assigning different controls to the Up and Down. My axis is reversed (i.e. shows 16383 at minimum position and -16384 at maximum rather than the other way around) and so my Up/Down assignments will also be reversed compared to normal axis (that goes from -16384 to +16383). I have created 3 ranges: +9000 to +16383: send Flaps Decr when entering from Up (sets Flaps 0 from flaps 4680)) -3500 to +3500: send Flaps Decr when entering from Up (sets Flaps 4680 coming from 9360) -3500 t0 +3500: send Flaps Incr when entering from Down (sets flaps 4680 coming from flaps 0) -16384 to -9000: send Flaps Incr when entering from Down (sets flaps 9360 coming from flaps 4680) These are my resulting ini assignments: 2. Similarly, for the wing sweep you also need to set 4 ranges and assign similarly to the flaps axis but use the wing swee up/down mouse macros: This seems to work pretty well mostly. However, you do get issues if you move the wing sweep axis when the flaps axis is not in the correct position and vica versa, moving the flaps axis when the wing sweep axis is not in the correct position. There is not much you can do about this with these assignments - you could maybe use lua to prevent such issues, but I think there would always be issues if/when your hardware levers mismatch the positions of the levers in the VC. Of course, it is not possible to do this (i.e. move the wing sweep lever when the flaps lever is not in the correct position, and vica-versa) in the VC, but there is nothing to stop you doing this with your own levers, and if you do then this is when mismatch problems can occur. Cheers, John

I thought I had updated this but my comment seems to have gone... Anyway, I checked this and the additional locks were added way back in the 7.4.0 release, so i don't know why things are slower. Looking in more detail, in may not be just the lvar reads. I will look into this further when time permits, but I can't see any changes between 7.4.11 and 7.4.12 that could cause this, except maybe with library updates (the MSFS SDK and the windows VC++ redistiubutable libraries), which I cannot do anything about. John

Not that I know of, and there should not really be any issues with different windows 11 versions - the network protocols used by WideFS should not change on windows updates as this would break many things... Check your network configuration - especially the Workgroup name. Please see the section Configure your Network in the WideFS User guide. Have you tried setting the ServerName or ServerIPAddr parameters, as well as the Protocol? I am still running 23H2 here on my Windows 11 laptop (as well as Windows 10 and Windows 7 on other PCs), so cannot verify with 24H2 at the moment,

Yes - in the offset functionality for lvars, if the lvar doesn't exist, then nothing will be written for read requests and write requests won't be processed either. The result offset is not set to zero as the lvar doesn't have a zero value, and, as I have said, I do not think that lvars can be uninitialized, at least those not created via the Gauge API. I can update the documentation to state the behavior when the lvar doesn't exist. Understood, and thanks for the kind words. John

Go to fsuipc.com and download and install the FSUIPC WASM module, the one with this description: Standalone FSUIPC WASM module. For users who need the FSUIPC WASM module for 3rd party cloents and don't have FSUIPC7 installed. Download, unzip and copy or move the fsuipc-lvar-module folder to your MSFS Community folder.

No, sorry, as you have already requested/used a trial license.

👍

It is actually quite difficult to crash the sim with this bug. The problem was that when certain events are received (i.e. an lvar update), the code wasn't exiting that code block for that specific request and was continuing to process the same data as another event. The behavior (i,e. a crash or something else) after it exits what the event that is processed then would depend on what was in the memory addresses being referenced - in 95% of the cases, this would be rubbish/unintelligible and the additional event processed would not do anything, but if this additional event was processed, meaning that certain data read in the event had certain values that were recognised by this subsequent block of code that processed events, then this could result in either an additional non-requested event happening, or more likely a CTD as the event would be trying to access data in memory addresses not available or allocated. Basically, it only happens occasionally and is very difficult to reproduce, but it was certainly a bug and the one that I think has been causing this issue. Of course, if you still get an issue with this version I will look into it again, but hopefully this updated WASM will fix this. I will probably release this in aa week or so anyway, as it certainly fixes a potential issue. John