John Dowson

Ok, thanks for the update. As I said (or hinted at) in my previous post, I do not know what could be causing such a delay. I will emulate your lua broadcast/server and reception/client scripts here to see if I also get such a delay. However, looking at the lua client script log, it seems that the issue is not with the UDP broadcasts itself (although adding additional logging after the udp2:receive call would confirm this) but is taken up by the vstruct.unpack call: So that is around 3 seconds to unpack the received data....I am not sure why this is so slow...I will investigate, but those are standard lua libraries and not provided by me so i am not sure if anything can be done. I will investigate later this week and report back, as I said. John

Ok...so the server lua is sending the offset changes via a udp socket, which is picked-up by the client and duplicated, and then the offset changes are picked up by the Dlight.lua and the corresponding lvars are set. For @GSaldenwhere this isn't working, I can only assume that this is a network issue and the client is not receiving the broadcasts. Check the host and port are correct in the BCastMemSvr.lua, and that firewalls are either disabled (I know you said they were, but please check again on both client and server PCs, as well as in any routers) or have an exception to allow the host/port to be accessed. You could also try using a different port number. May also be related to your router config - check any UDP related settings there. For @Sky Blue Flyer, where this is working but there is a 4-5 second delay, I don't know what to advise really...not sure what could be causing such a delay in sending/receiving UDP packets. It could be a general UDP issue relating to ARP message exchange, but I am no network expert (maybe try google), Have you thought of switching to TCP instead? One thing that strikes me as strange is that you are using the lights offsets 0x5301 and 0x5303 as unsigned bytes (UB), but have set events and are broadcasting them as unsigned words (UW). Not that this should make much difference...but maybe better to use UB throughout. And I really don't understand why you have this in the [General] section of your FSUIPC7.ini files (both client and server): This is similar to what goes into a [LvarOffsets] section, which adds lvars to offsets for both reading and writing. However, you cannot currently do this for specific bits - but I like this idea and may implement this in a future release. Note that if the lvars were added to the offsets (bits), then you wouldn't need the Dlights.lua as any offset change would automatically trigger the corresponding lvar to be updated. I can't see how this is needed and should be removed - unless you can explain to me what this is doing (and by what)? I don't really have experience in such a set-up and so cannot really advise on this any more at the moment. I will try and duplicate a similar set-up here, with one PC on windows 11 and another on windows 10. However, I cannot duplicate exactly as I only have one license for MSFS, and so would have to run FSUIPC on one PC as a client version, but the lua socket communication between the FSUIPC versions should be the same. I will try and similar offset exchange (broadcast and receive) via UDP to see what delay I experience, and will also try with TCP to see if that gives better performance. I won't have time to do this until later this week though. I will report back once I have done this. John

Sorry - these are available in the link to download. I will take a look... John

