John Dowson

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

Log file looks ok and just shows its working in the DHC2. I thought your issue was with the T-28, but you dom'y seem to be providing any of the requested logs for this, or reporting on the other controls I have asked you to try. Btw. you should consider using aircraft substrings for your profile sections rather than the full aircraft name, with livery. Then you won't have to continually have to add your aircraft to a profile if not previously used. For example, you could change: to You also have "DHC2 Beaver N1117F Straight Floats" in your "Single Engine Amphib" profile (as well as your "MilViz DHC2" profile) which you probably want to remove. However, if you do use different profiles for different variants (which seems strange to me!), then you may need to use the full aircraft name, but using substrings is far easier. See the documentation for details in profile substring matching. John

You can only have one parameter to events with FSUIPC. The events with 2 parameters were recently introduced (in the simconnect SDK) and I have not looked into making these available with FSUIPC yet - and am not sure if I will do this at the moment. This may be possible using calculator code - although I am also not sure on how to set two parameters for an event with calc. code either. However, the MF preset for the pedestal lights in the C172 classic uses the following calculator code: @ 655.35 / 0 max 100 min (>K:LIGHT_POTENTIOMETER_6_SET) So this takes an axis value parameter, converts that to a percentage (between 0 and 100) and then uses the LIGHT_POTENTIOMETER_6_SET event. So you could try just using that control instead, i.e. ipc.control(66910, x) where x is the percentage. The glareshield is similar - that uses LIGHT_POTENTIOMETER_5_SET which is ipc.control(66909, x). John