John Dowson

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

I have tested those in the C510 now and they work perfectly here, so I think you must be doing something wrong. If assigning to a key press, make sure that you have checked No repeats!. Otherwise, you can use logging to see what the problem is. John

Again? Then why post more questions in this topic, which is for assignments in the Mustang. This should not happen - you need to use logging to see why this is happening. Confusing - do you mean that toggle only works in one direction in the C700 Longitude, or in the C510? If you have questions on the C700 Longitude, please find an appropriate topic or create a new one. I will check that toggle in the C510 shortly and report back (can't do it now as it seems my MSFS is now stuck while 'checking for updates'...). As O have said, I am no expert in calculator code, but the 's0' will store the value !(L:LIGHTING_STROBE_1) in register 0, and the s0 will use that, so it looks like two numbers are passed to K:2:STROBES_SET, 1 and !(L:LIGHTING_STROBE_1). That is the conditional test, and when not true it executes '3 (>K:TOGGLE_MASTER_BATTERY)', then always executes ' 0 (>L:XMLVAR_STBYBattery_Test)'. The MSFS documentation on calculator code is now a lot better - see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm and for passing multiple parameters to key events (and simvars with multiple indeces), see https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Simulation_Variables.htm#SimVars Yes, and I am no expert in these matters. FSUIPC just provides access to these features, which are provided by MSFS. Therefore the MSFS documentation should be consulted for calculator code implementation, and the best place to discuss calculator code and presets for various aircraft would be the MobiFlight forums (MSFS2020 channel), not here. Not sure what you mean by 'including'. If you try to write to an lvar that doesn't exist, it will be created. If you try and read from it, then I do not know (and wouldn't expect) if the lvar is created or not - I would expect to read a nil value. But all FSUIPC does is sends any preset/calculator code to the WASM and then executes it. John

Can you disable the starting of the MSFS2020_AutoFPS.exe program and re-test without that being started (just put a ; before the RunIf. I don't expect this to make much of a difference but worth a try. If you get the same performance drop, can you disable the WAPI (Add-ons->WAPI->Disable) and see if that makes any difference. Also try re-starting after this change. Otherwise I have no idea why you get such a drastic drop in FPS. Looks like the main thread use is doing a lot more work. and also the GPU which I don't understand (FSUIPC does not use the GPU) - this may be due to the MSFS2020_AutoFPS.exe program. You could also try moving FSUIPC7 off of the main core, core 1, using the ThreadAffinityMask ini parameter. You would need to calculate the affinity mask to use for your system (online tools available for this). Other than that, I am not sure what I can do about this if this is only affecting the one aircraft. I will take a look on my flight PC to see what the performance is like there later today or over the weekend. John

Ah, ok. Would have been helpful to say that at the start... I would have to check the code for that offset to see that happens if the lvar doesn't exist, but I would think that this is not handled. it just calls the next level function (whatever that is) to get the lvar value and lets that handle the case where it doesn't exist and then just writes the value returned to the offset. I can check the code if needed, but better to just test and see what you get. Ok. But why are you using offsets to read lvar values? If doing this in code, maybe better to use the WAPI API directly (or one of its wrappers) rather than the old FSUIPC SDK. But that is for MSFS only, so I guess if you want compatibility for both FSUIPC6 and FSUIPC7 then you would have to use offsets. John

No. As I said, the MSFS documentation for get_named_variable_value returns 0 when the variable doesn't exist (see https://docs.flightsimulator.com/html/Programming_Tools/WASM/Gauge_API/get_named_variable_value.htm). However, you are not using this function directly, are you ? If you are reading the lvars via lua, the ipc.readLvar documentation (for both FSUIPC7 and FSUIPC6) states: Is that not the case? Otherwise, how are you reading lvars? There are various ways that lvars are read, and what you get when the lvar doesn't exist may depend on the interface you are using. Sorry, but I don't understand why all these questions on something so basic. If things are not working according to the documentation, please provide an example and I will look into it. Otherwise, follow the documentation. John

I just installed and tested this aircraft here (on my development laptop), just sitting on the runway at EGLL and I get a very low framerate for this aircraft - only around 16. If I start FSUIPC, this drops to 13, so I do get a drop of 3fps which is more than expected, but nothing like the 30-40 FPS drop that you see. I will also check on my flight PC later. This aircraft does seem to emit a lot of events when it is just sitting there doing nothing - mainly STEERING_SET, NOSE_WHEEL_STEERING_LIMIT_SET, LIGHT_POTENTIOMETER_SET and various LIGHT_POTENTIOMETER_x_SET events, and it even events like these lights ones that are emitted every 70-80ms or so: And there are about 1600 of these every second. This may account for a drop by a couple of FPS I guess, but no more. Anyway, show me your logs and also test with the MSFS FPS monitor and tell me what you see there (no need for pictures!). Which clients do you use with FSUIPC7? Do you get the same FPS with FSUIPC7 and the client programs you use running as when FSUIPC7 is running but not any client programs? John

This sounds very strange... Is this the new A320Neo Enhanced (free add-on) released in SU15? If so, I haven't installed this yet - will install and take a look here to see if I get the same. Could you show me / attach your FSUIPC7.log and FSUIPC7.ini files. They should be quite small but you will have a very low upload limit as you are new to the forum (it will increase the more you post), so you may need to compress/zip them first. Btw, those pictures are pretty useless - they don't show anything (I can't see what those boxes are never mind read the numbers!). For FPS monitoring, activate the MSFS Display FPS option, under the Debug menu (you need to activate developer tools for this). John