Not sure that I understand this... If you are running FSUIPC on both server and client, these are both full instances of FSUIPC with their own offset area and there is no communication between them FSUIPC running on a client PC receives all data via simconnect, as does FSUIPC on the server. I thought the only issue now was that there was a 4-5 second delay when turning the lights on via the client PC, which is not present when done in the server PC. Or maybe this is the issue for @Sky Blue Flyer and @GSalden does not have it working at all on the client? But if FSUIPC7 on the client isn't running, the lights still work in the server? If so, then it is the server PC that is controlling the lights. And I now assume you are also running MSFS on both client and server PCs, no? I am not sure how this type of set-up works... For example, the client and server logs you posted show different numbers of ;vars received: from the server: and from the client: Note that as more lvars are being received after the initial set of lvars is being received, you should increase the LvarScanDelay WASM ini parameter by 5-6 seconds, However, this is only really relevant if the lvars the lua scripts are using need those lvars - if it is the lua scripts that are creating the additional lvars, then no need to increase this delay. And I don't understand what the lvar lines in the [General] section of both client and server ini files is doing - what reads these: ? If something in your set-up is using that, then it should be in a separate file and not in the FSUIPC7.ini file... You also have WideServer running on both the client and server PCs. This is a bad idea - you should only have one copy of WideServer running on a network. I am not sure what will happen with two instances of WideServer running, so maybe disable one of those - or both if not using WideClient (which you shouldn't anyway as you are running FSUIPC7 on both server and clients). Ok, this helps...although it is still not 100% clear. The offset areas in the client and server PCs will be distinct, with each being populated from the MSFS instance it is connected to. And the available lvars are also different and independent on the client and server PCs. I do not know how WidevieW syncs these two instances of MSFS... Maybe you could show me the lua files which would help: BCastMemSvr, BCastMemClient, Dlight, ipcReady (for both client and server, although I assume that this just starts the other lua files). Note also that you can run FSUPC7 in a client PC and have it connect to the server MSFS instance. This is what I assumed you were doing when you said that FSUIPC was running on a client PC. Doing it this way, the lvars (and most offsets, but not user ones) would be the same on both client and server. John

If you gave assigned your throttles in the FS (or elsewhere outside of FSUIPC), FSUIPC may still calibrate the throttles, if instructed to do so. You can remove the calibration by going into FSUIPC's calibration tab and clicking the Reset button in the Throttle calibration sections on page 1 (for general throttle calibration) and page 3 (for separate engine throttles). If you still have issues after this, please show me your FSUIPC .log and .ini files. John

No, you were not instructed to do that - that is the vendor id for Saitek. As I said: The VID for the Honeycomb Bravo is 294B, and the PID is 1901 (as reported in your FSUIPC6.log file). So please try with those. If you still have issues after that, please attach your FSUIPC6.log and FSUIPC6.ini files (and not paste contents). John

I don't want to see anything related to WidevieW. I have said this several times now - FSUIPC and WideClient have nothing whatsoever to do with WidevieW. I have never used this and know next to nothing about it. Please restrict your questions and attached files to those that I need to see, i.e. those relating to FSUIPC and WideFS. Ok, so its either a WidevieW issue, or something related to how WidevieW uses/interacts with FSUIPC? This sounds more like an issue for WidevieW... So there is now no issue apart from the delay? And this is on a client, but the client doesn't use FSUIPC or WideClient, only Wideview? Then this again sounds like an issue for WidevieW. I don't see how I can help here, as the issue is on the client and that isn't using either FSUIPC or WideClient. And id this is present regardless of FSUIPC version, what has changed that has caused this issue? As this set-up seems to be using lvars, it could be related to the delay in initial lvar scan and the automatic re-scan for new lvars, although I doubt this very much if the issue is present regardless of version. You could try with the FSUIPC7 logging console window open (Log -> Open Console), and/or monitor the number of lvars available in the message in the FSUIPC7 main window. If you see this continually increasing, performance issues can be seen if new lvars are continually found amd reloaded - but this should affect both server and clients. For complex aircraft, you may need to increase the WASM ini parameter LvarScanDelay so that more time is allowed before the initial scan for lvars is performed. You can also adjust or disable the time between scans to detect new lvars. See the WASM section in the Advanced User guide for details. But, if the issue is on a client that is not using FSUIPC or WideClient, then I'm not sure I can help. In FSUIPC7 on the server, you can also enable logging for IPC Writes and IPC Reads, and again keep the logging console window open. This may help identifying when any request from an external application (i.e. WidevieW) is received. Interesting. That offset area is actually documented as being assigned to "Mark Hastings B777 Systems Simulator", not that it matters...! You could also monitor those offsets using FSUIPC7's offset monitoring facilities, and send the monitoring to the normal log file. Again, with the logging console window open, you should be able to see when FSUIPC7 receives these requests, and be able to determine where the delay is coming from. I suspect that this is a network issue, or maybe related to anti-virus or firewall software somewhere in the mix... John

Its the same version. You just don't need to register it to use the additional functionality provided by having a license and registering during the installation process. John

What have you tried? I have nothing further to add on the topic of auto-start that is not already in that FAQ entry I have referenced. Please read that carefully and make sure that you fully understand what I have said there. If MSFS is not obeying a correct EXE.xml, then it is an issue for Asobo/MSFS, and that topic also provides an alternative method to start FSUIPC7. I really have nothing more to add to this. and will therefore close/lock this thread. Any posts on auto-start will be referred to that thread as I have nothing more to say about this that has not already been said already. John

You need to check Pilot2ATC requirements to see if that uses the free or registered versions. I doubt very much that it needs the FSUIPC WASM only... I see you have also posted in the trial license topic, so you can try that if the free/unregistered version doesn't work. John

I will provide a new license a day or two after the current license expires, as I always do. John

If you tag him with the @Pete Dowson notation he may respond...I can also ask him to take a look the next time we chat, but I doubt he will remember much from that long ago... He stopped hacking into the dlls over 10 years ago, and many things have changed since then,,, John

Please see the following FAQ entry: Please also search the forum for similar issues before posting a new topic. This saves time for everyone. John

Yes. There is a User Contribution that allows for smooth braking on a single button - see John

What aircraft are you actually using? Is it the Asobo 172 Skyhawk? If so, those won;y work, as they are for the C172 Classic by WB Sim. For the Asobo 172 Skyhawk, the preset for the pedestal is called C172 DIMMING PEDESTAL Knob Set, which uses the following calculator code: @ 15 - 10 / near 0 max 100 min s0 (>L:LIGHTING_PEDESTRAL_1) l0 1 (>K:2:PEDESTRAL_LIGHTS_POWER_SETTING_SET) l2 ! 1 l0 (>K:2:PEDESTRAL_LIGHTS_SET) I adapted this to my axis range (-16284 = + 16384) and created the following preset (in the myevents.txt file): C172 DIMMING PEDESTAL Knob Set#@ 16384 + 32768.0 / 100 * near 0 max 100 min s0 (>L:LIGHTING_PEDESTRAL_1) l0 1 (>K:2:PEDESTRAL_LIGHTS_POWER_SETTING_SET) l2 ! 1 l0 (>K:2:PEDESTRAL_LIGHTS_SET) And then when I assign my axis to that preset, it works to control the pedestal lights. You could try something similar - if you want to do this in lua, you need to build the calc code string from your axis value and use the ipc.execCalcCode function. [Note I have use the @ symbol in my preset code for the parameter placeholder - for the current release, you need to use $Param instead. @ is what MF use and this will be accepted in the next FSUIPC release, 7.3.20, once I get time to release it....) There are similar presets for panels and avionics, but nothing yet for glareshield. However, I created a similar preset for the glareshield, based upon the pedestal one: C172 DIMMING GLARESHIELD Knob Set#@ 16384 + 32768.0 / 100 * near 0 max 100 min s0 (>L:LIGHTING_GLARESHIELD_1) l0 1 (>K:2:GLARESHIELD_LIGHTS_POWER_SETTING_SET) l2 ! 1 l0 (>K:2:GLARESHIELD_LIGHTS_SET) and this also works as expected. John

I know what WidevieW is and does, I just have never used it and do not know anything about the configuration of this software, It is completely independent of FSUIPC and WideFS. What is the "package" you are referring to here? Do you mean the lua scripts, used by WideClient and FSUIPC? Then this sounds like a communication/network issue due to the W11 update, as you are using the same version of FSUIPC7. If the communication issue is with WideClient/WideServer, check those logs. Maybe the workgroup name has changed due to the update? Either way, if its a network error, then the WideClient / WideServer log files should report this. Of course. You don't need the separate WideServer any more, as its part of FSUIPC7. There is no change or difference when running either FSUIPC or WideClient on windows 10 or 11. Any differences encountered after such an upgrade must be due to the upgrade itself. And for which I need to see the files I have requested... John

This indicates that the axis has been registered as a digital on/off axis in your windows registry. To correct this, see the following FAQ entry: Note the FAQ entry is for saitek devices, for the devices this issue was original reported, but can happen to other devices. Just make sure that you use the correct VID and PID numbers/strings for your device. And (always) take a back-up of your registry before editing it. John

Thats strange...I will take a look when I get a chance... I think that it would overcomplicate things considerably to allow two parameters for controls. However, I could possibly allow for this in lua scripts using either ipc.control or possibly a new lua function to distinguish the two (e.g. ipc.control2). I will look into this also, when time permits. John

Not sure what I am supposed to do with that - looks like something to do with WidevieW. I have never used and don't know much about this software, so cannot help with that. I can only help with FSUIPC and WideFS. So you issue started when upgrading windows, not when upgrading FSUIPC7? Or did you upgrade both? Is WideClient connecting ok, or are you saying that you now gave a connectuin issue with WideClient? I am getting confused by this topic, and would like to see the files I requested (i.e. logs, inis and luas) to see what is happening.

But you have them calibrated in FSUIPC7. It was always possible to calibrate axes even when assigned elsewhere, but this functionality was disabled in 7.3.9 due to changes made by Asobo in the SDK. I updated to correct for this problem in 7.3.13. So it is working for you in 7.3.11 as the axes aren't being calibrated in FSUIPC7 in that version. To correct for this in the latest versiin, go into the axis assignment panel, go to the calibration tab, and then remove/reset the calibration for all the axes that you have assigned in MSFS. John

As I said, please read the documentation....

I don't understand why you would expect calculator code to except what is used in xml markup... Its certainly not a viable option, and I am not going to add a warning as I think that would be confusing. It accepts a calculator code string, and if you don't know what a calculator code string is, then you should check the MSFS/Asobo documentation to see what is allowed. I only document the additions to that MSFS allows, which is currently the use of $Param which when used will be substituted with the relevant parameter value, and the next release will also allow the @ character for the same purpose, as this is what the MF presets (for potentiometer input) use. Similarly, it is not up to me to document or explain RPN notation. John

If it is working to your liking, no other suggestions needed - apart from what I have said (i.e. try assigning directly to the rudder trim set axis). But if it is working ok, why not just stick to that, John

No idea - no one has reported this. I am not sure about in FS9 (that is now very old!), but looking at this in FSX & P3D (FSUIPC4-6), this offset holds the simvar SEA LEVEL PRESSURE, and is the barometric pressure at sea level and cannot be set (i.e. read-only), and it is not available in MSFS2020 / FSUIPC7. I suspect that this is the same in FSUIPC3, although that is no longer supported and I don't have the source files to check. Pete retired several years ago and will certainly not be willing to look into anything related to FS9 - I am pretty sure he doesn't even have this any more. I think you would be better off re-directing your question to avsim.com. Regards, John

Then FSUIPC7 will not be auto-started with MSFS, you will have to start it manually by double-clicking the FSUIPC7.exe in Windows Explorer, or create a shortcut to start it from your desktop. Yes you did, as you selected to create the desktop icon. The desktop icon shows the splash screen "preparing the flight cabin" and starts MSFS, not FSUIPC7. It is MSFS that starts FSUIPC7, but only if you select to install this component (auto-start). The "auto-start" component is to auto-start FSUIPC7 when MSFS is started (i.e. when MSFS is started, it is MSFS that starts FSUIPC7), so if you want that then you have to select the auto-start component when you install FSUIPC7. You seem confused about these things - I suggest that you read the provided documentation, starting with the Installation and Registration guide, which will tell you what the various components do. John